本文转载自微信公众号《我的脑子是炸鱼》，作者陈建宇。转载本文请联系脑筋急转弯公众号。“告诉我，你敢开没有仪表盘的车吗？”“一辆没有仪表盘的车在路上行驶，你怎么知道是怎么回事？”“客户说你的车又坏了，你怎么知道是什么时候？”好的？问题是什么时候出现的？”前言将思想转移到实际的软件系统中。可想而知，没有监控系统，也就是没有“仪表盘”，真是惨不忍睹。你的失败总是由你的客户告诉你的，而且……当它发生时，你无法确定。只能通过客户的反馈把时间节点往后推，最终从错误日志中得到比较完整的日志信息。更严重的问题是不能掌握主动权，错误日志可能被人遗漏了，更不用说平均修复时间（MTTR）了，需要从0.1开始定位，先查看APP是哪个模块报的报错，然后猜是哪个服务的结果，打开链接跟踪系统，或者日志平台等，稍微复杂一点，排查基本是半个小时或者一个多小时。四个9绝对不能实现。如此一来，几个小时的P0对于业务性能来说可能并不爽，因为故障修复的速度简直太慢了。归根结底，要想破局怎么办，核心的第一步就是搭建整个监控告警的生态圈。监控的定义通常被称为监视和监控。监控的定义是监视和控制，检测某些事物的变化，以便于控制。在常见的软件系统中，大多分为三个观察类：业务逻辑：通常需要衡量项目对应的服务所承担的业务逻辑。例如：每秒下单数等。application：应用。例如：统一的基础框架。硬件资源：服务器资源情况等。例如：Kubernetes中的Cadvisor组件会提供大量的资源指标。从软件系统的角度来看，监控的定义就是对某个系统的实时定量数据进行采集、处理、汇总和展示，例如：请求的数量和类型、错误的数量和类型、错误的数量和类型等。各种调用/处理的耗时，应用服务的Lifetime等。监控目标了解监控的定义，了解监控的作用和具体的实施指标。我们要清楚监控的目标是什么：从实际的角度来看，监控的初衷是为了及时发现线上环境中的各种奇怪问题，从而保障业务的正常运行。因此，上图中整体分为四项：预测故障：故障尚未发生，但存在异常。监控系统根据流量模型、数据分析和测量趋势，计算出应用程序的异常趋势，计算出可能的故障点。故障发现：故障已经出现，但客户没有反馈给一线人员。监控系统根据真实的测量趋势，计算出已有的报警规则，找出失效的问题点。定位故障：故障已经发生，需要监控系统协助快速定位问题，即根源。这时候需要协调公司生态系统的多个组件，例如：链路跟踪系统、日志平台、监控系统、治理平台（限流和??熔断等），并使用来自监控系统的告警作为起始锚点，针对特定方向进行分析，进而形成“线索”报告，可以极大地辅助开发人员快速定位问题，查找故障点。故障恢复：故障已经发生，但自动恢复，或者通过自动化进行自愈。这种情况多发生在告警规则的阈值配置不合适，或者第三方依赖刚好恢复的时候。更值得探讨的是监控告警闭环的下半场，故障自愈，通过以上“预测故障、发现故障、定位故障”三点，一旦定位到故障，就可以配合与内部组件实现自动化。“自我修复”，减少人工干预，提高MTTR。因此，构建监控系统的目标非常明确，就是发现问题，解决问题，治愈自己，从而达到假期愉快，业务安心的目的。4个黄金指标都有定义和目标，那么指导呢？事实上，“业务逻辑、应用程序、硬件资源”已经成为监控系统监控构建的首要目标，大部分监控场景都可以归入其中。针对这三项，《Google SRE 运维解密》还总结出了4个黄金指标，在业界广为流传和借鉴：Latency：一个服务处理一个请求所花费的时间。区分成功和失败的请求很重要，例如：由于数据库连接丢失或其他后端问题导致的HTTP500错误可能具有非常低的延迟。所以在计算整体延迟时，包括500回复的延迟可能会产生误导性的结果。“慢”的错误比“快”的错误更糟糕。流量：使用系统中的某些高级指标衡量系统负载需求。对于Web服务器，此指标通常是每秒HTTP请求的数量，并且可以按请求类型（静态请求与动态请求）分类。对于音频流系统，指标可能是网络I/O速率或并发会话数。对于键值存储系统，指标可能是每秒事务数，或每秒读取器操作数。错误：请求失败的比率。显式失败（例如：HTTP500）。隐式失败（例如：HTTP200响应包含错误内容）。策略原因导致的失败（例如：要求1s内发送响应，任何超过1s的请求都是失败的请求）。Saturation：服务容量有多“满”，通常是衡量系统中当前最受限的一种资源的具体指标，例如：在内存受限的系统中，是内存；在I/Olimited在一个受限的系统中，就是??I/O。许多系统在达到100%利用率之前会经历严重的性能下降，因此请考虑添加一个利用率目标。延迟增加是饱和的前兆，99%的请求延迟（在一个小的时间范围内，例如一分钟内）都可以作为饱和的预警指标。需要预测饱和度，例如“看起来数据库将在4小时内填满硬盘”。如果这四个黄金指标都测得成功，并且能够在某个指标失效（或即将失效）时发出告警，那么在服务监控方面，基本满足了初步的监控需求。也就是说，可以知道哪里出了问题，哪里出了问题。光是这一步就提高了很多定位问题的时间效率，是从0到1的初级阶段。实践案例知道什么是（定义），为什么要做（目标），做的时候需要什么（4个黄金指标），现在还缺的是一个承载这些基础应用和业务思维的平台，让架构+运维+业务在上面集体大展拳脚。公司内部至少需要一个监控告警管理平台。平台搭建在云原生火热的现状下，大部分Kubernetes生态都普遍使用Prometheus，因此Prometheus+Grafana+AlertManger成为了一大选择，在行业中的占比也在不断提升。其基本架构如下：PrometheusServer：用于收集Index和存储时序数据，并提供一系列的查询和设置接口。Grafana：用于展示各种趋势图，通过PromQL从Prometheus服务器查询和构建图表。Alertmanager：用于处理告警事件。Prometheus服务器收到告警后，会进行去重、分组，然后路由到对应的Receiver发出告警。具体的基础知识学习和搭建可以参考我写的Prometheus系列，本文不再赘述。在平台上搭建好监控指标之后，第一步就是规划你整个系统的衡量指标。结合GoogleSRE的四大黄金指标，可以初步划分出以下几种常见的类型：系统层面：KubernetesNode、Container等指标，大部分已经被Cadvisor收集上报，也可以通过安装kube-state-metrics，让您对Kubernetes和应用的运行状态有更好的观察和告警。系统层：为全链路所有基础组件（如MySQL、Redis等）安装exporter，对相关基础组件进行采集、监控和告警。业务服务：RPC方式的QPS记录等。可以保证业务服务的流量情况可控，后续可以进行一系列的预测/预警动作，对自动扩容有一定的参考意义面对突如其来的交通而收缩。业务服务：RPC方法的错误情况等。可以发现应用和业务的常见异常，但需要在合理的状态/错误码规划的情况下才能发挥更大的作用。有一定的困难。一定要一开始就做对，否则以后就很难逆转了。应用：各种远程调用（如RPC、SQL、HTTP、Redis）的调用开销记录。最通用的指标之一，可以通过多种方式提供精确定位和分析，Web应用程序的标准。与P99/95/90通用。语言层面：内部分析记录，比如Goroutines的数量、panic情况等，经常可以发现一些意想不到的泄漏和空指针调用。如果没有这种类型的监控，它很可能永远不会被发现。第一步是实施指标。完成整个系统的衡量指标规划后，第二步就是对指标进行实际落实。无论是统一基础框架的管理，还是系统组件的导出，大多涉及到公司层面的跨部门协作。这个时候，更需要耐心、长期主义、不断纠错，才能尝到制度建设的果实。.在报警系统完成了监控指标和系统的建设之后，如何实施报警就成为了一大难题。再好的监控系统，如果闭环没做好，也发挥不了大的作用。因此，我们对告警定义了一些准则：告警不要太多，否则会造成“狼来了”。当出现告警时，需要具体处理，需要紧急解决。发生报警时，应进行一定的智力分析，不应是机械的行为。不需要人工响应/处理的告警规则直接删除。当出现警报时，您会下意识地观察所观察到的警报并直接进行调整。警报应该足够简单和直观，无需猜测。简单来说就是告警少，需要解决的事件，需要人工干预处理。不然右转自动自愈恢复可能更香。向谁发出警报？另一个问题是：谁应该通知谁触发警报？这是一个需要慎重考虑的问题。在告警规范方面，尽量遵循最小化原则，然后逐级上报。即先报警on-caller，如果超过X分钟，会逐级上报给整个业务组，然后由负责人逐级跟进，实现渐进报警.逐级上报，响应跟进，明确问题责任人。分步上报的数据来源可以通过员工管理系统获取，员工管理系统具有完整的从属关系（类似于OA审批中看到的流程节点），但如果系统没有开放API，那么也许你只能通过其他方式获得。比如通过企业微信获取部门关系和人员名单，然后手动设置上下级关系也可以达到目的，而在现实世界中，可能会有定制化的需求。规范建设即使监测体系、指标落地、预警体系都建立起来了，也不能掉以轻心。其实成为事实标准后，还是需要尽快报警后运行，构建整个闭环，即故障管理。与公司内部流程管理同学或QA一起，建立研发底线规范，进行详细的告警分类识别，告警后汇总运行分析，形成真正的故障管理规范。否则到最后可能会精疲力尽，而人的时间和精力总是有限的。面对全公司监控告警的建立，系统和事业群的共建，告警响应的监督，很可能到最后累死你，即使有一定是有用的，但在杂乱无章的告警中会流于形式。总结监控告警的系统生态有意义吗？这是不可避免的。一个成熟规范的监控告警系统生态具有重要意义。提前发现问题，定位问题，解决问题。您甚至可能不需要自己处理这个问题。多组件闭环后，可以直接实现自动化服务自愈。安心幸福地过国庆，很香。实现故障管理闭环后，可以分析业务服务告警情况，结合CI/CD系统等基础平台，自动分析实现每季度运营报表，帮助业务发现问题更多的问题，并提供其独特的价值。但要真正做到上述成熟规范的业务共建是有一定难度的，需要多方面的认可和公司标准的支持，才能做到最好的实现。所以，共同认同，求同存异，多做用户反馈分析也很重要。原文链接：https://mp.weixin.qq.com/s/qaNWBlDGgE2hNnu6SV4EBg
