function call 实战：让 LLM 自动判断 pod 异常、调用日志工具并完成故障分析

前言

今天是一期function call的实战

先上代码

先获取 Pod 当前状态
让 LLM 判断这个状态是否需要进一步排查
如果需要排查，就要求 LLM 调用 get_pod_logs 工具拿日志
再让 LLM 基于日志输出问题原因、根因分析和修复建议

OpenAI 客户端初始化

这部分代码的作用，是初始化模型客户端，并从环境变量里读取模型名和接口地址

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")

工具定义

声明可供模型调用的函数工具

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"]
            }
        }
    }
]

有一个叫 get_pod_logs 的工具
这个工具是用来获取 Pod 日志的
它需要什么参数
哪个参数是必填的

function call 的本质不是让模型直接跑 python，而是让模型知道，有什么工具可以调用外部世界的接口

获取 Pod 状态和日志

接下来这两个函数，是本地实现的模拟逻辑，后期可以接入正式环境的数据，这里先用模拟数据

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"

让 LLM 先判断是否有异常

下面这段代码，是第一次调用模型。

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[0].message.content.strip()

LLM 调工具拿日志

如果真的有问题，调用预定义的函数获取相关信息

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
)

这里和第一轮最大的区别，就是多传了一个 tools=tools，这意味着模型此时知道自己可以发起函数调用，随后代码会检查模型是否真的触发了工具调用：

python 复制代码

msg = response.choices[0].message

if msg.tool_calls:
    tool_call = msg.tool_calls[0]
    args = json.loads(tool_call.function.arguments)

拿到工具调用后，再由本地 Python 去真正执行：

python 复制代码

logs = get_pod_logs(**args)

然后把工具执行结果，再喂回模型，让它基于日志继续完成最终分析：

python 复制代码

final_resp = client.chat.completions.create(
    model=model,
    messages=[
        *messages,
        msg,
        {
            "role": "tool",
            "tool_call_id": tool_call.id,
            "content": logs[:3000]
        }
    ]
)

执行链路

text 复制代码

获取 Pod 状态
   ↓
LLM 判断：OK / NEED_DEBUG
   ↓
如果 NEED_DEBUG
   ↓
LLM 发起 tool call：get_pod_logs(pod_name, namespace)
   ↓
本地函数执行，拿到日志
   ↓
日志作为 tool message 回填给 LLM
   ↓
LLM 输出：问题原因 + 根因分析 + 修复建议

这里为什么不用 if-else

很多老哥看到这里，肯定会问：

既然 Running 就是正常，CrashLoopBackOff 就是异常，那直接 if-else 不香吗？

如果场景足够简单，当然可以直接写 if-else。甚至在这个场景中，第一段判断逻辑严格来说也确实可以用规则替代，像下面这样：

python 复制代码

if pod_state in ["Running", "Succeeded"]:
    decision = "OK"
else:
    decision = "NEED_DEBUG"

这么写没毛病，而且更便宜、更稳定、更可控，那为什么还要引入 LLM？因为真实线上环境，往往没这么简单

线上判断一个 Pod 是否异常，很多时候不是看一个字段就能拍板，而是要综合很多信息一起看

1）状态看起来正常，但其实已经不正常了， Pod 状态还是 Running，但实际上业务已经挂了，比如：

readiness probe 一直失败
接口 RT 飙升
错误率升高
日志持续报错
下游数据库连接频繁超时
CPU 不高，但线程池已经卡死

这时候如果你只写：

python 复制代码

if pod_state == "Running":
    return "OK"

2）状态异常，但未必需要立刻排查

pod 状态 Completed
灰度发布期间有短暂重建
HPA 扩缩容带来的短时波动
节点维护导致的瞬时漂移

这时候你如果只根据状态值机械判断，就很容易误报

3）真正有价值的判断，往往依赖多维信号

Pod 当前状态
restart 次数
最近 5 分钟日志
CPU / Memory 使用率
OOM 事件
节点状态
发布记录
同服务其他副本是否也异常
Prometheus 指标波动

这个时候用 if-else 纯流程化的判断模式，对于事件的判断就不太合适了。if-else 擅长处理边界清晰、模式稳定的场景

而LLM 更适合处理需要综合上下文、模糊判断以及不固定条件的综合判断，所以这里采用LLM 的表达能力和归纳能力会更方便

总结

通过 Function Call 获取外部数据，最后让 LLM 输出总结性的建议以及处理方案

至于为什么不用 if-else，简单场景当然可以用固定流程，但当判断开始依赖多维数据、日志语义和上下文综合分析时，LLM 会更灵活。在更加复杂的场景下，则是固定流程和 LLM 组合使用

后记

在本文中，明确告诉了llm，通过get_pod_logs去拿pod日志去拿对应的数据，那如果遇到更加复杂的事故，我们需要

1）拿pod日志，通过kubectl logs
2）拿业务日志，通过日志平台接口
3）获取负载数据，通过监控接口
4）获取发布数据，通过发布平台接口
5）获取上下游的top结构，通过cmdb接口
6）太多了，列举不完...

如何让llm通过当前事故情况，自动选取对应的接口函数获取数据呢？这是个非常现实、棘手的问题了，但这不是本期内容了，我们下一期再见

联系我

联系我，做深入的交流

至此，本文结束

在下才疏学浅，有撒汤漏水的，请各位不吝赐教...