《Flink 实战与性能优化》—— 基于 Flink 的实时监控告警系统

在如今微服务、云原生等技术盛行的时代,当谈到说要从 0 开始构建一个监控系统,大家无非就首先想到三个词:Metrics、Tracing、Logging。

12.3.1 监控系统的诉求

国外一篇比较火的文章 Metrics, Tracing, and Logging 内有个图很好的总结了一个监控系统的诉求,分别是 Metrics、Logging、Tracing,如下图所示。

监控系统的诉求

Metrics 的特点:它自己提供了五种基本的度量类型 Gauge、Counter、Histogram、Timer、Meter。

Tracing 的特点:提供了一个请求从接收到处理完毕整个生命周期的跟踪路径,通常请求都是在分布式的系统中处理,所以也叫做分布式链路追踪。

Logging 的特点:提供项目应用运行的详细信息,例如方法的入参、运行的异常记录等。

这三者在监控系统中缺一不可,它们之间的关系是:基于 Metrics 的异常告警事件,然后通过 Tracing 定位问题可疑模块,根据模块详细的日志定位到错误根源,最后再返回来调整 Metrics 的告警规则,以便下次更早的预警,提前预防出现此类问题。

12.3.2 监控系统包含的内容

针对提到的三个点,笔者找到国内外的开源监控系统做了对比,发现真正拥有全部功能的比较少,有的系统比较专注于 Logging、有的系统比较专注于 Tracing,而大部分其他的监控系统无非是只是监控系统的一部分,比如是作为一款数据库存储监控数据、作为一个可视化图表的系统去展示各种各样的监控数据信息。

拿 Logging 来说,开源用的最多最火的技术栈是 ELK,Tracing 这块有 Skywalking、Pinpoint 等技术,它们的对比如 APM 巅峰对决:Skywalking PK Pinpoint 一文介绍。而存储监控数据的时序数据库那就比较多了,常见的比如 InfluxDB、Prometheus、OpenTSDB 等,它们之间的对比介绍如下图所示。

常见时序数据库对比

监控可视化图表的开源系统个人觉得最好看的就是 Grafana,在 8.2 节中搭建 Flink 监控系统的数据展示也是用的 Grafana,当然还可以利用 ECharts、BizCharts 等数据图表库做二次开发来适配公司的数据展示图表。

上面说了这么多,这里笔者根据自己的工作经验先谈谈几点自己对监控系统的心得:

  1. 告警是监控系统第一入口,图表展示体现监控的价值:告警是唯一可以第一时间反映运行状态,它承担着系统与人之间的沟通桥梁,通常告警消息又会携带链接跳转到图表展示,它作为第一入口并衔接上了整个监控系统。
  2. 数据采集是监控的源泉:数据采集是监控系统的源泉,如果采集的数据是错误的,将导致后面的链路(告警、数据展示)全处于无效状态,所以千万千万要保证数据采集的准确性和完整性。
  3. 数据存储是监控最大挑战:当机器、系统应用和监控指标等变得越多来多时,采集上来的数据是爆炸性增长的,将海量的监控数据实时存储到任何一个数据库,挑战都是不小的。

说完心得再来讲解到底一个监控系统真正该包含哪些东西呢?笔者觉得首先分 6 层:数据采集层、数据传输层、数据计算层、告警、数据存储、数据展示,如下图所示。

监控系统分层

监控系统这六层的主要功能分别是:

  • 数据采集层:该层主要功能就是去采集各种各样的数据,比如 Metrics、Logging、Tracing 数据。
  • 数据传输层:该层主要功能就是传输采集到的监控数据,一般使用消息队列居多,比如 Kafka、RocketMQ 等。
  • 数据计算层:该层的主要功能是将采集到的数据进行数据清洗和计算,一般采用 Flink、Spark 等计算引擎来处理。
  • 告警:该层其实也属于数据计算层,但是因为告警涉及的内容太多,比如告警规则、告警计算、告警通知等,所以可以单独作为一个重要点来讲。
  • 数据存储层:该层的主要功能是存储所有的监控数据,为后面的数据可视化提供数据源。
  • 数据展示层:该层的主要功能是将监控数据通过可视化图表来展示出来,通过图表可以知道服务器、应用的运行状态。

12.3.3 Metrics/Tracing/Logging 数据实时采集

在 12.1 节中讲解了日志数据如何采集,那么对于 Metrics 和 Tracing 数据该怎么采集呢?

Metrics

Tracing

12.3.4 消息队列如何撑住高峰流量

RabbitMQ

Kafka

RocketMQ

12.3.5 指标数据实时计算

12.3.6 提供及时且准确的根因分析告警

告警本质

告警通知对象

告警通知方式

告警规则的设计

根因分析告警

告警事件解耦

告警工单记录告警解决过程

12.3.7 AIOps 智能运维道路探索

12.3.8 如何保障高峰流量实时写入存储系统的稳定性

12.3.9 监控数据使用可视化图表展示

Grafana 介绍

12.3.10 小结与反思

加入知识星球可以看到上面文章:https://t.zsxq.com/IeAYbEy

本章总结

本章讲了三个公司常见场景案例:日志处理、去重、监控告警。在日志处理案例中讲解了日志的采集的需求,以及分析了整个日志采集案例的架构设计分层,关于日志采集工具的选型在 11.5 节中有讲过,所以该案例中就直接讲述采集工具的使用和安装,并将采集到的数据发送到 Kafka,然后使用 Flink 清洗日志数据并将异常日志告警通知到相应负责人,接着将数据写入到 ElasticSearch,最后通过 Kibana 可以展示和搜索日志数据。

在百亿数据实时去重案例中通过对比通用解决方法、使用 BloomFilter、使用 HBase 和使用 Flink KeyedState 几种方案来分析实时去重的解决方案,并在该案例中还提及到如何去优化去重的效果。

在实时监控告警案例中讲述了公司通用的监控告警需求,包括 Metrics、Logging、Tracing,然后设计出整个监控告警系统的架构分层和技术选型,其中分层包含数据采集层、数据传输层、数据计算层、数据存储层、数据展示层。关于数据采集工具、消息队列、数据存储中间件、数据展示的技术选型,笔者也分别做了对比介绍,以便大家可以根据自己公司的情况做架构选型。另外针对实时告警这块,笔者也详述了很多,包括告警规则的设计、告警通知对象、告警通知方式、告警消息收敛、告警消息根因分析等,最后还讲了对监控告警的展望,希望能够在 AIOps 做更多的探索,对于这块的内容,笔者在社区钉钉群做过视频直播,大家可以去笔者的博客查看录播的视频。

×

纯属好玩

扫码支持
扫码打赏,你说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦

文章目录
  1. 1. 12.3 基于 Flink 的实时监控告警系统
    1. 1.1. 12.3.1 监控系统的诉求
    2. 1.2. 12.3.2 监控系统包含的内容
    3. 1.3. 12.3.3 Metrics/Tracing/Logging 数据实时采集
      1. 1.3.1. Metrics
      2. 1.3.2. Tracing
    4. 1.4. 12.3.4 消息队列如何撑住高峰流量
      1. 1.4.1. RabbitMQ
      2. 1.4.2. Kafka
      3. 1.4.3. RocketMQ
    5. 1.5. 12.3.5 指标数据实时计算
    6. 1.6. 12.3.6 提供及时且准确的根因分析告警
      1. 1.6.1. 告警本质
      2. 1.6.2. 告警通知对象
      3. 1.6.3. 告警通知方式
      4. 1.6.4. 告警规则的设计
      5. 1.6.5. 根因分析告警
      6. 1.6.6. 告警事件解耦
      7. 1.6.7. 告警工单记录告警解决过程
    7. 1.7. 12.3.7 AIOps 智能运维道路探索
    8. 1.8. 12.3.8 如何保障高峰流量实时写入存储系统的稳定性
    9. 1.9. 12.3.9 监控数据使用可视化图表展示
      1. 1.9.1. Grafana 介绍
    10. 1.10. 12.3.10 小结与反思
    11. 1.11. 本章总结