导读：收集常见架构技术点，作为项目经理了解这些知识点以及解决具体场景是很有必要的。技术要服务业务，技术跟业务具体结合才能发挥技术的价值。
目录
1. 服务监控
2. 全链路监控
2.1 服务拨测
2.2 节点探测
2.3 告警过滤
2.4 告警去重
2.5 告警抑制
2.6 告警恢复
2.7 告警合并
2.8 告警收敛
2.9 故障自愈
1. 服务监控
服务监控主要目的在服务出现问题或者快要出现问题时能够准确快速地发现以减小影响范围。服务监控一般有多种手段，按层次可划分为：
-
系统层（CPU、网络状态、IO、机器负载等）
-
应用层（进程状态、错误日志、吞吐量等）
-
业务层（服务/接口的错误码、响应时间）
-
用户层（用户行为、舆情监控、前端埋点）
监控运维管理领域里的组件（网络->设备->系统>应用->组件）
2. 全链路监控
2.1 服务拨测
服务拨测是探测服务（应用）可用性的监控方式，通过拨测节点对目标服务进行周期性探测，主要通过可用性和响应时间来度量，拨测节点通常有异地多个。
服务拨测通过模拟用户的登陆/查询，实现从被动投诉到主动发现的运维方式转变，当前支持的拨测协议有 HTTP(包含 HTTPS，GET 和 POST 方法）、TCP、UDP。
2.2 节点探测
节点探测是用来发现和追踪不同的机房（数据中心）节点之间网络可用性和通畅性的监控方式，主要通过响应时间、丢包率、跳数来度量，探测方法一般是ping、mtr或其他私有协议。
2.3 告警过滤
对某些可预知的告警进行过滤，不进入告警统计的数据，如少量爬虫访问导致的http响应500错误，业务系统自定义异常信息等。
2.4 告警去重
当一个告警通知负责人后，在这个告警恢复之前，不会继续收到相同的告警。
2.5 告警抑制
为了减少由于系统抖动带来的干扰，还需要实现抑制，例如服务器瞬间高负载，可能是正常的，只有持续一段时间的高负载才需要得到重视。
防止：耗费更多时间排查和处理问题，大大降低了运维效率，而且由于无法第一时间发现根源问题，延误了故障处理时间，往往会给业务运行带来潜在风险。
2.6 告警恢复
开发/运维人员不仅需要收到告警通知，还需要收到故障消除告警恢复正常的通知。
2.7 告警合并
对同一时刻产生的多条相同告警进行合并，如某个微服务集群同一时刻出现多个子服务负载过高的告警，需要合并成为一条告警。
2.8 告警收敛
有时某个告警产生时，往往会伴随着其它告警。这时可以只对根本原因产生告警，其它告警收敛为子告警一并发送通知。如云服务器出现CPU负载告警时往往伴随其搭载的所有系统的可用性告警。
2.9 故障自愈
实时发现告警，预诊断分析，自动恢复故障，并打通周边系统实现整个流程的闭环。
告警自愈是一套完备的故障自动化处理流程，通过打通监控工具、告警平台、任务调度平台、CMDB、ITIL等相关系统，实现从告警接收，根因定位，规则匹配，脚本执行，故障恢复，人工确认，最后到告警恢复，真正实现告警的全生命周期管理。
扩展：故障分类：
闪断类：故障发生后迅速自愈
重复类：单个对象的一个或多个指标持续告警
范围性故障：某个区域或某个集群出现范围性故障，范围内的多个对象短期内同时出现告警。
扩展 ：借鉴应对思路：某公司产品，一站式告警全生命周期管理平台，提供了从监控，到异常检测告警，针对压缩后告警进行根因分析的 AIOps 闭环能力
