监控圈子行业黑话

时间:2023-01-18 09:55:02

监控圈子行业黑话

监控

一般我们说监控 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