简介：监控最佳实际 –redis 及业务接口
1. 背景
1.1 问题
2020-12-04，客户侧 redis 集群版监控 DB0 CPU 突增至 100%，导致数据库无奈失常服务，经排查客户侧业务上存在 2M 左右的大 key 导致 DB0 阻塞。并且客户侧应用的集群连贯形式为默认 proxy 模式，如下图所示，DB0 阻塞导致其余节点也无奈失常服务；解决方法：客户侧配合切断大 key 业务的高频繁次调用，申请复原。
图 1：proxy 模式
1.2 思考
此次问题导致客户侧课程报名入口重大受损，进而引发深度思考。在应用 redis 等产品方面的监控报警伎俩不够欠缺，不够认真，并且后续再查看业务日志发现错误率曾经逐步增多，直至 redis 层面体现进去才 get 到问题所在。针对此次 redis 的大 key 问题，给客户提供了对于大 key 以及热点 key 的剖析方法，并倡议欠缺客户侧监控报警的可读性以及业务日志接口的谬误告警。
2. 数据库监控剖析
2.1 redis 监控指标分享
redis 集群版云监控指标如下表所示。
| 监控项 | 单位 | MetricName | Dimensions | Statistics |
|---|---|---|---|---|
| 均匀响应工夫 | us | ShardingAvgRt | userId、instanceId、nodeId | Average、Maximum |
| 连接数使用率 | % | ShardingConnectionUsage | userId、instanceId、nodeId | Average、Maximum |
| CPU 使用率 | % | ShardingCpuUsage | userId、instanceId、nodeId | Average、Maximum |
| 命中率 | % | ShardingHitRate | userId、instanceId、nodeId | Average、Maximum |
| 入方向流量 | KByte/s | ShardingIntranetIn | userId、instanceId、nodeId | Average、Maximum |
| 流入带宽使用率 | % | ShardingIntranetInRatio | userId、instanceId、nodeId | Average、Maximum |
| 出方向流量 | KByte/s | ShardingIntranetOut | userId、instanceId、nodeId | Average、Maximum |
| 流出带宽使用率 | % | ShardingIntranetOutRatio | userId、instanceId、nodeId | Average、Maximum |
| 缓存内 Key 数量 | 个 | ShardingKeys | userId、instanceId、nodeId | Average、Maximum |
| 最大响应工夫 | us | ShardingMaxRt | userId、instanceId、nodeId | Average、Maximum |
| 内存使用率 | % | ShardingMemoryUsage | userId、instanceId、nodeId | Average、Maximum |
| QPS 使用率 | % | ShardingQPSUsage | userId、instanceId、nodeId | Average、Maximum |
| 已用连接数 | 个 | ShardingUsedConnection | userId、instanceId、nodeId | Average、Maximum |
| 内存使用量 | Bytes | ShardingUsedMemory | userId、instanceId、nodeId | Average、Maximum、Sum |
| 均匀每秒拜访次数 | 个 | ShardingUsedQPS | userId、instanceId、nodeId | Average、Maximum |
2.2 redis 大 key 剖析
1. 在控制台抉择对应的实例，进行大 key 及 Hot key 剖析解决。
图 2：实例剖析
2. 利用 API 接口进行剖析大 key 以及 Hot key。
缓存剖析与热点 Key 查问可参考文后材料理解详情[1]。
2.3 数据库同环比监控
创立分组报警规定目前已更新至分组界面。
2.3.1 创立利用分组
图 3：创立利用分组
2.3.2 创立报警规定
图 4：创立报警规定
图 5：设置报警规定
3. 日志监控
利用 sls 接入客户端日志，能够通过设定规定建设仪表盘以及实现报警。此计划日志接入采取 logtail 形式内网传输。
3.1 装置 logtail
装置 logtail 办法可参考文后材料[2]。
3.2 创立 project 和 logstore
登录日志服务控制台，顺次创立对应地区的 project 及 logstore。
图 6：project-logstore 创立
3.3 数据接入向导
此次客户侧日志格局别离为 json、log4j。
3.3.1 json
抉择 json 文本日志 > 抉择现有机器组 > 对应 logtail 配置
图 7：logtail 配置
1. 设置索引
对于多重 json 日志，须要将字段类型更改为 json。
图 8: 设置索引
2. 查问剖析
图 9：查问剖析
3.3.2 log4j
抉择正则文本日志 \> 抉择现有机器组 \> 对应 logtail 配置
1. 正则辨认首行
图 10：设置主动生成
2. 提取字段
图 11: 日志提取字段
3. 设置索引
留神：只对新写入数据失效。
图 12：设置索引
4. 查问剖析
图 13：查问剖析
3.4 日志报警
3.4.1 仪表盘
图 14：仪表盘信息展现
3.4.2 报警
在仪表右上侧导航栏中单击告警，在下拉菜单中抉择创立。
图 15：创立告警
图 16：告警内容设置
对于钉钉机器人的告警内容可参考文后模板 [3] 进行设置。
参考文献
[1] 缓存剖析与热点 Key 查问：https://help.aliyun.com/document\_detail/184226.html?spm=a2c4g.11186623.6.975.255f3635R5By1i
[2] 装置 Logtail（Linux 零碎）：https://help.aliyun.com/document\_detail/28982.html?spm=a2c4g.11186623.2.5.31a09d7cBfTtvl
[3] 钉钉机器人告警模板：https://help.aliyun.com/document\_detail/91785.html?spm=5176.2020520112.0.dexternal.62b334c0S2Jxx2
咱们是阿里云智能寰球技术服务 -SRE 团队，咱们致力成为一个以技术为根底、面向服务、保障业务零碎高可用的工程师团队；提供业余、体系化的 SRE 服务，帮忙广大客户更好地应用云、基于云构建更加稳固牢靠的业务零碎，晋升业务稳定性。咱们冀望可能分享更多帮忙企业客户上云、用好云，让客户云上业务运行更加稳固牢靠的技术，您可用钉钉扫描下方二维码，退出阿里云 SRE 技术学院钉钉圈子，和更多云上人交换对于云平台的那些事。
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。