这次我们来看一个名为“Bounded GenAI metrics from Otel traces with O raw prompts”的开源项目。这个项目瞄准的是当前生成式AIGenAI应用开发与运维中的一个核心痛点如何有效监控和度量AI模型调用链路的性能、成本与质量。它通过OpenTelemetryOtel的追踪Traces数据自动提取并计算有界Bounded的GenAI指标并将原始提示词Raw Prompts作为关键上下文最终将指标暴露给Prometheus以便在Grafana等可视化工具中进行监控和告警。对于正在构建或维护涉及大语言模型LLM、图像生成等AI服务的开发者与运维工程师来说这个工具的价值在于它提供了一种标准化的、可观测性驱动的方案来回答以下关键问题每次AI调用的耗时多长Token消耗与成本是多少提示词工程的效果如何是否存在异常或低效的调用模式本文将从实战角度带你快速了解这个项目的核心能力、部署方式并演示如何将其集成到你的AI应用中实现对GenAI调用链路的深度可观测。无论你是想监控本地测试的Stable Diffusion API还是生产环境的GPT/Claude调用这套方案都能提供清晰的度量视角。1. 核心能力速览能力项说明项目类型开源监控指标提取与暴露工具核心原理解析OpenTelemetry Trace数据提取GenAI相关Span中的耗时、Token数、模型、提示词等属性聚合为Prometheus指标数据输入OpenTelemetry Trace通常通过OTLP协议接收指标输出Prometheus格式的指标通过HTTP端点暴露关键特性1.有界指标计算支持计算分位数如P95、P99延迟、成功率等聚合指标。2.原始提示词关联能将原始提示词或截断版本作为指标的标签Label便于按提示词模式进行分析。3.GenAI语义感知能识别LLM调用、Embedding调用等特定Span并提取llm.token.usage、gen_ai.system等属性。部署方式可作为独立服务二进制或Docker容器运行或作为库集成到应用中硬件门槛极低。作为指标处理服务对CPU和内存消耗很小通常不需要GPU。适合场景监控集成LLM/图像生成API的应用、评估不同提示词性能、分析AI调用成本与延迟、设置SLO告警。2. 适用场景与使用边界这个工具非常适合以下角色和场景AI应用开发者在开发阶段需要量化不同提示词、不同模型参数对响应时间和Token消耗的影响。运维/SRE工程师需要为生产环境的AI服务建立可观测性监控其健康度、延迟和错误率并配置告警。成本优化团队希望通过监控Token使用量分析并优化AI调用的成本。提示词工程师需要A/B测试不同提示词模板的效果包括响应时间、成功率和输出质量需结合业务指标。使用边界与注意事项依赖OpenTelemetry你的应用必须已经或计划接入OpenTelemetry SDK并生成包含GenAI语义约定的Trace数据。这是该工具工作的前提。提示词隐私与安全将原始提示词作为指标标签可能暴露敏感信息。项目通常提供截断、哈希或过滤机制使用时必须根据公司安全策略进行配置避免泄露用户隐私或商业机密。非性能压测工具它主要用于监控和度量而不是像Locust那样的压力测试工具。虽然它能反映性能但生成负载需要其他工具配合。指标而非日志它产出的是聚合后的指标不适合用于调试单次请求的详细输入输出。详细的日志仍需通过原生日志系统查看。3. 环境准备与前置条件在部署这个指标提取服务之前你需要确保以下环境就绪可观测性基础设施OpenTelemetry Collector一个运行中的OTel Collector服务用于接收来自应用的Trace数据并可能转发给后端如Jaeger、Tempo以及本工具。你需要知道它的OTLP接收端点通常是http://localhost:4318或4317。Prometheus用于抓取和存储本工具暴露的指标。需要确保Prometheus服务器可以访问到本工具暴露的/metrics端点。Grafana可选但推荐用于可视化Prometheus中的指标。已接入OpenTelemetry的AI应用你的应用程序需要使用支持OpenTelemetry的GenAI SDK或手动创建符合 OpenTelemetry GenAI语义约定 的Span。例如在Python中你可能使用opentelemetry-instrumentation-openai这样的库来自动化插桩。运行环境操作系统Linux、macOS或WindowsWSL2推荐用于Windows。容器运行时如果使用Docker部署需要安装Docker或Podman。网络确保本工具、OTel Collector、Prometheus之间网络互通。4. 安装部署与启动方式该项目可能提供多种部署方式。以下以假设项目提供Docker镜像和独立二进制两种方式为例给出通用部署步骤。4.1 通过Docker容器运行推荐这是最快捷的启动方式适合大多数环境。# 拉取镜像假设镜像名为 myrepo/genai-metrics-exporter:latest docker pull myrepo/genai-metrics-exporter:latest # 运行容器 docker run -d \ --name genai-metrics-exporter \ -p 8080:8080 \ # 暴露指标端点端口 -e OTEL_EXPORTER_OTLP_ENDPOINThttp://your-otel-collector:4318 \ # 指向你的OTel Collector -e METRICS_PORT8080 \ myrepo/genai-metrics-exporter:latest关键参数说明-p 8080:8080将容器内的8080端口映射到宿主机。Prometheus将从这个端口的/metrics路径抓取数据。OTEL_EXPORTER_OTLP_ENDPOINT环境变量告诉本工具从哪里拉取Trace数据。它需要连接到OTel Collector的OTLP gRPC或HTTP端口。其他可能需要的配置如采样率、提示词截断长度等需要通过环境变量或配置文件传入。4.2 通过二进制文件运行如果项目提供了针对不同平台的二进制文件部署流程如下# 1. 下载并解压二进制文件 wget https://github.com/your-org/genai-metrics-exporter/releases/download/v0.1.0/genai-metrics-exporter-linux-amd64.tar.gz tar -xzf genai-metrics-exporter-linux-amd64.tar.gz cd genai-metrics-exporter # 2. 创建配置文件 config.yaml cat config.yaml EOF server: port: 8080 otel: endpoint: http://localhost:4318 # OTel Collector地址 insecure: true # 如果使用非TLS连接 metrics: enable_cost_calculation: true prompt_truncate_length: 500 # 截断过长的提示词标签 EOF # 3. 启动服务 ./genai-metrics-exporter --config ./config.yaml4.3 验证服务是否启动服务启动后首先检查其健康状态和指标端点。# 检查健康端点假设为 /health curl http://localhost:8080/health # 预期返回{status: healthy} # 查看暴露的原始指标 curl http://localhost:8080/metrics如果/metrics端点能返回一系列以genai_为前缀的指标如genai_request_duration_seconds说明服务启动成功正在处理数据。5. 功能测试与效果验证部署完成后我们需要验证从AI应用产生Trace到本工具处理并暴露指标的全链路。5.1 准备测试AI应用假设我们有一个简单的Python Flask应用它调用OpenAI API并且已经通过OpenTelemetry进行了插桩。# app.py (示例片段) from opentelemetry import trace from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter from opentelemetry.instrumentation.flask import FlaskInstrumentor from opentelemetry.instrumentation.openai import OpenAIInstrumentor import openai from flask import Flask, request import os # 设置Trace导出到OTLP Collector tracer_provider TracerProvider() otlp_exporter OTLPSpanExporter(endpointos.getenv(OTEL_EXPORTER_OTLP_ENDPOINT, http://localhost:4318)) tracer_provider.add_span_processor(BatchSpanProcessor(otlp_exporter)) trace.set_tracer_provider(tracer_provider) # 自动插桩Flask和OpenAI app Flask(__name__) FlaskInstrumentor().instrument_app(app) OpenAIInstrumentor().instrument() client openai.OpenAI(api_keyos.getenv(OPENAI_API_KEY)) app.route(/chat, methods[POST]) def chat_completion(): user_input request.json.get(message) tracer trace.get_tracer(__name__) with tracer.start_as_current_span(genai_chat_request) as span: # 这些属性会被OpenTelemetry语义约定捕获 response client.chat.completions.create( modelgpt-3.5-turbo, messages[{role: user, content: user_input}], max_tokens150, ) span.set_attribute(gen_ai.system, openai) span.set_attribute(gen_ai.request.model, gpt-3.5-turbo) # Token使用信息通常由instrumentation库自动添加 return {reply: response.choices[0].message.content} if __name__ __main__: app.run(host0.0.0.0, port5000)5.2 生成Trace数据启动你的AI测试应用确保其OTLP导出指向正确的Collector。向应用发送几个请求例如curl -X POST http://localhost:5000/chat \ -H Content-Type: application/json \ -d {message: 请用中文解释什么是机器学习}检查OpenTelemetry Collector的日志确认它收到了Trace数据。5.3 验证指标生成等待片刻指标计算可能有短暂的聚合窗口然后再次查询本工具的指标端点。curl http://localhost:8080/metrics | grep genai_你应该能看到类似以下的指标输出# HELP genai_request_duration_seconds The duration of GenAI requests # TYPE genai_request_duration_seconds histogram genai_request_duration_seconds_bucket{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,le0.1} 1 genai_request_duration_seconds_bucket{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,le0.5} 5 ... genai_request_duration_seconds_sum{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo} 2.34 genai_request_duration_seconds_count{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo} 10 # HELP genai_token_usage_total Total tokens used in GenAI requests # TYPE genai_token_usage_total counter genai_token_usage_total{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,token_typeprompt} 4500 genai_token_usage_total{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,token_typecompletion} 1200 # HELP genai_request_total Total number of GenAI requests # TYPE genai_request_total counter genai_request_total{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,status_codeOK} 10 genai_request_total{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,status_codeERROR} 1判断成功的关键出现了genai_前缀的指标。指标带有有意义的标签如gen_ai_system、gen_ai_request_model。计数类指标_total,_count的数值随着你的请求次数增加而增长。如果配置了提示词相关的标签可能是哈希值或截断文本也出现在指标中。6. 配置Prometheus抓取与Grafana可视化指标暴露出来之后需要让Prometheus将其纳入监控体系。6.1 配置Prometheus抓取编辑你的Prometheus配置文件如prometheus.yml添加一个新的抓取任务。# prometheus.yml 片段 scrape_configs: # ... 其他抓取配置 ... - job_name: genai-metrics-exporter static_configs: - targets: [localhost:8080] # 你的genai-metrics-exporter服务地址 scrape_interval: 15s # 根据需求调整抓取间隔 metrics_path: /metrics重启Prometheus服务并在Prometheus的Web UI默认http://localhost:9090的“Targets”页面中确认genai-metrics-exporter的状态为“UP”。6.2 在Grafana中创建监控面板添加数据源确保Grafana中已经添加了你的Prometheus数据源。新建Dashboard和Panel创建一个名为“GenAI服务监控”的Dashboard。添加一个Graph面板查询PromQL语句例如请求率与错误率rate(genai_request_total{status_codeOK}[5m]) # 成功请求率 rate(genai_request_total{status_codeERROR}[5m]) # 错误请求率请求延迟P95histogram_quantile(0.95, rate(genai_request_duration_seconds_bucket[5m]))Token消耗速率rate(genai_token_usage_total[5m])利用标签如gen_ai_request_model进行拆分可以对比不同模型的性能。为关键指标如错误率1%、P95延迟10s设置告警规则Alert Rules。7. 资源占用与性能观察作为一个指标处理和暴露服务其资源消耗通常很低但以下几点需要注意内存占用主要消耗在于维护一个时间窗口内的Trace数据用于聚合计算。如果Trace流量非常大每秒数千Span需要关注内存使用量。可以通过容器或进程监控查看其RSS常驻内存集大小。CPU占用指标计算尤其是分位数计算和Prometheus格式序列化会消耗CPU。在Trace流量高峰时观察CPU使用率。网络I/O它需要从OTel Collector拉取或接收Trace数据并向Prometheus暴露指标。确保网络带宽和延迟不会成为瓶颈。观察方法容器环境使用docker stats genai-metrics-exporter或kubectl top pod。系统级使用top、htop或vmstat。自我监控该服务本身应该暴露Go或进程相关的运行时指标如go_memstats_alloc_bytes、process_cpu_seconds_total这些指标也可以被Prometheus抓取用于监控其自身健康状态。性能调优建议调整聚合窗口如果内存占用过高可以尝试缩短指标计算的聚合时间窗口如果配置支持。采样率在OTel Collector或应用SDK侧配置适当的采样率减少不必要的Trace数据量特别是对于高吞吐服务。标签基数谨慎选择作为指标标签的字段。将原始提示词全文作为标签会产生极高的基数严重拖慢Prometheus性能。务必使用截断、哈希或只提取提示词模板特征的方式。8. 常见问题与排查方法问题现象可能原因排查方式解决方案服务启动失败端口冲突指定的端口如8080已被其他进程占用netstat -tulnp | grep :8080或lsof -i :8080更换服务启动配置中的端口号。/metrics端点返回404或无数据服务未成功启动或未连接到OTel Collector1. 检查服务日志是否有错误。2. 检查/health端点是否正常。3. 检查环境变量OTEL_EXPORTER_OTLP_ENDPOINT配置是否正确网络是否连通。根据日志修复配置错误确保能访问到OTel Collector。Prometheus抓取目标状态为“DOWN”Prometheus无法连接到本工具的指标端点1. 在Prometheus服务器上使用curl尝试访问http://exporter-host:port/metrics。2. 检查防火墙/安全组规则。3. 检查服务是否真的在运行。解决网络连通性问题或修正Prometheus配置中的targets地址。有Trace数据但无genai_指标1. Trace数据不符合GenAI语义约定。2. 本工具配置过滤了某些Span。1. 检查原始的Trace数据通过Jaeger/Tempo UI确认Span是否包含gen_ai.system等属性。2. 检查本工具日志看是否有处理Span的记录或警告。确保AI应用使用正确的OpenTelemetry instrumentation库并生成了符合约定的Span属性。指标标签中提示词字段为空或为哈希这是正常的安全/性能配置检查本工具关于提示词处理的配置项如prompt_truncate_length,prompt_hash_enabled。如果业务需要查看部分提示词内容进行调试可以调整截断长度否则为了性能和隐私保持哈希或截断是推荐做法。内存使用量持续增长可能发生了内存泄漏或Trace数据量过大聚合窗口内数据未释放1. 观察内存增长曲线。2. 检查日志是否有OOM相关错误。3. 尝试减小聚合窗口大小或提高采样率。升级到最新版本调整配置参数如无改善需向项目方提交Issue。9. 最佳实践与使用建议从测试环境开始先在非生产环境集成和测试验证全链路应用 - OTel - 本工具 - Prometheus - Grafana畅通指标符合预期。定义清晰的指标和告警在Grafana中设计Dashboard时想清楚要监控什么。常见的GenAI SLO指标包括请求成功率、P99/P95延迟、Token消耗速率。为这些指标设置合理的告警阈值。谨慎处理提示词标签生产环境禁用明文绝对不要在生产环境将完整的、未处理的用户提示词作为指标标签这违反隐私法规且会摧毁Prometheus性能。使用特征提取考虑提取提示词的类型如“总结”、“翻译”、“代码生成”、长度区间、或使用预定义的模板ID作为标签这样既能分析又能控制标签基数。与业务指标关联GenAI的技术指标延迟、Token需要与业务指标用户满意度、转化率关联分析才能体现最大价值。尝试在Grafana中将它们放在同一个Dashboard中。建立基线在流量平稳期记录关键指标如平均延迟、Token/请求的正常范围作为后续性能退化判断的基线。文档化与团队共享将你建立的GenAI监控Dashboard和告警规则文档化并分享给相关的开发、运维和产品团队建立共同的可观测性语言。10. 总结与下一步“Bounded GenAI metrics from Otel traces with O raw prompts”这个项目为监控生成式AI应用提供了一个强大且标准的解决方案。它的核心价值在于将OpenTelemetry追踪数据中蕴含的丰富上下文特别是原始提示词转化为可聚合、可告警、可直观展示的运营指标。通过本文的步骤你应该已经能够完成从部署、集成到可视化监控的全过程。最值得尝试的下一步是选择一个内部AI应用哪怕只是一个简单的脚本为其加上OpenTelemetry插桩。快速部署本工具使用Docker方式在几分钟内拉起服务。跑通第一条数据链路发送几次请求在Grafana中看到第一条延迟曲线和Token计数。最容易踩的坑通常是网络配置OTLP端点不通和标签基数爆炸误用提示词全文做标签。按照本文的排查方法和最佳实践可以避开大部分问题。这套监控体系的建立不仅能让你实时掌握AI服务的健康状态更能为后续的成本优化分析Token消耗、性能调优定位慢请求和提示词工程A/B测试不同提示模板提供坚实的数据支撑。建议将相关配置代码和Dashboard模板纳入版本控制作为AI应用开发的基础设施的一部分。
基于OpenTelemetry与Prometheus的生成式AI应用监控实战
这次我们来看一个名为“Bounded GenAI metrics from Otel traces with O raw prompts”的开源项目。这个项目瞄准的是当前生成式AIGenAI应用开发与运维中的一个核心痛点如何有效监控和度量AI模型调用链路的性能、成本与质量。它通过OpenTelemetryOtel的追踪Traces数据自动提取并计算有界Bounded的GenAI指标并将原始提示词Raw Prompts作为关键上下文最终将指标暴露给Prometheus以便在Grafana等可视化工具中进行监控和告警。对于正在构建或维护涉及大语言模型LLM、图像生成等AI服务的开发者与运维工程师来说这个工具的价值在于它提供了一种标准化的、可观测性驱动的方案来回答以下关键问题每次AI调用的耗时多长Token消耗与成本是多少提示词工程的效果如何是否存在异常或低效的调用模式本文将从实战角度带你快速了解这个项目的核心能力、部署方式并演示如何将其集成到你的AI应用中实现对GenAI调用链路的深度可观测。无论你是想监控本地测试的Stable Diffusion API还是生产环境的GPT/Claude调用这套方案都能提供清晰的度量视角。1. 核心能力速览能力项说明项目类型开源监控指标提取与暴露工具核心原理解析OpenTelemetry Trace数据提取GenAI相关Span中的耗时、Token数、模型、提示词等属性聚合为Prometheus指标数据输入OpenTelemetry Trace通常通过OTLP协议接收指标输出Prometheus格式的指标通过HTTP端点暴露关键特性1.有界指标计算支持计算分位数如P95、P99延迟、成功率等聚合指标。2.原始提示词关联能将原始提示词或截断版本作为指标的标签Label便于按提示词模式进行分析。3.GenAI语义感知能识别LLM调用、Embedding调用等特定Span并提取llm.token.usage、gen_ai.system等属性。部署方式可作为独立服务二进制或Docker容器运行或作为库集成到应用中硬件门槛极低。作为指标处理服务对CPU和内存消耗很小通常不需要GPU。适合场景监控集成LLM/图像生成API的应用、评估不同提示词性能、分析AI调用成本与延迟、设置SLO告警。2. 适用场景与使用边界这个工具非常适合以下角色和场景AI应用开发者在开发阶段需要量化不同提示词、不同模型参数对响应时间和Token消耗的影响。运维/SRE工程师需要为生产环境的AI服务建立可观测性监控其健康度、延迟和错误率并配置告警。成本优化团队希望通过监控Token使用量分析并优化AI调用的成本。提示词工程师需要A/B测试不同提示词模板的效果包括响应时间、成功率和输出质量需结合业务指标。使用边界与注意事项依赖OpenTelemetry你的应用必须已经或计划接入OpenTelemetry SDK并生成包含GenAI语义约定的Trace数据。这是该工具工作的前提。提示词隐私与安全将原始提示词作为指标标签可能暴露敏感信息。项目通常提供截断、哈希或过滤机制使用时必须根据公司安全策略进行配置避免泄露用户隐私或商业机密。非性能压测工具它主要用于监控和度量而不是像Locust那样的压力测试工具。虽然它能反映性能但生成负载需要其他工具配合。指标而非日志它产出的是聚合后的指标不适合用于调试单次请求的详细输入输出。详细的日志仍需通过原生日志系统查看。3. 环境准备与前置条件在部署这个指标提取服务之前你需要确保以下环境就绪可观测性基础设施OpenTelemetry Collector一个运行中的OTel Collector服务用于接收来自应用的Trace数据并可能转发给后端如Jaeger、Tempo以及本工具。你需要知道它的OTLP接收端点通常是http://localhost:4318或4317。Prometheus用于抓取和存储本工具暴露的指标。需要确保Prometheus服务器可以访问到本工具暴露的/metrics端点。Grafana可选但推荐用于可视化Prometheus中的指标。已接入OpenTelemetry的AI应用你的应用程序需要使用支持OpenTelemetry的GenAI SDK或手动创建符合 OpenTelemetry GenAI语义约定 的Span。例如在Python中你可能使用opentelemetry-instrumentation-openai这样的库来自动化插桩。运行环境操作系统Linux、macOS或WindowsWSL2推荐用于Windows。容器运行时如果使用Docker部署需要安装Docker或Podman。网络确保本工具、OTel Collector、Prometheus之间网络互通。4. 安装部署与启动方式该项目可能提供多种部署方式。以下以假设项目提供Docker镜像和独立二进制两种方式为例给出通用部署步骤。4.1 通过Docker容器运行推荐这是最快捷的启动方式适合大多数环境。# 拉取镜像假设镜像名为 myrepo/genai-metrics-exporter:latest docker pull myrepo/genai-metrics-exporter:latest # 运行容器 docker run -d \ --name genai-metrics-exporter \ -p 8080:8080 \ # 暴露指标端点端口 -e OTEL_EXPORTER_OTLP_ENDPOINThttp://your-otel-collector:4318 \ # 指向你的OTel Collector -e METRICS_PORT8080 \ myrepo/genai-metrics-exporter:latest关键参数说明-p 8080:8080将容器内的8080端口映射到宿主机。Prometheus将从这个端口的/metrics路径抓取数据。OTEL_EXPORTER_OTLP_ENDPOINT环境变量告诉本工具从哪里拉取Trace数据。它需要连接到OTel Collector的OTLP gRPC或HTTP端口。其他可能需要的配置如采样率、提示词截断长度等需要通过环境变量或配置文件传入。4.2 通过二进制文件运行如果项目提供了针对不同平台的二进制文件部署流程如下# 1. 下载并解压二进制文件 wget https://github.com/your-org/genai-metrics-exporter/releases/download/v0.1.0/genai-metrics-exporter-linux-amd64.tar.gz tar -xzf genai-metrics-exporter-linux-amd64.tar.gz cd genai-metrics-exporter # 2. 创建配置文件 config.yaml cat config.yaml EOF server: port: 8080 otel: endpoint: http://localhost:4318 # OTel Collector地址 insecure: true # 如果使用非TLS连接 metrics: enable_cost_calculation: true prompt_truncate_length: 500 # 截断过长的提示词标签 EOF # 3. 启动服务 ./genai-metrics-exporter --config ./config.yaml4.3 验证服务是否启动服务启动后首先检查其健康状态和指标端点。# 检查健康端点假设为 /health curl http://localhost:8080/health # 预期返回{status: healthy} # 查看暴露的原始指标 curl http://localhost:8080/metrics如果/metrics端点能返回一系列以genai_为前缀的指标如genai_request_duration_seconds说明服务启动成功正在处理数据。5. 功能测试与效果验证部署完成后我们需要验证从AI应用产生Trace到本工具处理并暴露指标的全链路。5.1 准备测试AI应用假设我们有一个简单的Python Flask应用它调用OpenAI API并且已经通过OpenTelemetry进行了插桩。# app.py (示例片段) from opentelemetry import trace from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter from opentelemetry.instrumentation.flask import FlaskInstrumentor from opentelemetry.instrumentation.openai import OpenAIInstrumentor import openai from flask import Flask, request import os # 设置Trace导出到OTLP Collector tracer_provider TracerProvider() otlp_exporter OTLPSpanExporter(endpointos.getenv(OTEL_EXPORTER_OTLP_ENDPOINT, http://localhost:4318)) tracer_provider.add_span_processor(BatchSpanProcessor(otlp_exporter)) trace.set_tracer_provider(tracer_provider) # 自动插桩Flask和OpenAI app Flask(__name__) FlaskInstrumentor().instrument_app(app) OpenAIInstrumentor().instrument() client openai.OpenAI(api_keyos.getenv(OPENAI_API_KEY)) app.route(/chat, methods[POST]) def chat_completion(): user_input request.json.get(message) tracer trace.get_tracer(__name__) with tracer.start_as_current_span(genai_chat_request) as span: # 这些属性会被OpenTelemetry语义约定捕获 response client.chat.completions.create( modelgpt-3.5-turbo, messages[{role: user, content: user_input}], max_tokens150, ) span.set_attribute(gen_ai.system, openai) span.set_attribute(gen_ai.request.model, gpt-3.5-turbo) # Token使用信息通常由instrumentation库自动添加 return {reply: response.choices[0].message.content} if __name__ __main__: app.run(host0.0.0.0, port5000)5.2 生成Trace数据启动你的AI测试应用确保其OTLP导出指向正确的Collector。向应用发送几个请求例如curl -X POST http://localhost:5000/chat \ -H Content-Type: application/json \ -d {message: 请用中文解释什么是机器学习}检查OpenTelemetry Collector的日志确认它收到了Trace数据。5.3 验证指标生成等待片刻指标计算可能有短暂的聚合窗口然后再次查询本工具的指标端点。curl http://localhost:8080/metrics | grep genai_你应该能看到类似以下的指标输出# HELP genai_request_duration_seconds The duration of GenAI requests # TYPE genai_request_duration_seconds histogram genai_request_duration_seconds_bucket{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,le0.1} 1 genai_request_duration_seconds_bucket{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,le0.5} 5 ... genai_request_duration_seconds_sum{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo} 2.34 genai_request_duration_seconds_count{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo} 10 # HELP genai_token_usage_total Total tokens used in GenAI requests # TYPE genai_token_usage_total counter genai_token_usage_total{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,token_typeprompt} 4500 genai_token_usage_total{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,token_typecompletion} 1200 # HELP genai_request_total Total number of GenAI requests # TYPE genai_request_total counter genai_request_total{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,status_codeOK} 10 genai_request_total{gen_ai_systemopenai,gen_ai_request_modelgpt-3.5-turbo,status_codeERROR} 1判断成功的关键出现了genai_前缀的指标。指标带有有意义的标签如gen_ai_system、gen_ai_request_model。计数类指标_total,_count的数值随着你的请求次数增加而增长。如果配置了提示词相关的标签可能是哈希值或截断文本也出现在指标中。6. 配置Prometheus抓取与Grafana可视化指标暴露出来之后需要让Prometheus将其纳入监控体系。6.1 配置Prometheus抓取编辑你的Prometheus配置文件如prometheus.yml添加一个新的抓取任务。# prometheus.yml 片段 scrape_configs: # ... 其他抓取配置 ... - job_name: genai-metrics-exporter static_configs: - targets: [localhost:8080] # 你的genai-metrics-exporter服务地址 scrape_interval: 15s # 根据需求调整抓取间隔 metrics_path: /metrics重启Prometheus服务并在Prometheus的Web UI默认http://localhost:9090的“Targets”页面中确认genai-metrics-exporter的状态为“UP”。6.2 在Grafana中创建监控面板添加数据源确保Grafana中已经添加了你的Prometheus数据源。新建Dashboard和Panel创建一个名为“GenAI服务监控”的Dashboard。添加一个Graph面板查询PromQL语句例如请求率与错误率rate(genai_request_total{status_codeOK}[5m]) # 成功请求率 rate(genai_request_total{status_codeERROR}[5m]) # 错误请求率请求延迟P95histogram_quantile(0.95, rate(genai_request_duration_seconds_bucket[5m]))Token消耗速率rate(genai_token_usage_total[5m])利用标签如gen_ai_request_model进行拆分可以对比不同模型的性能。为关键指标如错误率1%、P95延迟10s设置告警规则Alert Rules。7. 资源占用与性能观察作为一个指标处理和暴露服务其资源消耗通常很低但以下几点需要注意内存占用主要消耗在于维护一个时间窗口内的Trace数据用于聚合计算。如果Trace流量非常大每秒数千Span需要关注内存使用量。可以通过容器或进程监控查看其RSS常驻内存集大小。CPU占用指标计算尤其是分位数计算和Prometheus格式序列化会消耗CPU。在Trace流量高峰时观察CPU使用率。网络I/O它需要从OTel Collector拉取或接收Trace数据并向Prometheus暴露指标。确保网络带宽和延迟不会成为瓶颈。观察方法容器环境使用docker stats genai-metrics-exporter或kubectl top pod。系统级使用top、htop或vmstat。自我监控该服务本身应该暴露Go或进程相关的运行时指标如go_memstats_alloc_bytes、process_cpu_seconds_total这些指标也可以被Prometheus抓取用于监控其自身健康状态。性能调优建议调整聚合窗口如果内存占用过高可以尝试缩短指标计算的聚合时间窗口如果配置支持。采样率在OTel Collector或应用SDK侧配置适当的采样率减少不必要的Trace数据量特别是对于高吞吐服务。标签基数谨慎选择作为指标标签的字段。将原始提示词全文作为标签会产生极高的基数严重拖慢Prometheus性能。务必使用截断、哈希或只提取提示词模板特征的方式。8. 常见问题与排查方法问题现象可能原因排查方式解决方案服务启动失败端口冲突指定的端口如8080已被其他进程占用netstat -tulnp | grep :8080或lsof -i :8080更换服务启动配置中的端口号。/metrics端点返回404或无数据服务未成功启动或未连接到OTel Collector1. 检查服务日志是否有错误。2. 检查/health端点是否正常。3. 检查环境变量OTEL_EXPORTER_OTLP_ENDPOINT配置是否正确网络是否连通。根据日志修复配置错误确保能访问到OTel Collector。Prometheus抓取目标状态为“DOWN”Prometheus无法连接到本工具的指标端点1. 在Prometheus服务器上使用curl尝试访问http://exporter-host:port/metrics。2. 检查防火墙/安全组规则。3. 检查服务是否真的在运行。解决网络连通性问题或修正Prometheus配置中的targets地址。有Trace数据但无genai_指标1. Trace数据不符合GenAI语义约定。2. 本工具配置过滤了某些Span。1. 检查原始的Trace数据通过Jaeger/Tempo UI确认Span是否包含gen_ai.system等属性。2. 检查本工具日志看是否有处理Span的记录或警告。确保AI应用使用正确的OpenTelemetry instrumentation库并生成了符合约定的Span属性。指标标签中提示词字段为空或为哈希这是正常的安全/性能配置检查本工具关于提示词处理的配置项如prompt_truncate_length,prompt_hash_enabled。如果业务需要查看部分提示词内容进行调试可以调整截断长度否则为了性能和隐私保持哈希或截断是推荐做法。内存使用量持续增长可能发生了内存泄漏或Trace数据量过大聚合窗口内数据未释放1. 观察内存增长曲线。2. 检查日志是否有OOM相关错误。3. 尝试减小聚合窗口大小或提高采样率。升级到最新版本调整配置参数如无改善需向项目方提交Issue。9. 最佳实践与使用建议从测试环境开始先在非生产环境集成和测试验证全链路应用 - OTel - 本工具 - Prometheus - Grafana畅通指标符合预期。定义清晰的指标和告警在Grafana中设计Dashboard时想清楚要监控什么。常见的GenAI SLO指标包括请求成功率、P99/P95延迟、Token消耗速率。为这些指标设置合理的告警阈值。谨慎处理提示词标签生产环境禁用明文绝对不要在生产环境将完整的、未处理的用户提示词作为指标标签这违反隐私法规且会摧毁Prometheus性能。使用特征提取考虑提取提示词的类型如“总结”、“翻译”、“代码生成”、长度区间、或使用预定义的模板ID作为标签这样既能分析又能控制标签基数。与业务指标关联GenAI的技术指标延迟、Token需要与业务指标用户满意度、转化率关联分析才能体现最大价值。尝试在Grafana中将它们放在同一个Dashboard中。建立基线在流量平稳期记录关键指标如平均延迟、Token/请求的正常范围作为后续性能退化判断的基线。文档化与团队共享将你建立的GenAI监控Dashboard和告警规则文档化并分享给相关的开发、运维和产品团队建立共同的可观测性语言。10. 总结与下一步“Bounded GenAI metrics from Otel traces with O raw prompts”这个项目为监控生成式AI应用提供了一个强大且标准的解决方案。它的核心价值在于将OpenTelemetry追踪数据中蕴含的丰富上下文特别是原始提示词转化为可聚合、可告警、可直观展示的运营指标。通过本文的步骤你应该已经能够完成从部署、集成到可视化监控的全过程。最值得尝试的下一步是选择一个内部AI应用哪怕只是一个简单的脚本为其加上OpenTelemetry插桩。快速部署本工具使用Docker方式在几分钟内拉起服务。跑通第一条数据链路发送几次请求在Grafana中看到第一条延迟曲线和Token计数。最容易踩的坑通常是网络配置OTLP端点不通和标签基数爆炸误用提示词全文做标签。按照本文的排查方法和最佳实践可以避开大部分问题。这套监控体系的建立不仅能让你实时掌握AI服务的健康状态更能为后续的成本优化分析Token消耗、性能调优定位慢请求和提示词工程A/B测试不同提示模板提供坚实的数据支撑。建议将相关配置代码和Dashboard模板纳入版本控制作为AI应用开发的基础设施的一部分。
