云原生监控系统Prometheus——监控就是艺术！

监控就是艺术！

　　监控是一门学问，也是一门艺术。

　　if you can't measure it, you can't improve it. (如果没有了如指掌，你就无法做出改进。)

　　监控如同切脉诊断，是技术人员先于用户发现问题的最佳手段。完善的监控系统能够先于用户发现风险，有助于团队将风险扼杀于萌芽之中，也有助于技术人员在系统发生故障时及时发现，并减少故障的生存时间，减少对用户使用体验期间的持续影响，更可以作为事后分析这次故障带来的影响范围、影响程度提供数据支撑和对未来容量管理规划管理提供数据依据。对软硬件进行监控，以实现系统的可观察性。

 一、完善的监控体系是什么样的？

　　1) 趋势分析：长期收集并统计监控样本数据，对监控指标进行趋势分析。例如：通过分析磁盘的使用空间增长率，可以预测何时需要对磁盘进行扩容。

　　2) 对照分析：随时掌握系统的不同版本在运行时资源使用情况的差异，或在不同容量的环境下系统并发和负载的区别。

　　3) 告警：当系统即将出现故障或已经出现故障时，监控可以迅速反应并发出告警。这样，管理员就可以提前预防问题发生或快速处理已产生的问题，从而保证业务服务的正常运行。

　　4) 故障分析与定位：故障发生时，技术人员需要对故障进行调查和处理。通过分析监控系统记录的各种历史数据，可以迅速找到问题的根源并解决问题。

　　5) 数据可视化：通过监控系统获取的数据，可以生成可视化仪表盘，使运维人员能够直观地了解系统运行状态、资源使用情况、服务运行状态等。

　　综上所述，一个完善的监控系统是 IT 系统构建爱之初就该考虑的关键要素。监控系统可以贯穿于移动端、前端、业务服务端、中间件、应用层、操作系统等，应该渗透到 IT 系统的各个环节。

　　通常情况下，监控系统可以分为客户端监控、业务监控、应用层监控、中间件监控、系统监控这 5 层。

　　　　a) 客户端监控：针对用户在体验上可以感知的对象进行架空，如 H5网站、APP、小程序等。有些公司会设置专门的客户端用户体验团队负责进行端监控。在移动客户端的系统中，客户端监控的对象主要有 H5、小程序、Android 系统、IOS 系统等，完善的客户端监控可以反馈地域、渠道、链接等多维度的用户体验信息；用户终端为传统的 Web 页面时，客户端监控仍会围绕用户体验采集数据，比如页面打开速度（测速）、页面稳定性（JS）和外部服务调用成功率（API），这3个方面的数据反映了web页面的监控度。

　　　　b) 业务层监控：对于业务层，可按需深度定制监控系统，实现对业务属性的监控告警功能，生成业务数据监控大屏。比如用户访问QPS、DAU日活、转化率、业务接口（如登录数、注册数、订单量、支付量、搜索量）等都是常见的监控对象。

　　　　c) 应用层监控：主要是对分布式应用和调用链应用的性能进行管理和监控，如对Spring Boot、JVM信息、服务链路、Dubbo等应用在进行诸如RPC调用、Trace链路追踪动作时产生的数据进行监控。

　　　　d) 中间件监控：监控的主要对象是框架自身的埋点、延迟、错误率等。这里的中间件包括不限于消息中间件(RabbitMQ、Kafka、RocketMQ等),数据库中间件(MySQL、Oracle、PostgreSQL、TIDB、PolarDB等),数据库连接池中间件(HikariCP、Druid、BoneCP等)，缓存中间件(Redis、Memcached等)和Web服务中间件(Tomcat、Jetty等)。

　　　　e) 系统层监控：如何对系统层进行监控，是运维工程师比较关心的问题。小米通过Open-Falcon提炼出了Linux系统的运维基础采集项，主要包含了 CPU、Load、内存、磁盘、I/O、网络相关参数、内核参数、ss统计输出、端口、核心服务的进程存活情况、关键业务进程资源消耗、NTP offset采集、DNS解析采集等指标。这些都可以作为系统层监控的关键指标。另外网络监控也是系统监控中很重要的部分，对交换机、路由器、防火墙、VPN进行的监控都属于网络监控的范畴，内网和外网的丢包率、网络延迟等也都是很重要的监控指标。

二、监控产品分类

　　近年来，随着 Kubernetes 为代表的云原生技术的崛起，软件的研发流程已经逐步进化到 iaas 层、Kubernetes 层、团队组织层。

　　Kubernetes 是强大的声明式容器编排工具，可以提供计算、存储、网络等功能接口，通过这些接口以插件形式实现相关功能。这种灵活、开放的设计理念使 kubernetes 非常容易集成外部工具，强化相应的功能。所以 Kubernetes 逐渐发展成为中间件和微服务的"底座"，同时也成为企业上云的"底座"。Kubernetes 和 iaas 有着天然的联系，Kubernetes 已经可以和诸如 OpenStack、AWS、Google云等iaas 云平台进行集成，在弹性、敏捷、动态方面，它都可以发挥巨大作用。在 iaas 层可以实现对硬件、网络等的监控；在 Kubernetes 层可以实现对日志、健康检查、自愈系统、分布式链路等的监控，Kubernetes 层作为中间件和微服务的"底座"，很多产品的监控都可以在这一层完成。

Zabbix:
　　Zabbix 是由 Alexei Vladishev 开源的分布式监控系统，支持多种采集方式和采集客户端，同时支持 SNMP、IPMI、JMX、Telnet、SSH 等多种协议。它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告警。
　　Zabbix 核心组件主要是 Agent 和 Server。其中 Agent 主要负责采集数据并通过主动或者被动的方式将采集数据发送到 Server/Proxy。除此之外，为了扩展监控项，Agent 还支持执行自定义脚本。Server 主要负责接收 Agent 发送的监控信息，并进行汇总存储、触发告警等。
　　Zabbix Server 将收集的监控数据存储到 Zabbix Database 中。Zabbix Database 支持常用的关系型数据库，如 MySQL、PostgreSQL、Oracle 等（默认是 MySQL），并提供 Zabbix Web 页面（PHP 编写）数据查询。
　　由于使用了关系型数据存储时序数据，Zabbix在监控大规模集群时常常在数据存储方面捉襟见肘。所以从 4.2 版本后 Zabbix开始支持 TimescaleDB 时序数据库，不过目前成熟度还不高。
Open-Falcon:
　　Open-Falcon 是小米开源的企业级监控工具，用 Go 语言开发而成。这是一款灵活、可扩展并且高性能的监控方案，包括小米、滴滴、美团等在内的互联网公司都在使用它。它的主要组件包括：
　　Falcon-agent：这是用 Go 语言开发的 Daemon 程序，运行在每台 Linux 服务器上，用于采集主机上的各种指标数据，主要包括 CPU、内存、磁盘、文件系统、内核参数、Socket 连接等，目前已经支持 200 多项监控指标。并且，Agent 支持用户自定义的监控脚本。
　　Hearthbeat server：简称 HBS 心跳服务。每个 Agent 都会周期性地通过 RPC 方式将自己的状态上报给 HBS，主要包括主机名、主机 IP、Agent 版本和插件版本，Agent 还会从 HBS 获取自己需要执行的采集任务和自定义插件。
　　Transfer：负责接收 Agent 发送的监控数据，并对数据进行整理，在过滤后通过一致性 Hash 算法发送到 Judge 或者 Graph。
　　Graph：这是基于 RRD 的数据上报、归档、存储组件。Graph 在收到数据以后，会以 rrdtool 的数据归档方式来存储，同时提供 RPC 方式的监控查询接口。
　　Judge 告警模块：Transfer 转发到 Judge 的数据会触发用户设定的告警规则，如果满足，则会触发邮件、微信或者回调接口。这里为了避免重复告警引入了 Redis 暂存告警，从而完成告警的合并和抑制。
　　Dashboard：这是面向用户的监控数据查询和告警配置界面。
Prometheus:
　　Prometheus 的基本原理是通过 HTTP 周期性抓取被监控组件的状态。任意组件只要提供对应的 HTTP 接口并且符合 Prometheus 定义的数据格式，就可以接入 Prometheus 监控。
　　Prometheus Server 负责定时在目标上抓取 metrics（指标）数据并保存到本地存储。它采用了一种 Pull（拉）的方式获取数据，不仅降低客户端的复杂度，客户端只需要采集数据，无需了解服务端情况，也让服务端可以更加方便地水平扩展。
　　如果监控数据达到告警阈值，Prometheus Server 会通过 HTTP 将告警发送到告警模块 alertmanger，通过告警的抑制后触发邮件或者 Webhook。Prometheus 支持 PromQL 提供多维度数据模型和灵活的查询，通过监控指标关联多个 tag 的方式，将监控数据进行任意维度的组合以及聚合。

 三、MDD 思想：从指标到洞察力

　　运行中的代码才是有价值的，以 Prometheus 为代表的遵从 MDD 理念的产品，并不会做静态代码检查，而是会对执行过的代码、代码执行次数、错误位置、错误数量等信息进行运行时动态监控。

3.1 MDD理念的概述

　　MDD(Metrics-Driven Development) 主张整个应用开发过程由指标驱动，通过实时指标来驱动快速、精确和细粒度的软件迭代。指标驱动开发的理念，可以让程序员可以帮助产品经理和运维人员一起关注相关的业务指标。

　　MDD 可以使所有可以测量的东西都得到量化和优化，进而为整个开发过程带来可见性，帮助相关人员快速、准确地做出决策，并在发生错误时立即发现问题并修复。MDD 可以感知应用的"脉搏"，并不断根据运行时的数据提供改进策略。

　　MDD 的关键原则如下：

• 将指标分配给指标所有者(业务、应用、基础架构等)。
• 创建分层指标并关联趋势。
• 指定决策时使用的指标。

　　TDD 主张在业务代码之前先编写测试代码，MDD 则主张将上线、监控、调试、故障调查及优化等纳入设计阶段，而不是等到实施后才补充。相对于通过指定各种复杂、严格的研发规定、以及开发无数的评审、研讨会来确保软件的安全发布、稳定运行，MDD理念的特别之处在于应用程序本身。在 MDD 理念下，采集必要的监控信息，通过持续交付方式进行快速迭代并进行反馈和修正，所有决定都是基于对不断变化的情况的观察做出的。在软件的设计初期就包括 Metrics 设计，设计一套规则来评价系统的稳定性、健康状态，并监控其他考核目标，将这些作为服务本身的 KPI。通过应用 MDD 理念，可以将 Dev 与 Ops 之间或多个 Dev 团队之间出现的责任博弈降低到最低，甚至使矛盾完全消失，这也有利于团队稳定发展。因此，MDD 可以用于决策支持、预测趋势、测试系统的补充、关联分析等。

3.2 指导监控实践的3大方法论

　　在了解了 MDD 理念后，大家还需要了解一些基于指标的方法论，这里以小知识点的形式总结如下：

　　1、Google 的四大黄金指标：

　　有4个来自 Google SRE 手册的黄金指标，这 4 个指标主要针对应用程序或用户部分。

• • 延迟(Latency)：服务请求锁需耗时，例如 HTTP 请求平均延迟。需要区分成功请求和失败请求，因为失败请求可能会以非常低的延迟返回错误结果。
  • 流量(Traffic)：衡量服务容量需求(针对系统而言)，例如每秒处理的 HTTP 请求数或者数据库系统的事务数量。
  • 错误(Errors)：请求失败的速率，用于衡量错误发生的情况，例如 HTTP 500 错误数等显式失败，返回错误内容或无效内容等隐式失败，以及由策略原因导致的失败(比如强制要求响应时间超过 30ms 的请求为错误)。
  • 饱和度(Saturation)：衡量资源的使用情况，例如内存、CPU、I/O、磁盘使用量(即将饱和的部分，比如正在快速填充的磁盘)。

　　2、Netflix 的 USE 方法：

　　USE 是 Utilization(使用率)、Saturation(饱和度)、Error(错误)的首字母组合，是 Netflix 的内核和性能工程师 Brendan Gregg 提出的，主要用于分析系统性能问题，可以知道用户快速识别资源瓶颈及错误。

• 使用率：关注系统资源的使用情况。这里资源主要包括但不限于 CPU、内存、网络、磁盘等。100%的使用率通常是系统性能瓶颈的标志。
• 饱和度：例如 CPU 的平均运行排队长度，这里主要是针对资源的饱和度(注意，不同于四大黄金指标)。任何资源在某种程度上的饱和都可能导致系统性能下降。
• 错误：错误数。例如，网卡在数据包传输过程中检测到以太网络冲突了14次。

　　3、Weave Cloud 的 RED 方法：

　　RED 方法是 Weave Cloud 基于 Google 的 4 个黄金指标再结合 Prometheus 及 Kubernetes 容器实践得出的方法论，特别适用于对云原生应用以及微服务架构应用进行监控和度量。在四大黄金指标的原则下，RED 方法可以有效地帮助用户衡量云原生以及微服务应用下的用户体验问题。RED 方法主要关注以下 3 钟关键指标：

• • (Request) Rate：每秒接受的请求数。
  • (Request) Errors：每秒失败的请求数。
  • (Request) Duration：每个请求所花费的时间，用时间间隔表示。

　　4、最佳实践：

　　在遵循 Google 四大黄金指标的前提下，对于在线系统，结合 RED 方法和缓存命中率方式进行监测；对于离线系统或者主机监控，以 USE 方法为主进行监测；对于批处理系统，可以采用类似 Pushgateway 的形式进行监控。

四、监控系统选型和误区讨论

4.1 黑盒监控和白盒监控

　　《SRE: Google 运维解密》 一书中指出，监控系统需要有效支持白盒监控和黑盒监控。

4.2 监控检查的两种模式——拉取和推送

　　监控系统执行监控检查的模式主要有拉取（Pull）和推送（Push）两种。这两种模式究竟哪种更好？对此，监控领域内部存在相当大的争议。

　　拉取模式（简称拉模式），是一种从监控对象中通过轮询获取监控信息的方式。拉模式更多拉取的是采样值或者统计值，由于有拉取间隔，因此并不能准确获取数值状态的变化，只能看到拉取间隔内的变化，因此可能会有一些毛刺现象，需要进一步进行数据处理。监控和性能测试更关注 p95/p99 位的原因就是存在长尾效应。数据采集过程中对数据进行的定义、采样、去尖刺等处理操作也是非常重要的。

　　拉模式的优点是告警可以按照策略分片，告警模块只需要拉取主机需要的数据，且可以完美支持聚合场景；

　　拉模式的缺点在于监控数据体量非常庞大，对存储有较高的要求，实战中可能还需要考虑数据的冷热分离。

　　推送模式（简称推模式），是应用程序基于事件主动将数据推向监控系统的方式。

　　推模式的优点是实时性好，一旦触发一个事件就可以立刻收集发送信息。

　　推模式的缺点是由于事件的不可预知性，大量的数据推送到监控系统，解析和暂存都会消耗大量的内存，这可能对监控的进程产生影响。

　　Prometheus 在收集数据时，主要采用拉模式（服务端主动去客户端拉取数据），当然它也支持接收推送到 Pushgateway 的事件；而以 Zabbix 为代表的传统监控系统采用推模式(客户端发送数据给服务端)。