运维监控系统实战笔记(day2)

基本概念：监控圈子有哪些行业黑话？

继续了解一些概念：包括监控、监控指标、指标类型、时序库，还有告警收敛与闭环等。

监控表示数据采集和可视化，不包括告警引擎和事件处理。但当我们讲监控系统的时候，因为说的是整个系统，所以也会包含告警和事件发送等相关功能。监控体系中最基础的是监控指标，监控系统就是围绕指标的采集、传输、存储、分析、可视化的一个系统，

监控指标

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

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

监控指标通常是一个全局唯一的字符串，如host.10.2.3.4.mem_used_percent，这个字符串中包含了机器的信息，也包含了指标名，可以唯一标识一条监控指标。

{
  "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
    }
  ]
}虽然这种方式一目了然，非常清晰，但是缺少对维度信息的描述，不便于做聚合计算。

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

下面是通过文本协议推给 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 的格式，多个标签之间使用空格分隔。

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

优雅高效的 Influx 指标格式

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

指标类型

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

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

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

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

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

听起来不错，但是有个问题，Summary 的计算是在客户端计算的，也就意味着不是全局的分位值，比如某个服务 service1，部署在两个机器上，服务代码里通过内嵌 Prometheus 的 SDK 做了埋点监控，SDK 里会计算 Summary 数据。也就是说，分位值延迟数据是进程粒度的，不是整个服务粒度的。这个问题也不严重，因为有负载均衡在起作用，

类型扩展知识

TimeSeries 数据结构中没有包含类型信息！

其实从存储角度还真的不需要知道，存储的时候只要知道指标标识、时间戳、值，就足够了。

那为什么还需要划分这么多类型呢？最主要的作用是在采集侧埋点的时候，SDK 会根据数据类型做不同的计算逻辑，比如 Histogram 类型，每次请求进来的时候，代码里调用一下 SDK 的 Observe 方法通知 SDK，SDK 就会自动计算生成多个指标，提升埋点便利性。

时序库

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

那什么是时序数据呢？时序数据最大的特点是每一条数据都带有时间戳，通常是单调顺序，不会乱序，流式发给服务端，通常不会修改，比如指标数据和日志数据，都是典型的时序数据。存储领域没有银弹，不同的数据场景侧重点不同，所以针对时序数据这个特定场景，产生了时序库这个专门的细分领域。在 DB-Engines 网站上，有一个时序库的流行度排序，你可以了解到当下哪些时序库比较流行。

告警收敛

同一台机器，连续多台报一个警，可以只报一条，减少干扰

告警闭环

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

小结

监控：这个词在不同的上下文会有不同的语义，有的时候表示数据采集和可视化，有的时候表示整个监控系统。不过不管怎么理解，通常都不影响交流。

监控指标：这个概念很关键，不同的监控产品有不同的描述方式，不过随着 OpenMetrics 标准的建立，指标描述方式会渐渐趋于一致。重点要了解 Prometheus 的指标描述方式 metric + labels，当然 metric 也可以看作一个特殊的 label。Influx 格式也很重要，建议你掌握，如果使用 Telegraf 作为采集器，就绕不过去这个格式。

指标类型：针对时下流行的 Prometheus，我们讲解了 4 种指标类型及每个类型的适用场景，最后明确了指标类型最核心的作用：在采集侧埋点时，SDK 会根据数据类型做不同的计算逻辑。

时序库：存储时序序列数据的数据库，它已经成为了一个单独的数据库细分方向，而且随着 IoT 的场景越来越多，以及微服务的发展，时序库这个话题也越来越流行。

告警收敛和告警闭环：告警事件层面的话题是所有监控系统都需要处理的。当然也可以作为一个专门的产品和多种监控系统对接，专注处理告警事件，希望国内能有超越 Bigpanda、Pagerduty 的产品出现。

学习来源：极客时间 运维监控系统实战笔记(day2)