滴滴高级专家工程师保姆级运维监控科普（三）

最新推荐文章于 2024-08-16 07:35:25 发布

「已注销」

最新推荐文章于 2024-08-16 07:35:25 发布

阅读量354

点赞数

文章标签：运维 java 数据库大数据人工智能

本文链接：https://blog.csdn.net/didi_cloud/article/details/117115138

版权

上一章我们大体看到了Linux、Redis相关的一些指标，大伙可能对监控指标是啥有了个大概了解。那在监控系统里，怎么表示一条指标呢？本章来解释这个问题。

比如我们要监控Linux系统的CPU、内存相关指标，我们通常会部署一个daemon进程在OS上，然后周期性去采集相关指标，上报给监控服务端。采集到的数据推送给服务端，具体是推送了个啥数据结构？我们来看看各个系统的实现。

1、Open-Falcon指标示例

以Open-Falcon举例，某个机器的CPU空闲率指标在某个时间点的值，用这种方式表示：

这里边比较重要的是metric，表示指标名称，timestamp表示采集数据点的那一刻的时间戳，value表示值，为了标识这个数据是来自哪个机器的，有个endpoint字段，另外还有一些多维度信息放在tags里，上例表示bj区域，cloud这个部门，便于未来做一些聚合计算，比如求取cloud部门的所有机器的平均cpu.idle（所以tags这种维度信息是非常重要的，便于做聚合，像Zabbix这种老一代监控系统就缺少了这种设计，导致不方便做聚合计算，所以很少有人会拿Zabbix做应用、业务层面的监控）。

counterType表示数据类型，Open-Falcon支持GAUGE和COUNTER两种类型，这个类型概念其实不是必须的，有些时序库压根就不支持数据类型的概念，step表示监控指标的采集上报频率，因为Open-Falcon底层存储用的rrdtool，rrd文件存储对step字段是必须的。

2、OpenTSDB指标示例

OpenTSDB是一款时序数据库，用来存储监控数据，因为监控数据是一种典型的时序数据，所以很多公司使用OpenTSDB作为监控系统的底层存储。

mysql.bytes_received是指标名称，1287333217是UNIX时间戳，327810227706是指标的值，schema=foo host=db1是tags，和Open-Falcon很像，更简单了，少了endpoint、counterType、step字段。

Prometheus的数据结构和OpenTSDB基本完全一致。对于指标数据来自哪个机器，并没有一个类似endpoint那样的字段表示，而是直接放到tags里了，从监控的角度来看，这两种表示方式其实没有本质的区别，不过在传统物理机、虚拟机时代，服务混部场景较多，我更倾向于提出这个单独的字段的设计，后面夜莺的设计就是这样的，至于原因，后面系列的文章会聊到。

3、Nightingale指标示例

熟悉我的人可能知道，现在已经基本不再维护Open-Falcon了，主要精力都放到夜莺上了，即Nightingale，大家可以把Nightingale看做Open-Falcon的下一代。最近在筹划v5版本，v5会是我当前认知里最好的一个版本，v5的监控数据结构会设计成什么样子呢？如下：

和Open-Falcon的设计很像，去掉了step字段，加了一个extra字段，这些都不重要，endpoint拆成了两个字段，一个ident，一个alias，其实看起来变化也不大。

最大的变化，是Open-Falcon不允许endpoint留空，Nightingale里会允许ident、alias留空，一个不允许留空，一个允许，变化看起来也不大，非也非也，Open-Falcon看图、告警策略，大都是依赖endpoint设计的，而Nightingale v5不会强依赖这个字段，初衷是希望Nightingale v5既可以方便的解决传统物理机、虚拟机的场景，也可以方便的解决非设备相关的监控，比如应用、业务层面的监控。

CPU、内存这种指标，都是跟设备相关的，但是很多指标其实跟设备无关，比如某个服务的某个接口的整体访问延迟：