尧图网页设计 
Opik OpenTelemetry Ingestion Client通过 Python SDK 将 OTLP 遥测数据接入 Opik 平台【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llm本篇技术指南聚焦 Opik Python SDK REST API 中的 OpenTelemetry Ingestion Client文档源文件它是 Opik 平台用于接收 OpenTelemetryOTLP遥测数据的官方接入客户端。读完本文你将掌握该客户端的访问路径、完整方法签名、底层 HTTP 端点与数据格式protobuf/JSON、原始响应与错误处理机制并能将其与后端OpenTelemetryResource实现相互印证形成从 SDK 调用到服务端落地的完整认知。客户端定位REST API 集成类客户端Opik Python SDK 将底层 HTTP 接口封装为一组资源客户端统一挂载在rest_client属性下。OpenTelemetry Ingestion Client 归属于其中的「Integration Clients集成类客户端」分组与 chat completions、guardrails、redirect 等客户端并列职责是支持与外部系统集成聊天补全 API、OpenTelemetry 数据摄入、内容校验与 URL 重定向见 REST API 客户端索引。通过opik.Opik()实例即可拿到该客户端import opik client opik.Opik() otel_client client.rest_client.open_telemetry_ingestionREST 客户端总入口定义于 rest_api/client.py其中聚合了open_telemetry_ingestion等全部子客户端每个子客户端由 Fern 依据 OpenAPI 定义openapi.yaml自动生成因此 Python 与 TypeScript 两个 SDK 的接口形状保持一致。客户端方法与 API 形态文档页通过 Sphinxautoclass指令完整渲染opik.rest_api.open_telemetry_ingestion.client.OpenTelemetryIngestionClient的全部成员含继承成员排除with_raw_response的重复展示。对照当前源码 client.py该客户端提供以下能力receive_protobuf_traces(request_optionsNone)核心摄入方法向 Opik 的私有 OTel 端点发起 POST 请求返回默认响应typing.Optional[typing.Any]。with_raw_response属性返回原始实现RawOpenTelemetryIngestionClient或异步版本AsyncRawOpenTelemetryIngestionClient此时方法返回的是HttpResponse包装对象包含原始 HTTP 响应与解析后的 data便于读取状态码、响应头等信息。同步/异步双形态OpenTelemetryIngestionClient与AsyncOpenTelemetryIngestionClient成对出现。异步版用法示例直接来自源码 docstringfrom opik import AsyncOpikApi import asyncio client AsyncOpikApi(api_keyYOUR_API_KEY, workspace_nameYOUR_WORKSPACE_NAME) async def main() - None: await client.open_telemetry_ingestion.receive_protobuf_traces() asyncio.run(main())每个方法均接受关键字参数request_options: Optional[RequestOptions]用于请求级配置如自定义 headers、超时等请求特定选项。说明文档页的 Usage Example 中还展示了ingest_traces(traces_data...)与ingest_logs(logs_datalogs_payload)两个调用示例分别摄入 OTel traces 与 logs 数据。从当前源码结构看自动生成的客户端目前暴露的方法为receive_protobuf_traces即直接对接 OTLP 端点的原始请求路径文档中的示例体现的是该客户端摄入 traces / logs 数据的整体用途定位。实际接入时建议以当前版本autoclass渲染出的方法签名为准。底层端点POSTv1/private/otel/v1/traces从 raw_client.py 可以看到receive_protobuf_traces最终执行的请求为_response self._client_wrapper.httpx_client.request( v1/private/otel/v1/traces, methodPOST, request_optionsrequest_options, )即对私有路径v1/private/otel/v1/traces的 POST 调用。该路径与后端 Java 服务中的资源类一一对应OpenTelemetryResource.java 声明了Path(/v1/private/otel/v1)其下的/traces子资源同时提供了两个POST实现——一个Consumes(application/x-protobuf)、另一个Consumes(MediaType.APPLICATION_JSON)。从源码结构看服务端能同时接受OTLP/HTTP protobufOpenTelemetry SDK 默认导出的二进制格式与OTLP/JSON两种载荷这正是receive_protobuf_traces命名的来源也解释了为什么 OpenTelemetry 各语言 SDKPython/JS/Ruby 等的 OTLP exporter 可以直接把OTEL_EXPORTER_OTLP_ENDPOINT指向 Opik 完成遥测上报。OpenAPI 定义中该路径同样注册在/v1/private/otel/v1/traces第 5561 行附近是 Fern 生成双端 SDK 的唯一事实来源。TypeScript SDK 中的同名实现 Client.ts 注释明确写道 Resource to ingest Traces and Spans via OpenTelemetry其receiveProtobufTraces()方法与 Python 版逐字段对应同样拼接v1/private/otel/v1/traces、同样使用 POST并支持baseUrl/environment解析、timeoutInSeconds默认 60 秒、maxRetries、Comet-Workspace头合并等行为。请求配置RequestOptions 的透传链路request_options参数贯穿高层客户端 → 原始客户端 → HTTP 包装器的完整调用链高层OpenTelemetryIngestionClient.receive_protobuf_traces将其原样透传给RawOpenTelemetryIngestionClient原始客户端再交给client_wrapper.httpx_client.request(..., request_optionsrequest_options)统一处理。结合 TypeScript 对应实现可见RequestOptions的典型语义包括请求头合并客户端级 headers 与请求级 headers 叠加、timeoutInSeconds超时控制、maxRetries重试次数、以及按 workspace 维度注入的Comet-Workspace标识。Python 侧的RequestOptionsopik.rest_api.core.request_options承担相同职责为高级场景自定义 header、调整超时/重试提供了统一的逃生舱口。响应解析与错误处理原始客户端对响应的处理逻辑值得逐行理解raw_client.py2xx 成功分支200 status_code 300时用parse_obj_as(Optional[Any], _response.json())将 JSON 体解析为data并封装进HttpResponse(response..., data...)返回。高层方法只取_response.data因此调用方拿到的是已解析的响应体。非 2xx 分支抛出ApiError携带status_code、headers与bodyJSON 可解析时为解析后的对象否则为原始文本。JSON 解析失败捕获JSONDecodeError后同样抛出ApiErrorbody 退化为_response.text避免二次异常掩盖真实错误。这种成功返回 data、失败抛带上下文的 ApiError的模式是该 REST API 层所有客户端的统一约定便于在批量摄入 OTel 数据时做统一的重试与告警封装。文档示例与验证路径文档给出的使用示例open_telemetry_ingestion.rstimport opik client opik.Opik() # Ingest OpenTelemetry traces data client.rest_client.open_telemetry_ingestion.ingest_traces( traces_datatraces_payload ) # Ingest OpenTelemetry logs data client.rest_client.open_telemetry_ingestion.ingest_logs( logs_datalogs_payload )其核心用法模式opik.Opik()初始化 →rest_client取子客户端 → 调用摄入方法与当前源码完全一致。验证该链路的测试资产也已在仓库中就位Python SDK 端到端集成测试 test_otel_distributed_trace.py通过真实 OTLP 上报指向v1/private/otel前缀端点验证分布式 trace 的完整落库链路后端资源单测 OpenTelemetryResourceTest.java直接针对服务端OpenTelemetryResource的接收与解析行为做断言。两端测试共同保证了SDK 客户端 → 私有 OTel 端点 → 后端资源这条摄入链路的行为一致性。小结Opik 的 OpenTelemetry Ingestion Client 是 Python SDK REST API 层中专责 OTel 遥测接入的集成客户端它通过rest_client.open_telemetry_ingestion暴露提供同步/异步成对的receive_protobuf_traces方法与with_raw_response原始响应访问底层统一 POST 到v1/private/otel/v1/traces与服务端OpenTelemetryResource的 protobuf/JSON 双格式接收端点精确对应。对于已经使用 OpenTelemetry 生态的应用无论是通过 OTLP exporter 直连还是通过该客户端以编程方式转发遥测载荷都能获得统一的请求配置、响应解析与ApiError错误语义是打通现有 OTel 埋点 → Opik 可观测平台的关键接入面。【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Opik OpenTelemetry Ingestion Client：通过 Python SDK 将 OTLP 遥测数据接入 Opik 平台
Opik OpenTelemetry Ingestion Client通过 Python SDK 将 OTLP 遥测数据接入 Opik 平台【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llm本篇技术指南聚焦 Opik Python SDK REST API 中的 OpenTelemetry Ingestion Client文档源文件它是 Opik 平台用于接收 OpenTelemetryOTLP遥测数据的官方接入客户端。读完本文你将掌握该客户端的访问路径、完整方法签名、底层 HTTP 端点与数据格式protobuf/JSON、原始响应与错误处理机制并能将其与后端OpenTelemetryResource实现相互印证形成从 SDK 调用到服务端落地的完整认知。客户端定位REST API 集成类客户端Opik Python SDK 将底层 HTTP 接口封装为一组资源客户端统一挂载在rest_client属性下。OpenTelemetry Ingestion Client 归属于其中的「Integration Clients集成类客户端」分组与 chat completions、guardrails、redirect 等客户端并列职责是支持与外部系统集成聊天补全 API、OpenTelemetry 数据摄入、内容校验与 URL 重定向见 REST API 客户端索引。通过opik.Opik()实例即可拿到该客户端import opik client opik.Opik() otel_client client.rest_client.open_telemetry_ingestionREST 客户端总入口定义于 rest_api/client.py其中聚合了open_telemetry_ingestion等全部子客户端每个子客户端由 Fern 依据 OpenAPI 定义openapi.yaml自动生成因此 Python 与 TypeScript 两个 SDK 的接口形状保持一致。客户端方法与 API 形态文档页通过 Sphinxautoclass指令完整渲染opik.rest_api.open_telemetry_ingestion.client.OpenTelemetryIngestionClient的全部成员含继承成员排除with_raw_response的重复展示。对照当前源码 client.py该客户端提供以下能力receive_protobuf_traces(request_optionsNone)核心摄入方法向 Opik 的私有 OTel 端点发起 POST 请求返回默认响应typing.Optional[typing.Any]。with_raw_response属性返回原始实现RawOpenTelemetryIngestionClient或异步版本AsyncRawOpenTelemetryIngestionClient此时方法返回的是HttpResponse包装对象包含原始 HTTP 响应与解析后的 data便于读取状态码、响应头等信息。同步/异步双形态OpenTelemetryIngestionClient与AsyncOpenTelemetryIngestionClient成对出现。异步版用法示例直接来自源码 docstringfrom opik import AsyncOpikApi import asyncio client AsyncOpikApi(api_keyYOUR_API_KEY, workspace_nameYOUR_WORKSPACE_NAME) async def main() - None: await client.open_telemetry_ingestion.receive_protobuf_traces() asyncio.run(main())每个方法均接受关键字参数request_options: Optional[RequestOptions]用于请求级配置如自定义 headers、超时等请求特定选项。说明文档页的 Usage Example 中还展示了ingest_traces(traces_data...)与ingest_logs(logs_datalogs_payload)两个调用示例分别摄入 OTel traces 与 logs 数据。从当前源码结构看自动生成的客户端目前暴露的方法为receive_protobuf_traces即直接对接 OTLP 端点的原始请求路径文档中的示例体现的是该客户端摄入 traces / logs 数据的整体用途定位。实际接入时建议以当前版本autoclass渲染出的方法签名为准。底层端点POSTv1/private/otel/v1/traces从 raw_client.py 可以看到receive_protobuf_traces最终执行的请求为_response self._client_wrapper.httpx_client.request( v1/private/otel/v1/traces, methodPOST, request_optionsrequest_options, )即对私有路径v1/private/otel/v1/traces的 POST 调用。该路径与后端 Java 服务中的资源类一一对应OpenTelemetryResource.java 声明了Path(/v1/private/otel/v1)其下的/traces子资源同时提供了两个POST实现——一个Consumes(application/x-protobuf)、另一个Consumes(MediaType.APPLICATION_JSON)。从源码结构看服务端能同时接受OTLP/HTTP protobufOpenTelemetry SDK 默认导出的二进制格式与OTLP/JSON两种载荷这正是receive_protobuf_traces命名的来源也解释了为什么 OpenTelemetry 各语言 SDKPython/JS/Ruby 等的 OTLP exporter 可以直接把OTEL_EXPORTER_OTLP_ENDPOINT指向 Opik 完成遥测上报。OpenAPI 定义中该路径同样注册在/v1/private/otel/v1/traces第 5561 行附近是 Fern 生成双端 SDK 的唯一事实来源。TypeScript SDK 中的同名实现 Client.ts 注释明确写道 Resource to ingest Traces and Spans via OpenTelemetry其receiveProtobufTraces()方法与 Python 版逐字段对应同样拼接v1/private/otel/v1/traces、同样使用 POST并支持baseUrl/environment解析、timeoutInSeconds默认 60 秒、maxRetries、Comet-Workspace头合并等行为。请求配置RequestOptions 的透传链路request_options参数贯穿高层客户端 → 原始客户端 → HTTP 包装器的完整调用链高层OpenTelemetryIngestionClient.receive_protobuf_traces将其原样透传给RawOpenTelemetryIngestionClient原始客户端再交给client_wrapper.httpx_client.request(..., request_optionsrequest_options)统一处理。结合 TypeScript 对应实现可见RequestOptions的典型语义包括请求头合并客户端级 headers 与请求级 headers 叠加、timeoutInSeconds超时控制、maxRetries重试次数、以及按 workspace 维度注入的Comet-Workspace标识。Python 侧的RequestOptionsopik.rest_api.core.request_options承担相同职责为高级场景自定义 header、调整超时/重试提供了统一的逃生舱口。响应解析与错误处理原始客户端对响应的处理逻辑值得逐行理解raw_client.py2xx 成功分支200 status_code 300时用parse_obj_as(Optional[Any], _response.json())将 JSON 体解析为data并封装进HttpResponse(response..., data...)返回。高层方法只取_response.data因此调用方拿到的是已解析的响应体。非 2xx 分支抛出ApiError携带status_code、headers与bodyJSON 可解析时为解析后的对象否则为原始文本。JSON 解析失败捕获JSONDecodeError后同样抛出ApiErrorbody 退化为_response.text避免二次异常掩盖真实错误。这种成功返回 data、失败抛带上下文的 ApiError的模式是该 REST API 层所有客户端的统一约定便于在批量摄入 OTel 数据时做统一的重试与告警封装。文档示例与验证路径文档给出的使用示例open_telemetry_ingestion.rstimport opik client opik.Opik() # Ingest OpenTelemetry traces data client.rest_client.open_telemetry_ingestion.ingest_traces( traces_datatraces_payload ) # Ingest OpenTelemetry logs data client.rest_client.open_telemetry_ingestion.ingest_logs( logs_datalogs_payload )其核心用法模式opik.Opik()初始化 →rest_client取子客户端 → 调用摄入方法与当前源码完全一致。验证该链路的测试资产也已在仓库中就位Python SDK 端到端集成测试 test_otel_distributed_trace.py通过真实 OTLP 上报指向v1/private/otel前缀端点验证分布式 trace 的完整落库链路后端资源单测 OpenTelemetryResourceTest.java直接针对服务端OpenTelemetryResource的接收与解析行为做断言。两端测试共同保证了SDK 客户端 → 私有 OTel 端点 → 后端资源这条摄入链路的行为一致性。小结Opik 的 OpenTelemetry Ingestion Client 是 Python SDK REST API 层中专责 OTel 遥测接入的集成客户端它通过rest_client.open_telemetry_ingestion暴露提供同步/异步成对的receive_protobuf_traces方法与with_raw_response原始响应访问底层统一 POST 到v1/private/otel/v1/traces与服务端OpenTelemetryResource的 protobuf/JSON 双格式接收端点精确对应。对于已经使用 OpenTelemetry 生态的应用无论是通过 OTLP exporter 直连还是通过该客户端以编程方式转发遥测载荷都能获得统一的请求配置、响应解析与ApiError错误语义是打通现有 OTel 埋点 → Opik 可观测平台的关键接入面。【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考