本文转载自微信公众号「脑子里煎鱼」，作者陈煎鱼。转载本文请联系脑子里煎鱼公众号。
“你敢开没有仪表盘的车吗？”
“路上没有仪表盘的车怎么知道现在发生了什么？”
“客户说你的车又崩了。你怎么知道什么时候好？什么时候出问题？”
前言
将思考转换到现实的软件系统中，可想而知没有监控系统的情况下，也就是没有 ”仪表盘“ 太可怕了。
你的故障总是由你的客户告诉你的，...你不确定什么时候会发生，只能通过客户的反馈将时间节点推回来，最后从错误的日志中获得相对完整的日志信息。
问题
更重要的是，你不能掌握主动权。错误的日志可能会被遗漏，平均修复时间(MTTR)更不用说从 0.1 开始定位，先看 APP 哪个模块报错，猜测是哪个服务造成的，然后打开链路跟踪系统或日志平台。
稍微复杂一点，调查基本上是半小时，一个多小时， 4 9 肯定达不到，这几次 P0 怕几个小时不是业务绩效，因为故障修复速度太慢。
归根结底，如果你想打破游戏，核心的第一步是建立监控和报警的整个生态系统。
监控定义
监控通常被称为监控。监控的定义是监控和控制，检测某些事物的变化，以便于控制。在常见的软件系统中，大多分为三类：
- 业务逻辑：项目对应的服务通常需要测量其业务逻辑。例如：每秒的订单数量等。
- 应用程序：应用程序。例如：统一的基本框架。
- 硬件资源：服务器资源等。Kubernetes 中的 Cadvisor 组件将提供大量的资源指标。
监控目标
在了解了监控的定义、监控的作用和具体的实施指标后。我们需要清楚地知道监控的目标是什么：
从现实层面来看，监控的初衷是及时发现网络环境中的各种奇怪问题，护送业务的正常运行。
因此，整体分为上图四项：
- 预测故障：故障尚未发生，但有异常。监控系统根据流量模型、数据分析和测量趋势计算应用程序的异常趋势，并计算可能出现故障的问题点。
- 发现故障：已发生故障，客户尚未向一线人员反馈。监控系统根据实际测量趋势计算现有报警规则，发现故障问题点。
- 定位故障：出现故障，需要监控系统协助快速定位，即根据定位(root cause)。此时，需要协调公司生态系统的多个组件，如链路跟踪系统、日志平台、监控系统、治理平台（限流熔断器等）。，并根据监控系统报警的问题进行具体方向的分析”线索“ 报告可以大力协助开发人员快速定位问题，发现故障点。
- 故障恢复：故障已经发生，但自动恢复，或通过自动自愈。这种情况主要发生在报警规则阈值配置不当或第三方依赖刚刚恢复的情况下。
所以做监控系统的目标很明确，就是发现问题，解决问题，最好自愈，达到快乐休假、业务安心的目的。
4 黄金指标
有定义，有目标，那么指导呢？
实际上 “业务逻辑、应用程序、硬件资源” 已成为监控系统监控建设的主要目标，大部分监控场景都可以分类。
针对这三大项，《Google SRE 运维解密还总结了 4 黄金指标，在业内广泛传播和借鉴：
- 延迟：服务处理请求所需的时间。
- 区分成功和失败的请求非常重要，例如：数据库连接丢失或其他后端问题引起的 HTTP 500 错误可能延迟很低。因此，在计算整体延迟时，如果计算 500 回复的延迟，可能会产生误导性结果。
- “慢” 比 错误“快” 错误更糟。
- 流量：使用系统中的某个高层次的指标针对系统负载需求所进行的度量。
- 对 Web 对于服务器，该指标通常是每秒 HTTP 请求数量可根据请求类型(静态请求和动态请求)进行分类。
- 对于音频流媒体系统，指标可能是网络 I/O 速率，或者并发会话数量。
- 对于存储系统的键值，指标可能是每秒的交易量，或每秒的读者操作量。
- 错误：请求失败率。
- 显式失败(例如:HTTP 500)。
- 例如：HTTP 200 回复包含错误内容)。
- 战略原因导致的失败(例如，如果需要回复 1s 内发出，任何超过 1s 请求都是失败请求)。
- 饱和度:服务容量有多大“满”，通常是系统中某些资源最有限的特定指标的测量，如内存有限的系统，即内存； I/O 限制系统中，即 I/O。
- 在达到 100% 利用率之前，许多系统的性能会严重下降，因此可以考虑增加利用率目标。
- 延迟增加是饱和度的先导现象，99% 请求延迟(在一定时间内，比如一分钟)可以作为饱和度早期预警的指标。
- 需要预测饱和度，如 “数据库似乎在 4 小时内填满了硬盘”。
也就是说，你可以知道问题是什么，问题在哪里，这一步提高了许多定位问题的时间效率，是从 0 到 1 的初始阶段。
实践案例
知道是什么(定义)，为什么要做(目标)，做的时候需要什么(4 一个黄金指标)，还缺少一个承载这些基本应用和业务思维的平台，让架构 运维 业务在上面展示自己的实力。
公司至少需要一个监控报警管理平台。
平台搭建
目前云原生火热，Kubernetes 主要用于生态学Prometheus，因此 Prometheus Grafana AlertManger 已成为行业的首选，其基本结构如下：
- Prometheus Server：用于收集指标和存储时间序列数据，并提供一系列查询和设置接口。
- Grafana：通过 展示各种趋势图PromQL 从 Prometheus 查询并构建服务端的图表。
- Alertmanager：从 处理报警事件Prometheus 服务端接收 alerts 之后，将重量去除，分组，然后路由到相应的Receiver，发出报警。
监控指标
在平台搭建完毕后，常要做的第一步，那就是规划你整个系统的度量指标，结合 Google SRE 4 金指标可初步分为以下常用类型：
- 系统层面：Kubernetes Node、Container 等大部分指标都是 Cadvisor 已收集上报，也可安装 kube-state-metrics 加强，这样就可以对 Kubernetes 对应用程序的运行有较好的观察和报警。
- 系统层面：全链路上的所有基本组件（如：MySQL、Redis 等)安装 exporter，收集、监控和报警相关基本组件。
- 业务服务：RPC 方法等 QPS 记录。它可以保证业务服务的流量控制，并可以做一系列预测/预警的动作。面对突发流量的自动扩张，具有一定的参考意义。
- 业务服务：RPC 方法等错误情况。可以发现应用程序和业务的常见异常情况，但在合理规划状态/错误码时需要发挥很大的作用。一开始很难做对，否则以后很难扭转。
- 应用:各种远程调用(如:RPC、SQL、HTTP、Redis)调用费记录。最万金油的测量指标之一可以在很多方面使用提供准确的定位和分析，Web 标配应用程序。常用于 P99/95/90。
- 语言水平：内部分析记录，如：Goroutines 数量、Panic 情况等，经常会发现一些意想不到的泄漏和空指针调用。没有这样的监控，很可能永远不会被发现。
第一步完成整个系统的测量指标规划后，第二步是确实落地指标。
无论是统一的基本框架，系统组件 exporter，大多数都涉及到公司级的跨多部门合作。此时，需要更多的耐心和长期主义，不断纠正方向，才能尝到系统建设的果实。
告警体系
监控指标和系统建设完成后，如何做报警已成为一个大问题。无论监控系统有多好，闭环都不能发挥很大的作用。因此，我们定义了一些警告指南：
不要报警太多，否则会导致“狼来了”。
报警出现时，需要具体操作某些事情。
告警出现时，应当要进行某些智力分析，不应该是机械行为。
不需要人工响应/处理的报警规则应直接删除。
当警报出现时，你下意识地观察警报，直接调整。
报警应该足够简单，直观，不需要猜测。
简单来说，报警少，事件需要解决，人工干预需要处理。否则右转自动化自愈可能会更香。
告警给谁?
另一个问题是：谁诱发报警，通知谁？
这是一个需要考虑的问题。在报警规范中，尽量遵循最小原则，然后逐步报告。也就是说，先给 报警on-call 人，如果超过 X 分钟后，逐级向全业务组报告，然后对其负责人进行一级跟踪，实现渐进报警。
逐级报告，响应即跟踪，明确问题点的负责人。逐级报告的数据源可以通过员工管理系统获得，员工管理系统中有完整的上下级关系(类似 OA 审批中看到的流程节点)，但如果系统不开放 API 等等，也许你只能通过其他方式获得。
例如，通过企业微信获取部门关系和人员列表，然后手动设置上下级关系，也可以实现目标，在现实世界中可能存在定制需求。
规范建立
即使建立了监控系统、指标着陆和报警系统，也不能掉以轻心。事实上，在成为事实标准后，你仍然需要在报警后尽快奔跑，建立整个闭环，即故障管理。
与公司内部流程管理的学生或 QA，共同建立研发底线规范，详细识别报警分级，总结报警后的操作分析，形成真正的故障管理规范。
否则，最终可能会疲惫不堪，人们的时间和精力总是有限的，面对整个公司的监控和报警建设，系统和业务组的建设，敦促报警响应，最终可能会疲惫不堪，即使它真的有一定的用途，在混乱的无限报警最终只是一种形式。
总结
监控报警系统生态有意义吗？
这是不可避免的。成熟、标准化的监控和报警系统生态具有重要意义，可以提前发现、定位和解决问题。即使是这个问题也可能不需要你自己处理，在多组件闭环后，直接实施自动化服务自我愈合，轻松快乐的国庆节，非常香。
闭环故障管理实施后，结合 CI/CD 系统等基础平台每季度自动分析实施运营报表，帮助业务发现更多问题，提供其独特价值。
然而，要真正实现上述成熟和标准化，业务建设困难，需要多方面的认可和公司标准的支持才能最好地实现。因此，共同认可、求同存异、多做用户反馈分析也非常重要。
原文链接：https://mp.weixin.qq.com/s/qaNWBlDGgE2hNnu6SV4EBg