零侵入监控：node_exporter、mtail 与 Prometheus、Grafana 组合实战

1. 先统一认知：node_exporter、mtail、Prometheus、Grafana 各管哪一段

我见过很多团队做监控，第一反应是“先装一套 Prometheus + Grafana”，装上之后发现只有 CPU、内存、磁盘这些机器指标，业务到底跑得好不好完全看不见。后来有人开始折腾埋在代码里的 metrics 接口，但老系统根本不敢动，发一次版可能要排两周。直到我把 mtail 加进来，才真正把这套方案拼完整。

这套组合里，四个组件各自解决的问题非常清晰：node_exporter 负责机器层指标，mtail 负责从日志中提取业务指标，Prometheus 负责采集、存储、计算和告警，Grafana 负责把数据变成能直接看懂的画面。它们不是替代关系，而是流水线关系。

1.1 一条请求日志到一张监控图的全过程

拿一个典型的订单系统举例。某次用户下单，后端服务打出一条日志：

2024-06-01 12:00:01 INFO order 1001 user 501 amount 99.80 status success cost_ms 120 region cn

如果没有 mtail，这条日志要么被 logstash 收走全文存储，要么躺在本机没人看。引入 mtail 之后，它做的事情是：实时读日志文件，用 mtail 程序里写的正则去匹配每一行，把命中的字段提取出来，累加到对应的指标里。比如匹配到status=success就把order_requests_by_status{status="success"}这个计数器加一，匹配到cost_ms=120就把耗时观测值丢进直方图。

mtail 本身会暴露一个 HTTP 端口，默认3903，Prometheus 每隔 15 秒来拉一次指标。数据进到 Prometheus 之后，你可以写 PromQL 就算出五分钟内的 QPS、成功率、P95 耗时，然后在 Grafana 里画曲线、做告警。整个过程不需要改一行业务代码，这就是它最值钱的地方。

node_exporter 则在另一条线上工作：每台机器上跑一个进程，采集 CPU、内存、磁盘、网络、文件系统、进程数、systemd 服务状态等几百个指标，同样暴露 HTTP 端口，Prometheus 来拉。

所以最终你在 Grafana 上看到的监控大屏，左手是机器负载曲线，右手是业务 QPS 和错误率。这两类数据原本各自孤立，现在因为都在 Prometheus 里，就能放在一起做关联分析。

1.2 为什么不是 ELK、不是埋点、不是 pushgateway

很多人会问：日志监控我有 ELK 了，为什么还要 mtail？这里的差异是本质的。ELK 做的是全文检索和日志归档，是把日志原文存下来供查询；而 mtail 做的是流式聚合，日志读完就丢，只保留统计结果。同样是 100 万条日志，ELK 可能要占几百 MB 存储，mtail 最终只贡献几个时间序列。Elasticsearch 再快，查一条日志还是要秒级；而 Prometheus 一条rate查询出来是毫秒级。二者不是二选一，更常见的是并存：ELK 留原文排障，mtail 出指标做监控。

为什么不用在业务代码里直接埋点暴露 metrics？埋点当然是正路，但现实是很多遗留系统、第三方组件、甚至是运维自己写的脚本，根本不会给你留 metrics 口子。发版一次的成本非常高，等埋点上线，事故可能已经发生了。mtail 的价值在于零侵入、快速接入，十分钟就能把新业务日志变成指标。它不完美，但它能立刻解决问题。

为什么不用 pushgateway？Prometheus 默认是 pull 模型，也就是 Prometheus 主动去各 exporter 上抓取。一旦引入 pushgateway，就变成了被动的 push 模型，网关本身成为单点和数据造假的重灾区，还要额外处理指标过期的问题。对于“机器负载 + 业务监控”这个场景，没有理由用 push 方案。

我整理过一张表，方便你对照理解这四个组件到底谁负责什么：

一句话总结：node_exporter 管机器，mtail 管业务，Prometheus 管存储和算数，Grafana 管让人看懂。

2. 从空机器开始：四个组件的安装、注册与联调

先说明，我不打算讲 Docker Compose 一把梭。生产环境里我习惯用二进制 + systemd 管理，原因很简单：二进制部署排错直观，systemd 可以控制启动顺序、日志采集、崩溃重启，也方便跟配置管理工具整合。如果你只是想本地快速验证，手动起几个进程也完全没问题。

2.1 目录与运行账号规划

在动手之前，先把目录和账号规划好。我见过最乱的部署就是所有东西一股脑 root 跑在/root下，权限混乱不说，exporter 一旦被利用，攻击者直接拿到 root 权限。所以第一件事是建一个专用账号：

sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus

然后规划目录，我习惯用/data作为数据盘挂载点，监控数据单独放在里面，避免和系统盘抢空间：

sudo mkdir -p /data/prometheus sudo mkdir -p /data/mtail sudo mkdir -p /opt/{prometheus,node_exporter,mtail,grafana} sudo chown -R prometheus:prometheus /data/prometheus /data/mtail

2.2 node_exporter 与 Prometheus 的 systemd 化

从官方 releases 页面下载二进制包，解压后把可执行文件放到/opt对应目录即可。node_exporter 启动参数通常不需要纠结，默认的采集项已经覆盖大部分场景，按需开启 systemd 采集器也很有用：

[Unit] Description=Node Exporter After=network.target [Service] User=prometheus Group=prometheus Type=simple ExecStart=/opt/node_exporter/node_exporter \ --web.listen-address=:9100 \ --collector.systemd \ --collector.processes Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

Prometheus 的 systemd 服务类似，但存储路径和配置文件路径必须提前给好：

[Unit] Description=Prometheus After=network.target [Service] User=prometheus Group=prometheus Type=simple ExecStart=/opt/prometheus/prometheus \ --config.file=/etc/prometheus/prometheus.yml \ --storage.tsdb.path=/data/prometheus \ --web.listen-address=:9090 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

接下来是prometheus.yml，这是整套监控的入口。我给出一个最小可用的版本：

global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: prometheus static_configs: - targets: ['127.0.0.1:9090'] - job_name: node static_configs: - targets: - '10.0.0.10:9100' - '10.0.0.11:9100' - job_name: mtail static_configs: - targets: - '10.0.0.10:3903'

这里的scrape_interval决定数据采样粒度，15 秒是默认值，监控业务波动比较大的系统可以调到 5 秒，但要注意磁盘写入量会成倍增加。我先用 15 秒起步。

2.3 mtail 与 Grafana 的接入

mtail 的启动命令里，-progs指定程序目录，-logs指定要监控的日志文件，可以带通配符。注意这里用的是 glob 表达式，日志轮转时老文件和新文件都会被匹配到：

[Unit] Description=mtail Log Exporter After=network.target [Service] User=prometheus Group=prometheus Type=simple ExecStart=/opt/mtail/mtail \ -progs /etc/mtail \ -logs '/data/logs/order/*.log' \ -port 3903 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

/etc/mtail目录下放 mtail 程序文件，文件后缀通常是.mtail，例如order.mtail。这个目录的内容在下一章详细讲。

Grafana 我同样用二进制部署，解压后有个bin/grafana server，用 systemd 拉起来，默认监听 3000 端口。首次登录使用admin/admin，进去之后先改密码，然后添加 Prometheus 数据源。数据源 URL 填http://127.0.0.1:9090，访问方式选 Server，Access 选默认的 Browser 或 Server 都可以，我建议 Server 模式，避免浏览器跨域问题。数据源保存之后，你可以在 Explore 页面输入up查一下，如果返回了多个值为 1 的序列，说明采集链路已经通了。

2.4 第一轮联调验证

我每次装完不会急着看 Grafana，而是先用 curl 把三层链路分别验证一遍：

1. node_exporter 是否存活：curl -s http://localhost:9100/metrics | grep node_load1
2. mtail 是否存活：curl -s http://localhost:3903/metrics | grep order_
3. Prometheus 是否抓到了目标：curl -s 'http://localhost:9090/api/v1/targets'

第 3 步非常关键。很多人配置了scrape_configs但忘了开防火墙端口，结果 Prometheus 侧 Target 一直显示 Down。如果你发现 node_exporter 和 mtail 的/metrics都能手动访问，但 Prometheus 抓不到，优先检查安全组和本机防火墙对 9100、3903 端口的放行规则。

所有服务启动之后，用systemctl status确认进程都处于 running 状态，再用journalctl -u mtail -f看 mtail 日志，确认它有没有真的在读业务日志文件。很多时候程序文件写错，mtail 启动并不会报错，只是默默不产生任何指标，这一步踩坑概率非常高。

3. 把业务日志变成指标：mtail 程序设计与调试

mtail 的价值全在程序文件里。它不是什么复杂语言，本质上就是“正则匹配 + 计数器累加”。但越简单的东西越容易写糙，我见过太多人把 mtail 程序写成垃圾正则堆砌，跑两天内存飙升。所以这一章我不只给示例，还会把匹配模型讲清楚。

3.1 一个能直接抄的 mtail 程序

假设订单日志的格式稳定成这样：

2024-06-01 12:00:01 INFO order 1001 user 501 amount 99.80 status success cost_ms 120 region cn 2024-06-01 12:00:02 INFO order 1002 user 502 amount 199.00 status failed cost_ms 80 region us

在/etc/mtail/order.mtail里写：

# 请求总量，按状态区分 counter order_requests_total counter order_requests_by_status by status # 销售额累计 counter order_amount_total # 耗时分布 histogram order_cost_ms # 最近一次耗时，方便看瞬时值 gauge order_last_cost_ms # 核心匹配块 /status=(?P<status>\w+) cost_ms=(?P<cost>\d+)/ { order_requests_total++ order_requests_by_status[$status]++ order_cost_ms = $cost order_last_cost_ms = $cost } /order (?P<id>\d+) .* amount=(?P<amount>[\d.]+)/ { order_amount_total += $amount }

这里有几个关键点需要说清楚。

第一个正则里，(?P<status>\w+)是命名捕获组，mtail 会把捕获到的内容作为标签值。order_requests_by_status[$status]++的意思就是：按status这个标签维度累加计数器。日志里出现status=success，就往status="success"的序列上加一；出现status=failed，就生成另一个序列。如果在 Prometheus 里查order_requests_by_status，你会看到按 status 分组的多个时间序列。

第二个正则匹配整行里的amount=xx，这里我用了.*跳过中间其他字段，但注意不要滥用。日志行越长，正则的匹配成本越高，后面我会专门讲性能问题。

histogram是 mtail 里最容易理解错的一个类型。它并不是“存一个值”，而是把观测值丢进预设的桶里。你不需要管桶边界具体是多少，只要把order_cost_ms = $cost写上去，mtail 会自动生成order_cost_ms_bucket、order_cost_ms_sum、order_cost_ms_count这些序列。之后在 Grafana 里用histogram_quantile算 P95 时，依赖的就是这套桶数据。

3.2 mtail 的匹配模型与指标语义

理解 mtail，要先理解它的运行方式。每个日志行进来，mtail 不会像一个普通脚本那样从头到尾顺序执行所有规则，而是把所有正则片段编译成一个状态机。程序文件里的内容会被拆成若干条规则，每条规则只关心自己需要的那个片段。

比如我上面写的第一个规则只匹配status=... cost_ms=...这两个字段，第二个规则只匹配amount=...。日志行先走第一条规则，如果匹配上了，执行大括号里的累加逻辑；然后再尝试第二条规则，匹配上了则继续执行。换句话说，同一行日志可以被多条规则命中，多次贡献指标。这也是为什么我在第二个正则里没有再去匹配 status，而是单独处理 amount，避免重复累加。

指标类型上，mtail 提供三种：

设计 mtail 程序时，最容易犯的错误就是把只增不减的量写成 gauge。比如“当前排队数”应该是 gauge，因为它会降下来；但“累计处理请求数”必须是 counter，因为它是单调递增的。一旦类型选错，你在 PromQL 里用rate()算出来的速率就会忽正忽负，画出来的曲线没法看。

3.3 正则写不好时，mtail 会怎么拖后腿

正则匹配看起来没什么技术含量，但 mtail 是实时处理大量日志的，性能问题很快会在生产环境爆出来。

第一，不要用灾难性回溯的正则。比如.*.*.*嵌套、大量\d+的交替分支，在极端情况下会让匹配卡住，日志处理吞吐直接归零。我见过一个团队在 mtail 里写了个非常复杂的 URL 解析正则，某天日志里出现一条超长异常 URL，mtail 进程 CPU 立刻打满，所有业务指标停滞。

第二，能用前缀匹配就不用全量扫描。mtail 状态机本身会优化，但如果你写的模式太宽泛，比如/(.*)/，那等于每条日志都要做大量无用功。我通常的做法是先定位一个有辨识度的前缀，比如order_id=、status=，再在附近提取字段。

第三，命名捕获组是开销，但值得。使用(?P<name>...)会产生标签维度，每一条日志都要把这个值写入内存里的标签集合。低基数标签完全没问题，高基数标签问题在第 5 章细说。

写完程序之后，怎么调试？我建议先用 mtail 的-v 2参数把它跑起来，让它实时读日志，然后在/metrics页面盯着看指标有没有增长：

/opt/mtail/mtail -progs /etc/mtail -logs '/data/logs/order/*.log' -port 3903 -v 2

如果你发现指标一直为 0，先用tail -f看业务日志里有没有新行，再用一个最简单的测试程序，比如只匹配INFO一行，看能不能出数。逐层缩小范围，十次里有八次是日志格式和正则不匹配。

4. 让业务指标和机器负载出现在同一张图：查询设计与告警规则

组件全部跑起来之后，重头戏才刚开始。Prometheus 里现在有两类数据：一类来自 node_exporter，是node_开头的机器指标；另一类来自 mtail，是order_开头的业务指标。每一个指标都已经在时序库里了，接下来就是问它问题。

4.1 业务侧三个最常用的 PromQL

我自己的习惯，是给任何业务先做三张图：流量、成功率、延迟。对应到 PromQL 分别是下面三个。

第一个是 QPS，也就是每秒请求数：

sum(rate(order_requests_total[5m])) by (instance)

rate()计算的是每秒平均增量，5 分钟窗口可以平滑掉毛刺。前面我说 order_requests_total 是 counter 类型，PromQL 里所有对 counter 计算速率都必须用rate()或increase()，不要直接拿 counter 原始值画折线图，否则你看到的是一条永远向上的直线，没有参考意义。

第二个是成功率。注意，错误率的分子分母都要用 rate，否则窗口不一致会算出奇怪的值：

sum(rate(order_requests_by_status{status="success"}[5m])) by (instance) / sum(rate(order_requests_total[5m])) by (instance)

第三个是 P95 延迟。这个依赖 histogram 数据，_bucket后缀的序列记录了累计分布：

histogram_quantile(0.95, sum(rate(order_cost_ms_bucket[5m])) by (le) )

histogram_quantile是 Prometheus 专门算分位数的函数，le是 histogram 的桶上界标签。这个公式在所有 Prometheus 环境里都是通用的，你只需要把order_cost_ms换成自己的 histogram 指标名。

在 Grafana 里，我把这三个查询分别做成三个面板，然后再加上一个总览面板，把三个指标叠在同一张图上。面板时间范围选“最近 6 小时”，刷新频率 30 秒，基本就能覆盖日常巡检需求。

4.2 把 node_load1 和业务 QPS 放在一起看

单纯看业务 QPS 只能说明“业务忙不忙”，机器负载放在另一张图上又不容易关联。真正的价值在于把两者叠加。

我在 Grafana 里建了一个叫“负载与吞吐对照”的面板，左边 Y 轴是node_load1，右边 Y 轴是 QPS：

# 左轴：归一化后的机器负载 node_load1 / on(instance) count(node_cpu_seconds_total{mode="system"}) by (instance) # 右轴：订单 QPS sum(rate(order_requests_total[5m])) by (instance)

node_load1 / CPU核心数这一步很重要。同样负载 4，在 4 核机器上是满载，在 32 核机器上只是小浪花。归一化之后，负载超过 1.0 就说明 CPU 已经饱和。count(node_cpu_seconds_total{mode="system"}) by (instance)的作用就是算出每台机器的 CPU 逻辑核心数。

两张曲线叠在一起之后，你能看到几种典型状态：

• 业务 QPS 上升，负载同步上升：说明当前是正常的流量驱动，扩容理由充分。
• 业务 QPS 下降，负载仍然高位：说明有别的进程在吃 CPU，或者系统在做大量 IO 等待、内存回收，需要查非业务进程。
• 负载很低，但业务错误率上升：说明问题不在资源，而在依赖调用、网络、数据库连接数等外部因素。
• 负载打满，QPS 反而下跌：典型的性能瓶颈，请求被阻塞了。

这一张对照图，比分开看十张图都管用。我后来做容量评估时，都在它上面拉一条参考线，看到某条业务曲线逼近负载曲线，就该提前扩容了。

4.3 告警规则：机器负载阈值要归一化，业务告警要加护栏

告警规则写在 Prometheus 配置文件里，用groups、rules组织。我给出两个最值得抄的规则。

第一个是机器负载告警，注意阈值不是固定值，而是归一化后的负载：

groups: - name: instance_alerts rules: - alert: HighLoad1m expr: | node_load1 / on(instance) count(node_cpu_seconds_total{mode="system"}) by (instance) > 0.8 for: 10m labels: severity: warning annotations: summary: "实例 {{ $labels.instance }} 负载持续偏高"

for: 10m表示负载连续 10 分钟超过阈值才告警，过滤掉瞬时尖峰。告警的意义不是让你半夜爬起来重启机器，而是让你在问题即将影响业务之前介入。

第二个是业务错误率告警。这里我加了一个护栏条件：如果请求量太低，错误率的绝对值没有意义。比如 1 分钟只有 2 个请求，失败 1 个，错误率 50%，但这不代表系统挂了。所以用and把 QPS 下限带上：

- alert: OrderErrorRateHigh expr: | ( sum(rate(order_requests_by_status{status="failed"}[5m])) by (instance) / sum(rate(order_requests_total[5m])) by (instance) ) > 0.05 and sum(rate(order_requests_total[5m])) by (instance) > 10 for: 5m labels: severity: critical annotations: summary: "订单错误率超过 5%，当前业务存在异常"

这套规则我用了很久，最大的感受是：机器负载告警要防“突然”，业务告警要防“持续”。机器负载抖动剧烈，适合用较长for窗口；业务错误率只要持续几分钟不降，往往预示着大问题，窗口可以短一点，但一定要有流量护栏，不然低峰期误报能把你烦死。

5. 这套监控在真实环境里容易踩的五个坑

部署完成、面板画好、告警配完，这只是开始。真正让人头疼的是跑起来之后的那些“看起来没毛病但数据莫名其妙”的问题。我在多个环境里用过这套组合，下面五个坑是出现频率最高的，每一个都花过我不少时间去定位。

5.1 日志格式一改，历史对比直接失真

业务日志是研发说了算的东西，他们今天在status前面加一个字段，明天把cost_ms改成cost，你的 mtail 程序完全不知情。正则匹配不到新格式，指标就会更新频率骤降甚至归零。更麻烦的是，如果新旧格式混杂在同一个日志文件里，统计出来的数据既包含新格式的贡献，又包含旧格式的缺失，趋势图会变得极其诡异。

我的做法是给 mtail 程序加一个“兜底规则”：如果一行日志匹配不到任何业务规则，就累加到一个unmatched_lines计数器上。

counter unmatched_lines_total // 放在程序末尾 /.*/ { unmatched_lines_total++ }

注意这个规则必须小心，因为每条日志都会命中这个.*，所以它只能作为兜底，不能跟其他规则混在一个计数口径里用。我在 Grafana 上给这个指标单独画了一个面板，一旦它开始持续增长，就说明日志格式变了，马上去找研发对齐。

5.2 标签维度失控：从几百个序列涨到几十万

mtail 的标签机制用起来很爽，但也很容易失控。order_requests_by_status by status这种低基数维度没问题，status 总共就那么几个值。但如果你写的是order_requests_by_order_id by order_id，每天产生几十万订单，这个时间序列量就会爆炸式增长。

Prometheus 单机存储是本地 TSDB，时序数量超过一定量级之后，查询性能和磁盘占用都会恶化。标签高基数是整个 Prometheus 生态最经典的问题，没有之一。

我的经验是：mtail 程序里只对枚举值类字段做标签分组，比如 status、region、method、error_code。像 order_id、user_id、request_id 这种每行都变化的值，绝对不要作为标签。如果你想看某个大客户的量，可以单独用日志里的统计值在业务侧聚合，或者另建一个按客户维度汇总的文件，而不是让 mtail 为每个客户生成一个时间序列。

5.3 日志轮转方式不对，指标被重复累加

业务日志通常按天或按大小轮转，Linux 下常见的方式是logrotate。轮转策略有两种：copytruncate和create。前者是把原文件复制一份然后清空，后者是把原文件改名，再新建一个同名文件。

mtail 在监控日志文件时会记住自己读到了哪个位置。如果使用copytruncate，文件被清空后，mtail 可能无法正确感知，会从偏移 0 开始重新读一遍，导致计数器被重复累加，QPS 看起来突然翻倍。反之，使用create方式轮转，新日志进入新文件，mtail 会跟踪到重命名的旧文件和新文件，通常表现更稳定。

我在生产里被这个坑折腾过一次。某天凌晨订单 QPS 曲线突然出现一个两倍尖峰，持续了十几分钟又恢复，排查了很久才发现是当天凌晨 0 点日志轮转触发造成的重复读取。后来我把日志轮转配置统一改成create方式，这种尖峰再也没有出现过。如果你用copytruncate有历史原因改不了，至少要把这个问题写进排障手册。

5.4 mtail 进程死了，业务监控直接瞎眼

node_exporter 挂了还会有机器层的基础指标，Prometheus 自身也能监控up。但 mtail 是业务指标的入口，它一挂，业务曲线立刻变直线，而你很可能根本不知道是业务挂了还是监控挂了。这很危险，因为监控系统的可用性本身也需要被监控。

所以我在告警规则里永远是先加一条：

- alert: MtailDown expr: up{job="mtail"} == 0 for: 2m labels: severity: critical annotations: summary: "mtail 服务不可用，业务监控数据中断"

另外，同一个 mtail 实例如果负责解析多个日志文件，程序文件写错了也不会影响进程存活，只是某些指标不出来。我在实际运营里会设置一个“心跳文件”，让业务定时往一个固定文件里写一行heartbeat，mtail 把它变成一个 counter。如果在 Grafana 上看到心跳指标停了，业务很可能是真的出了问题；如果连这个文件都没人写了，那就要区分是业务日志停了还是 mtail 没读到。

5.5 本地存储的容量账要提前算

Prometheus 本地存储是自带压缩的，但时序数据的增长依旧很吓人。一个中等规模的集群，机器指标加业务指标，一天可能产生 2~3 GB 数据。按默认 15 天保留期算，30 GB 到 45 GB 是起步。如果业务指标写得多，一个月的保留期可能就需要上百 GB 磁盘。

很多人一开始没在意，直到 Grafana 查询变慢才发现 TSDB 所在磁盘快满了。我的建议是部署第一天就单独挂一块数据盘给 Prometheus，并预留出 1.5 倍到 2 倍于预期的空间。--storage.tsdb.retention.time参数可以控制保留期，我一般设 15 天，太长的历史数据留给远程存储或对象存储去解决，本地只保留能回答“最近两周发生了什么”的数据。

还有一个容易忽略的点：scrape_interval从 15 秒改成 5 秒后，数据点是原来的 3 倍，存储增长也是 3 倍。如果你对实时性没有那么苛刻，15 秒完全够用。监控不是采样频率越高越好，频率越高，磁盘和查询压力越大，而你要回答的核心问题往往 15 秒级别的数据就能覆盖。

最后给一点个人经验。这套方案第一次落地时，不要追求大而全，先从最小的闭环开始：一台机器装 node_exporter，一条业务日志配一个 mtail 正则，一张 Grafana 面板把负载和 QPS 画出来，一条告警规则覆盖机器高负载。跑一周，确认数据可信、告警无噪声，再慢慢加指标、加机器。监控的关键从来不是工具数量，而是当你半夜被叫醒时，能不能在三十秒内判断出“现在系统到底好不好”。把这条链路做扎实了，Prometheus、Grafana、mtail、node_exporter 这四个组件才能真正成为你的值班拍档。