文章目录

• 监控圈子行业黑话
• • 监控
  • 监控系统
  • 监控指标
  • • 全局唯一字符串作为指标标识
    • 标签集的组合作为指标标识
    • 优雅高效的 Influx 指标格式
    • 指标类型
    • • Gauge
      • Counter
      • Histogram
      • Summary
  • 时序库
  • • • 时序数据
  • 告警
  • • 告警收敛
    • 告警闭环

监控圈子行业黑话

监控

一般我们说监控 MySQL、监控 Redis 的时候，都是指能够采集到 MySQL、Redis 的监控数据，并能可视化展示。这时候监控表示数据采集和可视化，不包括告警引擎和事件处理。

监控系统

当我们讲监控系统的时候，因为说的是整个系统，所以也会包含告警和事件发送等相关功能。

监控指标

监控指标是指数值类型的监控数据，比如某个机器的内存利用率，某个 MySQL 实例的当前连接数，某个 Redis 的最大内存上限等等。不同的监控系统，对于监控指标有不同的描述方式，典型的方式有三种，下面我们分别介绍一下。

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

监控指标通常是一个全局唯一的字符串，比如某机器的内存利用率 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，也是这样标识监控指标的。

虽然这种方式一目了然，非常清晰，但是缺少对维度信息的描述，不便于做聚合计算。比如下面几条用于描述 HTTP 请求状态码的指标。

myhost.service1.http_request.200.get
myhost.service1.http_request.200.post
myhost.service1.http_request.500.get
myhost.service1.http_request.500.post
myhost.service2.http_request.200.get
myhost.service2.http_request.500.post

myhost 这个机器上部署了两个服务，分别是 service1 和 service2。有些请求状态码是 200，有些是 500，有些 HTTP method 是 get，有些是 post。我们想分别统计这些指标的数量，就要把这些分类维度信息都拼到指标标识中。但是这样做会产生两个弊端：一是看起来比较混乱，二是不方便聚合统计。

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

OpenTSDB 的数据示例

mysql.bytes_received 1287333217 327810227706 schema=foo host=db1
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

上面这 6 条监控指标，都通过空格把指标分隔成了多个字段。第一段是指标名，第二段是时间戳（单位是秒），第三段是指标值，剩下的部分是多个标签（tags/labels），每个标签都是 key=value 的格式，多个标签之间使用空格分隔。

了 OpenTSDB，新时代的时序库大都引入了标签的概念，比如 Prometheus，它们甚至认为指标名也是一种特殊的标签（其标签 key 是 name ），所以 Prometheus 仅仅使用标签集作为指标标识，从 Prometheus 的数据结构定义中就可以看出来。

message Sample {double value    = 1;int64 timestamp = 2;
}message Label {string name  = 1;string value = 2;
}message TimeSeries {repeated Label labels   = 1 [(gogoproto.nullable) = false];repeated Sample samples = 2 [(gogoproto.nullable) = false];
}

TimeSeries 这个结构中并没有一个单独的 metric 字段，指标名的信息实际是放到了 labels 数组中了。

优雅高效的 Influx 指标格式

nfluxData 公司有一款开源时序库非常有名，叫InfluxDB，InfluxDB 在接收监控数据写入时，设计了一个非常精巧的指标格式，一行可以传输多个指标。

mesurement,labelkey1=labelval1,labelkey2=labelval2 field1=1.2,field2=2.3 timestamp

总体来看，分为 4 个部分，measurement,tag_set field_set timestamp，其中 tag_set 是可选的，tag_set 与前面的 measurement 之间用逗号分隔，其他各个部分之间都是用空格来分隔的。我们可以通过下面的例子来理解。

weather,location=us-midwest temperature=82 1465839830100400200|    -------------------- --------------  ||             |             |             ||             |             |             |
+-----------+--------+-+---------+-+---------+
|measurement|,tag_set| |field_set| |timestamp|
+-----------+--------+-+---------+-+---------+

我们把上面 OpenTSDB 的指标示例改写成 Influx 格式，结果是这样的。

mysql,schema=foo,host=db1 bytes_received=327810227706,bytes_sent=6604859181710 1287333217000000000
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 越多的情况下它的优势越明显，网络传输的时候可以节省更多带宽。当然了，OpenTSDB 的格式或者 Prometheus 的格式如果做了数据压缩，节省带宽的效果也是不错的，因为字符的压缩效果一般比较明显。现如今机房内部通信动辄万兆网卡，这个流量的大小区别倒也不用太关注。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fbKPk6I6-1673924951575)(…\images\image-20230116112109573.png)]

指标类型

有些监控系统是不区分指标类型的，有些会做区分。90 年代左右社区就出现了一款作品 RRDtool，它是一个环形数据库，也是一个绘图引擎，很多监控工具都是使用 RRDtool 来存储或绘制监控趋势图的，比如 Cacti、MRTG、Zabbix 等等。RRDtool 还提出了数据类型的概念，支持 GAUGE、COUNTER、DERIVE、DCOUNTER、DDERIVE、ABSOLUTE 等多种数据类型。

Prometheus 生态也支持数据类型，分为 Gauge、Counter、Histogram、Summary4 种，下面我们简单了解一下 Prometheus 的这 4 种类型。

Gauge

测量值类型，可大可小，可正可负。这种类型的数据，我们通常关注的是当前值，比如房间里的人数、队列积压的消息数、今年公司的收入和净利润。

Counter

表示单调递增的值，比如操作系统自启动以来网卡接收到的所有流量包的数量。每接收到一个包，操作系统就会加 1，所以这个值是持续递增的。但是操作系统可能会重启，导致这个值出现重置，比如第一次是从 0 一直涨到了 239423423，然后机器重启，新采集的数据是一些比 239423423 小很多的值，这种情况怎么办？此时 Prometheus 看到值没有递增，就能感知到重置的情况，会把新采集的值加上 239423423 再做计算。

Histogram

直方图类型，用于描述数据分布，最典型的应用场景就是监控延迟数据，计算 90 分位、99 分位的值。所谓的分位值，就是把一批数据从小到大排序，然后取 X% 位置的数据，90 分位就是指样本数据第 90% 位置的值。

Summary

Summary 这种类型是在客户端计算分位值，然后把计算之后的结果推给服务端存储，展示的时候直接查询即可，不需要做很重的计算，性能大幅提升。

时序库

时序库（Time series database）是一种专门处理时序数据的数据库 。我们常见的数据库中，MySQL 是关系型数据库，Redis 是 KV 数据库，MongoDB 是文档数据库，而 InfluxDB、VictoriaMetrics、M3DB 等都是时序库，Prometheus 其实也内置实现了一个时序存储模块。

时序数据

时序数据最大的特点是每一条数据都带有时间戳，通常是单调顺序，不会乱序，流式发给服务端，通常不会修改，比如指标数据和日志数据，都是典型的时序数据。

告警

告警收敛

基础设施层面的故障，比如基础网络问题，可能会瞬间产生很多告警事件，形成告警风暴，导致接收告警的媒介拥塞，比如手机不停接收到短信和电话呼入，没办法使用。这个时候，我们就要想办法让告警事件变少，用的方法就是告警收敛。

最典型的手段是告警聚合发送，聚合可以采用不同的维度，比如时间维度、策略维度、监控对象维度等等。如果 100 台机器同时报失联，就可以合并成一条告警通知，减少打扰。

另外一个典型的收敛手段是把多个事件聚合成告警，把多个告警聚合成故障。比如某个机器的 CPU 利用率告警，监控系统可能每分钟都会产生一条事件，这多个事件的告警规则、监控对象、监控指标都相同，所以可以收敛为一条告警。假设有 100 台机器都告警了，其中 50 台属于业务 A，另外 50 台属于业务 B，我们可以按照业务来做聚合，聚合之后产生两个故障，这样就可以起到很好的收敛效果。

告警闭环

闭环这个词是个互联网黑话，表示某个事情有始有终，告警怎么判断是否闭环了呢？问题最终被解决，告警恢复，就算是闭环了。产品怎么设计才能保证告警闭环呢？通常来讲，没人响应的告警能够升级通知，告警 oncall 人员可以认领告警，基本就有比较好的保障了。

《运维监控系统实战笔记》 学习笔记 day2