ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

LiteLLM 回调系统实战:给 LLM 调用接上告警与监控

LiteLLM 回调系统实战:给 LLM 调用接上告警与监控 LiteLLM 回调系统实战给 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/litellm凌晨两点告警群弹出一条消息某团队 API Key 预算超了 120%没人说得清是哪个模型烧的。LiteLLM 的回调callback系统就是干这个的把 LLM 调用的成功、失败、流式事件接到告警和监控。这篇文章面向要给 LLM 网关落地观测能力的中初级开发者讲 Slack 告警、Datadog 指标和自定义审计日志怎么配。核心概念速览三个钩子看懂 LiteLLM 回调回调系统就像快递柜的取件通知放入、送达、被取走每个节点系统都会发一次通知你决定通知发给谁——Slack、监控平台还是自己的日志文件。LiteLLM 把所有 LLM 调用收到统一入口在生命周期节点触发钩子你的处理器订阅钩子即可。基类是 custom_logger.py#L61-L149 中的CustomLogger。log_pre_api_call请求发出前触发可做前置检查log_post_api_call响应返回后触发包含完整请求与响应log_stream_event流式响应每来一块就触发一次log_success_event/log_failure_event调用成功/失败后触发统计监控最常用success_callback/failure_callbackyaml 里注册回调名字的开关5 分钟跑通最小回调配置一个配置同时开 Slack 告警和 Datadog 上报这就是最小可用形态# proxy_server_config.yaml general_settings: alerting: [slack] # 开启 Slack 告警通道 alert_to_webhook_url: # 告警类型 - Webhook 映射 budget_alerts: https://hooks.slack.com/services/YOUR/WEBHOOK litellm_settings: success_callback: [datadog] # 成功调用上报 Datadog 指标 failure_callback: [datadog] # 失败也上报用于算错误率 datadog_api_key: os.environ/DD_API_KEY # 从环境变量读 Key别写死 datadog_site: os.environ/DD_SITE # 站点域名如 us5.datadoghq.com执行litellm --config proxy_server_config.yaml启动发一次请求Datadog 里就有延迟和 token 指标预算类事件会推进 Slack。按场景深入告警、指标与审计Slack 实时告警预算超标秒级触达适用于预算快烧完、代理配置出错这类需要运维立即响应的事件。general_settings: alerting: [slack] alert_to_webhook_url: budget_alerts: https://hooks.slack.com/services/YOUR/WEBHOOK # 预算告警如果你只想抄作业建一个 Slack Incoming Webhook把地址填进budget_alerts就这一处。支持的事件类型由AlertType枚举定义预算、Key 状态、代理错误各有对应值见 slack_alerting.py。Datadog 性能指标延迟与成本分位数需要 p95 延迟、按模型的 token 成本、错误分布时启用触发时机是每次调用的成功/失败回调。litellm_settings: success_callback: [datadog] datadog_api_key: os.environ/DD_API_KEY datadog_site: os.environ/DD_SITE # 必填漏了初始化直接报错实现位于 datadog/DD_SITE没设会抛异常而不是静默吞掉这点比很多集成友好。审计与追踪合规日志与 Langfuse 接入要回答谁在什么时间调了什么模型接审计日志要排查一条调用链的输入输出接 Langfuse。litellm_settings: success_callback: [langfuse] failure_callback: [langfuse] langfuse_public_key: os.environ/LANGFUSE_PUBLIC_KEY langfuse_secret_key: os.environ/LANGFUSE_SECRET_KEY代理控制台自带审计日志视图记录每类操作的主体与对象合规审查时直接截图场景核心能力典型触发时机配置复杂度Slack 告警预算/异常事件即时推送预算超阈值、配置错误⭐⭐Datadog 指标延迟、成本、错误分布每次调用成功/失败⭐⭐审计与追踪合规审计、调用链排查成功/失败事件落库⭐⭐⭐自定义 Logger继承 CustomLogger 的骨架内置集成覆盖不到时写自有 S3、转发内部消息队列、加公司特有字段自己继承CustomLogger。别急着全实现先只重写一个钩子import json, time import litellm from litellm.integrations.custom_logger import CustomLogger class AuditLogger(CustomLogger): def __init__(self, log_pathaudit.jsonl): self.log_path log_path super().__init__(turn_off_message_loggingTrue) # 消息正文不落日志控量 def log_success_event(self, kwargs, response_obj, start_time, end_time): # 只重写这一个钩子每次成功调用落一条审计记录 record { model: kwargs.get(model), team_id: kwargs.get(team_id), duration: end_time - start_time, ts: time.time(), } with open(self.log_path, a) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) litellm.success_callback [AuditLogger()] # 注册到全局后续调用全部生效为什么选log_success_event而不是log_post_api_callsuccess 事件每次逻辑调用恰好触发一次kwargs里带 model、team、user 等审计要的全部字段log_post_api_call偏向逐响应检查审计场景用不上。要记失败再补一个log_failure_event即可。踩坑与调优回调不触发、日志爆量怎么办现象原因解法回调从不触发实现的钩子和触发的事件不匹配统计类用log_success_event/log_failure_event流式场景必须单独实现log_stream_eventDatadog 收不到指标未设置DD_SITE补上datadog_site初始化校验逻辑见 datadog.py#L232-L238日志体积失控默认记录完整消息正文构造时传turn_off_message_loggingTrue从源头截断回调拖慢主链路钩子内做了同步 IO改写async_log_success_event等异步版本 高吞吐场景继承 CustomBatchLogger内存队列 周期 flush队列默认上限 5 万条超出丢最旧防止目标端故障时内存打爆⚠️ 大 payload长上下文 RAG一律开消息脱敏日志量通常能降九成 Slack 告警已有内置批量聚合10 秒窗口见 batching_handler.py别自行逐条发 Webhook资源索引源码路径导航custom_logger.py#L61-L149 —CustomLogger基类与五个同步钩子定义写自定义回调的入口SlackAlerting/ — Slack 告警类型与批量发送实现搞清楚支持哪些事件datadog/ — Datadog 指标与成本上报实现核对到底报了哪些指标custom_batch_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),仅供参考
返回列表