13518219792
一般我们说监控 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.postmyhost 这个机器上部署了两个服务，分别是 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% 位置的值。
SummarySummary 这种类型是在客户端计算分位值，然后把计算之后的结果推给服务端存储，展示的时候直接查询即可，不需要做很重的计算，性能大幅提升。
时序库时序库（Time series database）是一种专门处理时序数据的数据库 。我们常见的数据库中，MySQL 是关系型数据库，Redis 是 KV 数据库，MongoDB 是文档数据库，而 InfluxDB、VictoriaMetrics、M3DB 等都是时序库，Prometheus 其实也内置实现了一个时序存储模块。
时序数据时序数据大的特点是每一条数据都带有时间戳，通常是单调顺序，不会乱序，流式发给服务端，通常不会修改，比如指标数据和日志数据，都是典型的时序数据。
告警 告警收敛基础设施层面的故障，比如基础网络问题，可能会瞬间产生很多告警事件，形成告警风暴，导致接收告警的媒介拥塞，比如手机不停接收到短信和电话呼入，没办法使用。这个时候，我们就要想办法让告警事件变少，用的方法就是告警收敛。
最典型的手段是告警聚合发送，聚合可以采用不同的维度，比如时间维度、策略维度、监控对象维度等等。如果 100 台机器同时报失联，就可以合并成一条告警通知，减少打扰。
另外一个典型的收敛手段是把多个事件聚合成告警，把多个告警聚合成故障。比如某个机器的 CPU 利用率告警，监控系统可能每分钟都会产生一条事件，这多个事件的告警规则、监控对象、监控指标都相同，所以可以收敛为一条告警。假设有 100 台机器都告警了，其中 50 台属于业务 A，另外 50 台属于业务 B，我们可以按照业务来做聚合，聚合之后产生两个故障，这样就可以起到很好的收敛效果。
告警闭环闭环这个词是个互联网黑话，表示某个事情有始有终，告警怎么判断是否闭环了呢？问题最终被解决，告警恢复，就算是闭环了。产品怎么设计才能保证告警闭环呢？通常来讲，没人响应的告警能够升级通知，告警 oncall 人员可以认领告警，基本就有比较好的保障了。
《运维监控系统实战笔记》 学习笔记 day2
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
