前言

1. 首先描述下公司APP监控的建构，通过agent采集app的request-metrics，jvm-metrics，第三方（mysql-metrics，http-metrics）等指标信息
2. 通过thrift协议发送到服务端，push到kafka，最终持久化时序数据库druid。
3. 我们alarm系统就是从kafka拉去consumer数据来做流式计算达到即时报警的目的。

初始版本问题

1. 由于是按照metrics设计策略，一次只能选择一个metric，同一个app需要设置n策略才能app所有监控，而且产生多个alarm通知，使用体验不好。
2. 于是决定把关于app的所有指标维度都聚合在一起。
3. 参考alartManager把通知事件进行一个聚合，聚合方案就是30s等待时间，发结果一次通过email发送出去。

指标整理

1. request-metric app本身流量指标

   • request 每分请求数
   • count5xx 每分500错误数
   • count5xxRate 500错误率=总500错误数/总请求数
   • costTime 平均响应时间=总响应时间/总请求数

2. http-metric 第三方调用

   • request 每分请求数
   • count5xx 每分500错误数
   • count5xxRate 500错误率=总500错误数/总请求数
   • costTime 平均响应时间=总响应时间/总请求数

3. zbrd-metirc 网关域名的流量指标

   • request 每分请求数
   • count5xx 每分500错误数
   • count5xxRate 500错误率=总500错误数/总请求数
   • costTime 平均响应时间=总响应时间/总请求数

4. gc-metirc 负载指标

   • GC次数 gcCount
   • GC时间 gcTime

5. jvm-metirc 负载指标

   • 已使用堆内存大小 heapUsed
   • CPU使用率 processCpuLoad
   • 堆内存使用率 heapUsedRate(新) heapUsed/heap(最大堆内存)

6. jdbc-metrics 连接池

   • activeCount 活跃连接数
   • activeCount/pooling_values 激活数（代表在使用的）与连接pool的数（是变化的）的比例Rate，

7. sql-metrics client调用sql 第三方调用

   • request 每分Sql执行数
   • errorCount 每分Sql执行错误数
   • errorRate 执行错误率
   • costTime 平均执行时间=总响应时间/总请求数

8. kafka-metrics 集群

   • offset-lag (依赖topic group)
   • message-in (集群，topic，broker)不做

最终架构方案

1. 流式计算的构建采用kafka-stream。
2. FilterProcessor主要用于根据策略过滤消息。
3. ReduceProcessor主要根据appId对指标做数据聚合，这里我们又采用异步数据聚合（主要考虑每次都与redis通信，IO消耗时间太大）。先聚合在local，再10s轮询同步到redis。
4. MatchProcessor主要是聚合数据与策略进行匹配，触发报警。把报警事件推送到kafka来解耦
5. alarmEvent处理器主要提供消息持久化，email聚合推送，钉钉等各种渠道推送。

结果总结

1. 结果

1. 处理的上报数据量日均在682百万以上。
2. 报警行为延迟在10s内，主要来自agent推送，轮询到分布式cache。
3. 处理数据会随着公司app增加而增大，横向扩展能力强。

2. 价值结果

1. 技术价值很好的一个实时流式计算，聚合业务指标的案例落地。在现代业务系统中越来越多Lambda架构数据系统。
2. 业务价值，报警系统是app监控系统一个重要组成部分，是公司服务可用性的基础组件。

界面展示

1.创建策略界面

2.钉钉报警通知

3.email报警通知