每个关注高可用的人都应该了解的监控知识：监控圈子的行业黑话（上）本文仅对监控在稳定性保障体系中的重要性进行了阐述，并介绍

作者：Tshb

标签：#稳定性保障体系 #监控概念 #指标描述方式 #Prometheus #InfluxDB

引言

在当今的技术环境中，尤其是对于关键业务和服务，高可用性及稳定性已经成为一个基本要求。

那到底何为高可用性及稳定性？

其指的是系统能够持续不间断地提供服务，即便在面临硬件故障、软件故障或其他影响服务的问题时，也能够确保服务的连续性和用户的访问需求。

而要保证系统的稳定性，一是要保证系统在任意时间都可以访问；另一方面则是要保证系统性能满足合理的预期。

但事无绝对，无论系统设计的多么精良，都存在故障的可能：硬件可能会损坏，软件可能有 bug，人为操作也可能出错，更别说自然灾害等不可预测的因素。

所以稳定性保障体系的核心说白了还是一件事：减少故障。

让我们先看一下一个故障的生命周期：

故障生命周期，来源：@Tshb

通过分析一个故障的生命周期，可见减少故障可以从两个层面理解：一是做好常态预防，防止故障发生；二是在故障发生后，能够立即发现，迅速止损，减少故障时长。

这就引入了监控这个可以有效减少故障的重要手段。

在常态预防阶段，监控系统通过收集系统的状态数据，可以直观地反映出系统的实时状态，且通过对历史数据的趋势分析，也可以在一定程度上识别和预测出潜在的故障点，从而避免故障发生。

而当故障发生的时候，监控系统可以通过设定的阈值触发告警，及时通知到运维及开发团队，帮助他们快速找到故障点，从而减少故障的处理时间。

同时，监控还可以为系统的性能调优提供数据支撑，让技术人员能够提前发现系统及中间件的性能瓶颈或不合理的配置。

正因如此，几乎所有优秀的软件或平台，在其架构设计中都考虑了各类故障的发现和应对手段，内置了监控数据的暴露方法，如 MySQL 的一些全局变量、Redis 的 info all 命令、Kubernetes 组件的 metrics 接口等。虽然方式各不相同，但都可以让用户了解其运行时的健康状况。是否可被监控和观测，正是评价软件架构好坏的一个重要标准。

可以说，无论是运维、开发还是架构师，每个关注高可用、关注服务稳定性的技术人员，想要在技术这条路上走得更远，都应该了解一些监控相关的知识。

那么现在，就让我们正式进入本文的主题，了解一下监控圈子里的一些行业黑话，即监控领域的一些关键概念。

监控指标

监控指标是用来量化分析系统或应用性能的数值度量，简单来说就是数值类型的监控数据。

具体指标因监控目标的不同而不同，对于一个 web 服务器，监控指标可以是请求次数、请求相应时间等；而对于一个数据库，它可以是活跃连接数或查询数等。

只要能够帮助理解应用表现或解决问题，都可以让其作为一个监控指标。

监控指标描述方式

不同的监控系统对于监控指标有不同的描述方式，比较典型的有下面几种：

1. 全局唯一字符串作为指标标识

监控指标通常是一个全局唯一的字符串，如某机器的内存利用率可以表示为： host.10.2.3.4.mem_used_percent

这个字符串中包含了机器的信息，也包含了指标名，可以唯一标识一条监控指标。
假设监控数据采集频率是 30 秒，2 分钟采集了 4 个数据指标，JSON 格式可描述如下：

  "name": "host.10.2.3.4.mem_used_percent",
  "points": [
    {
      "clock": 1662449136,
      "value": 45.4
    },
    {
      "clock": 1662449166,
      "value": 43.2
    },
    {
      "clock": 1662449196,
      "value": 44.9
    },
    {
      "clock": 1662449226,
      "value": 44.8
    }
  ]
}

老一些的监控系统和采集器，如 Graphite 和 Collectd 就是这样标识监控指标的。
这种描述方法的优点是一目了然，从指标名称就能看出监控的是什么信息；缺点是缺少对维度信息的描述，不便于做聚合计算。

在监控系统刚刚开始发展的时候，因为主要关注的还是对硬件设备、数据库的监控，不会有太多维度的信息，所以其缺点并不明显。但随着时代的发展，业界开始关注应用层面的监控时，便逐渐暴露出了这个问题。

如当想统计不同 METHOD、不同响应码的 HTTP 请求数量，就需要针对每个 URL 和每个 METHOD 都创建监控指标，计算时还需要对指标标识进行正则匹配，然后再通过匹配到的标识拉取指标数据进行计算，乱且麻烦。

2. 标签集的组合作为指标标识

随着时序数据库 OpenTSDB 诞生而诞生的一种描述指标的方式，示例如下：

mysql.bytes_sent 1287333217 6604859181710 schema=foo host=db1
mysql.bytes_received 1287333232 327812421706 schema=foo host=db1
mysql.bytes_sent 1287333232 6604901075387 schema=foo host=db1
mysql.bytes_received 1287333321 340899533915 schema=foo host=db2
mysql.bytes_sent 1287333321 5506469130707 schema=foo host=db2

其中第一段是指标名，第二段是时间戳（单位是秒），第三段是指标值，其余部分则称为标签，每个标签都是 key=value 的格式，多个标签之间使用空格分隔。可见这种方法更加灵活，也更方便聚合计算。

新时代的时序库大都引入了标签的概念，比如 Prometheus，其甚至认为指标名也是一种特殊的标签（其标签 key 是 name ）。

3. Influx 指标格式

时序数据库 InfluxDB 描述指标的方式，示例如下： mesurement,labelkey1=labelval1,labelkey2=labelval2 field1=1.2,field2=2.3 timestamp

可总结为： measurement,tag_set1,tag_set2 field_set1,field_set2 timestamp

其中 tag_set 为可选项，tag_set 与 measurement 之间用逗号分隔，多个 tag_set、多个 field_set 之间也用逗号分隔，其他部分之间用空格分隔，时间戳的单位是 ns。

将上述 OpenTSDB 的指标示例改写成 Influx 格式，结果如下：

mysql,schema=foo,host=db1 bytes_received=327812421706,bytes_sent=6604901075387 1287333232000000000
mysql,schema=foo,host=db2 bytes_received=340899533915,bytes_sent=5506469130707 1287333321000000000

这种格式可以大大降低标签的重复度，field_set 越多的情况下它的优势越明显，可以节省更多的网络传输带宽。

小结

由于篇幅所限，本文仅对监控在稳定性保障体系中的重要性进行了阐述，并介绍了监控指标及其描述方式。

对于监控领域中的其他关键概念，如监控指标类型、时序数据与时序库、告警收敛、告警闭环等，将在下半部分中继续为大家说明，敬请关注~

最后，将本文重点总结如下，感谢大家的阅读~

监控领域关键概念小结，来源：@Tshb

参考资料：

关注Mapmost，持续更新GIS、三维美术、计算机技术干货

Mapmost是一套以三维地图和时空计算为特色的数字孪生底座平台,包含了空间数据管理工具(Studio)、应用开发工具(SDK)、应用创作工具（Alpha）。平台能力已覆盖城市时空数据的集成、多源数据资源的发布管理，以及数字孪生应用开发工具链，满足企业开发者用户快速搭建数字孪生场景的切实需求，助力实现行业领先。

欢迎进入官网体验使用：Mapmost——让人与机器联合创作成为新常态