监控系统概述

概述

参考：

• 马哥视频
• 公众号，贵司的监控系统处于什么时代

Network Monitor Server(网络监控服务器，简称 NMS)。最早的时候，在产生大规模监控需求前，一般都是通过在本机安装监控系统来实现对单台主机进行监控，后来当主机越来越多，这种让每台设备各自监控的方式显然是不行的，这时候为了解决这个问题，一般采用的方式是通过一个 NMS 来监控各个 node host，这台 NSM 要求能够定期得向每个被监控 node host 的传感器发送数据采集请求，各 node 收到请求后，收集对方请求的本地指标来返回给 NMS

NMS 会周期得完成数据采集，然后进行本地存储。为了实现简单便捷对被监控节点进行管理，就出现了 SNMP 这个协议。SNMP 是一种基于 UDP 的 7 层协议。

监控协议：

• SNMP # 详见 SNMP(传统监控标准)
• HTTP # 详见 HTTP(新监控标准)

时间序列数据

在监控体系里，被采集的数据一般就称为 时间序列数据。通常人们将每一条时序数据，也称为 Metrics(指标)。一系列的指标，就是用来总结被监控目标在一段时间内的运行状态。

Metrics(指标) 就是指随时间变化的数据。不管是通过 SNMP 还是 HTTP 中的任何一种协议，从被监控对象采集到的状态信息，都统称为 Metrics(指标)。

监控系统组件

一套完整的监控系统，通常都包含实现下面几种功能的组件：

• 指标数据采集(有时候 采集 也称为 刮擦/抓取，英文一般是 Scrape)
• 指标数据存储
• 指标数据趋势分析及可视化
• 告警

常见的监控对象

系统层监控

• 硬件状态
• 系统监控：CPU、Load(负载)、Memory、DiskIO、Processes、Kernel Parameters 等等
• 网络监控：网络设备、网络延迟、丢包率 扽等
• 端口存活状态、JVM 的状态等

中间件及基础设施类系统监控

• 消息中间件：Kafka、RabbitMQ、RocketMQ 等
• Web 服务器容器：Tomcat、Jetty 等
• 数据库及缓存：MySQL、PostgreSQL、MogoDB、ElasticSearch、Redis 等
• 数据库连接池：ShardingSpere 等
• 存储系统：Ceph 等

应用层监控

• 用于衡量应用程序代码的状态和性能
• 状态码、时延、QPS 等

业务层监控

• 用于衡量应用程序的价值，例如电子商务网站删的销售量
• QPS、DAU 日活、转化率、成功率、增长速度 等等
• 业务接口：登陆数、注册数、订单量、搜索量、支付量 等等。

监控指标选择原则：

• 选择能够表示一个主体是否稳定的指标，如果不是这个主体本身的指标，或者不能标识主体稳定性的，就要排除在外
• 优先选择与用户体验强相关或用户可以明显感知的指标

监控体系

监控分为两种：

• 白盒监控# 善于发现系统中单个组件的问题，但是很难覆盖系统端到端的健康检查。
• 黑盒监控# 可以提供最接近真实用户的系统端到端的检测。

白盒监控

白盒监控就是传统意义上的监控，通过指标采集、存储、展示等一系列操作，来观察被监控目标的运行状态。

通常，白盒监控体系包含如下几个步骤：数据采集–>数据存储–>数据展示|告警

数据采集

通过采集程序来采集相关数据，比如温度，磁盘用量，网卡流量，服务是否可用，进程是否运行等，通常都需要一个客户端来采集数据，并主动推送 或者 被动等待拉取，以便将数据统一保存起来。

以被监控对象为行为主体，数据采集主要有 2 种模式，分为：主动推送和被动拉取，这两种采集方式各有利弊。

主动推送

优点

• 不存在目标发现问题，新应用上线后自动可以加入监控
• 监控系统架构简单，应用只需调用接口上报数据即可

缺点

• 缺乏准确的需要监控的目标数
• 难以区分合法和非法的数据上报（权限验证可以有所帮助）
• 当数据没有准时推送时，监控很难判断是应用 overload 或者 dead 了
• 时钟不同步导致的时间序列对齐问题

被动拉取

优点

• 所有时间序列都是对齐的
• 知道需要抓取的准确目标数
• 容易区分应用 overload 或者 dead，通过记录每次抓取花费的时间

缺点

• 需要额外机制发现新添加的监控目标
• 需要更复杂的 library 或者 agent 给应用吐数据
• 难以监控 short-live 的应用，比如 cronjob

上面两种采集方法的缺点都是可以被改善的，取决于愿意为之花费的工程师时间。

总体来说被动拉取方式在体现监控的完备性上更好一些，其最大的短板是监控 short-live 应用，可以让这些应用主动推送到 proxy 应用，之后被动拉取。目标发现则可以结合公司内部名字系统实现。

数据存储

时间序列采集之后就是怎么存储的问题了，主流存储有 3 种方式：

1. RRD（Round Robin Database）
   1. 老牌的 Nagios，collectd 和 Ganglia 采用的是这种存储方式；graphite 采用的 Wisper 也是基于 RDD 的基本思想设计的。特点是采用基于圆形队列的数据库(Circular buffer based database），数据库大小在系统初始化后是恒定的，不用担心数据存储空间不足。缺点也是在于数据库大小恒定，因此只能保存一定时间的数据，而且时间序列的间隔在数据库初始化后不能调整。另外一个致命的缺点是受单机磁盘限制，当需要监控的规模很大时数据存储和读取瓶颈。
2. Relational DataBase(关系型数据库)
   1. Zabbix 使用 MySQL 存储时间序列数据。MySQL 也受到单机磁盘大小和性能限制，但是可以通过 partition 缓解。
3. Time Series Database(时间序列数据库)
   1. 用 No-SQL 存储时间序列的应用有很多：Opentsdb，kairosdb，newts。使用 No-SQL 存储时间序列没有单机磁盘限制，数据量大时不存在扩展问题。

时间序列的存储一般不需要考虑数据存储的 schema，客户端只通过简单 API 存取时间序列数据，具体的存储 schema 由底层存储系统（MySQL or No-SQL）决定，但是不同的存储 schema 决定了数据查询/展示的性能。

RRD 和 Relational DataBase 都受限于单机磁盘的性能，SSD 可以显著提高数据的读取性能，在数据量大时 MySQL 可以通过 partition 进行扩展，RRD 无法扩展。MySQL 虽然可以进行 paritition，但是复杂度和维护成本也很高。

Time Series Database 天生就适合存储时间序列，可以提供超大的存储能力和读性能，但是也需要考虑维护成本，如果公司有 No-SQL 公共服务可以适用，那 No-SQL 存储时间序列是不二的选择。

数据展示

采集到的数据一般为时间序列数据，根据时间流逝产生的采样点收集到的数据，把所有采集点所采集到的数据连成线，就可绘制出来一个数据趋势图。数据展示需要具备以下绘图能力：

• 数据汇聚，根据原始数据计算生成新的时间序列并画图
• 不同时间序列之间的合并计算，一般用来计算比例关系
• 多条时间序列汇总展示，用来查找事件相关性。
• 不同的图表样式，针对不同场景
• 比如每隔 1 分钟采集一次网卡流量，把 1 个小时内的每分钟采集到的网卡流量按照横向为时间轴，纵向为流量数轴的方式，展现出来，并把每个时间点都连成线，形成如有图的样子，这就是以时间序列产生的数据趋势图

数据展示有 2 个应用场景

• 一是提供给运维人员定位问题时使用，需要能够快速的编辑生成新的图表验证猜想，所以需要灵活易用；
• 二是业务人员查看统计数据，需要强大的综合汇总以反映系统总体运行状况。

数据展示有时会涉及大量时间序列的短时间内读取，亦或是很多人同时有绘图查询需要读取数据，底层的数据存储格式是影响查询性能的主要因素。底层数据存储的 schema 影响查询性能，合理的架构设计能够极大的提升查询性能。 常见的优化点有：

• 冷热数据分离：近期的数据是最容易被查询的，可以增加内存存储的 replica 数（Bigtable/HBase)，历史数据可以放在硬盘上。
• downsample：不仅减少存储，也降低了查询成本，但是需要好的策略降低对数据准确性的影响
• 资源隔离：不同部门时间序列数据存储在不同 server 上，减少相互影响。

告警

异常触发

数据采集到了，也存储好了，图表展示也没有问题了，但是没人会愿意每天盯着图表去发现问题，根据历史经验，通过定义一些条件触发某些动作的需求应运而生。 这需要一个 rule evaluatoin 引擎，可以是单独的进程也可以和数据采集集成在一起。输入是时间序列和用户定义的 rule，当时间序列符合 rule 里定义的状态时执行指定的动作，一般的动作包括：执行一个命令（修复脚本），发送定义好的内容到外部系统，等。

对引擎系统的要求有：

• 规则定制：灵活，强大。因为需要满足不同部门不同应用的需求，必须灵活且强大。
• 规则依赖：service 内部依赖、service 外部依赖。很少有大的应用系统不依赖于其他系统，所以异常触发的判断一定要能够根据依赖系统的异常触发情况进行抑制，没有必要因为某个组件的异常而触发一系列其他组件的异常（这些异常根本原因是一个）。

报警发送

异常触发之后，可以自动修复的一定是自动化去解决，当自动化无法解决的异常发生之后，就需要发送警报给人来介入了。

最基本的报警发送是发送邮件，高级一点的可以支撑短信和语音呼叫，现在手机普及了有的公司可能有手机软件可以接收报警信息了。

发送的警报内容一般包含：

• 发生问题的组件信息
• 具体的问题描述，是 error rate 高了还是程序 down 了
• 问题的持续时间

高级的报警内容还可能包含：

• 产生这个警报的时间序列和触发的 rule 定义
• 如何处理这个问题的文档链接
• 如何暂时关闭这个报警(处理需要较长时间，不想再次收到同样的报警)

黑盒监控

黑盒监控与白盒监控不太一样。黑盒监控并不去采集被监控目标主动暴露出来的一些可监控指标数据。而是让客户端模拟用户的行为，对监控目标执行一些操作，并以时间序列的方式存储这些操作所导致的结果，通过对这个结果数据进行监控。

常见的黑盒监控方式：

• 使用 HTTP 探针、TCP 探针、DNS 探针、ICMP 探针 等用于检测站点、服务的可访问性、服务连通性、服务效率等。

以 etcd 集群的可用性来举例，我们可以实现一个探测用例，逻辑是对 etcd 做 create/get/delete/txn 等等操作，并记录每个操作的成功率/消耗时间，当成功率低于 100% 或消耗时间超过容忍阈值后，触发报警。我们将周期高频运行这个 etcd 的探测用例，同时对于 etcd 集群的任何变更都会发出一个事件 event 触发这个 etcd 探测立即运行，这样就能尽量确保第一时间发现 etcd 可用性故障了。同时，当 etcd 集群因为某些原因不可用了，我们也可以通过手动触发等其他方式做探活，也能第一时间得到是否恢复的信息。

黑/白盒监控的比较

两者比较：黑盒监控相较于白盒监控最大的不同在于黑盒监控是以故障为导向当故障发生时，黑盒监控能快速发现故障，而白盒监控则侧重于主动发现或者预测潜在的问题。一个完善的监控目标是要能够从白盒的角度发现潜在问题，能够在黑盒的角度快速发现已经发生的问题。

定期巡检

在大规模集集群/系统场景下，数据一致性是一定会面临的难题。数据不一致，将导致一些隐患，可能会在未来引发某些确定性的故障。

相比于黑盒探测面对的未知故障场景，定向巡检的目标是对集群的已知风险点做扫描。

我们希望 一个程序 能够定期对整个集群/链路做定向的巡检，找出这些数据不一致的点，判断数据不一致是否可能引发风险，从而能够防患于未然，治未病。

比如 etcd 冷热备多集群覆盖不全，可能导致集群遇到故障无法快速恢复。那么我们就定期对 etcd 的冷热备覆盖情况做定向巡检，找出没有覆盖推平的集群，并告警。比如 集群风控系统没有全集群链路覆盖，限流配置没有全集群链路推平，可能导致某些故障场景引发集群全面崩溃，我们定期对风控配置全网扫描，判断是否可能导致故障，找出这些隐藏的已知风险点并告警。

著名的监控方法论

Google 的四个黄金指标

常用于在服务级别帮助衡量终端用户体验、服务中断、业务影响等层面的问题。适用于应用及服务监控

• Latency(延迟)
  • 服务请求所需要的时长，例如 HTTP 请求的平均延迟。需要区分失败请求和成功请求
• Traffic(流量)
  • 衡量服务的容量需求，例如每秒处理的 HTTP 请求书或者数据库的事务数量
• Errors(错误)
  • 请求失败的速率，用于衡量错误发生的情况
  • 例如，HTTP 500 错误数量等显式失败，返回错误内容或无效内容等隐式失败，以及由策略原因导致的失败(例如强制要求响应时间超过 30 毫秒的请求视为错误)
• Saturation(饱和度)
  • 衡量资源的使用情况，用于表达应用程序有多“满”
  • 例如 内存、CPU、I/O、磁盘等资源的使用量

Netflix 的 USE 方法

全称为 Utilization Saturation and Errors Method。主要用于分析系统性能问题，可以指导用户快速识别资源瓶颈以及错误的方法。应用于主机指标监控

• Utilization(使用率)
• Saturation(饱和度)
• Errors(错误)

Weave Cloud 的 RED 方法

Weave Cloud 基于 Google 的四个黄金指标的原则下，结合 Prometheus 以及 Kubernetes 容器实践，细化和总结的方法论，特别适合于云原生应用以及微服务架构应用的监控和度量。

• (Request)Rate # 每秒接收的请求数
• (Request)Errors # 每秒失败的请求数
• (Request)Duration # 每隔请求所花费的时长

常见的大型监控工具

著名的开源监控工具：zabbix，zennos，opennms，cacti，nagios(icinga)，ganglia

1. Cacti：是一套基于 PHP,MySQL,SNMP 及 RRDTool 开发的网络流量监测图形分析工具。
   1. 本身不具备报警能力，需要安装第三方插件才可以
   2. rrd 存储系统：
2. Nagios：在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。
   1. 本身不具备展现数据趋势图功能
3. zabbix：同时具有 Cacti 与 Nagios 的特点
   1. zabbix server
   2. zabbix database
   3. zabbix web gui
   4. zabbix proxy 分布式数据采集
   5. zabbix agent 每台需要监控的设备上都要装的代理
   6. Passive checks related：监控 Server 主动来找 agent 收取监控数据
   7. Active checks related：agent 主动上传监控数据给监控 Server
4. Prometheus # 基于 HTTP 的新时代监控

HTTP 黄金信号（HTTP Golden Signals）

指标来作为 HTTP（即 API 层）连接健康状况的三个关键指标，这三个指标分别是：

• HTTP 请求速率；
• HTTP 请求延迟；
• HTTP 请求响应码。