HolmesGPT 实战：让 AI 把告警、日志和指标串成故障线索

python运维技术

2026年7月19日 14:00
北京

在小说阅读器读本章

去阅读

SRE AGENT · INCIDENT2026.07

先猜原因，再找证据？

先把 证据 摆到桌面上

再判断故障方向

HolmesGPT · 告警 · 日志 · 指标 · 变更

python运维技术

SREAI

3 Parts + Conclusion

滑动

PART 01

事故调查

它解决哪一段

PART 02

安装取证

国内模型与命令

PART 03

生产边界

权限、数据、验证

PART ///

写在最后

先读，再执行

上次写 K8sGPT 的时候，我其实一直在想另一个问题。

如果 AI 已经能帮我们看 Kubernetes 资源异常了，那再往前走一步，它能不能帮运维调查一次真正的生产故障？

这里我说的不是自动修复。

生产故障刚发生的时候，最怕的不是没人执行命令，而是大家还没看清现场，就已经开始猜原因。

告警在 Alertmanager 里。

指标在 Prometheus 里。

日志在 Loki 或 ELK 里。

服务状态在 Kubernetes 里。

最近一次发布记录可能在 Argo CD、GitHub、GitLab 或 Jenkins 里。

再加上值班群里的几句描述，整个现场很容易碎成一地。

这时候 AI 如果直接说“我来修”，我一般不敢信。

但如果它能先帮我把证据捞出来，告诉我它看到了哪些异常、这些异常之间有没有关系、下一步应该查什么，这个方向就比较靠谱。

HolmesGPT 做的就是这一类事情。

01

PART

HolmesGPT 是什么

POSITION · SRE AGENT

告警触发

先确定异常范围

→

跨源取证

资源、日志、指标

→

整理线索

给出判断依据

HolmesGPT 的价值，是把分散证据放进同一次调查。

HolmesGPT 是一个开源的 SRE Agent。

官方对它的定位很直接：用来调查生产事故，帮助定位根因。它不是只盯着 Kubernetes，也可以连接虚拟机、云服务、数据库、SaaS 平台和各种可观测性系统。

从运维角度看，我更愿意把它理解成一个“排障调查助手”。

它不是替你点重启按钮的人。

它更像是值班时坐在旁边的人，你问它：

...text

这个服务为什么不健康？

这个 Pod 为什么起不来？

当前有哪些 Prometheus 告警？

这个 namespace 里最近有什么异常？

然后它会去查自己能访问的数据源。

Kubernetes 资源状态、Pod 日志、Prometheus 指标、Grafana 面板、Loki 日志、Datadog、AlertManager、PagerDuty、Jira、GitHub、GitLab、Jenkins，这些都在它官方列出的集成范围里。

这就和 K8sGPT 有点不一样了。

K8sGPT 更像是给 Kubernetes 资源加一层诊断和解释。

HolmesGPT 想做得更宽一点：围绕一次事故，把告警、指标、日志、资源状态和变更信息串起来看。

这个方向很像真实运维现场。

因为故障很少只藏在一个命令输出里。

02

PART

它解决的是哪一段问题

INCIDENT · INVESTIGATION

我觉得 HolmesGPT 解决的不是“最后怎么修”，而是“前面怎么查”。

很多线上故障，真正耗时间的是前 10 到 20 分钟。

告警来了，先看哪个服务？

是应用问题，还是 Kubernetes 调度问题？

是新版本引入的，还是依赖服务挂了？

是流量变大了，还是资源限制太小？

这些问题都不难，但现场信息分散的时候，人会很容易绕。

尤其是凌晨值班。

人一困，第一反应就容易去翻自己最熟悉的地方。熟悉日志的人先看日志，熟悉 Prometheus 的人先看指标，熟悉 Kubernetes 的人先 kubectl describe。

这些动作都没错。

问题是，它们未必是这次故障最短的路径。

HolmesGPT 的价值在这里：它可以先按一个 Agent 的方式去调用工具，查资源、查日志、查指标、查告警，再给出一个排查结论。

这个结论不一定百分百对。

但如果它能把证据列出来，就已经有用了。

比如它告诉你：

某个 Deployment 的 Pod 正在 CrashLoopBackOff；

Pod 之前的日志里出现数据库连接超时；

同一时间 Prometheus 里数据库连接数打满；

最近一次发布刚好改过连接池参数。

这时候它不是在“神奇地算根因”。

它只是把你本来要手工拼的线索，提前摆到桌面上。

这就够了。

03

PART

先跑起来看看

START · CLI USAGE

如果只是想体验 HolmesGPT，先用 CLI 就行。

安装 CLI

macOS 或 Linux 可以用 Homebrew：

...bash

brew tap robusta-dev/homebrew-holmesgpt

brew install holmesgpt

holmes ask --help

也可以用 pipx：

...bash

pipx install holmesgpt

holmes ask --help

官方也提供了 Docker 方式，适合不想在本机装太多东西的人。实际使用时，需要把 kubeconfig、云厂商配置或 API Key 挂进去。

入门阶段，我建议先用本地 kubeconfig 测试。

先确认当前 kubectl 指向的是你想看的集群：

...bash

kubectl config current-context

配置国内模型 API

然后配置模型 API。

HolmesGPT 通过 LiteLLM 调用大模型，也支持 OpenAI 兼容接口。下面用 DeepSeek 官方 API 做示例。

\\这里有一个前提：模型必须支持 Function Calling，也就是能按 HolmesGPT 的要求调用 kubectl、日志和监控查询工具。\\只会聊天、不能调用工具的模型，接上去也完成不了事故调查。

当前可以使用 deepseek-v4-flash：

...bash

export OPENAI\_API\_BASE=\"https://api.deepseek.com\"

export OPENAI\_API\_KEY=\"your-deepseek-api-key\"

export MODEL=\"openai/deepseek-v4-flash\"

虽然环境变量沿用了 OPENAI\_\* 这个名字，实际请求发送到的是 DeepSeek。openai/deepseek-v4-flash 里的 openai/ 是 HolmesGPT 识别 OpenAI 兼容接口所需的前缀。

\\API Key 不要写进脚本或提交到 Git 仓库。\\团队正式部署时，应该放进 Kubernetes Secret 或密钥管理系统。

跑一次测试

配置完成后，先问一个具体问题：

...bash

holmes ask \"请用中文检查当前集群中状态异常的 Pod，说明异常原因，并列出判断依据。\"

如果你想按官方 walkthrough 做一次测试，可以创建一个有问题的测试 Pod：

...bash

kubectl apply -f https://raw.githubusercontent.com/robusta-dev/kubernetes-demos/main/pending\_pods/pending\_pod\_node\_selector.yaml

再让 HolmesGPT 调查：

...bash

holmes ask \"请用中文调查 user-profile-import Pod 为什么无法调度，并给出证据和建议的处理步骤。\"

这一步跑通以后，你基本就能理解它的工作方式了。

如果团队已经在用阿里云百炼，也可以把 API Base 换成 DashScope 的 OpenAI 兼容地址，把模型名换成支持工具调用的通义千问模型。配置思路一样，关键还是确认模型和接口都支持 Function Calling。

它不是让你在聊天框里凭空问问题。

它会根据你的问题，去调用已经配置好的数据源，然后基于查到的结果回答。

这点很重要。

生产环境里，我不喜欢那种纯靠大模型猜的运维工具。排障这件事，必须让工具先拿证据说话。

04

PART

Kubernetes 里它能看什么

KUBERNETES · EVIDENCE

HolmesGPT 的 Kubernetes 工具集默认就能用。

官方文档里写得比较清楚：默认的 Kubernetes 集成通过 kubectl 读取资源。CLI 场景使用本地 kubeconfig，部署到集群里时使用 Pod 的 ServiceAccount。

它默认是只读权限。

而且 secrets 等敏感资源默认排除。

从生产使用角度看，这个设计比较合理。

它可以查节点、Deployment、Pod 等资源状态，也可以读取 Pod 日志。日志方面，除了直接读 Kubernetes Pod 日志，也能接 Loki、Elasticsearch / OpenSearch、Coralogix、Datadog 这类日志系统。

如果集群里有 Metrics Server，还可以开启 live metrics，看当前 Pod 和 Node 的 CPU、内存使用。

如果你接了 Prometheus，它可以进一步从指标维度查问题。

这就比单纯 kubectl describe 往前走了一步。

因为很多故障只看 Kubernetes 状态是不够的。

Pod 在重启，只是现象。

为什么重启，可能要看应用日志。

应用日志里看到超时，还要看依赖服务指标。

依赖服务指标异常，又可能要看最近一次发布或配置变更。

HolmesGPT 的思路，就是尽量把这些数据源放到一个调查过程中。

05

PART

我会怎么在生产里用

PRODUCTION · PRACTICE

我会先放在三个位置。

第一个位置：只读排查。

给它一个只读权限的 kubeconfig 或 ServiceAccount，让它只能看资源、看日志、查指标，不允许改资源。

先在测试集群或预发集群跑。

我关心的不是它回答得多漂亮，而是它有没有稳定找到真实异常，有没有乱推断，有没有把无关信息说成根因。

第二个位置：告警辅助分析。

比如 Alertmanager 里来了一个服务不可用告警，不要直接让 HolmesGPT 修。

可以让它先回答几个固定问题：

...text

你看到了哪些异常？

这些异常来自哪些数据源？

你认为最可能的方向是什么？

下一步建议人工检查哪几个点？

这个提示词比“帮我解决这个故障”更适合生产环境。

因为它把工具限制在调查和建议层。

第三个位置：事故复盘素材。

很多事故结束后，大家才发现现场证据没有留好。

当时 Pod 是什么状态？

有没有重启？

当时的错误日志是什么？

Prometheus指标有没有一起抖？

如果 HolmesGPT 的调查过程能保留下来，它可以成为复盘材料的一部分。

当然，不能只信它。

复盘还是要回到原始日志、指标、发布记录和人的判断。

06

PART

它比普通脚本强在哪里

COMPARE · SCRIPT

以前我们也会写巡检脚本。

脚本查 Pod 状态、查重启次数、查 PVC、查 Node、查证书过期、查磁盘、查资源配额。

这类脚本很稳。

但脚本的问题也明显：它只会按你写好的规则工作。

规则里没写，它就看不到。

HolmesGPT 这类工具多了一层 Agent 调用能力。它可以根据问题决定下一步查什么，而不是固定跑一串命令。

比如你问的是 Pod 为什么不健康，它可能会先查 Pod 状态，再看 Event，再看日志，再看相关 Deployment。

如果你接了 Prometheus，它还可能去看指标。

这个过程有点像一个有经验的运维在排障，只不过它的判断质量取决于工具配置、数据质量和模型能力。

所以我不会说它替代脚本。

更合适的关系是：脚本负责稳定巡检，HolmesGPT 负责临时调查。

脚本适合回答“有没有问题”。

HolmesGPT 更适合回答“这个问题可能和什么有关”。

07

PART

真用的时候，别跳过这些边界

RISK · BOUNDARY

第一，不要让它一开始就有写权限。

HolmesGPT 官方有 Kubernetes Remediation 相关能力，可以做扩缩容、回滚、修改资源等动作。

但这类能力不适合一上来就在生产环境打开。

先只读。

等团队对它的输出质量、审计方式、回滚流程都熟了，再讨论能不能进入执行层。

这个顺序不要反。

第二，注意数据出网和敏感信息。

虽然 Kubernetes 工具集默认排除 secrets，但日志里可能有 token、内部域名、用户信息、数据库错误、接口路径。

如果公司对数据出网有要求，就要考虑本地模型、内网模型，或者先做脱敏。

不要因为工具看起来方便，就把生产日志整包丢给外部模型。

第三，AI 给的是调查结论，不是事故定责。

它可以说“我观察到这些现象，所以怀疑某个方向”。

但最终根因要靠++证据闭环++。

有没有发布记录？

有没有指标拐点？

有没有日志时间线？

有没有回滚验证？

这些东西缺一块，结论就不要写得太死。

第四，别让新人绕过基础能力。

这类工具对新人很有帮助。

但帮助的方式应该是让新人更快理解现场，而不是让新人不用学 Kubernetes、Prometheus、日志和发布流程。

比较好的用法是：先看 HolmesGPT 的结论，再用 kubectl describe、kubectl logs、PromQL 和原始日志去验证。

验证几次，比单纯看 AI 输出更长本事。

08

PART

普通团队可以怎么落地

LANDING · TEAM

如果团队现在还没有完整 AIOps 平台，也不用急。

可以先做一个很小的试点。

1

第一步，选一个非核心集群。

2

第二步，安装 HolmesGPT CLI。

3

第三步，只配置只读 kubeconfig。

4

第四步，挑几个常见问题测试，比如 Pod Pending、CrashLoopBackOff、Service 无 Endpoints、资源不足。

5

第五步，把 HolmesGPT 的输出和人工排查结果对照。

6

第六步，记录它在哪些场景有用，哪些场景容易猜错。

7

第七步，再考虑接 Prometheus、Loki、AlertManager。

这个过程看起来慢，但符合运维做事的习惯。

先让工具证明自己能稳定减少重复劳动，再给它更多上下文。

不要一开始就追求“自动闭环”。

自动闭环听起来好听，出了问题就不好听了。

///

LAST

最后的判断

SUMMARY · JUDGEMENT

HolmesGPT 比 K8sGPT 更像一个面向事故调查的 AI 运维助手。

K8sGPT 的入口更聚焦 Kubernetes 资源诊断。

HolmesGPT 的野心更大，它想把告警、日志、指标、资源状态、工单和代码平台都接进一次调查里。

这个方向我觉得值得关注。

但在生产环境里，我对这类工具的态度还是那句话：

先让它读。

再让它解释。

再让它建议。

最后才讨论能不能执行。

如果你现在已经在用 Kubernetes、Prometheus、Loki 或 Grafana，又想试试 AI 在运维排障里到底能不能帮上忙，HolmesGPT 可以作为 K8sGPT 之后的下一个工具来看。

不要指望它一上来替你处理事故。

先让它帮你把现场看清楚。

这一步做好，已经能省不少时间。

参考资料

HolmesGPT GitHub：https://github.com/HolmesGPT/holmesgpt

HolmesGPT CLI 安装文档：https://holmesgpt.dev/latest/installation/cli-installation/

HolmesGPT Kubernetes 工具集：https://holmesgpt.dev/latest/data-sources/builtin-toolsets/kubernetes/

HolmesGPT 内置数据源：https://holmesgpt.dev/latest/data-sources/builtin-toolsets/

HolmesGPT 推荐配置：https://holmesgpt.dev/latest/data-sources/recommended-setup/

HolmesGPT OpenAI 兼容模型配置：https://holmesgpt.dev/latest/ai-providers/openai-compatible/

DeepSeek API 文档：https://api-docs.deepseek.com/

DeepSeek Function Calling：https://api-docs.deepseek.com/guides/function\_calling/

我是 python运维技术，长期关注 Python 自动化、Linux、Kubernetes 和 AI 运维在生产环境里的真实用法。

既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。

点赞

在看

转发

THANKS FOR READING

---