LangSmith 为追踪和调试 LangChain 应用程序提供了极有价值的专用工具,但生产环境通常要求与更广泛的现有可观测性平台集成。许多组织已将 Datadog、Grafana/Prometheus、Splunk、Jaeger 或 Honeycomb 等系统作为标准,以获取其整个技术栈的统一视图。将 LangChain 应用程序监控集成到这些平台中,可以帮助您关联 LLM 应用程序行为与基础设施性能、其他微服务和业务指标,同时使用现有的警报和事件管理流程。本节介绍如何将 LangChain 应用程序的运营数据(日志、指标和追踪)引入这些第三方系统。LangChain 中可观测性的主要构成有效的可观测性通常依赖于三种数据类型:日志: 带时间戳的独立事件记录。在 LangChain 中,这包括应用程序启动、错误、警告、特定的函数调用(如工具使用),以及如果配置并符合隐私要求的话,可能还包括输入/输出。指标: 随时间变化的数值测量数据。对于 LangChain 应用程序,重要指标包括 LLM 调用延迟、令牌计数(提示、完成、总数)、预估成本、检索延迟、工具调用次数、每个组件的错误率和缓存命中率。追踪: 表示请求在通过不同组件或服务时的整个生命周期。LangSmith 在处理 LangChain 内部的这类数据方面表现出色,但传播或导出这些追踪数据可以实现与上游/下游服务的关联。集成日志功能LangChain 使用 Python 标准的 logging 库。这使得集成相对简单。您可以配置 Python 的日志处理程序,将日志转发到您所选平台支持的不同目标。常见方法包括:配置日志处理程序: 使用特定平台的 Python 日志处理程序(例如 datadog_api_client.v2.logs、用于 Splunk HEC 的库,或由 Fluentd 或 Logstash 等代理监控的标准处理程序,如 logging.handlers.SysLogHandler 或 logging.FileHandler)。结构化日志: 以结构化格式(如 JSON)输出日志,大多数日志聚合平台都可以轻松解析。python-json-logger 等库可以提供帮助。# 示例:JSON 日志的基本配置 import logging import sys from pythonjsonlogger import jsonlogger # 获取根日志记录器 logger = logging.getLogger() logger.setLevel(logging.INFO) # 使用流处理程序将输出发送到标准输出(可由代理收集) logHandler = logging.StreamHandler(sys.stdout) # 使用 JSON 格式化程序 formatter = jsonlogger.JsonFormatter('%(asctime)s %(name)s %(levelname)s %(message)s') logHandler.setFormatter(formatter) # 添加处理程序 logger.addHandler(logHandler) # 现在,LangChain(和您的应用程序)使用标准日志记录器输出的日志将是 JSON 格式的 logging.info("应用程序已启动。") # LangChain 组件日志记录示例 # (假设 LangChain 组件内部使用标准日志记录) # try: # result = my_chain.invoke({"input": "一些查询"}) # except Exception as e: # logging.error("链执行失败", exc_info=True) 确保发送给第三方的日志已清除敏感信息(个人身份信息、API 密钥),除非平台有针对此类数据批准的特定安全处理机制。导出指标指标提供关于性能和资源消耗的可量化视图。集成 LangChain 指标需要对您的应用程序进行检测,以收集相关数据点并进行导出。检测: 您可能需要包装特定的 LangChain 组件或使用回调/处理程序来捕获指标。例如,创建自定义的 Runnable 或修改链执行逻辑,以记录 LLM 调用或工具执行前后延迟或令牌计数。导出: 使用可观测性平台提供的客户端库(例如 prometheus_client、datadog、statsd)来发送指标。这些库通常允许您定义指标类型(计数器、量规、直方图)并将数据推送到平台,或公开一个用于抓取的端点(Prometheus 常见)。# 示例:使用 Prometheus 检测 LLM 调用延迟 from prometheus_client import Histogram, start_http_server import time from langchain_core.runnables import RunnableLambda from langchain_openai import ChatOpenAI # 定义一个 Prometheus 直方图指标 llm_latency_histogram = Histogram( 'langchain_llm_latency_seconds', 'LLM 调用延迟,单位秒', ['llm_provider', 'model_name'] ) # 假设 llm 是一个已初始化的 LangChain LLM 组件(例如 ChatOpenAI) llm = ChatOpenAI(model="gpt-3.5-turbo") # 替换为您的实际 LLM def llm_with_metrics(input_data): """封装 LLM 调用以记录延迟。""" start_time = time.time() try: # 获取提供商/模型信息(可能需要根据 LLM 对象进行调整) provider = llm.__class__.__module__.split('.')[-1] # 启发式方法 model = getattr(llm, 'model_name', 'unknown') result = llm.invoke(input_data) # 实际的 LLM 调用 latency = time.time() - start_time # 记录延迟 llm_latency_histogram.labels(llm_provider=provider, model_name=model).observe(latency) return result except Exception as e: # (可选)也将错误记录为指标 raise e # 创建一个 RunnableLambda 以插入到链中 instrumented_llm_runnable = RunnableLambda(llm_with_metrics) # 启动 Prometheus 客户端 HTTP 服务器(通常在应用程序启动时执行一次) # start_http_server(8000) # 在 8000 端口公开指标 # 现在在您的链中使用 instrumented_llm_runnable # 例如:my_chain = prompt | instrumented_llm_runnable | parser 建议导出的重要指标:整体请求延迟每个组件的延迟(LLM、检索器、工具)每次请求/调用的令牌计数(提示、完成、总数)每次请求/调用的预估成本每个组件的错误计数和错误率缓存命中/未命中率检索分数或相关性指标(如果适用)使用 OpenTelemetry 集成追踪现代追踪通常依赖于 OpenTelemetry (OTel),这是一个用于生成和收集遥测数据的开放标准。LangChain 内置支持 OpenTelemetry,使集成更顺畅。LangSmith 本身也常使用与 OTel 兼容的理念。与 Jaeger、Tempo、Honeycomb 或 Datadog APM 等平台集成通常涉及:安装 OTel 包: 将所需的 OpenTelemetry API、SDK 和导出器包添加到您的项目。pip install opentelemetry-api opentelemetry-sdk opentelemetry-exporter-otlp # 或特定导出器配置导出器: 配置 OTel SDK,将追踪数据导出到您选择的后端。这通常涉及设置环境变量或以编程方式配置 SDK,使其指向后端(通常是 OTel Collector 或平台的直接数据摄取端点)的 OTel 端点。环境变量(常见): 许多 OTel 库会根据 OTEL_EXPORTER_OTLP_ENDPOINT、OTEL_SERVICE_NAME 等标准环境变量自动配置。编程配置: 在应用程序代码中明确设置追踪器提供者、处理器和导出器。启用 LangChain OTel 集成: 如果 SDK 初始化正确,LangChain 可能会自动获取 OTel 配置;或者您可能需要根据所用版本和组件设置特定标志或设置。确保追踪上下文正确传播,特别是当您的 LangChain 应用程序是大型分布式系统的一部分时。主要益处是分布式追踪:您不仅可以在 LangChain 应用程序内部,还可以在其交互的其他服务(例如,初始 API 网关、工具调用的后续微服务)中看到单个请求的路径。digraph G { rankdir=LR; node [shape=box, style=rounded, fontname="Arial", fontsize=10, color="#adb5bd", fontcolor="#495057"]; edge [fontname="Arial", fontsize=9, color="#868e96"]; subgraph cluster_app { label = "LangChain 应用程序"; bgcolor="#e9ecef"; app [label="Python 进程\n(LangChain 应用)", shape=component, color="#4263eb"]; otel_sdk [label="OpenTelemetry SDK", color="#1c7ed6"]; app -> otel_sdk [label="发出日志、\n指标、追踪"]; } subgraph cluster_infra { label = "可观测性基础设施"; bgcolor="#e9ecef"; collector [label="OTel Collector / Agent\n(可选聚合器)", shape=cylinder, color="#74b816"]; logs_backend [label="日志平台\n(例如:Splunk, ELK)", shape=database, color="#f76707"]; metrics_backend [label="指标平台\n(例如:Prometheus,\nDatadog Metrics)", shape=database, color="#ae3ec9"]; traces_backend [label="追踪平台\n(例如:Jaeger, Tempo,\nDatadog APM)", shape=database, color="#1098ad"]; } otel_sdk -> collector [label="OTLP 导出"]; collector -> logs_backend [label="日志"]; collector -> metrics_backend [label="指标"]; collector -> traces_backend [label="追踪"]; # 直接导出替代方案 otel_sdk -> logs_backend [style=dashed, label="直接日志处理程序"]; otel_sdk -> metrics_backend [style=dashed, label="直接指标客户端"]; otel_sdk -> traces_backend [style=dashed, label="直接追踪导出器"]; }LangChain 应用程序的观测数据流向,通过可选的收集器传输到专业后端平台。应用程序也可以直接与后端集成。平台选择与考量可观测性平台的选择通常取决于您组织内现有的工具。但请考虑:兼容性: 该平台是否能很好地支持 Python 应用程序和 OpenTelemetry?功能: 评估日志搜索、指标仪表板/警报以及追踪可视化/分析的能力。它如何处理 LLM 应用程序中常见的高基数数据(例如,不同的提示、用户 ID)?成本: 可观测性数据量可能很大。了解定价模型(每 GB 摄入量、每主机、每追踪),并在必要时对追踪以及可能的指标/日志使用采样策略(基于头部、基于尾部)来管理成本。关联性: 确保该平台能方便地使用共享标识符(如 trace_id)来关联日志、指标和追踪。安全性: 再次强调通过遥测防止敏感数据泄露的重要性。使用数据屏蔽、过滤,或确保平台提供足够的安全控制。将 LangChain 应用程序监控集成到您组织的标准可观测性技术栈中,可以全面了解其在更大系统中的行为。它利用现有的工具和专业知识投入,能够更快地进行故障排除、性能优化,并为您的生产 LLM 应用程序提供更稳定的运行。