概述

监控系统到底是解决什么问题的？
通常所谓的监控系统，其实只是可观测性OAP三大支柱之一，何为可观测性OAP三大支柱？
作为OAP支柱之一的指标监控系统，具体有哪些特点？

监控系统到底是解决什么问题的？

最初就是系统出问题了我们能及时感知。
但是随时的时代的发展，白开水对监控系统提出了更多的诉求，比如：

• 了解趋势，知道系统在未来的某个时刻可能出问题
• 了解系统的水位情况，可以在资源不足的时候及时扩容
• 把脉系统，感知到哪里需要优化，比如一些中间件的参数的调优
• 洞察业务，知道业务发展的情况，业务异常了也能及时感知
  监控系统越来越重要，不但可以解决上面这些诉求，还能沉淀sop知识，以及稳定性相关的知识。

OAP可观测性三大支柱

监控平台

通常所谓的监控系统，其实只是指标监控，体现在图表上的一条折线图，比如某个机器的CPU利用率，或者某个数据库实例的流量，或者网站的在线人数，都体现为随着时间变化的一条线。
指标监控只能处理数字，历史数据存储成本较低，实时性好，生态庞大，是可观测性领域里最重要的一根支柱。有很多系统都是只处理指标数据，比如 Zabbix、Open-Falcon、Prometheus、Nightingale 这些系统在业内有很广泛的应用。

日志平台

除了指标监控，另一个重要的可观测性支柱，是日志。从日志中也可以得到很多信息，对于了解软件的运行情况、业务的运营情况，都很关键。比如操作系统的日志、接入层的日志、服务日志，都是重要的数据源，从操作系统的日志中，可以得知很多系统级的事件发生了，从接入层的日志中，可以得知有哪些域名、IP、URL 收到了访问，是否成功以及延迟情况等，从服务日志中可以查询到 Exception 的信息，调用堆栈等，对于排查问题，非常关键。
处理日志这个场景，也有很多专门的系统，如ELK。

链路追踪

除了了指标和日志，可观测三大支柱还有一环，即：链路追踪。随着微服务的普及，原本的单体应用被拆分成很多个小的服务，服务之间有错综复杂的调用关系，一个问题，是因哪个模块导致的，排查起来并不容易。
链路追踪的思路是，以请求串联上下游模块，为每个请求生成一个随机字符串作为请求ID，服务之间调用的时候把这个ID逐层往下传递，各层分别花费了多久时间，是否正常处理，都可以收集起来附到这个请求ID上，后面追查问题时，拿着请求ID就可以把串联的所有信息提取出来。链路追踪这个领域也有很多产品，比如 Skywalking、Jaeger、Zipkin 等，都是个中翘楚。

小结

虽然OAP可观测性领域划分了3大支柱，实际上他们之间是有很强的关联关系的。比如我们经常会从日志中提取指标，转存到指标监控系统，或者从日志中提取链路信息来做分析，这在业界都有诸多实践。

指标监控产品特点

为了重点探讨指标监控，首先要了解何为指标？指标就是衡量目标的数值。
比如 Linux 操作系统，我们可以从多个方面去衡量它的负载情况，比如 CPU 的使用率方面：

• cpu_usage_system（CPU内核态时间占比）
• cpu_usage_user（CPU用户态时间占比）
• cpu_usage_idle（CPU空闲时间占比）
  内存方面则有:
• mem_available_percent（内存可用率）
• mem_used（内存使用量）
  磁盘方面则有:
• disk_used_percent（磁盘使用率）
• diskio_write_bytes（磁盘写入量）

一般，会在服务器内安装一个客户端软件，作为一个常驻进程运行，按照一个固定的频率来采集（比如15秒），采集到数据之后，发给服务端存储和分析展示。

故而，指标监控的几个特点：
一般只处理数值数据，不处理字符串（个别监控系统也可以处理字符串，大部分都不处理）
指标数据是时序数据，每隔一个固定的间隔就采集一次，把采集到的数据上报，永不停歇
指标数据是采样数据，比如15秒采集一次，只能拿到采集的那一时刻的数据，如果把采集频率调小，可以获取更丰富的更精确的数据，但是代价会更大，需要更多存储，更多算力来处理，实际生产环境，30秒或者60秒就够了，如果对精度要求高，15秒就够了，再小的频率，意义不大，因为监控数据的核心是感知异常和感知趋势，如果出现异常，一般异常会持续一段时间，偶尔的异常通常也不需要关注，所以采样数据通常也可以感知到异常，而对于趋势，如果查看的时间越大，采集频率可以越大，如果看1小时的数据，15秒一个点是可以的，如果看1年的数据，每小时一个点的频率也完全够用，太多的数据点，可能会把浏览器打爆
因为是处理的时序数据，每个值都带有一个时间戳，这种数据很有规律，行业内出现了专注于这类数据处理的数据库，称为时序数据库，比如InfluxDB、VictoriaMetrics、M3DB等，监控系统依赖一个时序数据库，也就变成了一个典型的架构特点
架构上来说，指标监控系统除了依赖一个时序库，还必然需要一个采集器去采集各种指标数据，其次就是告警引擎和可视化展示，典型的系统架构如下：

image.png

Collector表示采集器，专门做采集器的开源项目也有很多，比如 Telegraf、Grafana-Agent、Datadog-Agent、Categraf，以及，Prometheus 生态的各种 Exporter。橙色部分是监控的服务端，通常包括UI展示能力和服务端告警引擎。最后，依赖一个时序数据库：Time Series Database。

参考

龙渊秦五专栏连载：《说透运维监控系统》