共计 5640 个字符，预计需要花费 15 分钟才能阅读完成。
是不是常常会遇到，有人在群里 @你，通知你你的零碎出故障了，你在犹豫是不是真的出故障的同时还得慌乱地去查找？
老板问你零碎当初到底衰弱与否，能不能疾速给个判断，你却不敢断言？业务方说你的零碎有问题，但你认为没问题，又无奈自证？
这所有都源自于你的零碎没有做好监控和告警：
没有监控或者没有一个好的监控，导致你无奈疾速判断零碎是不是衰弱的；
没有告警或者没有一个精准的告警，当零碎出问题时不能及时告诉到你，并且通知你哪里出了问题，影响是什么以及具体怎么解决。
一、监控告警为什么重要？
除了在下面提到的几个常见的场景，监控告警在咱们保障系统的稳定性和事变疾速复原的全周期中都是至关重要的。这里提到了一个事变全周期的概念，它蕴含发现、定位、解决 3 个阶段，其中疾速发现和定位是要害，而这部分次要依附的就是监控和告警，解决问题也须要依附监控和告警提供的具体的信息。
所以它关乎咱们是否能发现或者疾速的发现，定位和解决事变。特地是在业务高峰期，早一分钟解决就能缩小很多损失，如果一个事变呈现较长时间没有解决，甚至没有定位，将会间接影响用户的理论应用体验，这对公司形象和业务产生的影响与损失都是不可估量的。监控告警的重要性也就显而易见了，能够那么说做好了监控告警能事倍功半。那监控和告警应该怎么做呢？
二、监控与告警体系该怎么搭建？
监控的定义就是监测和管制，监测某些事物的变动，以便进行管制。在常见的软件系统中，大多分为四大察看类别：
- 业务逻辑：我的项目所对应的服务及其承当的业务逻辑，通常须要对其进行度量。例如：单量，库存量。
- 应用程序：应用程序。例如：对立的根底框架，接口耗时，接口 QPS。
- 硬件资源：服务器资源状况等。例如：CPU Load，内存使用量。
- 网络状况：比方网络丢包状况等。
1、明确监控告警的指标
要想让监控施展它本有的价值，那咱们必须先明确做监控的指标是什么。从事实层面登程，做监控的初衷，就是心愿可能及时的发现线上环境的各种各样奇奇怪怪的问题，为业务的失常运行保驾护航。因而整体分为下图四项：
- 预测故障：故障还没呈现，但存在异样。监控零碎依据流量模型、数据分析、度量趋势来推算应用程序的异样趋势，推算可能呈现故障的问题点。
- 发现故障：故障曾经呈现，客户还没反馈到一线人员。监控零碎依据实在的度量趋势来计算既有的告警规定，发现曾经呈现故障的问题点。
- 定位故障：故障曾经呈现，但未找到具体故障地位，此时是须要协调公司内的多个组件，例如：链路追踪零碎、日志平台、监控零碎等，来定位故障点。
故障复原：呈现故障后，咱们依据 SOP 或者其余形式 (hotfix 等) 来复原故障。
2、确定具体监控指标
有了指标，下一步咱们就是要确定监控什么，监控哪些指标。这些在业内其实是有优良的教训能够借鉴的，给大家介绍两个概念，心愿能够给大家一些启发。
2.1 根底监控指标——黄金指标
《Google SRE 运维解密》总结出了 4 个黄金指标，在业界广为流传和借鉴：
1）提早：服务解决某个申请所须要的工夫。
- 辨别胜利和失败申请很重要，例如：某个因为数据库连贯失落或者其余后端问题造成的 HTTP 500 谬误可能提早很低。因而在计算整体提早时，如果将 500 回复的提早也计算在内，可能会产生误导性的后果。
- “慢”谬误要比“快”谬误更蹩脚。
2）流量：应用零碎中的某个高层次的指标针对零碎负载需要所进行的度量。
- 对 Web 服务器来讲，该指标通常是每秒 HTTP 申请数量，同时可能按申请类型分类（动态申请与动静申请）。
- 针对音频流媒体零碎来说，指标可能是网络 I/O 速率，或者并发会话数量。
- 针对键值对存储系统来说，指标可能是每秒交易数量，或每秒的读者操作数量。
3）谬误：申请失败的速率。
- 显式失败（例如：HTTP 500）；
- 隐式失败（例如：HTTP 200 回复中蕴含了谬误内容）；
- 策略起因导致的失败（例如：如果要求回复在 1s 内收回，任何超过 1s 的申请就都是失败申请）。
4）饱和度：服务容量有多“满”，通常是零碎中目前最为受限的某种资源的某个具体指标的度量，例如：在内存受限的零碎中，即为内存；在 I/O 受限的零碎中，即为 I/O。
- 很多零碎在达到 100% 利用率之前性能会重大降落，因而能够思考减少一个利用率指标。
- 提早减少是饱和度的前导景象，99% 的申请提早（在某一个小的工夫范畴内，例如一分钟）能够作为一个饱和度晚期预警的指标。
- 饱和度须要进行预测，例如“看起来数据库会在 4 小时内填满硬盘”。
如果曾经胜利度量了这四个黄金指标，且在某个指标呈现故障时（或者快要产生故障）可能收回告警，那么从服务的监控层面来讲，根本也就满足了初步的监控诉求。也就是能够做到晓得了出了问题，是一个从 0 到 1 的起步阶段。
2.2 外围监控指标——指南针指标
个别的状况下，黄金指标的确是十分重要且通用的指标，是每个零碎都是必须要有的根底监控。然而对于一个简单的业务零碎来说，黄金指标这些通用的指标是不足以或者不能准确的反馈业务零碎的外围价值的。每个业务零碎的业务架构都不同，当然掂量业务零碎的指标也应该是不一样的。
因而咱们 B 站在理论状况中提出了“指南针指标”的概念：
- 指南针指标是系统对业务的外围价值体现，指南针指标同时也体现零碎的衰弱与否
- 指南针指标的稳定，肯定意味着业务呈现稳定，业务呈现问题，指南针指标肯定异样。同时，一旦建设了指南针指标，每天就要关注本人的指南针指标：
- 呈现稳定须要给出解释
- 要对指南针指标设置告警
指南针指标不能很多，最好就一个指标，如果切实难以定义成一个指标，也不要超过 3 个，而且尽量准确简洁明了。对于技术管理者来说，指南针指标十分重要，他能够每天通过查看本人团队负责业务的指南针指标，提前预知一些危险和以后团队服务的衰弱状况。这也是为什么我说指南针指标不能太多，否则会让人抓狂。
以上是咱们给出的指南针指标的定义，接下来举个具体的例子不便大家了解：对于弹幕零碎来说，弹幕成功率就是指南针指标。这里须要解释一下，这是一个业务指标不是一个技术指标。弹幕往往波及到风控，登陆等业务逻辑，比方在发送弹幕的时候被风控了而导致没有胜利，在业务上咱们不认为是发弹幕失败了，因为他不是弹幕零碎自身的起因，而是跟风控系统的规定相干。同时弹幕发送耗时在这里咱们也不算做是指南针指标，因为在发弹幕场景，往往是异步的，用户是能承受肯定水平的延时的。如果延时有肯定增长然而又在某个范畴内，实际上时并不影响最终的后果，所以弹幕发送耗时这个指标不是指南针指标，但并不是说他不重要，他还是能够作为一个零碎的外围指标。
2.3 日志监控
其实除了零碎指标的监控，当初日志监控也是常常用到的。对谬误日志进行监控和告警是解决故障的重要因素。日志监控跟具体的业务相关性比拟大，这里给出的倡议是：
- 谬误日志量要有监控
- 外围链路上易出问题的中央务必设置日志监控和告警
3、联合监控设置正当的告警
监控往往并不是独自应用的，会有对应的告警设置，因为大多数状况下，大家都不会始终盯着监控，那样耗时又费劲，所以如何正当的设置告警就成了要害。
3.1 一些实用的告警准则
再好的监控体系，闭环做不好，就无奈施展出很大的作用。因而咱们给告警设置了一些实用的准则：
- 告警不要太多，否则会导致“狼来了”。
- 告警呈现时，该当要有具体的操作，或者 SOP。
- 不须要人工响应 / 解决的告警规定，该当间接删除。
- 告警信息该当有告警级别，影响面，如何解决等。
简略来讲就是告警要少要准确，事件须要解决，解决要人工染指。
3.2 故障等级与告警设置
定义故障的等级，在 B 站咱们除了应用损失 pv、支出来定义故障等级，故障的持续时间也是很重要的一个指标，对于一个外围服务，如果：
- 故障工夫超过 40 分钟，属于 P0 事变；
- 故障工夫超过 30 分钟，属于 P1 事变；
- 故障工夫超过 20 分钟，属于 P2 事变；
- 故障工夫超过 10 分钟，属于 P3 事变。
因而如何让事变在短时间内解决其实也是在考验咱们告警设置的能力。后面我讲过事变全周期的概念，其中发现和定位其实很大水平依赖于告警，特地是发现故障。所以告警怎么设置，这里有几点能够供参考：
- 告警分级别，依据严重性，咱们能够分为：提醒，预警，重大，劫难
- 告警分起因
- 告警要有解决方案
如果是日志告警，咱们还须要加上：
- 输出和返回参数
4、明确告警的人员和形式
4.1 渐进式告警到负责人
告警给谁？这是一个须要斟酌的问题，在告警的标准上，要尽可能遵循最小准则，再逐级上报。也就是先告警给 on-call 人，若超出 X 分钟，再逐级上报到全业务组，再及其负责人，一级级跟踪，实现渐进式告警。逐级上报的数据起源，可通过员工管理系统来获取，在员工管理系统中有残缺的上下级关系（相似 OA 审批上看到的流程节点）。
4.2 告警投群
往往还有另外一种状况，就是服务负责人不能立马看到告警，针对这种状况咱们能够提前准备告警群，把告警投入小组的群里，这样群里的其他同学也能看到告警，帮负责人解决告警或者揭示负责人解决告警。
4.3 告警拉群
对于一些外围服务的劫难级别告警，咱们能够应用告警拉群的形式，因为过往的教训通知咱们呈现事变时不少工夫都花在拉人进群上，而且当外围服务呈现劫难级别告警就意味着外围零碎呈现了故障，有必要间接拉群进行故障解决工作。
三、监控告警平台的搭建
监控告警应该有本人的一套流程与规范，个别会通过平台搭建的模式来落实与经营。在这里次要给大家介绍一下业内罕用的两个监控告警平台：Prometheus 和 CAT，此外还会再给大家介绍一个日志监控和告警平台 ELK。
1、Prometheus
Prometheus 是一款基于时序数据库的开源监控告警零碎，基于 golang。Prometheus 的基本原理是通过 HTTP 协定周期性抓取被监控组件的状态，任意组件只有提供对应的 HTTP 接口就能够接入监控。Prometheus 提供了从指标裸露，到指标抓取、存储和可视化，以及最初的监控告警等一系列组件，整体架构如下：
Prometheus Server：用于收集指标和存储工夫序列数据，并提供一系列的查问和设置接口。
Grafana：用于展现各类趋势图，通过 PromQL 从 Prometheus 服务端查问并构建图表。
Alertmanager：用于解决告警事件，从 Prometheus 服务端接管到 alerts 后，会进行去重，分组，而后路由到对应的 Receiver，发出报警。
Promethus 有以下特点：
- 多维度数据模型，一个工夫序列由一个度量指标和多个标签键值对确定；
- 灵便的查询语言，对收集的时序数据进行重组；
- 弱小的数据可视化性能，除了内置的浏览器，也反对跟 Grafana 集成；
- 高效的存储，内存加本地磁盘，可通过性能分片和联盟来扩大性能；
- 运维简略，只依赖本地磁盘，Go 二进制安装包没有任何其余库包依赖；
- 准确告警；
- 十分多的客户端库；
- 提供了许多导出器来收集常见零碎指标；
- 能够通过两头网关进行时序列数据推送；
- 通过服务发现或者动态配置来发现指标服务对象。
具体可见：https://zhuanlan.zhihu.com/p/…
2、CAT
CAT 是基于 Java 开发的实时利用监控平台，为美团点评提供了全面的实时监控告警服务。CAT 作为服务端我的项目根底组件，提供了 Java, C/C++, Node.js, Python, Go 等多语言客户端，曾经在美团点评的基础架构中间件框架（MVC 框架，RPC 框架，数据库框架，缓存框架等，音讯队列，配置零碎等）深度集成，为美团点评各业务线提供零碎丰盛的性能指标、健康状况、实时告警等。
具体可见：https://github.com/dianping/cat
3、ELK&ElastAlert
3.1 ELK
ELK 是 ElasticSearch、LogStash、Kibana 三个开源工具的简称，当初还包含 Beats，其分工如下:
- LogStash/Beats: 负责数据的收集与解决
- ElasticSearch: 一个开源的分布式搜索引擎，负责数据的存储、检索和剖析
- Kibana: 提供了可视化的界面。负责数据的可视化操作
基于 ELK 能够构建日志剖析平台、数据分析搜寻平台等十分有用的我的项目。
具体可见：https://blog.csdn.net/Ahri_J/…
3.2 ElastAlert
然而对于谬误日志的监控 ELK 架构并没有提供，所以咱们须要应用到第三方工具 ElastAlert，来帮忙咱们及时发现业务中存在的问题。ElastAlert 通过定期查问 Elasticsearch，并将数据传递到规定类型，该规定类型确定何时找到匹配项。产生匹配时，将为该警报提供一个或多个警报，这些警报将依据匹配采取行动。具体可见：https://mp.weixin.qq.com/s/W9…
四、B 站的实际案例
讲了那么多方法论，可能大家还是没有一个特地清晰的概念，我这边就拿 B 站的理论利用监控来给大家具体说说，先给大家展现一下。
1、黄金指标类的监控
服务罕用指标监控：
服务接口监控：
依赖的服务监控
依赖的组件监控
2、指南针指标类监控
弹幕指南针指标
相干下钻指标
那监控其实是咱们安插在利用身上的眼睛，它做的事件是察看和收集，要怎么无效利用这些数据指标，还是得靠人。仍旧以后面的弹幕发送成功率这个指标为例，来说说 B 站的告警是怎么做的。
个别咱们会依据业务需要设置一些告警触发条件，当成功率低于肯定数值就会产生提醒 / 预警，咱们采取的是告警投群的形式，这种形式的益处后面也有提，不便合作也不至于脱漏重要告警的解决。
告警拉群的形式 B 站也在踊跃尝试中，心愿可能达到当外围服务的劫难级别的告警呈现，能够间接触发拉群，将相干服务负责人及其下级、运维相干同学主动拉入群中的一个成果，目前该性能 B 站还在研发中。
五、总结
监控告警的最佳状态就是实现“一五十”，所谓“一五十”，就是指咱们能一分钟发现事变，五分钟定位，十分钟解决。置信这也是泛滥企业 SRE 的想要达成的指标，心愿明天给大家讲的这些内容可能帮忙大家实现精准的监控和告警，把问题扼杀在摇篮里，缩小故障带来的业务损失。
👉更多精彩内容点击【故障教训库】
