架构师配置稳定性监控中遇到的坑

稳定性三大指标.

   1.请求量 2.耗时 3.异常.

日志规范:

    入口日志通过filter打印

报警配置基本规范:

 

1. 请求量和耗时的同比
2. 异常量的绝对值
3. 环比也要监控.
4. 核心接口大盘,人工观察
5. 总量肯定多的,监控宕机类问题.
6. 细分到服务器级别. 
7. 异步后接口级无用,需要监控error

报警坑:

 

1. 入口日志中异常通过业务字段是否会空来表征
2. 报警监控要有请求量限制
3. 报警分组没有考虑某台机器,结果机器挂了. 拒绝服务. 上游不报警,本地就不知道了.
4. 报警分组考虑了机器, 由于有请求量限制. 对于低流量请求的请求量降低也不报警. 这个需要N次间隔汇总和>限制.
5. 报警分组考虑了机器, 由于有请求量限制. 如果遇到宕机严重问题,也只报警一点时间. 从而导致无人发现. 这个需要有个业务心跳机制. 需要有两台心跳发起机器. 或者核心大流量的接口专门配置报警监控,他也有低峰期. 监控系统配置 1. 历史的流量>100 不管现有流量多少. [如果刚好两周的同一时间异常,那就有问题了] 故环比也有监控.
6. 监控没那么智能,核心的流程要通过大盘,肉眼观察,一周曲线.

报警review:

 

1.  有些异常,会导致无日志,能否监控到. 例如 1. 机器宕机 2.filter之上的异常,线程池占满.
2. 一台机器的进程,线程池占满(ping,进程,监听都ok),整体接口流量ok.