从全链路追踪到云监控实时报警再到报警聚类总结

背景

• 曾经，我们是这样解决问题的：
  我们不知道故障范围有多大——是客户投诉告诉我们的;
  我们不知道到底是什么故障——是事后一点一点排除各个环节的嫌疑推理
  出来的;

• 曾经对于线上出现的Exception，掣肘于各种原因，只能T+1查看异常汇总

  
  image.png

• 曾经在各个工程中发现业务异常后，需要提供各种参数给服务端排查问题，才能最终定位到原因，是因为服务端出现某个异常所以导致客户端超时了。排查线上问题，无法做到一目了然、实时。

鉴于上面所遇到的问题，我们采取了几个措施：

1. 工程引入基于OpenTracing标准的全链路追踪
2. 对全链路采集的日志数据采用flink进行实时计算分析
3. 针对链路日志的分析结果进行实时报警、提取故障报告及生成系统诊断的异常聚类报告

目标

• 对线上系统异常做到先知先觉，一旦发生问题，实时报警。由上而下、由内而外的输出问题原因及应对策略，
• 每一次报警都能够一览到底，从web端，到各个中心center，到数据库，到redis每一个环节展示的清清楚楚，一看便知本次请求哪个环节出了问题
• 对一段时间内的报警进行聚类汇总，将同一原因引起的报警进行聚合，最终形成几条报警摘要，使得对一段时间的问题有个统筹反馈

设计

链路追踪 Tracing Analysis

使用了阿里云提供的链路追踪产品。客户侧的应用程序通过集成链路追踪的多语言客户端 SDK 上报服务调用数据。此处采用了jaeger的客户端进行数据采集。鉴于以下两个问题
①自己提供存储维护成本问题
②针对链路数据的分析问题
我们的实现方案如下：

image.png

链路数据采集技术方案如下：

image.png

实时分析——云监控系统

实时分析主要依赖于阿里云日志服务提供的实时消费功能。
根据对链路数据的分析，我们提供了云监控系统。

image.png

报警聚类

通过对全链路数据的修剪，我们可以提炼出每一次请求异常的根因，即我们提供的每次请求的RCA报告，鉴于此，我们只需要对每次请求的RCA进行聚类分析即可得到最终的异常报警聚合报告。

image.png

效果

实时报警

• 钉钉实时报警

  
  image.png

• 短信实时报警

  
  image.png
  image.png

异常聚类

image.png