2、监控数据采集：基础指标采集与Agent部署

监控数据采集，是整个自主运维系统的「眼睛」和「耳朵」。

你想想看，如果连服务器跑得多快、磁盘还剩多少都不知道，那故障识别就无从谈起。我个人习惯把数据采集比作「地基」——地基没打好，上层再漂亮的告警规则都是空中楼阁。

2.1 基础指标采集：CPU、内存、磁盘、网络

这四个指标，是运维监控的「四大金刚」。几乎每个系统都得采，但怎么采得准、采得稳，这里头有门道。

2.1.1 CPU 指标采集

CPU 指标，说白了就是看它忙不忙。但「忙」也分好几种忙法。

  • user：用户态进程占用的 CPU 时间。我一般关注这个，如果持续飙高，说明应用层在疯狂计算。
  • system：内核态占用的 CPU。嗯，这里要注意，如果 system 过高，往往意味着系统调用太频繁，或者有驱动问题。
  • iowait：CPU 等待磁盘 I/O 的时间。这个指标很关键——我曾经遇到过一台机器 CPU 空闲 90%，但 iowait 高达 30%，业务照样卡成狗。
  • idle：空闲百分比。低于 20% 就要拉警报了。

采集方式：Linux 下从 /proc/stat 读取。Windows 下用 Get-Counter 或 WMI。

# 一个简单的 CPU 采集脚本（伪代码）
cat /proc/stat | grep 'cpu ' | awk '{print $2, $3, $4, $5, $6, $7, $8}'
# 计算差值，得到各状态的百分比

我的经验：采集 CPU 时，采样间隔别太短。我习惯设 10 秒一次。太短（比如 1 秒）会导致数据抖动剧烈，反而看不清趋势。

2.1.2 内存指标采集

内存指标，很多人只看「已用内存」。其实这是个坑。

  • total：物理内存总量。
  • used：已用内存。但注意，Linux 会把空闲内存用作缓存（cache/buffer），这部分其实可以回收。
  • available：真正可用的内存。这个值才是你该关注的！
  • swap used：交换分区使用量。如果 swap 持续增长，说明物理内存不够了。

避坑指南：我曾经踩过一个坑——只看 used 指标，发现内存用了 90%，吓得赶紧加内存。后来才发现，那 90% 里有一半是缓存，实际可用内存还有 40%。所以，请务必采集 available 或 MemAvailable。

# 从 /proc/meminfo 采集
cat /proc/meminfo | grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|SwapFree)'

2.1.3 磁盘指标采集

磁盘指标，分两块：容量和性能。

容量指标：

  • 磁盘分区使用率（used%）。超过 80% 就要关注，超过 90% 必须告警。
  • inode 使用率。这个容易被忽略——inode 满了，磁盘还有空间也写不了文件。

性能指标：

  • iops：每秒读写次数。我见过一个数据库服务器，iops 冲到 5000 以上，磁盘直接成为瓶颈。
  • throughput：吞吐量（MB/s）。
  • await：平均 I/O 等待时间。超过 100ms 就算异常了。

采集命令：iostat -x 1 或读取 /proc/diskstats。

2.1.4 网络指标采集

网络指标，我一般关注这几个：

  • 带宽使用率：流入/流出速率。如果接近网卡上限，说明该扩容了。
  • 丢包率：/proc/net/dev 里的 drop 字段。丢包率超过 0.1% 就要排查。
  • 连接数：ESTABLISHED 状态的 TCP 连接数。我曾经帮一个客户排查问题，发现连接数从 2000 突然飙到 8000，原来是 DDoS 攻击。
  • 重传率：TCP 重传比例。超过 2% 说明网络质量有问题。
# 采集网络流量
cat /proc/net/dev | grep eth0 | awk '{print $2, $10}'
# 分别对应接收字节和发送字节，计算差值得到速率

2.2 日志采集原理

基础指标是「定量」数据，日志是「定性」数据。两者结合，才能还原故障全貌。

日志采集的核心原理，说白了就三步：

  1. 读取：从日志文件中读取新写入的内容。
  2. 解析：把非结构化的文本，解析成结构化的字段（时间、级别、模块、消息等）。
  3. 传输：把解析后的数据发送到中央存储（如 Elasticsearch、Kafka）。

关键点：日志采集必须「增量读取」，不能每次都全量扫描。否则文件大了，CPU 和磁盘 I/O 都会爆炸。

我常用的日志采集工具有 Filebeat、Logstash、Fluentd。它们的原理大同小异：

  • 维护一个 offset（偏移量），记录上次读到了哪里。
  • 定期检查文件是否有新内容，有则读取并更新 offset。
  • 支持多行合并（比如 Java 异常栈，跨多行）。
# Filebeat 配置示例（简化版）
filebeat.inputs:
- type: log
  paths:
    - /var/log/nginx/access.log
  multiline.pattern: '^\d{4}-\d{2}-\d{2}'
  multiline.negate: true
  multiline.match: after

output.elasticsearch:
  hosts: ["localhost:9200"]

我的建议：日志采集别贪多。我见过有人把 debug 日志全采了，结果一天产生 100GB 数据，存储成本扛不住。只采集 WARN 及以上级别，或者关键业务的 INFO 日志，就够了。

2.3 Agent 部署与配置

Agent 是部署在每台机器上的「哨兵」。它负责采集数据，并上报给中央服务器。

2.3.1 Agent 的架构设计

一个标准的 Agent，通常包含这几个模块：

  • 采集器：负责拉取 CPU、内存等指标。
  • 日志读取器：负责读取日志文件。
  • 缓存队列：临时存储采集到的数据，防止网络抖动丢数据。
  • 发送器：把数据发送到服务端（HTTP、gRPC 或 MQ）。

核心原则：Agent 必须「轻量」。它不能占用太多 CPU 和内存，否则就本末倒置了。

2.3.2 部署方式

我习惯用两种方式部署 Agent：

  • 直接安装：通过 RPM/DEB 包安装，适合传统环境。
  • 容器化部署：用 Docker 或 Kubernetes DaemonSet 部署，适合云原生环境。
# Docker 部署 Agent 示例
docker run -d \
  --name=monitor-agent \
  --restart=always \
  --net=host \
  -v /proc:/host/proc:ro \
  -v /var/log:/var/log:ro \
  monitor-agent:latest \
  --server=192.168.1.100:9090

避坑指南：我曾经在容器化部署时，忘了挂载 /proc 和 /var/log，结果 Agent 采集到的全是容器自身的数据，而不是宿主机的。嗯，这个坑我踩过一次，后来就记住了——一定要用 --net=host 和正确的卷挂载。

2.3.3 配置管理

Agent 的配置，我建议集中管理，而不是每台机器手动改。

  • 使用配置中心（如 Consul、Etcd）下发配置。
  • 配置内容：采集频率、采集项、服务端地址、日志路径等。
  • 支持热加载：修改配置后，Agent 自动重载，无需重启。

我的习惯：我会在 Agent 配置里加一个「自监控」开关。开启后，Agent 会把自己的 CPU、内存、发送成功率也上报上去。这样，如果 Agent 本身出问题了，我能第一时间发现。

2.4 知识体系结构图

下面这张图，帮你理清本章的核心脉络：

监控数据采集知识体系 基础指标采集 日志采集 Agent部署配置 CPU 内存 磁盘 网络 增量读取 + offset管理 结构化解析 + 多行合并 传输到ES/Kafka 采集器 + 日志读取器 直接安装 / 容器化部署 集中配置 + 热加载 核心目标：全面、准确、轻量地采集数据 为故障识别提供可靠的数据基础

2.5 本章小结

监控数据采集，说白了就是三件事：

  • 采什么：CPU、内存、磁盘、网络，四大基础指标一个不能少。
  • 怎么采：日志要增量读，指标要算差值，Agent 要轻量。
  • 怎么部署：集中配置、容器化部署、自监控，一个都不能省。

我记得刚入行时，觉得采集数据很简单，不就是跑几个命令嘛。后来吃过亏才明白——数据采不准，后面所有分析都是白搭。所以，这一章的内容，我建议你多花点时间消化。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →