互联网APP监控即时报警解决最终方案及总结
前言
- 首先描述下公司APP监控的建构，通过agent采集app的request-metrics，jvm-metrics，第三方（mysql-metrics，http-metrics）等指标信息
- 通过thrift协议发送到服务端，push到kafka，最终持久化时序数据库druid。
- 我们alarm系统就是从kafka拉去consumer数据来做流式计算达到即时报警的目的。
初始版本问题
- 由于是按照metrics设计策略，一次只能选择一个metric，同一个app需要设置n策略才能app所有监控，而且产生多个alarm通知，使用体验不好。
- 于是决定把关于app的所有指标维度都聚合在一起。
- 参考alartManager把通知事件进行一个聚合，聚合方案就是30s等待时间，发结果一次通过email发送出去。
指标整理
-
request-metric app本身流量指标
- request 每分请求数
- count5xx 每分500错误数
- count5xxRate 500错误率=总500错误数/总请求数
- costTime 平均响应时间=总响应时间/总请求数
-
http-metric 第三方调用
- request 每分请求数
- count5xx 每分500错误数
- count5xxRate 500错误率=总500错误数/总请求数
- costTime 平均响应时间=总响应时间/总请求数
-
zbrd-metirc 网关域名的流量指标
- request 每分请求数
- count5xx 每分500错误数
- count5xxRate 500错误率=总500错误数/总请求数
- costTime 平均响应时间=总响应时间/总请求数
-
gc-metirc 负载指标
- GC次数 gcCount
- GC时间 gcTime
-
jvm-metirc 负载指标
- 已使用堆内存大小 heapUsed
- CPU使用率 processCpuLoad
- 堆内存使用率 heapUsedRate(新) heapUsed/heap(最大堆内存)
-
jdbc-metrics 连接池
- activeCount 活跃连接数
- activeCount/pooling_values **数（代表在使用的）与连接pool的数（是变化的）的比例Rate，
-
sql-metrics client调用sql 第三方调用
- request 每分Sql执行数
- errorCount 每分Sql执行错误数
- errorRate 执行错误率
- costTime 平均执行时间=总响应时间/总请求数
-
kafka-metrics 集群
- offset-lag (依赖topic group)
- message-in (集群，topic，broker)不做
最终架构方案
- 流式计算的构建采用kafka-stream。
- FilterProcessor主要用于根据策略过滤消息。
- ReduceProcessor主要根据appId对指标做数据聚合，这里我们又采用异步数据聚合（主要考虑每次都与redis通信，IO消耗时间太大）。先聚合在local，再10s轮询同步到redis。
- MatchProcessor主要是聚合数据与策略进行匹配，触发报警。把报警事件推送到kafka来解耦
- alarmEvent处理器主要提供消息持久化，email聚合推送，钉钉等各种渠道推送。
结果总结
1. 结果
- 处理的上报数据量日均在682百万以上。
- 报警行为延迟在10s内，主要来自agent推送，轮询到分布式cache。
- 处理数据会随着公司app增加而增大，横向扩展能力强。
2. 价值结果
- 技术价值很好的一个实时流式计算，聚合业务指标的案例落地。在现代业务系统中越来越多Lambda架构数据系统。
- 业务价值，报警系统是app监控系统一个重要组成部分，是公司服务可用性的基础组件。
界面展示
1.创建策略界面
2.钉钉报警通知
3.email报警通知