litellm 回调系统5 个事件钩子 × 4 个监控平台的自定义日志与监控集成指南【免费下载链接】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多模型网关上线两周混用了 6 个 provider 的 deployment错误率突然涨了一倍只能去各平台后台手动翻日志对齐是哪个请求挂了、花了多少钱。litellm 回调系统把请求生命周期拆成几个固定事件点所有 provider 的请求、响应、异常都能写进你自己指定的日志目标排查时只需要看一处。最小配置启用第一个回调代理模式下三步即可不需要写任何代码在配置文件里声明回调名只写平台名litellm 内部会注册对应的 logger# proxy_server_config.yaml general_settings: success_callback: [langfuse]导出该平台要求的凭据环境变量Langfuse 对应LANGFUSE_PUBLIC_KEY、LANGFUSE_SECRET_KEY凭据清单可对照 集成目录文档。重启进程发一个测试请求到 Langfuse 后台确认 trace 逐条出现即完成。SDK 直连场景则是把回调实例传给completion()的callbacks参数或挂到全局litellm.callbacks效果相同。5 个事件钩子的触发时机与可取数据回调基类 CustomLogger 把一次调用切成下面的事件点每个钩子都有async_*同名变体事件钩子触发时机可获取数据典型用途log_pre_api_call请求发往 provider 之前model、messages、完整 kwargs参数改写、请求拦截、前置审计log_post_api_call响应解析完成之后请求 响应 start/end 时间戳算耗时、统计 token 与成本log_stream_event流式响应中每个 chunk当前 chunk 内容流式转发、逐 chunk 打点log_success_event调用成功收尾时同 post 事件无异常成功侧指标、批量落盘log_failure_event调用抛异常时同 post 事件 异常信息告警、错误类型分布需要注意两点同步与异步钩子是独立方法只实现同步版在 async 路径上不会触发流式调用只会走到log_stream_event不会触发 post 钩子。按场景选平台告警、指标、追踪、质量对比表内置适配器超过 15 个按目的分四类选型更清晰场景工具核心能力接入成本告警响应SlackAlerting预算阈值如用到 80%、慢请求、hanging 请求经 webhook 推到 Slack/MS Teams支持按告警类型分流不同渠道低一个 webhook URL 阈值参数性能观测Datadog调用延迟分位、按 token 的成本指标、错误类型分布可走 API key 或本地 agent 两种通道中需 API key 或部署 agent调试追踪LangSmith以 span 串起完整调用链看对话上下文与中间状态低2 个环境变量质量监控ArizePhoenix评测、模型行为质量观测高需要额外配置评测流程选型上值班团队先上 SlackAlerting 兜底性能调优再补 Datadog开发和联调阶段用 LangSmith 最省事。继承 CustomLogger 的最小自定义处理器模板内置工具覆盖不了的场景比如合规脱敏日志继承基类重写对应钩子即可import json from litellm.integrations.custom_logger import CustomLogger class RedactedLogger(CustomLogger): def log_post_api_call(self, kwargs, response_obj, start_time, end_time): record { model: kwargs.get(model), duration_s: round(end_time - start_time, 3), # 不写 messages 原文只留可追溯元数据 } with open(/var/log/litellm/access.log, a) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)启用时completion(..., callbacks[RedactedLogger(turn_off_message_loggingTrue)])。三个要点turn_off_message_loggingTrue让标准日志 payload 不再携带消息原文是控制日志体积的第一道闸高 QPS 下不要逐条写参考 CustomBatchLogger 做批量聚合上报并发压力大的环境自行加采样如 10% 记录全量、其余只记元数据。回调不触发、日志过大等常见坑排查现象原因处理回调完全不触发只实现了同步钩子而请求走 async 路径或事件类型没对上流式只走log_stream_event补实现async_log_*变体流式场景单独实现 stream 钩子日志体积暴涨每条记录都带 messages 全文构造时传turn_off_message_loggingTrue或自行截断 payload 中的 content监控指标缺失Prometheus 指标服务未启动或指标未注册检查 prometheus_services.py 中指标注册与抓取配置只部分调用有数据general_settings漏写回调名或凭据环境变量未设置logger 初始化时静默跳过对照 集成文档 补齐回调名与环境变量代理端没数据、SDK 端有代理读general_settingsSDK 读litellm.callbacks两处配置不通用明确生效面两边各配一次回调系统只覆盖日志与监控这一层内容护栏、预算和限流由 guardrails 与 budget manager 各自负责路由与负载均衡在 router 模块混用时不要把它们的职责算到回调里。完整钩子签名含 prompt 管理、pre-routing 等扩展钩子以 CustomLogger 源码 为准各平台的接入细节见 集成目录。【免费下载链接】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 回调系统：5 个事件钩子 × 4 个监控平台的自定义日志与监控集成指南
litellm 回调系统5 个事件钩子 × 4 个监控平台的自定义日志与监控集成指南【免费下载链接】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多模型网关上线两周混用了 6 个 provider 的 deployment错误率突然涨了一倍只能去各平台后台手动翻日志对齐是哪个请求挂了、花了多少钱。litellm 回调系统把请求生命周期拆成几个固定事件点所有 provider 的请求、响应、异常都能写进你自己指定的日志目标排查时只需要看一处。最小配置启用第一个回调代理模式下三步即可不需要写任何代码在配置文件里声明回调名只写平台名litellm 内部会注册对应的 logger# proxy_server_config.yaml general_settings: success_callback: [langfuse]导出该平台要求的凭据环境变量Langfuse 对应LANGFUSE_PUBLIC_KEY、LANGFUSE_SECRET_KEY凭据清单可对照 集成目录文档。重启进程发一个测试请求到 Langfuse 后台确认 trace 逐条出现即完成。SDK 直连场景则是把回调实例传给completion()的callbacks参数或挂到全局litellm.callbacks效果相同。5 个事件钩子的触发时机与可取数据回调基类 CustomLogger 把一次调用切成下面的事件点每个钩子都有async_*同名变体事件钩子触发时机可获取数据典型用途log_pre_api_call请求发往 provider 之前model、messages、完整 kwargs参数改写、请求拦截、前置审计log_post_api_call响应解析完成之后请求 响应 start/end 时间戳算耗时、统计 token 与成本log_stream_event流式响应中每个 chunk当前 chunk 内容流式转发、逐 chunk 打点log_success_event调用成功收尾时同 post 事件无异常成功侧指标、批量落盘log_failure_event调用抛异常时同 post 事件 异常信息告警、错误类型分布需要注意两点同步与异步钩子是独立方法只实现同步版在 async 路径上不会触发流式调用只会走到log_stream_event不会触发 post 钩子。按场景选平台告警、指标、追踪、质量对比表内置适配器超过 15 个按目的分四类选型更清晰场景工具核心能力接入成本告警响应SlackAlerting预算阈值如用到 80%、慢请求、hanging 请求经 webhook 推到 Slack/MS Teams支持按告警类型分流不同渠道低一个 webhook URL 阈值参数性能观测Datadog调用延迟分位、按 token 的成本指标、错误类型分布可走 API key 或本地 agent 两种通道中需 API key 或部署 agent调试追踪LangSmith以 span 串起完整调用链看对话上下文与中间状态低2 个环境变量质量监控ArizePhoenix评测、模型行为质量观测高需要额外配置评测流程选型上值班团队先上 SlackAlerting 兜底性能调优再补 Datadog开发和联调阶段用 LangSmith 最省事。继承 CustomLogger 的最小自定义处理器模板内置工具覆盖不了的场景比如合规脱敏日志继承基类重写对应钩子即可import json from litellm.integrations.custom_logger import CustomLogger class RedactedLogger(CustomLogger): def log_post_api_call(self, kwargs, response_obj, start_time, end_time): record { model: kwargs.get(model), duration_s: round(end_time - start_time, 3), # 不写 messages 原文只留可追溯元数据 } with open(/var/log/litellm/access.log, a) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)启用时completion(..., callbacks[RedactedLogger(turn_off_message_loggingTrue)])。三个要点turn_off_message_loggingTrue让标准日志 payload 不再携带消息原文是控制日志体积的第一道闸高 QPS 下不要逐条写参考 CustomBatchLogger 做批量聚合上报并发压力大的环境自行加采样如 10% 记录全量、其余只记元数据。回调不触发、日志过大等常见坑排查现象原因处理回调完全不触发只实现了同步钩子而请求走 async 路径或事件类型没对上流式只走log_stream_event补实现async_log_*变体流式场景单独实现 stream 钩子日志体积暴涨每条记录都带 messages 全文构造时传turn_off_message_loggingTrue或自行截断 payload 中的 content监控指标缺失Prometheus 指标服务未启动或指标未注册检查 prometheus_services.py 中指标注册与抓取配置只部分调用有数据general_settings漏写回调名或凭据环境变量未设置logger 初始化时静默跳过对照 集成文档 补齐回调名与环境变量代理端没数据、SDK 端有代理读general_settingsSDK 读litellm.callbacks两处配置不通用明确生效面两边各配一次回调系统只覆盖日志与监控这一层内容护栏、预算和限流由 guardrails 与 budget manager 各自负责路由与负载均衡在 router 模块混用时不要把它们的职责算到回调里。完整钩子签名含 prompt 管理、pre-routing 等扩展钩子以 CustomLogger 源码 为准各平台的接入细节见 集成目录。【免费下载链接】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），仅供参考