litellm 回调系统入门3 步接入 LLM 日志监控与异常告警【免费下载链接】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/litellmlitellm 回调系统可以在网关层统一记录 LLM 调用请求、追踪成本并触发告警。本文面向首次接触 litellm 运维能力的开发者讲解如何用最小改动完成 litellm 日志监控配置并接入现有监控平台。为什么 LLM 调用需要统一观测直接调用各家模型 SDK 时延迟、成本、错误数据分散在不同组件里排查问题只能逐个翻日志。把所有调用收口到 litellm 网关后一套数据就能回答三类问题请求明细谁在什么时候调用了哪个模型、耗时多少成本口径按团队、按 API key 统计 token 与花费异常分布超时、限流、鉴权失败的占比变化数据口径统一后告警规则和看板可以直接复用同一份日志来源不需要为每个供应商单独埋点。litellm 回调系统如何工作4 类事件节点回调系统的核心是一组钩子函数在 LLM 调用的不同阶段被触发你的日志逻辑只需实现对应方法。基类是CustomLogger源码见 litellm/integrations/custom_logger.py主要同步钩子如下钩子方法触发时机log_pre_api_call请求发出前log_post_api_call响应返回后携带完整请求/响应数据log_stream_event流式响应过程中持续触发log_success_event/log_failure_event调用成功 / 失败时每个钩子都有对应的异步版本如async_log_post_api_call生产环境建议优先实现异步方法避免日志动作拖慢主请求。所有钩子默认都是空实现只重写你关心的部分即可。快速配置用 litellm 回调配置启用内置日志最快的路径是通过 proxy 配置启用内置适配器不用写代码。litellm 预置了 15 集成Prometheus、Langfuse、Datadog、OpenTelemetry、S3 等目录见 litellm/integrations/完整注册表定义在 litellm/proxy/_types.py 的AllCallbacks中。在proxy_server_config.yaml的litellm_settings下启用litellm_settings: success_callback: [prometheus] failure_callback: [prometheus]各回调通常还需配置对应环境变量例如 Langfuse 使用LANGFUSE_PUBLIC_KEYDatadog 使用DD_API_KEY。配置生效后成功与失败的调用都会自动向目标写出标准化日志载荷。实时告警方面SlackAlerting 模块支持代理、团队、用户、API key 多级预算超限通知。litellm 监控集成把指标接入现有监控平台如果团队已有监控栈按现有栈选择适配器避免多一套系统要维护Prometheus导出请求数、延迟、token 用量与成本指标配合 Grafana 建看板Langfuse / LangSmith记录完整调用链适合调试 prompt 与模型行为Datadog指标直接进入 Datadog复用已有告警规则OpenTelemetryotel导出标准 span可对接任意 OTel collector这是 litellm proxy 上报到 Langfuse 的真实调用追踪截图可以看到每次请求的完整链路。一个容易忽略的细节让指标维度对齐团队组织结构。仓库自带配置中演示了通过default_team_settings给不同团队绑定不同的 langfuse 项目日志按团队天然隔离。litellm 自定义日志最小改法内置适配器不够用时比如成本要写进自有数仓继承CustomLogger只重写一个方法即可from litellm.integrations.custom_logger import CustomLogger class CostLogger(CustomLogger): def log_post_api_call(self, kwargs, response_obj, start_time, end_time): print(kwargs.get(model), response_obj.total_cost)把实例加入success_callback列表即可生效。两个实用点构造时传turn_off_message_loggingTrue消息正文会被脱敏只记元数据日志体积大幅下降批量上报场景可参考 litellm/integrations/custom_batch_logger.py 的CustomBatchLogger事件聚合后批量发送降低高 QPS 下的外部依赖压力上线前检查清单回调不拖主流程优先异步钩子避免在回调里做同步慢 IO日志字段够用至少包含 model、用户/团队标识、耗时、成本消息脱敏已开启敏感内容不落盘告警有去抖Slack 告警内置批处理约 10 秒或达到事件数才发送确认符合你的告警节奏验证真实落盘发一笔测试调用在目标平台确认数据到位而不是只看配置小结litellm 回调系统在请求前、响应后、流式过程中提供了统一钩子。大多数场景下内置适配器加几行 litellm 回调配置就能完成日志监控接入需要定制时继承CustomLogger是最小改动方案。建议从 litellm/integrations/custom_logger.py 和 proxy_server_config.yaml 两个入口读起。【免费下载链接】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 回调系统入门：3 步接入 LLM 日志监控与异常告警
litellm 回调系统入门3 步接入 LLM 日志监控与异常告警【免费下载链接】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/litellmlitellm 回调系统可以在网关层统一记录 LLM 调用请求、追踪成本并触发告警。本文面向首次接触 litellm 运维能力的开发者讲解如何用最小改动完成 litellm 日志监控配置并接入现有监控平台。为什么 LLM 调用需要统一观测直接调用各家模型 SDK 时延迟、成本、错误数据分散在不同组件里排查问题只能逐个翻日志。把所有调用收口到 litellm 网关后一套数据就能回答三类问题请求明细谁在什么时候调用了哪个模型、耗时多少成本口径按团队、按 API key 统计 token 与花费异常分布超时、限流、鉴权失败的占比变化数据口径统一后告警规则和看板可以直接复用同一份日志来源不需要为每个供应商单独埋点。litellm 回调系统如何工作4 类事件节点回调系统的核心是一组钩子函数在 LLM 调用的不同阶段被触发你的日志逻辑只需实现对应方法。基类是CustomLogger源码见 litellm/integrations/custom_logger.py主要同步钩子如下钩子方法触发时机log_pre_api_call请求发出前log_post_api_call响应返回后携带完整请求/响应数据log_stream_event流式响应过程中持续触发log_success_event/log_failure_event调用成功 / 失败时每个钩子都有对应的异步版本如async_log_post_api_call生产环境建议优先实现异步方法避免日志动作拖慢主请求。所有钩子默认都是空实现只重写你关心的部分即可。快速配置用 litellm 回调配置启用内置日志最快的路径是通过 proxy 配置启用内置适配器不用写代码。litellm 预置了 15 集成Prometheus、Langfuse、Datadog、OpenTelemetry、S3 等目录见 litellm/integrations/完整注册表定义在 litellm/proxy/_types.py 的AllCallbacks中。在proxy_server_config.yaml的litellm_settings下启用litellm_settings: success_callback: [prometheus] failure_callback: [prometheus]各回调通常还需配置对应环境变量例如 Langfuse 使用LANGFUSE_PUBLIC_KEYDatadog 使用DD_API_KEY。配置生效后成功与失败的调用都会自动向目标写出标准化日志载荷。实时告警方面SlackAlerting 模块支持代理、团队、用户、API key 多级预算超限通知。litellm 监控集成把指标接入现有监控平台如果团队已有监控栈按现有栈选择适配器避免多一套系统要维护Prometheus导出请求数、延迟、token 用量与成本指标配合 Grafana 建看板Langfuse / LangSmith记录完整调用链适合调试 prompt 与模型行为Datadog指标直接进入 Datadog复用已有告警规则OpenTelemetryotel导出标准 span可对接任意 OTel collector这是 litellm proxy 上报到 Langfuse 的真实调用追踪截图可以看到每次请求的完整链路。一个容易忽略的细节让指标维度对齐团队组织结构。仓库自带配置中演示了通过default_team_settings给不同团队绑定不同的 langfuse 项目日志按团队天然隔离。litellm 自定义日志最小改法内置适配器不够用时比如成本要写进自有数仓继承CustomLogger只重写一个方法即可from litellm.integrations.custom_logger import CustomLogger class CostLogger(CustomLogger): def log_post_api_call(self, kwargs, response_obj, start_time, end_time): print(kwargs.get(model), response_obj.total_cost)把实例加入success_callback列表即可生效。两个实用点构造时传turn_off_message_loggingTrue消息正文会被脱敏只记元数据日志体积大幅下降批量上报场景可参考 litellm/integrations/custom_batch_logger.py 的CustomBatchLogger事件聚合后批量发送降低高 QPS 下的外部依赖压力上线前检查清单回调不拖主流程优先异步钩子避免在回调里做同步慢 IO日志字段够用至少包含 model、用户/团队标识、耗时、成本消息脱敏已开启敏感内容不落盘告警有去抖Slack 告警内置批处理约 10 秒或达到事件数才发送确认符合你的告警节奏验证真实落盘发一笔测试调用在目标平台确认数据到位而不是只看配置小结litellm 回调系统在请求前、响应后、流式过程中提供了统一钩子。大多数场景下内置适配器加几行 litellm 回调配置就能完成日志监控接入需要定制时继承CustomLogger是最小改动方案。建议从 litellm/integrations/custom_logger.py 和 proxy_server_config.yaml 两个入口读起。【免费下载链接】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），仅供参考