function call 实战：让 LLM 自动判断 pod 异常、调用日志工具并完成故障分析
<h2 id="前言">前言</h2><p>今天是一期function call的实战</p>
<h2 id="先上代码">先上代码</h2>
<p>function_call</p>
<p><img alt="illustration-01" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202604/1416773-20260416112520542-1952465206.png" class="lazyload"></p>
<ul>
<li>先获取 Pod 当前状态</li>
<li>让 LLM 判断这个状态是否需要进一步排查</li>
<li>如果需要排查，就要求 LLM 调用 <code>get_pod_logs</code> 工具拿日志</li>
<li>再让 LLM 基于日志输出问题原因、根因分析和修复建议</li>
</ul>
<h4 id="openai-客户端初始化">OpenAI 客户端初始化</h4>
<p>这部分代码的作用，是初始化模型客户端，并从环境变量里读取模型名和接口地址</p>
<pre><code class="language-python">from openai import OpenAI
import json
import os
client = OpenAI(
api_key=os.getenv("OPENAI_API_KEY"),
base_url=os.getenv("API_BASE_URL")
)
model = os.getenv("DEFAULT_MODEL")
</code></pre>
<h4 id="工具定义">工具定义</h4>
<p>声明可供模型调用的函数工具</p>
<pre><code class="language-python">tools = [
{
"type": "function",
"function": {
"name": "get_pod_logs",
"description": "获取Pod日志用于排查问题",
"parameters": {
"type": "object",
"properties": {
"pod_name": {"type": "string"},
"namespace": {"type": "string"}
},
"required": ["pod_name"]
}
}
}
]
</code></pre>
<ul>
<li>有一个叫 <code>get_pod_logs</code> 的工具</li>
<li>这个工具是用来获取 Pod 日志的</li>
<li>它需要什么参数</li>
<li>哪个参数是必填的</li>
</ul>
<p>function call 的本质不是让模型直接跑 python，而是让模型知道，有什么工具可以调用外部世界的接口</p>
<h4 id="获取-pod-状态和日志">获取 Pod 状态和日志</h4>
<p>接下来这两个函数，是本地实现的模拟逻辑，后期可以接入正式环境的数据，这里先用模拟数据</p>
<pre><code class="language-python">def get_pod_state(pod_name, namespace):
# 可以用 kubectl 或 k8s API, 返回：Running / CrashLoopBackOff / OOMKilled 等
return "CrashLoopBackOff"
def get_pod_logs(pod_name, namespace="default"):
# 去日志平台上获取对应的日志即可
return "ERROR: database connection failed\nException: timeout"
</code></pre>
<h4 id="让-llm-先判断是否有异常">让 LLM 先判断是否有异常</h4>
<p>下面这段代码，是第一次调用模型。</p>
<pre><code class="language-python">messages = [
{
"role": "system",
"content": """你是Kubernetes运维专家。
判断 Pod 状态：
- 如果是 Running / 正常 → 返回 OK
- 如果是 CrashLoopBackOff / OOMKilled / Error → 返回 NEED_DEBUG
只返回 OK 或 NEED_DEBUG"""
},
{
"role": "user",
"content": f"Pod状态是: {pod_state}"
}
]
resp = client.chat.completions.create(
model=model,
messages=messages
)
decision = resp.choices.message.content.strip()
</code></pre>
<h4 id="llm-调工具拿日志">LLM 调工具拿日志</h4>
<p>如果真的有问题，调用预定义的函数获取相关信息</p>
<pre><code class="language-python">messages = [
{
"role": "system",
"content": """你是一个Kubernetes故障诊断专家。
当Pod异常时：
1. 必须调用 get_pod_logs 获取日志
2. 根据日志分析问题
3. 输出：
- 问题原因
- 根因分析
- 修复建议
"""
},
{
"role": "user",
"content": f"Pod {pod_name} 状态是 {pod_state}，请排查问题"
}
]
response = client.chat.completions.create(
model=model,
messages=messages,
tools=tools
)
</code></pre>
<p>这里和第一轮最大的区别，就是多传了一个 <code>tools=tools</code>，这意味着模型此时知道自己可以发起函数调用，随后代码会检查模型是否真的触发了工具调用：</p>
<pre><code class="language-python">msg = response.choices.message
if msg.tool_calls:
tool_call = msg.tool_calls
args = json.loads(tool_call.function.arguments)
</code></pre>
<p>拿到工具调用后，再由本地 Python 去真正执行：</p>
<pre><code class="language-python">logs = get_pod_logs(**args)
</code></pre>
<p>然后把工具执行结果，再喂回模型，让它基于日志继续完成最终分析：</p>
<pre><code class="language-python">final_resp = client.chat.completions.create(
model=model,
messages=[
*messages,
msg,
{
"role": "tool",
"tool_call_id": tool_call.id,
"content": logs[:3000]
}
]
)
</code></pre>
<h4 id="执行链路">执行链路</h4>
<p><img alt="illustration-02" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202604/1416773-20260416112558477-405667869.png" class="lazyload"></p>
<pre><code class="language-text">获取 Pod 状态
↓
LLM 判断：OK / NEED_DEBUG
↓
如果 NEED_DEBUG
↓
LLM 发起 tool call：get_pod_logs(pod_name, namespace)
↓
本地函数执行，拿到日志
↓
日志作为 tool message 回填给 LLM
↓
LLM 输出：问题原因 + 根因分析 + 修复建议
</code></pre>
<h2 id="这里为什么不用-if-else">这里为什么不用 if-else</h2>
<p>很多老哥看到这里，肯定会问：</p>
<p>既然 <code>Running</code> 就是正常，<code>CrashLoopBackOff</code> 就是异常，那直接 if-else 不香吗？</p>
<p>如果场景足够简单，当然可以直接写 if-else。甚至在这个场景中，第一段判断逻辑严格来说也确实可以用规则替代，像下面这样：</p>
<pre><code class="language-python">if pod_state in ["Running", "Succeeded"]:
decision = "OK"
else:
decision = "NEED_DEBUG"
</code></pre>
<p>这么写没毛病，而且更便宜、更稳定、更可控，那为什么还要引入 LLM？因为真实线上环境，往往没这么简单</p>
<p>线上判断一个 Pod 是否异常，很多时候不是看一个字段就能拍板，而是要综合很多信息一起看</p>
<p>1）状态看起来正常，但其实已经不正常了， Pod 状态还是 <code>Running</code>，但实际上业务已经挂了，比如：</p>
<ul>
<li>readiness probe 一直失败</li>
<li>接口 RT 飙升</li>
<li>错误率升高</li>
<li>日志持续报错</li>
<li>下游数据库连接频繁超时</li>
<li>CPU 不高，但线程池已经卡死</li>
</ul>
<p>这时候如果你只写：</p>
<pre><code class="language-python">if pod_state == "Running":
return "OK"
</code></pre>
<p>2）状态异常，但未必需要立刻排查</p>
<ul>
<li>pod 状态 <code>Completed</code></li>
<li>灰度发布期间有短暂重建</li>
<li>HPA 扩缩容带来的短时波动</li>
<li>节点维护导致的瞬时漂移</li>
</ul>
<p>这时候你如果只根据状态值机械判断，就很容易误报</p>
<p>3）真正有价值的判断，往往依赖多维信号</p>
<ul>
<li>Pod 当前 状态</li>
<li>restart 次数</li>
<li>最近 5 分钟日志</li>
<li>CPU / Memory 使用率</li>
<li>OOM 事件</li>
<li>节点状态</li>
<li>发布记录</li>
<li>同服务其他副本是否也异常</li>
<li>Prometheus 指标波动</li>
</ul>
<p>这个时候用 if-else 纯流程化的判断模式，对于事件的判断就不太合适了。if-else 擅长处理边界清晰、模式稳定的场景</p>
<p>而LLM 更适合处理需要综合上下文、模糊判断以及不固定条件的综合判断，所以这里采用LLM 的表达能力和归纳能力会更方便</p>
<p><img alt="illustration-03" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202604/1416773-20260416112627637-1477895473.png" class="lazyload"></p>
<h2 id="总结">总结</h2>
<p>通过 Function Call 获取外部数据，最后让 LLM 输出总结性的建议以及处理方案</p>
<p>至于为什么不用 if-else，简单场景当然可以用固定流程，但当判断开始依赖多维数据、日志语义和上下文综合分析时，LLM 会更灵活。在更加复杂的场景下，则是固定流程和 LLM 组合使用</p>
<h2 id="后记">后记</h2>
<p>在本文中，明确告诉了llm，通过<code>get_pod_logs</code>去拿pod日志去拿对应的数据，那如果遇到更加复杂的事故，我们需要</p>
<ul>
<li>1）拿pod日志，通过kubectl logs</li>
<li>2）拿业务日志，通过日志平台接口</li>
<li>3）获取负载数据，通过监控接口</li>
<li>4）获取发布数据，通过发布平台接口</li>
<li>5）获取上下游的top结构，通过cmdb接口</li>
<li>6）太多了，列举不完...</li>
</ul>
<p>如何让llm通过当前事故情况，自动选取对应的接口函数获取数据呢？这是个非常现实、棘手的问题了，但这不是本期内容了，我们下一期再见</p>
<h2 id="联系我">联系我</h2>
<ul>
<li>联系我，做深入的交流</li>
</ul>
<p><img alt="" width="500" height="200" loading="lazy" src="https://img2024.cnblogs.com/blog/1416773/202411/1416773-20241121135740959-1907948957.png#" class="lazyload"></p>
<p>至此，本文结束</p>
<p>在下才疏学浅，有撒汤漏水的，请各位不吝赐教...</p>
</div>
<div id="MySignature" role="contentinfo">
<p>本文来自博客园，作者：it排球君，转载请注明原文链接：https://www.cnblogs.com/MrVolleyball/p/19876155</p>
<div>本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须在文章页面给出原文连接，否则保留追究法律责任的权利。 </div><br><br>
来源：https://www.cnblogs.com/MrVolleyball/p/19876155
頁:
[1]