运维监控系统实战笔记(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)

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值