4. 指标数据采集：系统指标与应用指标
大家好，我是老张。今天咱们聊聊指标采集这个核心环节。
说实话，很多运维新手一上来就扎进告警配置里，结果发现告警不准、数据对不上。为什么？因为数据采集这第一步就没走稳。我见过太多项目，最后排查问题发现是采集器配置错了，白白浪费好几天。
所以这一章，咱们把指标采集这件事彻底讲透。
4.1 系统指标：CPU、内存、磁盘、网络
系统指标是运维的「体温计」。机器状态好不好，先看这几个基础指标。
4.1.1 CPU 指标
CPU 不是看「用了多少」，而是看「怎么用的」。我个人习惯关注这几个维度：
- user：用户态 CPU 使用率。应用跑得欢不欢，看这个。
- system：内核态 CPU 使用率。系统调用频繁时，这个会飙高。
- iowait：等待 I/O 的 CPU 时间。这个高了，说明磁盘或网络是瓶颈。
- idle：空闲率。低于 20% 就要警惕了。
4.1.2 内存指标
内存指标容易踩坑。很多人只看「已用内存」，其实不对。
Linux 的内存管理机制里，buff/cache 这部分是可以回收的。真正需要关注的是：
- available：可用内存。这是实际能用的，包括可回收的 cache。
- used：已用内存。但注意，这个值通常偏大。
- swap usage：交换分区使用量。一旦开始用 swap，性能就会急剧下降。
available 而不是 used。
4.1.3 磁盘指标
磁盘指标分两块：容量和性能。
容量方面：
- 磁盘使用率（used%）
- inode 使用率（inode 满了也会报错）
性能方面：
- IOPS：每秒读写次数。数据库这类应用很敏感。
- 吞吐量：每秒读写的数据量。
- await：I/O 平均等待时间。超过 10ms 就要注意了。
嗯，这里要注意：磁盘性能指标最好按设备分开采集，别混在一起。不然你根本不知道是哪块盘拖了后腿。
4.1.4 网络指标
网络指标相对简单，但容易漏掉关键点：
- 带宽使用率：入口和出口要分开看。
- 丢包率：哪怕 0.1% 的丢包，对 TCP 连接的影响都很大。
- 连接数：特别是 TIME_WAIT 状态的数量，多了会耗尽端口。
4.2 应用指标：QPS、延迟、错误率
系统指标告诉你机器「健不健康」，应用指标告诉你服务「好不好用」。
这三个指标，我称之为「黄金三指标」。任何一个出问题，用户都会直接感知到。
4.2.1 QPS（每秒查询数）
QPS 是应用吞吐量的直接体现。但要注意：
- 区分成功和失败的 QPS：失败的请求也算 QPS，但意义不同。
- 看趋势，不看绝对值：QPS 突然下降，可能是上游服务挂了；突然上升，可能是被攻击了。
我建议把 QPS 按接口维度采集。这样哪个接口流量异常，一眼就能看出来。
4.2.2 延迟（Latency）
延迟是用户体验的「晴雨表」。采集延迟时，别只看平均值。
为什么？因为平均值会掩盖问题。举个例子：
- 99% 的请求延迟是 10ms
- 1% 的请求延迟是 10s
- 平均延迟只有 110ms
你看，平均值看起来还行，但实际有 1% 的用户体验极差。
4.2.3 错误率（Error Rate）
错误率是最直接的「报警器」。但采集时要注意：
- 区分错误类型：4xx 是客户端问题，5xx 是服务端问题。处理方式完全不同。
- 设置合理的阈值：0.1% 的错误率在某些场景下可以接受，但在支付场景下 0.01% 都不行。
我曾经遇到一个案例：错误率从 0.1% 突然升到 0.5%，但业务方说没收到投诉。后来发现是某个内部接口超时了，外部用户没感知。但如果不采集这个指标，等外部接口出问题时，我们已经错过了最佳排查时机。
4.3 使用 Prometheus Exporter 采集
好了，指标定义清楚了，怎么采集呢？
Prometheus 生态里，Exporter 就是干这个活的。说白了，Exporter 是一个「翻译官」——把各种系统数据翻译成 Prometheus 能理解的格式。
4.3.1 常用 Exporter
| Exporter 名称 | 采集对象 | 端口 | 备注 |
|---|---|---|---|
| node_exporter | 系统指标（CPU、内存、磁盘、网络） | 9100 | 最常用，几乎每台机器都装 |
| mysqld_exporter | MySQL 数据库指标 | 9104 | 连接数、慢查询、缓冲池等 |
| nginx_exporter | Nginx 指标 | 9113 | 需要开启 stub_status 模块 |
| blackbox_exporter | 网络探测（HTTP、TCP、ICMP） | 9115 | 用于外部监控 |
4.3.2 实战：部署 node_exporter
咱们以 node_exporter 为例，看看怎么采集系统指标。
第一步：下载并启动
# 下载最新版本
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
# 解压
tar -xzf node_exporter-1.6.0.linux-amd64.tar.gz
# 启动（默认监听 9100 端口）
./node_exporter第二步：验证采集是否正常
# 访问 metrics 接口
curl http://localhost:9100/metrics | head -20你会看到类似这样的输出：
# HELP node_cpu_seconds_total Seconds the cpus spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 123456.78
node_cpu_seconds_total{cpu="0",mode="system"} 2345.67
node_cpu_seconds_total{cpu="0",mode="user"} 34567.89嗯，这就是 Prometheus 能识别的指标格式了。
第三步：配置 Prometheus 抓取
# prometheus.yml
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']4.3.3 应用指标采集：自定义 Exporter
系统指标有现成的 Exporter，但应用指标往往需要自己写。Prometheus 提供了多种语言的客户端库：
- Go：prometheus/client_golang
- Python：prometheus_client
- Java：simpleclient
以 Python 为例，采集 QPS 和延迟：
from prometheus_client import start_http_server, Summary, Counter
import random
import time
# 定义指标
REQUEST_COUNT = Counter('app_requests_total', 'Total requests')
REQUEST_LATENCY = Summary('app_request_latency_seconds', 'Request latency')
# 模拟业务逻辑
@REQUEST_LATENCY.time()
def handle_request():
time.sleep(random.uniform(0.01, 0.5))
REQUEST_COUNT.inc()
if __name__ == '__main__':
start_http_server(8000)
while True:
handle_request()启动后访问 http://localhost:8000/metrics，就能看到自定义的应用指标了。
4.4 本章小结
指标采集这件事，说难不难，说简单也不简单。核心就三点：
- 系统指标：CPU、内存、磁盘、网络，用 node_exporter 一把梭。
- 应用指标：QPS、延迟、错误率，黄金三指标一个不能少。
- 采集工具：Prometheus Exporter 生态成熟，开箱即用。
你想想看，如果连数据都采不准，后面的告警、分析、自动化，全都是空中楼阁。所以这一章的内容，值得你反复实践。
下一章咱们聊聊数据存储和查询，到时候会用到 PromQL，那才是真正体现功力的地方。
公众号:蓝海资料掘金营，微信deep3321