使用 OpenTelemetry 和 Elastic 的 ML 和 AI Ops 可观测性

作者来自 Elastic Almudena Sanz Olivé学习如何使用 OpenTelemetry 和 Elastic 对 ML 和 AI 管道进行插装以关联从 notebooks 到生产推理服务的 traces、logs 和 metrics。虽然孤立的执行日志可能适用于本地实验但对于复杂、可投入生产的 Machine Learning (ML) 管道和 Artificial Intelligence (AI) agents 的新时代来说这已经不再足够。现代 ML 和 AI 系统呈现出三个独特挑战分布式组件单个请求可能会经过 API gateway从 feature store 获取数据在 Python 推理服务中评估预测模型查询向量数据库并调用外部 LLM。非确定性AI agents 会做出自主决策并调用工具。如果 agent 失败你需要完整的 trace 来理解它的推理循环以及它尝试调用了哪些外部工具。上下文依赖你不仅关心发生了错误还需要知道当时运行的是哪个模型版本、使用了哪些超参数、输入数据是什么样的以及引入该更改的 commit 是什么。其中许多属性是你的应用自定义的你需要一个具备灵活性的 Observability 环境能够动态创建新参数并使用它们来发现和修复问题。此外随着 AI agents 被越来越多地用于生成代码和做出自主决策Observability 成为理解哪些有效、哪些无效的关键。它创建了一个关键的反馈循环以便快速修复问题。比以往任何时候都更需要ML 和 AI 应用必须采用成熟软件工程系统的最佳实践才能成功。本指南展示了如何使用 OpenTelemetry 和 Elastic 关联 traces、logs 和 metrics以跟踪运行、比较模型行为并在 Python 和 Go 服务之间使用共享上下文来追踪请求。问题背景为什么 AI 系统更难调试传统服务已经存在分布式故障模式但 ML 和 AI 系统增加了更多可变因素notebook 实验和临时任务批量训练和评估管道在线推理服务外部 API 调用包括 LLM 提供商不断变化的模型版本和超参数当某条预测路径变慢或开始失败时单纯的孤立日志无法回答足够的问题。你需要关联运行了什么run ID、模型版本、参数时间花在了哪里管道阶段延迟结果是什么模型统计、预测、API 调用、与其他运行对比发生了什么变化代码、数据、依赖在未来的博客文章中我们将向你展示如何使用 Elastic Workflows 和我们的 AI 集成来设置自动 RCA 和修复。但作为第一步ML 和 AI 管道需要一个强大的 Observability 框架而使用 OpenTelemetry 和 Elastic 可以非常容易地实现这一点。解决方案概览OpenTelemetry 为你提供了一种标准方式来生成 traces、metrics 和 logs。Elastic 提供完整的 OpenTelemetry 数据接入让你可以在一个地方存储和查询这些 telemetry。Kibana 的 UI 与 OpenTelemetry 完全集成使你可以开箱即用地探索你的服务、服务依赖、服务延迟、spans 和 metrics。你可以从两种部署方式开始Cloud将 OpenTelemetry 数据直接发送到 Elastic Cloud 托管的 OTLP EndpointmOTLP docs无需管理 collectors 的开销Local使用 start-local 运行 Elastic 和 EDOT CollectorEDOT Collector 会自动在 localhost:4317 监听 OTLP 数据这两种方式都允许你在初始实现时无需更改应用代码。步骤 1Python 服务的零代码基线首先只需安装 Elastic Distribution of OpenTelemetry PythonEDOT Python包并使用 opentelemetry-instrument 包装器来运行你的脚本。只需通过该包装器运行脚本 —— 无需修改应用代码 —— 你的 Python 服务就会立即开始生成标准 telemetry。这包括通过 logging 导出的任何 logs以及自动 instrumentation 库的 metrics 和 traces。这些数据可以直接发送到 Elastic 的托管 OTLP endpoint 或本地 EDOT collector。pip install elastic-opentelemetry edot-bootstrap --actioninstall导出 OpenTelemetry 环境变量然后在你的脚本上运行 opentelemetry-instrument 以启用自动 instrumentation。export OTEL_EXPORTER_OTLP_ENDPOINThttps://motlp-endpoint # No need when using start-local with EDOT export OTEL_EXPORTER_OTLP_HEADERSAuthorizationApiKey key # No need when using start-local with EDOT export OTEL_RESOURCE_ATTRIBUTESdeployment.environmentprod,service.version1.0.0 # Set the environment and version for your app export OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLEDtrue export ELASTIC_OTEL_SYSTEM_METRICS_ENABLEDtrue export OTEL_METRIC_EXPORT_INTERVAL5000 # Choose the interval for your application metrics opentelemetry-instrument --service_namepipeline-name python3 your_python_script.py # Set your chosen name for your service通过这个基线你可以快速获得带有 trace 上下文的集中式日志。任何通过 logging 导出的 logs 都可以在 Elastic 和 Kibana 中搜索并支持对日志进行全文搜索为日志错误设置告警进程和系统 metrics。执行过程中产生的系统和进程 metrics 会自动导出到 Elastic。你可以对其进行可视化并分析内存使用泄漏、OOM 错误、CPU 利用率瓶颈 / 峰值、线程数量、磁盘 I/O 瓶颈或网络 I/O 饱和情况为 metrics 设置告警自动 instrumentation 库的 spans服务延迟基线和错误趋势对错误率、延迟或吞吐量设置手动或异常检测告警在单一共享上下文中关联 logs、metrics 和 traces使用 OpenTelemetry 进行 instrumentation使用 Elastic 进行分析从而快速找到问题的根因。一旦数据被接入Kibana 会立即填充开箱即用的仪表板。你可以探索支持全文搜索的日志监控系统和进程 metrics分析自动 instrumentation 的 trace 瀑布图使用服务地图梳理你的 ML 依赖关系并轻松为延迟峰值、内存或 CPU 使用率以及日志错误设置告警。对于特定于 LLM 的 ObservabilityOpenTelemetry 提供了官方的 Generative AI 语义规范用于标准化如何跟踪 token 使用、模型名称和 prompts。这些语义规范仍在开发中尚未稳定。一些针对该领域常用库的 instrumentation 正在作为 OpenTelemetry Python Contrib 仓库的一部分进行开发。或者你也可以在自定义 spans 中手动实现这些规范。发送到 Elastic 的与 LLM 相关的 OpenTelemetry logs、metrics 和 traces 将处于同一上下文中并自动与应用或应用栈的其余部分相关联。步骤 2使用自定义 spans 和日志字段添加 ML 特定上下文自动 instrumentation 只是起点。对于 ML 和 AI Ops需要在业务阶段周围添加显式 spans并附加运行元数据。Elastic 的 schema 灵活性和动态映射使其非常适合用于仅属于你的管道或特定实验的自定义属性或 metrics。你无需在写入数据之前就知道数据的结构。你可以动态创建新参数Elastic 会自动映射并且你可以立即对其进行跟踪。将自定义字段和类似 metric 的值作为结构化日志字段添加以便之后可以对它们进行可视化和告警logger.info(training metrics, extra{ ml.run_id: run_id, ml.training_accuracy: train_accuracy, ml.validation_accuracy: val_accuracy, ml.drift_detected: drift_detected, })由于 Elastic 处理动态映射你记录的任何自定义 metrics 或属性例如模型 ids、训练准确率或漂移检测都会被即时索引并可在 Discover 中搜索或通过 Dashboards 进行可视化。这使得仪表板和规则变得实用当 ml.validation_accuracy 0.8 时告警当 ml.drift_detected true 时告警按 ml.model_version 对阶段延迟进行对比你可以使用这些自定义属性来构建有针对性的可视化并在验证准确率等 ML 特定指标低于关键阈值时触发告警。添加自定义 spans 可以让你拆分 ML 管道的各个具体阶段例如数据加载和模型训练将它们包装成各自可度量的执行块并分析特定管道阶段的平均延迟或错误率。from opentelemetry import trace tracer trace.get_tracer(ml.pipeline) with tracer.start_as_current_span(load_data) as span: span.set_attribute(ml.run_id, run_id) span.set_attribute(ml.dataset, dataset_source) load_data() with tracer.start_as_current_span(train_model) as span: span.set_attribute(ml.model_version, model_version) span.set_attribute(ml.learning_rate, learning_rate) train_model()自定义 spans 会在 APM UI 中与你的 traces 一起展示。因此你可以探索它们的延迟、对整体执行的影响、stack traces 以及错误率。步骤 3在生产环境中跨 Python 和 Go 追踪实际推理路径通常跨越服务边界。例如在生产环境中用户请求可能会先经过基于 Go 的 API然后才到达你的 Python ML 推理服务。OpenTelemetry 确保 trace 上下文在这些边界之间无缝保留。在我们的示例中我们有一个简单的 Go HTTP 服务作为入口点并展示了 Go 中的 OpenTelemetry instrumentation。该 REST API 服务通过查询 Elasticsearch 基于源数据集的数据 ID 来存储和检索 ML 预测。它的所有端点都已原生通过 OTel spans 进行 instrumentation。完整请求生命周期如下Go API 接收客户端请求。它在 Elasticsearch 中搜索已有预测或调用 Python 模型服务进行推理。Python 服务加载特征运行模型并返回预测结果。当两个服务都使用 OpenTelemetry 时trace 上下文会通过 headers 自动传播。在 Elastic 中你可以检查一个端到端 trace并按服务和 span 定位延迟或错误。在 Elastic 中生成的分布式 trace 将整个过程拼接在一起。你可以看到 Go API 与 Python 模型所花时间的精确分解并在单一统一视图中关联两个服务的日志。验证清单完成 instrumentation 后通过简短的 runbook 验证确认每个服务的 logs、metrics 和 traces 已到达。验证你的自定义属性例如 run_id、model_version、llm_ground_truth_score是否存在于 traces 和 logs 中。比较每个阶段的 p95 延迟load_data、train_model、predict。触发一次可控故障确认错误 trace 包含 stack 上下文。测试一条错误规则、一条延迟峰值规则和一条模型质量字段规则。设置一个 connector 并将其附加到规则以通过 Slack、email 或触发自动修复 workflow 联系你。结论和下一步OpenTelemetry 为 ML 和 AI 团队提供统一的 telemetry 层而 Elastic 使这些数据在整个生命周期中 —— 从 notebook 实验到生产推理 —— 即时可查询和可操作。通过从零代码 instrumentation 开始并逐步添加 ML 特定属性和跨语言追踪你的团队可以轻松采用成熟软件工程系统的 Observability 最佳实践并在复杂 AI 运维的新纪元中取得成功。在 Elastic Cloud 中尝试此设置并使用 mOTLP 作为托管接入路径。如果你想先使用本地沙箱环境可以从 Elastic start-local EDOT Collector 开始。原文https://www.elastic.co/observability-labs/blog/ml-ai-ops-observability-opentelemetry-elastic