ARTICLE · 1122787
AIOps落地:Dify + Loki MCP做智能日志分析助手
搞 AIOps 一年多了，手上已经攒了一批能直接落地的打法，也有了一套自己研发的 AIOps 平台，有兴趣的朋友可以来找我聊（后台回复：链接）
◆ 摘 要
三个官方工具、一套排查型提示词，就能让AI像高级SRE一样查日志、找根因、给方案。全文含可直接抄作业的部署命令与完整提示词。
◆ 核 心 观 点智能日志分析的灵魂，不在工具多强，而在"先探索、再查询、后分析"的排查纪律被固化成了流程。别指望大模型天赋异禀，好的SOP才是智能体落地的前提。
玩AIOps这一年多，最大的感受就一句话：运维的尽头，是让机器替你值班。🔥
说说我的情况。我一直在折腾智能日志分析，之前的方案是Grafana的MCP，底下挂Loki。用是能用，但总觉得隔了一层。
直到有天我翻Grafana仓库，才发现一个被忽略的事实——Loki官方自己就带MCP服务，压根不用绕道Grafana。
不过话说回来，官方这个MCP只给了3个工具，看着寒酸：查label名称、查label下的值、执行LogQL查询。
但别小看这仨。日志分析的本职工作，本来就是"先摸清结构、再精准查询"。工具少，反而逼着Agent把探索流程做得更聪明。👍
工具从来不是瓶颈，不会把排查思路教给AI才是。
一、把Loki MCP跑起来
前提：Loki你已经装好了，这步不废话。项目在GitHub上：github.com/grafana/loki-mcp
① 拉代码
git clone https://github.com/grafana/loki-mcp.git
② 打成Docker镜像（有个小坑：国内编译Go项目会卡在依赖下载，先把代理换成国内源）
cd loki-mcp
sed -i 's#RUN go mod download#RUN go env -w GOPROXY=https://goproxy.cn,direct && go mod download#' Dockerfile
docker build -t loki-mcp-server:local .
③ 启动并验证
docker run -d -p 8080:8080 -i loki-mcp-server:local
curl http://localhost:8080/sse
二、接入Dify
这步简单到没什么好写的：工具 → MCP → 添加MCP服务，地址指向刚才那个8080端口，完事。
三、调教你的日志分析Agent
进Dify的工作室，新建一个空白的Agent应用，把Loki MCP的三个工具挂上去。
然后是最关键的部分——提示词。我把规则拆成了六个模块，核心思路不变，但更好维护：
◆ 模块1 · 角色与铁律
你是资深的Loki日志分析专家，手上有三个MCP工具：loki_label_names（列出所有label）、loki_label_values（查某个label的所有取值）、loki_query（执行LogQL查询）。不了解日志结构时，严格按顺序来：先查label_names → 再查label_values → 最后才写查询。禁止凭空捏造label名、取值和查询语句。
◆ 模块2 · 探索流程
用户说"帮我排查""看看为什么挂了""分析下500错误"这类需求时：先拉label_names → 重点留意job、app、service、namespace、pod、container、level、cluster、instance这些高频label → 对可疑label查values，挑出与问题最匹配的 → 基于真实存在的label组合写出精准LogQL。
◆ 模块3 · 查询规范
必须用精确label过滤（比如 {job="nginx"}）；严禁全库扫描（{} |= "error"这种写法直接毙掉）；时间范围默认最近1小时，可按需收窄到5分钟或放宽到24小时；返回条数默认100。
◆ 模块4 · 报错怎么办
日志里出现error、timeout、panic、OOM、CrashLoopBackOff、502/503/504等关键词时：提取核心错误 → 归纳模式 → 判断原因 → 评估影响面 → 给修复建议。发现namespace/pod/container等label时，再按K8s维度分析：pod是否反复报错、有没有重启、超时、upstream error、数据库连不上、资源吃紧。
◆ 模块5 · 输出格式
三段式，缺一不可：① 发现了什么 ② 为什么发生 ③ 怎么修。绝不甩一堆原始日志给用户，日志太长只留关键片段并归纳共性。
◆ 模块6 · 兜底与安全
查不到别放弃：先检查label对不对、value存不存在，换label、放宽条件再试；用户给的服务名不存在时，主动找相似的service/pod/job。安全红线：token、password、secret、access_key一律自动脱敏。
◆ 读 者 反 驳你可能在想：就3个工具的MCP，我能直接写LogQL，为啥还要套一层Agent？多此一举吧？
说白了，差别在半夜三点的告警现场。你手写LogQL，得先想label叫什么、再猜服务名、再翻文档试语法，一个都不熟就得卡半天。而这套Agent是"说人话进去，给结论出来"——它自己探索结构、自己试错、自己总结。工具越少，流程越清晰，反而越不容易跑偏。
四、实测效果
◆ 测试1 · 摸底
扔过去一句"帮我看看都有哪些日志"——Agent自己先探索label，再列出可查的日志源，全程没让我操心。
◆ 测试2 · 定向排查
"看一下/var/log/messages日志里有没有oom相关日志"——直接构造查询、过滤关键词、给出分析结论，一气呵成。🎯
说实话，这种"说人话就能查日志"的体验，用过就回不去了。
收尾
这套方案的精髓，不在于工具多强，而在于提示词把"运维专家的排查思路"固化成了流程——先探索、再查询、后分析，一步一步来，AI就不会瞎编。
别指望大模型天赋异禀，好的SOP才是智能体落地的前提。