1 前言
我们已经完成了metric收集工具类的开发。我们需要通过插件的方式，收集指定metric。部分重要metric 上报给效能平台的监控平台，当达到阀值时，告警，通知开发同学，然后开发同学直接通过日志平台看到更加具体详细的metric信息，帮助我们快速定位接口流量，rt返回慢，tomcat 请求队列积压，以及pod 重启问题。
监控metric收集设计文档地址https://www.jianshu.com/p/930811562fbc
1.0 目前存在情况
* 目前 pod 重启严重， 存活检测是以发请求的形式的检测。如果tomcat 请求堆积。 多次超过pod存活检测的时长，pod 会重启。我们需要监控tomcat 请求队列，线程池等情况
* 目前接口出现请求超时 ， 调用es服务超时。你没有法快速定位到接口，以及获取接口最近1m，5m，15m 实际rt ，tps 。 这对于线上高并发环境，可以快速定位接口
* 当你提供服务的时候，别人需要对你接口的实际运行情况，有个初步了解，比如生命周期内服务接口的99% rt时间在20ms 之内 ，ok ，你这个接口是值得信任的。 如果是1s ，你的接口是需要优化的。
* grafana 数据不准确。队列消费 几千tps变成几十亿。没有提前告警能力
1.1 目前监控平台
主要是以key value 记录metric信息。目前时间维度1分钟级别，选择该平台主要还是因为可以快速告警，后期如果有需要强大图表展示能力，也能快速接入公司的promethues平台
1.2 需要上报的metric-上报监控平台
指标尽量pod级别为主，以高风险指标为主
pod 级别 最近1分钟 tps ，
pod 级别 最近1分钟 99% rt ， max rt ， 平均rt
pod 级别 tomcat 请求队列 收集
java gc 内存相关metric （后期再做）
1.3 需要收集的metric-日志输出
当收到报警，说明已经超过阀值。比如1分钟 99% rt 已经超过1秒，tomcat 请求队列已经出现大量请求堆积。我们需要的是快速定位问题接口，以及方法。
指标以服务接口级别为主，超过固定阀值或者有高风险指标上报时，打印日志。
| 指标作用域 | 指标 | 打印条件 | 备注 |
|---|---|---|---|
| pod 服务方法级别 | 最近15s 99%rt ，max rt ，平均rt | 最近15s 99% 方法rt 超过1s 时打印 warn 级别 | 危险程度高 |
| pod服务生命周期方法级别 | 75%，95，99% rt ，99.9% rt | 每1小时打印一次 info级别 | 作为接口性能评价 |
| pod 级别 | 最近5分钟 tps | 最近5分钟 tps >200 打印warning 级别 | 最近5分钟 pod 负载较高，危险程度低 |
| pod 服务方法级别 | 最近1分钟 tps | 最近1分钟 tps >200 打印warning 级别 | 最近1分钟 pod 方法负载较高，危险程度低 |
| pod 级别 | 最近1分钟 99% rt max rt ， 平均rt | 最近1分钟 pod 级别平均rt>1s warning 级别 | 最近1分钟 pod 级别平均rt>1s 危险较高 |
| pod 级别 | tomcat 请求队列 | 堆积超过100 warning 级别 | 堆积长度超过100个请求，有一定危险度 |
| pod 级别 | tomcat 请求队列 | 堆积超过200 warning 级别 | 堆积长度超过200个请求，危险度高，每分钟打印一次 |
| pod 级别 | 最近1分钟tps ，tomcat 请求队列 | 最近1分钟tps <5 且 tomcat 请求队列>0 | 请求队列有堆积，且tps很低时候 ，通常都是有阻塞发生，容易引起pod重启 |
1.5 与监控平台对接
目前是通过tqmq的方式接入监控预警平台。类似于
metric
key: podIp_1m_tps value: tps
key：podIp_1m_99rt value: rt
监控平台告警阀值，通知都和以前一样。可以每个应用设计独特的告警规则，通知人，每分钟检查等。
1.6 未来开发计划
如果大家用的还挺好的话，希望有更多metric收集上报 ，更丰富的图表展示，可以找我和范锐，我们是大大的欢迎的
网友评论