litellm回调配置实战三步定位监控数据不来的原因【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm上周四凌晨我们线上 AI 网关突然批量报错可监控大盘上那个小时的曲线依旧平滑——两边对不上。排查到最后问题出在一个很隐蔽的地方litellm 的回调链路根本没把失败请求记下来。这篇文章不讲怎么接入那部分官方文档已经够清楚而是站在接好之后的视角怎么确认回调真的在工作、怎么挑对日志方案、以及最常见的数据不进来该怎么排。 先明确你要学会什么接入一个最小自定义回调验证成功/失败事件是否按序触发配置proxy 端的 prometheus 指标并用一条命令验证数据进来对比五类日志方案的核心能力与上手成本选出适合你团队的组合排查注册了却没数据的几类典型症状 第一步用一个探针证明回调在触发结论先行回调不生效时最先该怀疑的不是配置语法而是事件钩子选错了。litellm 的每个回调至少区分成功、失败、流式、调用前后四类钩子你注册了成功钩子却盯着失败事件等数据自然一行都看不到。下面这段最小探针专门用来回答钩子到底响没响import litellm # 最小探针成功/失败事件触发时各打印一行 class Probe: def log_success_event(self, kwargs, response_obj, start_time, end_time): print([success], kwargs.get(model), f{end_time - start_time:.2f}s) def log_failure_event(self, kwargs, response_obj, start_time, end_time): print([failure], kwargs.get(model), response_obj) litellm.success_callback [Probe()] # 注册成功钩子 litellm.failure_callback [Probe()] # 注册失败钩子 litellm.completion(modelgpt-4o-mini, messages[{role: user, content: ping}])跑一次正常请求应看到[success]把 model 故意改成不存在的名字应看到[failure]。两步都通了说明钩子链路没问题再往上排查才有意义。钩子完整清单可直接对照 CustomLogger 基类 的方法签名。 第二步在 proxy 上配置回调并验证指标SDK 里验证通过只是单点真正的战场在 proxy 集群。litellm 的 proxy 配置支持两级回调全局litellm_settings兜底default_team_settings按团队覆盖——多团队共用一个网关时这层隔离能避免 A 团队的调用被记进 B 团队的计费项目。# proxy_server_config.yaml litellm_settings: success_callback: [prometheus] # 成功请求进指标 failure_callback: [prometheus] default_team_settings: - team_id: team-search # 该团队的日志单独走 Langfuse success_callback: [langfuse] langfuse_public_key: os.environ/LF_PK langfuse_secret: os.environ/LF_SK配完别急着关终端用这条命令确认指标真的在累加# 连续执行两次观察计数值是否增长 curl -s localhost:4000/metrics | grep ^litellm_ | head指标名带total_requests、time_to_first_token、token等维度。如果两次输出完全一致问题几乎一定在回调注册或权限上而不是监控端。prometheus 集成 的实现很短读一遍能知道每条指标对应的钩子。 方案怎么选一张表对齐五类回调选型没有标准答案关键看数据给谁看。下面是我们对比后沉淀的结论方案核心能力适用场景上手成本prometheus内置请求数、时延、token、成本指标自建 SRE 监控栈低两行配置SlackAlerting预算超标、错误率、挂起请求告警值班团队即时响应中需配 WebhookLangfuse单请求追踪、prompt/响应回放研发调效果、复现 badcase中需申请密钥对DatadogAPM 指标 追踪第三方大盘已采购 Datadog 的团队中高generic_api 自定义标准 JSON 推到自有端点合规留痕、内部审计平台高自己写接收端我们的实际组合是prometheus 兜底 Langfuse 给研发 Slack 给值班三类数据各进各的盘子互相不打架。✍️ 第三步写一个刚好够用的自定义回调内置方案覆盖不了的往往是业务规则。继承CustomLogger时给个建议钩子方法保持同步轻量重活放到async_log_success_event里别在流式回调里同步写远端否则高并发下每个 chunk 都在等 IO。from litellm.integrations.custom_logger import CustomLogger class SpendGuard(CustomLogger): def __init__(self, threshold5.0): self.threshold threshold # 单请求成本上限美元 async def async_log_success_event(self, kwargs, response_obj, start_time, end_time): cost response_obj.cost or 0 if cost self.threshold: # 超阈值打告警不阻塞主流程 print(over budget:, kwargs.get(model), cost)规则只有一条回调代码里绝不做会失败的事写远端要加超时和吞异常否则你的可观测组件会成为下一个故障源。 排错五种没数据的典型症状现象可能原因解法注册后一行日志都没有实现的钩子与观察的事件不匹配对照基类方法签名确认注册到 success 还是 failure指标无新增序列只配了 success_callback失败请求无人记录成对补上 failure_callback某团队数据缺失回调只配了全局团队级被覆盖或遗漏检查 default_team_settings 的覆盖顺序日志里没有消息内容消息记录被关闭或被截断检查 turn_off_message_logging 及截断配置流式请求时延抖动流式钩子里同步写远端改用 async 版本钩子收尾把回调当探针而不是配置项来用监控数据的问题 80% 能在十分钟内核实。现在就能做的小任务给你本地的 litellm proxy 加上第一节的Probe发 10 次请求数一数 success 和 failure 事件加起来是不是正好 10 条——如果不是你就亲手复现了一次最常见的线上问题。你在生产里踩过最深的一个回调坑是什么欢迎在评论区说说。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
litellm回调配置实战：三步定位监控数据不来的原因
litellm回调配置实战三步定位监控数据不来的原因【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm上周四凌晨我们线上 AI 网关突然批量报错可监控大盘上那个小时的曲线依旧平滑——两边对不上。排查到最后问题出在一个很隐蔽的地方litellm 的回调链路根本没把失败请求记下来。这篇文章不讲怎么接入那部分官方文档已经够清楚而是站在接好之后的视角怎么确认回调真的在工作、怎么挑对日志方案、以及最常见的数据不进来该怎么排。 先明确你要学会什么接入一个最小自定义回调验证成功/失败事件是否按序触发配置proxy 端的 prometheus 指标并用一条命令验证数据进来对比五类日志方案的核心能力与上手成本选出适合你团队的组合排查注册了却没数据的几类典型症状 第一步用一个探针证明回调在触发结论先行回调不生效时最先该怀疑的不是配置语法而是事件钩子选错了。litellm 的每个回调至少区分成功、失败、流式、调用前后四类钩子你注册了成功钩子却盯着失败事件等数据自然一行都看不到。下面这段最小探针专门用来回答钩子到底响没响import litellm # 最小探针成功/失败事件触发时各打印一行 class Probe: def log_success_event(self, kwargs, response_obj, start_time, end_time): print([success], kwargs.get(model), f{end_time - start_time:.2f}s) def log_failure_event(self, kwargs, response_obj, start_time, end_time): print([failure], kwargs.get(model), response_obj) litellm.success_callback [Probe()] # 注册成功钩子 litellm.failure_callback [Probe()] # 注册失败钩子 litellm.completion(modelgpt-4o-mini, messages[{role: user, content: ping}])跑一次正常请求应看到[success]把 model 故意改成不存在的名字应看到[failure]。两步都通了说明钩子链路没问题再往上排查才有意义。钩子完整清单可直接对照 CustomLogger 基类 的方法签名。 第二步在 proxy 上配置回调并验证指标SDK 里验证通过只是单点真正的战场在 proxy 集群。litellm 的 proxy 配置支持两级回调全局litellm_settings兜底default_team_settings按团队覆盖——多团队共用一个网关时这层隔离能避免 A 团队的调用被记进 B 团队的计费项目。# proxy_server_config.yaml litellm_settings: success_callback: [prometheus] # 成功请求进指标 failure_callback: [prometheus] default_team_settings: - team_id: team-search # 该团队的日志单独走 Langfuse success_callback: [langfuse] langfuse_public_key: os.environ/LF_PK langfuse_secret: os.environ/LF_SK配完别急着关终端用这条命令确认指标真的在累加# 连续执行两次观察计数值是否增长 curl -s localhost:4000/metrics | grep ^litellm_ | head指标名带total_requests、time_to_first_token、token等维度。如果两次输出完全一致问题几乎一定在回调注册或权限上而不是监控端。prometheus 集成 的实现很短读一遍能知道每条指标对应的钩子。 方案怎么选一张表对齐五类回调选型没有标准答案关键看数据给谁看。下面是我们对比后沉淀的结论方案核心能力适用场景上手成本prometheus内置请求数、时延、token、成本指标自建 SRE 监控栈低两行配置SlackAlerting预算超标、错误率、挂起请求告警值班团队即时响应中需配 WebhookLangfuse单请求追踪、prompt/响应回放研发调效果、复现 badcase中需申请密钥对DatadogAPM 指标 追踪第三方大盘已采购 Datadog 的团队中高generic_api 自定义标准 JSON 推到自有端点合规留痕、内部审计平台高自己写接收端我们的实际组合是prometheus 兜底 Langfuse 给研发 Slack 给值班三类数据各进各的盘子互相不打架。✍️ 第三步写一个刚好够用的自定义回调内置方案覆盖不了的往往是业务规则。继承CustomLogger时给个建议钩子方法保持同步轻量重活放到async_log_success_event里别在流式回调里同步写远端否则高并发下每个 chunk 都在等 IO。from litellm.integrations.custom_logger import CustomLogger class SpendGuard(CustomLogger): def __init__(self, threshold5.0): self.threshold threshold # 单请求成本上限美元 async def async_log_success_event(self, kwargs, response_obj, start_time, end_time): cost response_obj.cost or 0 if cost self.threshold: # 超阈值打告警不阻塞主流程 print(over budget:, kwargs.get(model), cost)规则只有一条回调代码里绝不做会失败的事写远端要加超时和吞异常否则你的可观测组件会成为下一个故障源。 排错五种没数据的典型症状现象可能原因解法注册后一行日志都没有实现的钩子与观察的事件不匹配对照基类方法签名确认注册到 success 还是 failure指标无新增序列只配了 success_callback失败请求无人记录成对补上 failure_callback某团队数据缺失回调只配了全局团队级被覆盖或遗漏检查 default_team_settings 的覆盖顺序日志里没有消息内容消息记录被关闭或被截断检查 turn_off_message_logging 及截断配置流式请求时延抖动流式钩子里同步写远端改用 async 版本钩子收尾把回调当探针而不是配置项来用监控数据的问题 80% 能在十分钟内核实。现在就能做的小任务给你本地的 litellm proxy 加上第一节的Probe发 10 次请求数一数 success 和 failure 事件加起来是不是正好 10 条——如果不是你就亲手复现了一次最常见的线上问题。你在生产里踩过最深的一个回调坑是什么欢迎在评论区说说。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
