告警平台方案调研

本文是关于告警平台的能力以及方案，设计思路的调研

数据源

阿里监控系统 Sunfire

操作系统，JVM，中间件等，大多数业务的监控指标都从应用的日志中抽取。

腾讯天网

主动：所有的业务开发出来的应用程序，在上线之前能够按照运维的要求，或者自身对代码质量的监控，提前做好了很多埋点。
被动：一种从外部探测而非自主上报的被动行为。
旁路：舆情监控等跟第三方的对比数据，来间接的反应我们外网服务的真实情况

衡量监控点

请求量、成功率、延时

全链路监控

数据上报

运营开发更专注于对Storm逻辑的一些封装，专注于原始数据的高效加工处理，然后，告诉数据消费者（运维）有什么样的数据，在数据银行中提供了哪些数据的类型，提供了哪些丰富的接口，所有产品化的工作都是由运维来实现的。

腾讯SNG全链路日志监控平台

腾讯SNG全链路日志监控平台之构建挑战

全链路日志监控平台提供了4种数据格式支持，分别是分隔符、正则解析、json格式和api上报：

分隔符、正则解析和json格式用于非侵入式的数据采集，灵活性好。但是服务端的日志解析性能较低，分隔符的数据解析只能做到 4W/s 的处理性能。而api方式则能达到 10W/s 处理性能。对于内部业务，我们推荐采用统一的日志组件，并嵌入api上报数据。

腾讯运维

每天5万条告警，腾讯如何做到“咖啡运维”？

腾讯监控业务发展时间轴：

基础指标监控，每家都有，我们也一样。
自动化测试模拟监控，我们通过模拟用户请求的方式来对我们的服务进行播测发现问题。
模块间调用质量监控，在我们的监控里是非常重要的体系，它是由服务的调用数据上报到后通过各种运算，来反应服务调用成面的监控。
测速与返回码统计，下图是直接由用户端报给我们的各种数据，其实这些监控特别多，我前面提到的有一大半都是干这些事的，大家一看也能看懂，都很熟悉。

腾讯蓝鲸数据平台之告警系统

拨测：定时curl一下某个url，有问题就告警。这个是走原数据=>直接录入为异常=>告警
日志集中检索：ELK的经典用法。走原数据=>检索库
日志告警：5分钟Error大于xxx次告警。走原数据=>实时统计出指标=>检测异常=>告警
指标告警：cpu使用率大于xxx告警。走原数据=>录入到指标库=>检测异常=>告警

一般来说简单来说可以分为四层：

产品策略和营销：它们决定了根本的请求到达的速率
应用层（更粗俗一点可以叫web层）：最上层的胶水
服务层：db，各种RPC服务，以及层层嵌套的服务
硬件层：cpu，内存，磁盘，网络

架构

传统的日志监控，现在大多数监控平台采用的一个方案。Agnet 检测日志变化增量推送，经过消息中间件如 kafka，流式计算引擎如 Jstorm/flink 去消费 kafka 产生出来的数据，中间的流式计算可能有多步的处理，最后流向 DB，很传统的架构。

这个架构最麻烦的是我不知道什么时候数据已经全部到齐了。如果机器很多，agent 返回数据的时间并不确定, 要保证所有机器日志采齐了数据才准确，这在流式计算里很难处理。

解决方案参考

1 2	https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101 https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102

阿里监控系统 Sunfire

功能结构

阿里万亿交易量级下的秒级监控

架构

有三个角色 Brain、Reduce 和 Map。这三个角色我们统称为计算模块。

onfigDB 里面配置了监控项。监控项会定义配置需要从哪个应用、哪个路径采集日志、采集回来的日志应该做哪些的处理、根据什么样的规则进行计算。Brain 会按照周期从 ConflgDB 里读取配置，生成拓扑。然后安装到 Reduce 上面，Reduce 把拓扑再分解成它的子任务，再安装到 Map 上面，最后 map 去拉日志。

阿里妈妈 Goldeneye

Goldeneye监控系统的四个输入：实时监测数据、历史数据、预测策略、报警过滤规则。

预测策略主要包括：

阈值参数：设置基于预测基准值的系数决定阈值上下限区间、分时段阈值预测系数、分报警灵敏度阈值预测系数；
预测参数：样本数量、异常样本过滤的高斯函数水位或者过滤比例、基于均值漂移模型的样本分段选取置信度等。

报警过滤规则：

主要是为了在充分捕捉疑似异常点的前提下，过滤不必要的报警。比如指标M1异常，但是组合规则是M1和M2同时异常才报警，这种就会过滤掉。

再比如，按照报警收敛规则，一个监控项的第1次，第2次，第10次，第50次连续报警值得关注

架构演进

阿里Goldeneye业务监控平台之架构演进，如何实时处理100T+/天的日志量？

总结是：

从每个业务线单独开发逻辑，部署任务，自己写拿 Hbase 数据，解析日志，等逻辑；到封装 write、join、topN 逻辑给开发人员调用；到开发人员写 SQL 语句，通过解析 SQL 来实现逻辑

腾讯运维

每天5万条告警，腾讯如何做到“咖啡运维”？

去阈值

我们在成功率上使用了统计学的方式，设一个成功率的滑动窗口，利用环比同比数据通过 3Sigma 算法计算出一个动态率值区间，只要超出这个区间就认为 DLP 出现了问题。

AIOps

文本 + NLP：比较有特点的产品叫舆情监控，还有智能对话机器人这部分。
预测 / 判问题：基于在线预算量、预测未来等等相关的比较多，基本上是基于时间序列。
信息收敛问题
根因分析
根源分析

并发

阿里妈妈 Goldeneye

参考阿里Goldeneye业务监控平台之架构演进，如何实时处理100T+/天的日志量？这篇文章

监控

阿里妈妈 Goldeneye

对于业务监控人工维护阈值就比较复杂，需要有丰富的经验来拍定阈值，需要人工持续的维护不同监控项的监控阈值。所以，在业务快速发展的前提下，传统的静态阈值监控很容易出现了误报、漏报的问题，而且人工维护成本高

智能监控就是让系统在业务监控的某些环节上代替人工执行和判断的过程。人工维护监控目标和阈值是以经验为参考的，系统如何自动判断哪些目标需要监控、自动设定监控目标的阈值水位、不用人力维护，是基于对历史样本数据统计分析得出判断依据。

发现异常点

让程序自动对监控项指标的基准值、阈值做预测，在检测判断异常报警时使用规则组合和均值漂移算法，能精确地判断需要报警的异常点和变点。

以往做法：

给指标M1设置一个水位线，低于（或高于）水位，触发报警；
给指标M1设置同比、环比波动幅度，比如同比波动20%、环比波动10%触发报警；

Goldeneye 做法：

动态阈值

动态阈值是为控制图的时间序列每个点，预估该点对应时刻这个指标的基准值、阈值上限、阈值下限，从而让程序可以自动判断是否有异常

变点检测

就是持续微量下跌到一定时间，累积变化量到一定程度后，使得变点前后监测指标在一段时间内的均值发生漂移。

变点检测弥补了动态阈值对细微波动的检测不足，这两种方式结合起来，基本可以达到不漏报和不误报的平衡

辅助定位

全链路tracing：全链路分析有两种数据记录方式，要么链路每个节点内部透传，拼接成完整链路处理信息记录到最终的节点日志；要么异步地每个节点各自将信息push到中间件

报警时间点上发生了什么：把运维事件、运营调整事件尽可能地收集起来，将这些事件地散点图和监测报警的控制图结合起来

时间序列平稳化

滑动平均：比如波动锯齿明显，容易造成误报干扰的化，则加大监控监测周期，将5分钟提高到30分钟
持续报警判断：如果觉得30分钟发现问题会比较晚，可以按5分钟检测，锯齿波动容易发生报警，但可以连续3次报警再发通知

监控项自动发现

判断如何筛选监控项的规则交给系统，让它去定期检查哪些监控项已经实效，哪些监控项需要新增，哪些监控项的阈值需要调节。

过滤误报

对误报case欲擒故纵，在首先确保不漏报的基础上降低误报率。

这一环节我们基于动态阈值去检测时相对严格一些（或者说这一环节不用考虑报警收敛的问题），然后对这些疑似异常点再做验证、过滤，最终生成报警通知，验证和过滤的依据是预先定义的规则，比如指标组合判断、报警收敛表达式等。

腾讯天网

腾讯亿万量级告警是如何做到全、准、快的？

ROOT智能监控系统

我们的DB挂了，会层层往前推，我们的逻辑层、接入层、负载均衡，甚至到我们的用户端报上的成功率都会受到影响。

但是运维并不希望收到这N个现象告警，我们希望把DB宕机的根源告警发出来，其他告警都收敛掉。

基于我们的业务拓扑图，根据时间的相关性，把告警都叠加在链路上，把一些不需要关注的点都过滤掉，最后得到一个经过经验分析的模型。

里面包括了：降维策略、时间相关性分析、权重面积分析，具体可以参考文章内容

腾讯SNG全链路日志监控平台

腾讯SNG全链路日志监控平台之构建挑战

系统自动容灾和扩缩容

为做到系统自动容灾和扩缩容，第一步是将模块做无状态化设计。比如系统的接入模块、解析模块和处理模块，这类无需状态同步的模块，可单独部署提供服务。

但对这类无状态业务模块，需要增加剔除异常链路机制。也就是数据处理链路中如果中间一个节点异常，则该节点往后的其他节点提供的服务是无效的，需要中断当前的链路。异常链路剔除机制有多种，如通过zk的心跳机制剔除。

有状态的服务通常是存储类服务。这类服务通过主备机制做容灾。如果同一时间只允许一个master提供服务则可采用zk的选举机制实现主备切换。

数据通道的容灾

我们采用两种机制：双写方式和消息队列。

对于数据质量要求高的监控数据，采用双写方式实现。这种方式要求后端有足够的资源应对峰值请求。提供的能力是低延时和高效的数据处理能力。
对于日志数据采用具备数据容灾能力的消息队列实现。使用过的选型方案有kafka和rabbitmq+mongodb。

数据在接入层按1万条或累积30s形成一个数据块。将数据块随机写入由多个mongodb实例构成的集群。

查询

全链路上报的数据按用户ID或请求ID作为主key进行hash分片。分片后的数据在缓存模块累积1min或1M大小，然后写入文件服务器集群。文件写入集群后，将hash值与文件路径的映射关系写入ElasticSearch。

第一类是按主key查询。查询方式是对待查询key计算hash值，从ES中检索出文件路径后送入查询模块过滤查找；
第二类查询能力是非主key的关键字查找。根据业务场景，提供的查询策略是查询到含关键字的日志即可。该策略的出发点是平衡查询性能，避免检索全量文本。也就是第一次查询1000个文件，如果有查询结果则停止后续的查询。