Prometheus监控告警后，如何自动进行故障根因分析？catpaw运维工具解读

TL;DR：Prometheus 很擅长做指标采集、时间序列存储、趋势分析和规则告警。catpaw 想补的不是这套能力，而是另一层东西：主机侧 check、监控盲区、告警后的第一轮根因初筛。两者不是替代关系，而是职责分层。

一个非常常见的问题

每次有人第一次听说 catpaw 这个工具，几乎都会问同一句话：

我已经有 Prometheus 和 Grafana 了，还需要它吗？

这个问题问得很对。因为如果连工具的边界都讲不清，任何新工具看起来都像是在“重复造轮子”。

我的结论很直接：

• 如果你要的是指标采集、趋势图、历史查询，Prometheus 非常强，而且已经是事实标准。
• 如果你要的是“这台机器现在到底出了什么异常”、“告警之后该先查什么”，Prometheus 并不直接负责。

这不是说 Prometheus 不行。恰恰相反，是因为 Prometheus 已经把自己该做的事做得足够好了，所以我们才更需要把不同工具的职责边界讲清楚。

Prometheus 擅长什么，不擅长什么

Prometheus 最擅长的，是把系统状态变成一组持续可查询的时间序列。
比如：

• CPU 使用率
• 内存占用
• 磁盘 IO
• QPS
• 错误率
• P99 延迟

然后你可以在 Grafana 上画图，用 PromQL 做聚合分析，在 Alertmanager 里配置告警路由。

这套链路非常适合回答下面这些问题：

• 最近一周 CPU 使用率是不是持续走高？
• 哪些服务实例的错误率在过去 15 分钟出现了异常抬升？
• 某次发版之后，接口延迟的响应曲线有没有明显变化？
• 整个集群的资源使用率有没有长期逼近瓶颈？

这些问题本质上都属于趋势和历史分析。

但运维值班时，还经常碰到另一类棘手问题：

• 为什么服务进程明明在线，用户连接还是超时？
• 为什么监控大盘全绿，新的 Pod 却启动失败或连不上？
• 为什么健康检查（healthcheck）正常，但用户请求还是偶发失败？
• 为什么文件描述符（fd）突然耗尽，明明 CPU 和内存都还没到瓶颈？

这些问题就不只是“看指标”了，而是“判断异常”。甚至更进一步，是去确认这是否已经构成故障，以及接下来该优先排查哪一层。

指标采集、异常检测、根因初筛，本来就是三层事

很多团队容易把这三件事混在一起，从而产生一种错觉：“指标都采集全了，监控应该就完整了吧？”

其实不然。更合理的架构拆解应该是这样的：

层次	典型工具	解决的问题
Metrics	Prometheus / Node Exporter	系统现在有哪些数字，趋势怎么变
Alerting	Alertmanager / 告警规则	哪些变化值得通知，通知谁
Check + RCA	catpaw	哪些状态已经构成问题，告警后先查什么

注意，这里最容易被忽略的一层就是 Check + RCA。因为很多时候，原始 metrics 明明存在，但距离“一条对值班人有直接帮助的异常判断”还差得很远。例如：

• 有 node_nf_conntrack_entries 这个指标，但没人帮你判断它是否已经逼近内核上限。
• 有网络错误的累计值，但没人帮你计算增量、设置合理阈值、并过滤掉瞬时抖动。
• 有 TCP 各种状态的数量，但没人直接告诉你 CLOSE_WAIT 堆积这么多基本就是连接泄漏。
• 有 listen queue 相关的计数器，但没人把它翻译成“服务在线，但请求可能已被内核静默丢弃”。

指标存在，不等于故障可见。 这就是 check 层工具存在的核心意义。

为什么很多故障在 Grafana 上看不出来

如果你做过一段时间 On-call（值班），大概率遇到过这种时刻：

• 用户反馈服务不稳定。
• 登录服务器发现应用进程还在。
• CPU 使用率正常。
• 内存占用正常。
• 磁盘 IO 正常。
• Grafana 上的监控大盘一片绿色。

然后你不得不开始手动执行一系列 SSH 命令来排查：

dmesg | grep -i conntrack
cat /proc/net/netstat
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn
sysctl net.core.somaxconn
lsof -p <pid> | wc -l

这说明了什么？说明你真正需要的关键故障信息，并不在常规的监控 Dashboard 那一层。更准确地说，是不在已经被加工成通用图表和告警规则的那一层。

有些问题属于典型的主机侧故障信号，例如：

• conntrack 表满了
• 邻居表（ARP）满了
• 关键 sysctl 内核参数发生漂移
• listen 队列溢出
• CLOSE_WAIT 状态连接堆积
• 系统级文件描述符（fd）使用量逼近上限

这些问题，有的或许能从各种 exporter 的指标中拼凑出来，有的甚至根本不会直接出现在常规的 dashboard 上。但就算你能采集到原始指标，也还需要再做几层工作：

1. 从海量原始指标里筛选出真正有故障指示意义的项。
2. 把累计值转换成增量，把冷冰冰的数字转化为“是/否”的故障判断。
3. 设计合理的阈值，在避免误报和漏报之间取得平衡。
4. 把多个关联信号串联起来，形成一条可执行的、标准化的排查路径。

这显然已经超出了“把 metrics 存起来并查询”的范畴。

Node Exporter 的职责不是替你做故障判断

这里很容易对 Node Exporter 产生一种“不公平”的期待。它的设计职责，本来就是将宿主机上的一批系统状态暴露为 Prometheus 可抓取的指标。它不是故障知识库，也不是值班教练。

举例来说：

• 它可以把当前 conntrack 条目数暴露为 node_nf_conntrack_entries。
• 可以把 sockstat 的部分计数暴露出来。
• 可以把网络层错误的累计值暴露出来。
• 可以把各种内核统计信息暴露出来。

但它不会替你回答：

• 对于我当前这个业务场景，conntrack 达到多少算危险？
• 哪几个指标值应该组合在一起看才有意义？
• 哪些短时尖峰应该被忽略，哪些持续抬升的信号必须立刻告警？
• 告警触发之后，下一步该优先排查磁盘、网络、内核还是应用进程？

这不是 Node Exporter 的问题，而是分工本来就不一样。如果做一个类比：

• Prometheus 像一个强大的数据仓库和查询引擎。
• Grafana 像一个强大的可视化与报表界面。
• Alertmanager 像一个强大的告警通知编排器。
• catpaw 则更像一个自带故障知识库和主机侧诊断能力的 check Agent。

一个最典型的例子：conntrack

这是我最喜欢用来解释这个边界问题的场景。假设一台 K8s Node 上出现了连接偶发超时。你打开 Grafana，看到：

• CPU 正常
• 内存正常
• 网络带宽正常
• 磁盘 IO 正常

然后你可能以为一切正常。但真正的问题可能藏在内核日志里：

nf_conntrack: table full, dropping packet.

这时候，新的网络连接包会被内核静默丢弃。用户看到的是 timeout，应用感知到的是“请求好像没发过来”。而你的监控大盘上，很可能没有一个特别刺眼的红色区块告诉你：“这不是应用抖动，是连接跟踪表已经满了！”

为什么？因为从“当前 conntrack 条目数”这个原始指标，到“这是一个正在发生的故障”这个结论之间，至少还隔着两步：

1. 你得知道这台机器上 conntrack 的上限（nf_conntrack_max）是多少。
2. 你得知道当前使用量（nf_conntrack_count）与上限的比例一旦超过某个阈值（比如 90%）意味着什么。

catpaw 的 conntrack 插件在这一层做的事情就很直接：

• 它不会先给你一堆需要自己组合的 metrics。
• 它会直接检查 nf_conntrack_count / nf_conntrack_max 的比例。
• 一旦超过预设的阈值，就直接产出一个标准化的、语义明确的异常事件。

配置也非常简洁：

[[instances]]
[instances.conntrack_usage]
warn_ge = 75.0
critical_ge = 90.0

interval = "30s"

[instances.alerting]
for_duration = 0
repeat_interval = "5m"
repeat_number = 0

这就是 check 型 Agent 的核心价值：它帮你把“原始信号”加工成了“面向故障的判断”。

再看一个场景：sysctl 参数漂移

这类问题更能说明“有指标”和“能发现问题”之间的差别。比如，你明明在系统初始化时调优好了下面这些内核参数：

• net.core.somaxconn = 65535
• vm.swappiness = 1
• fs.file-max = 1000000

但三个月后，可能因为一次内核升级，或者某个配置管理（Ansible/Puppet）任务被意外覆盖，这些参数又悄悄“漂移”回了默认值。你不会立刻发现，直到某次流量高峰来临，服务开始偶发超时或 listen 队列溢出，才意识到不对劲。

Prometheus 能不能采集这些参数？能，或者至少能通过自定义脚本或 exporter 拿到一部分。但关键问题是：谁来维护这份“黄金基线”？谁来持续进行比对？谁来把“偏离基线”这件事直接翻译成一条异常事件？

这时，catpaw 的 sysctl 插件就更接近一个真正意义上的运维基线守护工具：

[[instances]]
[instances.param_check]
params = [
  { key = "net.core.somaxconn", op = "ge", value = "65535" },
  { key = "vm.swappiness", op = "le", value = "10" },
  { key = "fs.file-max", op = "ge", value = "1000000" },
]

这做的不是趋势分析，而是基线守卫和合规性检查。

catpaw 补的，不是 metrics，而是 check 和告警后的动作

如果把 catpaw 定位得更准确一点，我会这样描述它：

1. 它是 check-first，不是 metrics-first

catpaw 的插件设计不是围绕“暴露多少指标”展开的，而是围绕“有哪些典型的故障信号值得直接进行检查”来设计的。这也使得它天然适合以下场景的检测：

• 磁盘空间 / inode 使用率 / 目录可写性
• conntrack / 邻居表 / socket 统计
• TCP 连接状态 / 进程 fd / 系统 filefd
• sysctl 参数 / 文件系统挂载 / 安全模块
• systemd 服务 / Docker 容器 / Redis 实例

2. 它输出的是标准化事件

catpaw 的输出不是一大坨需要再次加工的原始指标，而是更接近运维值班语义的标准化事件，结构清晰地包含：

• 什么检查项触发了
• 目标主机或服务是谁
• 当前检测到的值是什么
• 预设的阈值或判断条件是什么
• 事件的严重级别是什么（Warning/Critical）

这意味着它产出的结果天生就适合直接对接值班通知渠道，比如：

• 控制台（console）
• Webhook API
• Flashduty
• PagerDuty

3. 告警触发后，它还能继续做第一轮诊断

这一点是 catpaw 与大多数传统 check 工具（如 Nagios Plugin）拉开差距的地方。告警事件送出去之后，catpaw 还可以根据事件上下文自动触发 AI 辅助诊断：

• 聚合发生在同一目标上的多个关联告警事件。
• 调用内置的 70+ 种本地诊断工具（如 ss, dmesg, lsof 等）收集上下文信息。
• 必要时，通过模型上下文协议（MCP）接入 Prometheus、Jaeger 等外部数据源，获取历史趋势或链路追踪数据。
• 生成一份结构化的初步诊断报告，再次返回到通知链路中，提供给值班人员。

所以，它补充的不只是“发现异常”，还包括“帮你把异常推进到第一轮根因分析”。

更现实的做法不是替换，而是分层组合

我更倾向于建议大家把监控观测栈理解成一个组合拳，而不是一道单选题。一个更贴近生产现实的架构分层大致如下：

Prometheus / Grafana
  - 指标采集与存储
  - 历史趋势分析
  - 可视化仪表盘
  - PromQL 即席查询

Alertmanager / On-call 平台
  - 告警路由与降噪
  - 值班排班与升级策略
  - 多通道通知编排

catpaw
  - 主机侧深度异常检测
  - 补齐监控盲区
  - 告警后第一轮根因初筛（RCA）

MCP 外部数据源
  - 为 AI 诊断补充历史上下文
  - 对接 Prometheus / Jaeger / CMDB 等

在这个分层架构里，每一层的职责都非常清晰：

• Prometheus 负责看全局、看长期趋势。
• catpaw 负责盯住那些在主机侧可直接引发故障的“钉子户”问题。
• On-call 平台 负责确保异常信息被送达到正确的人。
• MCP 框架 负责把外部系统的历史数据拉回诊断链路，提供更丰富的上下文。

这样组合起来使用，远比争论“到底该选哪一个工具”更接近复杂的真实生产环境。

什么时候特别适合引入 catpaw

如果你的团队已经部署了 Prometheus，但仍经常遇到下面这些情况，那么 catpaw 很可能是一个有价值的补充：

• 值班时还经常需要 SSH 登录机器，凭记忆临时拼接命令排查。
• 监控大盘常常显示绿色，但业务故障还是发生了。
• 团队里只有少数几个人熟悉 Linux 内核层的排障命令，知识无法沉淀。
• Node Exporter 暴露的指标很多，但真正有用的、准确的告警规则始终难以配齐。
• 希望告警发出去的时候，就能顺手附上第一轮的自动化分析结论。

尤其是下面这几类 catpaw 内置插件，通常非常适合作为首批上线的检测项：

• conntrack - 连接跟踪表检查
• tcpstate - TCP 连接状态分析
• sockstat - 系统 socket 统计
• sysctl - 内核参数基线守卫
• procfd - 进程文件描述符检查
• filefd - 系统级文件描述符检查

这些都是传统以 Prometheus 为中心的监控栈里，最容易出现“知道有数字，但不知道如何转化为故障判断”的典型盲区。

什么时候不必强推

反过来讲，也没有必要把 catpaw 鼓吹成所有团队都必须立刻接入的银弹。如果你当前的运维建设处在以下阶段，那么引入 catpaw 的优先级可能没有那么高：

• 观测基础未打好：还没有建立起基础的 Metrics（指标）、Logging（日志）、Tracing（链路追踪）体系。
• 流程尚未规范化：团队暂时还没有正式的值班（On-call）和事件响应流程。
• 业务规模较小：当前核心诉求仅仅是保证服务 UpTime 和对基础资源（CPU、内存、磁盘）的监控。
• 主要矛盾在其他方面：当前最大的痛点不是监控盲区，而是告警泛滥、噪音过大、或基础运维规范太差。

这并非说明 catpaw 无用，而是强调解决问题的优先级和顺序要对。在基础的、可观测性能力没打牢之前，任何更高级的自动化排障闭环都很难发挥出其真正的价值。

真正该替代的，不是 Prometheus，而是那段重复的人肉劳动

我认为这篇文章最想传达的一个核心观点是：catpaw 不是来替代 Prometheus 的。

它更像是在尝试替代下面这段重复、低效且高度依赖个人经验的人肉劳动：

1. 在深夜收到一条内容模糊、缺乏上下文的告警通知。
2. 迷迷糊糊地 SSH 登录到目标机器。
3. 在脑海中回忆相关场景的排查命令。
4. 手动拼接执行 cat /proc/net/...、ss、dmesg、sysctl、lsof 等一系列命令。
5. 将这些原始、杂乱的命令输出结果，翻译成人类语言后截图发到值班群里同步。

Prometheus 不该为这段工作缺失而“背锅”，因为它从未承诺自己要负责这部分。而 catpaw 想做的，恰恰就是把这段劳动中重复、可标准化的部分压缩掉。

如果你已经有 Prometheus，可以怎么开始

最简单的切入方式不是搞“一刀切”的替换，而是从最易出事、最难通过现有大盘直观发现的几个痛点补起。

例如，可以先从下面这 3 个插件开始尝试：

1. conntrack

适合部署在 K8s Node、NAT 网关、高并发入口服务器等场景。

2. tcpstate

适合用于排查 CLOSE_WAIT / TIME_WAIT 堆积、连接泄漏、端口耗尽等经典网络问题。

3. sysctl

适合将你认为关键的内核调优参数（如 somaxconn, file-max）固化为长期守护的基线，而不是依靠人的记忆。

部署后，可以先保留默认的控制台（console）输出，直观感受检查结果：

[notify.console]
enabled = true

或者，直接将事件输出到你正在使用的 On-call 平台（如钉钉、飞书、Flashduty等）。如果想进一步验证告警后自动诊断的能力，可以启用 AI 诊断模块（需配置 API Key）：

[ai]
enabled = true
model_priority = ["default"]

[ai.models.default]
base_url = "https://api.openai.com/v1"
api_key = "${OPENAI_API_KEY}"
model = "gpt-4o"

这样，你就能获得非常清晰的体验分层：

• Prometheus 继续负责全局大盘和长期趋势分析。
• catpaw 开始负责主机侧的深度异常检测和第一轮根因线索提供。

最后总结

如果用最简短的话来总结 Prometheus 与 catpaw 的职责分野，我会这么回答：

• Prometheus 擅长回答：“最近（一段时间）发生了什么变化？趋势如何？”
• catpaw 更擅长回答：“这台机器（现在）到底哪里不对？可能是什么原因？”

一个负责看趋势、看历史。一个负责盯现场、盯即时故障信号。一个告诉你曲线怎么走，一个在半夜提醒你：“注意，这不是普通波动，这已经是个需要立刻处理的问题，并且建议你先从X方面查起。”

所以，一个真正成熟、健壮的监控观测体系，通常不是某个单一工具胜出，而是每一层工具都各司其职，协同工作。

Prometheus 很强，但它不负责半夜帮你查机器。 而这，正是像 catpaw 这样的工具想要弥补的领域。对于更深入的技术讨论和实际运维中遇到的各类稳定性、效率问题，也欢迎到专注于 运维 & 测试 的版块，或者更广泛的 云栈社区 技术论坛与同行们交流分享。