监控指标的完备程度，是衡量一个监控系统优劣的重要因素。指标不仅是个名称+数值，更蕴含了目标监控对象的领域知识，理解指标，会加深对目标领域的认知。——晓辉说。

前言

很多用户来问，这个指标是什么意思，那个指标是什么意思，解释半天也解释不明白，核心原因是，用户对他要监控的目标本身就缺乏知识。比如Nightingale里的一个net.in.dropped指标，表示入方向的网卡每秒丢包量，如果你从来没有执行过ifconfig命令，对网络丢包不知道是咋回事，真的就很难理解这个指标的意思了。

下面会分别讲解一些常见指标的获取方式，让大家有个感性的认识，会带出部分Linux基础知识。坐好扶稳~

一、Linux相关指标举例

Linux下很多指标都是来自/proc目录下的一些信息，这个目录很特殊，从网上摘抄一段话给大家：

Linux系统上的/proc目录是一种文件系统，即proc文件系统。与其它常见的文件系统不同的是，/proc是一种伪文件系统（也即虚拟文件系统），存储的是当前内核运行状态的一系列特殊文件，用户可以通过这些文件查看有关系统硬件及当前正在运行进程的信息，甚至可以通过更改其中某些文件来改变内核的运行状态。

基于/proc文件系统如上所述的特殊性，其内的文件也常被称作虚拟文件，并具有一些独特的特点。例如，其中有些文件虽然使用查看命令查看时会返回大量信息，但文件本身的大小却会显示为0字节。此外，这些特殊文件中大多数文件的时间及日期属性通常为当前系统时间和日期，这跟它们随时会被刷新（存储于RAM中）有关。

为了查看及使用上的方便，这些文件通常会按照相关性进行分类存储于不同的目录甚至子目录中，如/proc/scsi目录中存储的就是当前系统上所有SCSI设备的相关信息，/proc/N中存储的则是系统当前正在运行的进程的相关信息，其中N为正在运行的进程（可以想象得到，在某进程结束后其相关目录则会消失）。

大多数虚拟文件可以使用文件查看命令如cat、more或者less进行查看，有些文件信息表述的内容可以一目了然，但也有文件的信息却不怎么具有可读性。不过，这些可读性较差的文件在使用一些命令如apm、free、lspci或top查看时却可以有着不错的表现。

我们挑一类简单的指标：最近1min、5min、15min的负载数据，这3个指标我们平时用的比较多，执行uptime命令就能看到，比如：

监控系统去采集的时候，并非是执行uptime命令，那就太low了，效率也差，实际上我们是从/proc/loadavg文件读取的，因为/proc的读取不涉及真实的硬盘IO所以效率是非常高的。看一眼这个文件的内容哈：

看完了负载的指标，再看个内存利用率，我们经常用free -h来看内存使用情况，实际内存数据是在/proc/meminfo文件，我们来看一眼：

MemTotal、MemFree、MemAvailable都有。

最后再看一下磁盘使用情况，这个要比上面两个都更难获取，不仅仅是读取/proc的内容了。Linux上面的命令就是df -h，可以看到各个挂载点的使用情况。监控系统实际在采集这个数据的时候，是分成两步。

第一步是读取/proc/mounts获取所有的挂载点，过滤掉一些虚拟挂载点，然后执行Statfs的一个系统调用才能得到这个分区的使用情况。

二、Redis相关指标举例

我这有一个redis实例，连上去执行一下info命令给大家看看输出：

看到了吧，各种指标都有，当我们谈到redis监控的时候，主要就是监控这些指标。

做得易用的监控，会允许你直接配置redis的连接地址，监控系统会自动连上去执行命令。如果没有提供页面配置方式，一般至少也会提供插件扩展方式，容许用户写脚本，用脚本去采集监控指标，然后将监控数据推给监控服务端。

三、应用业务层面指标监控

应用层面的监控主要是接口成功率、响应时长、QPS等，这些监控数据的采集，最好是能在统一的HTTP框架或RPC框架里搞定，或者在统一的七层接入里搞定，减少各业务接入成本。

如果要做trace监控或者业务层面的指标监控，那基本就只能埋点了，比如监控系统的数据接口模块，我想统计一下每秒接收多少个数据点，那就需要数据接收模块在代码里写相关的采集逻辑了。

通过日志提取指标，也是个典型手段，通常就是用ELK这种方案，把日志收集到中心，写查询语句去查询分析。但这种方式比较重，我们在Nightingale中引入了一种更轻量的方案供大家参考。核心逻辑是在服务端配置正则表达式，下发到agent侧，agent流式读取日志文件，每读到一行，就用正则匹配一下，看是否命中，如果命中，就可以从中提取出一些指标信息。

举例1：如果有程序OOM，通常会在/var/log/messages中打印 Out of memory 这样的关键字，我想在系统触发OOM的时候告警，那就可以写个正则去匹配/var/log/messages，计算最近1min有多少条日志命中，把命中的日志行数作为指标上报即可。

举例2：比如有个交易程序，每一笔订单都把交易金额打印到日志里，我们就可以写个正则从日志里提取这个金额，统计最近1min的交易总量或者平均交易单价之类的。

滴滴Logi日志服务套件

滴滴Logi日志服务套件在滴滴内部经过7年多的沉淀打磨，针对日志采集、日志存储、日志计算、日志检索、日志分析各个环节，在组件能力上PAAS化建设、在引擎稳定性与扩展性上进行了针对性的优化。

目前该套件已经开源了滴滴Logi-KafkaManager，后期还会陆续开源Logi-Agent、Logi-LogX、Logi-ElasticSearchManager各PAAS套件。

1、滴滴Logi-KafkaManager Github：https://z.didi.cn/4newP

2、快速体验地址：http://117.51.150.133:8080/kafka 账号密码 admin/admin

3、日常FAQ：https://github.com/didi/Logi-KafkaManager/blob/master/docs/user_guide/faq.md

4、升级手册：https://github.com/didi/Logi-KafkaManager/tree/master/docs/dev_guide/upgrade_manual

5、滴滴Logi-KafkaManager云平台建设总结：

https://mp.weixin.qq.com/s/9qSZIkqCnU6u9nLMvOOjIQ

6、系列视频教程：https://mp.weixin.qq.com/s/9X7gH0tptHPtfjPPSdGO8g

滴滴夜莺

滴滴夜莺是一套分布式高可用的运维监控系统，最大的特点是混合云支持，既可以支持传统物理机虚拟机的场景，也可以支持K8S容器的场景。同时，滴滴夜莺也不只是监控，还有一部分CMDB的能力、自动化运维的能力，很多公司都基于夜莺开发自己公司的运维平台。

Github：https://z.didi.cn/4WurZ

官方文档：https://n9e.didiyun.com

提问必读：https://gocn.vip/topics/10811

语音答疑：https://m.ximalaya.com/keji/45095827/

视频教程：https://m.bilibili.com/space/442531657

二次开发：https://xie.infoq.cn/article/30d37e98fbe52ff2a79fc04b4

如果大家在使用滴滴Logi-KafkaManager和夜莺的过程中出现问题，或者有疑问需要与开发者交流的，都可以扫描下方二维码进入滴滴Logi及夜莺的开源用户群，在群中提问。

群内有滴滴Logi-KafkaManager和夜莺项目负责人：滴滴高级专家工程师—张亮、秦晓辉等技术大咖，在线为大家解答问题，欢迎大家长按二维码加小助手进群。（需备注Kafka或夜莺）