监控告警

 

监控系统三要素
Metrics 的特点：它自己提供了五种基本的度量类型 Gauge、Counter、Histogram、Timer、Meter。
Tracing 的特点：提供了一个请求从接收到处理完毕整个生命周期的跟踪路径，通常请求都是在分布式的系统中处理，所以也叫做分布式链路追踪。
Logging 的特点：提供项目应用运行的详细信息，例如方法的入参、运行的异常记录等。

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

 

检测算法
基础性能类指标，一般选择静态阈值检测算法。
触发条件
时序类指标(CPU、内存等)的检测周期默认为采集周期，事件类告警为分钟（事件类告警无固定的采集周期）。
建议 : 默认选择5个周期满足N次检测算法 （1）抖动类的指标如CPU总使用率，N可选择3；非抖动类的如磁盘使用率，N可选择1。 （2）为告警收敛的恢复检测做准备。比如5分钟内满足2次检测算法，则恢复检测的触发条件是检查前5个周期满足少于2次检测算法。

 

告警状态
一旦这些警报存储在Alertmanager，它们可能处于以下任何状态：
Inactive：这里什么都没有发生。
Pending：已触发阈值，但未满足告警持续时间（即rule中的for字段）
Firing：已触发阈值且满足告警持续时间。警报发送到Notification Pipeline，经过处理，发送给接受者。
这样目的是多次判断失败才发告警，减少邮件。

 

告警收敛手段：
分组（group）：将类似性质的警报分类为单个通知
抑制（Inhibition）：当警报发出后，停止重复发送由此警报引发的其他警报
静默（Silences）：是一种简单的特定时间静音提醒的机制

 

告警收敛：告警产生后状态未恢复，N小时内不再产生告警
场景：一段时间内持续满足告警的触发条件，容易出现告警风暴，将邮箱塞满。
方案：如果告警持续产生，但未恢复，则一段时间内仅通知1次
告警恢复检测：和告警检测条件相反，例如触发条件为“5个周期内，满足3次检测算法”，则 告警恢复检测的触发条件是“当满足触发条件时，会检查是否满足 前5个周期少于3次检测算法"
告警产生后状态未恢复，24小时内不再产生告警
告警产生后状态未恢复，0小时内不再产生告警：表示满足触发条件将直接发出告警，不再收敛。
持续产生数据，突然不上报数据时，则产生无数据告警
若上报数据不连续，则不建议开启。

 

 

告警模块

1.轮询式告警
业务方配置好需要告警的接口、阈值和告警方式，我们通过crontab运行一组脚本，定期扫描存储中的相关指标，满足条件即触发告警
存在以下几个问题
延迟:从存储中轮询指标，这意味着已经有了一段时间的延迟。
灵活性差:系统是动态发展的，业务量在不断增长，固定的规则，阈值很难适应这种情况，网络抖动引起的短暂异常也会引发大量的误报。

2.流式告警
一方面，虽然还少不了有一些人工培植告警的工作，但已经可以根据推送数据自动提取告警规则，在很大程度上简化了告警配置；
另一方面，告警数据不再存储，而是经过流式计算后存入redis队列，满足阈值和触发条件的会被消费(告警)，不满足的会被定期从队列中清除

流式告警的几个好处:
1.实时性:数据流过就会计算是否符合规则，不用再走存储流程。
2.规则抽象:我们按照几个层次(业务线、服务池、IP、接口)抽象了告警逻辑。
最小级别的接口异常标准按照SLA或者KPI指标自动设定。
逐层向上收敛。在服务池级别有多少IP发生异常即触发本级别的告警事件(比如5%的IP响应时间超过SLA设定，为服务池warning时间，
超过10%为服务池error事件)，到了业务线级别，告警的判断标准是有多少服务池发生异常(warning，error，fatal等)。每一层的告警事件都会向上收敛，
如果不超出上一层的SLA设定，则只会展示在九宫格中或者事件列表里，而不会直接报给用户，最终向上汇总的最高级，用户在宏观层面即可整体把握可用性(
不影响整体的话可以不用立刻干预)，又可逐级向下追溯具体的问题节点
3.规则自动提取:只要推送数据符合协议(包含业务线，服务池等信息)，报警规则和收敛方式就会自动进入配置库(mysql)，后面的九宫格、邮件、推送都
自动生成，不需要人工干预(这里生成的都是抽象出来的通用规则，用户也可以通过后台定制自己的专属规则)
4.告警API:除针对单个指标设置规则外，还可以通过API批量导入告警规则，尤其是在指标特别多的时候。(在某些情况下，业务方对告警逻辑的抽象和我们不同，
因此不适用自动提取规则)。
流式告警上线后，基本上自动规则就能解决80%的告警需求，但仍有一些特殊化的需求还不能覆盖，比如徒增突降告警，同比环比等复杂的需要经过统计运算的告警。
这个阶段可以称之为"重服务质量，轻告警"，真正需要通知到用户的告警数量比较少，大部分告警事件都因为对整体服务影响不大而被“降噪”了。

3.智能告警阶段是通过算法，对告警的数量和质量(误报率)进行不断修正的过程。在智能告警阶段主要的方法包括:
1.将告警聚合成“关联事件”
2.合并重复的告警
3.自动恢复策略
4.告警分类

1.数据聚合/关联技术

1.数据聚合
数据聚合对实时、时序数据(监控数据和运维事件)的聚合。而数据分析属于离线计算模式，是对数据的深加工、二次利用。
有两个层面,一是对数据的聚合运算(计算，平均，抽样等)；二是多维度的聚合(在实际应用中维度通常指时间,地点,业务线,服务,接口等)，也可称为是标签，用来标注看待数据的不同角度。

没有聚合这一层，不得不存储所有的原始数据，但在运维监控工作中基本上不需要，读取时也需要读出原始数据后再计算结果，这样写入量和读取量就会比不做聚合时大得多，在海量数据场景下，对系统复杂度和稳定性都是一个考验。

2.降低维度
告警事件的收敛和聚合一直是运维工作中的重要环节。收敛和聚合一方面可以减少噪音和干扰，另一方面可以确定主要因素、定位故障、如果每天有上万个告警事件，如何收敛到人可以处理的程度(少于10个)