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/litellm请求量上来之后LLM 网关通常逃不开两个问题调用明细去哪存延迟和花费谁来盯。LiteLLM 插件系统LiteLLM plugin system对这两个问题给出的答案很统一——任何继承同一个基类的回调对象都能挂到 LLM 请求的生命周期上。落到对象存储也好导出 Prometheus 指标也罢差别只在参数不在写法。三步把插件接到一次 LLM 调用上第一步最小配置。以把调用明细写进 S3 为例实例化一个 S3Logger 只需要三个关键参数s3_bucket_name目标桶名s3_path对象在桶内的存放路径前缀s3_region_name区域自建 MinIO 类服务时改传s3_endpoint_url第二步把插件挂到请求上。把实例放进callbacks列表即可有两种粒度全局写在litellm.callbacks只影响后续所有调用或者作为callbacks参数传给单次completion调用只影响这一次。第三步验证生效。发起一次真实调用然后去桶里看s3_path下是否多了一个 JSON 对象——里面是按标准结构整理的请求参数、响应内容与耗时。import litellm from litellm.integrations.s3 import S3Logger litellm.callbacks [ S3Logger(s3_bucket_namemy-llm-logs, s3_pathlitellm/, s3_region_nameus-east-1) ] litellm.completion(modelgpt-4o-mini, messages[{role: user, content: hi}])插件挂在请求生命周期的哪些钩子上整个机制可以用一条线讲完注册 → 挂载钩子 → 事件触发。注册插件实例进入callbacks列表框架据此持有它的引用挂载钩子CustomLogger 基类为请求生命周期的不同阶段预留了同名方法你覆写哪个就算挂上了对应钩子事件触发一次调用走完后框架按阶段依次调用这些方法把kwargs、响应对象、起止时间戳递进来。核心方法只有几个各自一句话职责方法职责log_success_event/async_log_success_event调用成功后触发拿到完整响应对象log_failure_event/async_log_failure_event调用失败后触发拿到异常上下文async_pre_call_hook请求真正发出去之前介入守卫类插件用在这里async_logging_hook标准日志载荷组装完毕后触发是离落盘最近的一个点两个真实场景的接法场景一把每次调用的明细写进对象存储解决什么问题排查线上问题时当时到底发了什么、模型回了什么经常无处可查。S3 日志插件让每次调用成功和失败都会记录自动变成一个 JSON 对象落到对象存储天然带版本管理也方便用 Athena 这类工具直接查询。怎么配除了上面最小集成里的三个参数常用还有s3_use_ssl是否强制 TLS、s3_server_side_encryption服务端加密方式。凭证可以走 AWS 环境变量也可以在初始化时显式传s3_aws_access_key_id/s3_aws_secret_access_key。效果零额外维护——不存在日志进程挂了这种状态因为写入动作寄生在调用链上调用成功就有对象生成。场景二给网关挂一块 Prometheus 仪表板解决什么问题管理层问这个月花了多少钱、P95 延迟多少靠翻日志太慢。PrometheusLogger 把每次调用转成指标暴露给 Prometheus 抓取。怎么配先装prometheus-client依赖然后把实例追加进回调列表即可from litellm.integrations.prometheus import PrometheusLogger litellm.callbacks.append(PrometheusLogger())效果请求总数、失败数、花费spend counter和端到端延迟直方图自动开始累计配 Grafana 就是一个现成的网关仪表板。注意它和 prometheus_services.py 里的PrometheusServicesLogger不是一回事——后者专门用于/metrics端点上 Redis、Postgres 等周边服务健康度。内容安全审计也是同一套机制CustomGuardrail 声明自己支持的pre_call/post_call事件钩子就能在请求前后做拦截。上手前的四个注意事项执行顺序即列表顺序同一钩子上挂多个插件时按它们在callbacks列表中的先后依次执行。有副作用改写、拦截的放前面纯观测的放后面。耗时操作走异步方法网络 IO 请实现async_log_success_event一族别在同步方法里阻塞否则 LLM 响应会跟着等。盯住监控插件自身的开销指标标签集合在插件初始化时就固定了运行期再变会导致序列爆炸或报错调整标签需重启进程。跟着核心版本走钩子方法签名随 LiteLLM 版本演进跨版本升级前对照 custom_logger.py 复核一遍自己的覆写方法。写在最后插件系统把接一个新后端压缩成了实现两个方法、填一个参数列表的固定动作。完整的内置集成一览见 litellm/integrations/。下期我们聊聊如何在 Proxy 配置里用 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/litellm请求量上来之后LLM 网关通常逃不开两个问题调用明细去哪存延迟和花费谁来盯。LiteLLM 插件系统LiteLLM plugin system对这两个问题给出的答案很统一——任何继承同一个基类的回调对象都能挂到 LLM 请求的生命周期上。落到对象存储也好导出 Prometheus 指标也罢差别只在参数不在写法。三步把插件接到一次 LLM 调用上第一步最小配置。以把调用明细写进 S3 为例实例化一个 S3Logger 只需要三个关键参数s3_bucket_name目标桶名s3_path对象在桶内的存放路径前缀s3_region_name区域自建 MinIO 类服务时改传s3_endpoint_url第二步把插件挂到请求上。把实例放进callbacks列表即可有两种粒度全局写在litellm.callbacks只影响后续所有调用或者作为callbacks参数传给单次completion调用只影响这一次。第三步验证生效。发起一次真实调用然后去桶里看s3_path下是否多了一个 JSON 对象——里面是按标准结构整理的请求参数、响应内容与耗时。import litellm from litellm.integrations.s3 import S3Logger litellm.callbacks [ S3Logger(s3_bucket_namemy-llm-logs, s3_pathlitellm/, s3_region_nameus-east-1) ] litellm.completion(modelgpt-4o-mini, messages[{role: user, content: hi}])插件挂在请求生命周期的哪些钩子上整个机制可以用一条线讲完注册 → 挂载钩子 → 事件触发。注册插件实例进入callbacks列表框架据此持有它的引用挂载钩子CustomLogger 基类为请求生命周期的不同阶段预留了同名方法你覆写哪个就算挂上了对应钩子事件触发一次调用走完后框架按阶段依次调用这些方法把kwargs、响应对象、起止时间戳递进来。核心方法只有几个各自一句话职责方法职责log_success_event/async_log_success_event调用成功后触发拿到完整响应对象log_failure_event/async_log_failure_event调用失败后触发拿到异常上下文async_pre_call_hook请求真正发出去之前介入守卫类插件用在这里async_logging_hook标准日志载荷组装完毕后触发是离落盘最近的一个点两个真实场景的接法场景一把每次调用的明细写进对象存储解决什么问题排查线上问题时当时到底发了什么、模型回了什么经常无处可查。S3 日志插件让每次调用成功和失败都会记录自动变成一个 JSON 对象落到对象存储天然带版本管理也方便用 Athena 这类工具直接查询。怎么配除了上面最小集成里的三个参数常用还有s3_use_ssl是否强制 TLS、s3_server_side_encryption服务端加密方式。凭证可以走 AWS 环境变量也可以在初始化时显式传s3_aws_access_key_id/s3_aws_secret_access_key。效果零额外维护——不存在日志进程挂了这种状态因为写入动作寄生在调用链上调用成功就有对象生成。场景二给网关挂一块 Prometheus 仪表板解决什么问题管理层问这个月花了多少钱、P95 延迟多少靠翻日志太慢。PrometheusLogger 把每次调用转成指标暴露给 Prometheus 抓取。怎么配先装prometheus-client依赖然后把实例追加进回调列表即可from litellm.integrations.prometheus import PrometheusLogger litellm.callbacks.append(PrometheusLogger())效果请求总数、失败数、花费spend counter和端到端延迟直方图自动开始累计配 Grafana 就是一个现成的网关仪表板。注意它和 prometheus_services.py 里的PrometheusServicesLogger不是一回事——后者专门用于/metrics端点上 Redis、Postgres 等周边服务健康度。内容安全审计也是同一套机制CustomGuardrail 声明自己支持的pre_call/post_call事件钩子就能在请求前后做拦截。上手前的四个注意事项执行顺序即列表顺序同一钩子上挂多个插件时按它们在callbacks列表中的先后依次执行。有副作用改写、拦截的放前面纯观测的放后面。耗时操作走异步方法网络 IO 请实现async_log_success_event一族别在同步方法里阻塞否则 LLM 响应会跟着等。盯住监控插件自身的开销指标标签集合在插件初始化时就固定了运行期再变会导致序列爆炸或报错调整标签需重启进程。跟着核心版本走钩子方法签名随 LiteLLM 版本演进跨版本升级前对照 custom_logger.py 复核一遍自己的覆写方法。写在最后插件系统把接一个新后端压缩成了实现两个方法、填一个参数列表的固定动作。完整的内置集成一览见 litellm/integrations/。下期我们聊聊如何在 Proxy 配置里用 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），仅供参考