尧图网页设计 
使用 OneUptime 接入 OpenTelemetry日志、指标与链路追踪的完整集成指南【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本指南以 OneUptime 官方文档为基础完整讲解如何通过 OpenTelemetryOTel标准将应用程序的日志Logs、指标Metrics和链路追踪Traces接入 OneUptime 平台覆盖 Telemetry Ingestion Token 的创建、OTLP 环境变量配置、OpenTelemetry Collector 转发以及日志中异常Exception自动提取为问题Issue的高级特性。读完本文你将掌握从零配置到生产级 Collector 转发的全套接入方案并能结合源码理解 OneUptime 的 OTLP 摄取Ingest链路原理。接入总览OneUptime 的 OTLP 摄取链路OneUptime 的 Telemetry遥测子系统是一个完整的 OpenTelemetry 后端实现。从 OTelIngest.ts 的源码可以看到平台暴露了标准的 OTLP HTTP 端点POST /otlp/v1/traces— 摄取链路追踪数据POST /otlp/v1/metrics— 摄取指标数据POST /otlp/v1/logs— 摄取日志数据POST /otlp/v1/profiles— 摄取性能剖析Profiles数据每条摄取请求都会依次经过TelemetryIngestionDisabled功能开关、parseBody请求体解析、摄取度量中间件、产品类型识别getProductType以及TelemetryIngestIngestion Key 鉴权等中间件最终由对应的 Ingest Service如 OtelLogsIngestService.ts处理后写入消息队列与存储。正因为 OneUptime 实现了标准 OTLP 协议任何支持 OpenTelemetry 的语言 SDK 或 Collector 都可以无缝对接无需使用专有 SDK。第一步创建 Telemetry Ingestion Token接入的第一步是在 OneUptime 中创建 Telemetry Ingestion Key遥测摄取密钥它是平台识别并隔离不同项目遥测数据的凭据。注册并登录 OneUptime创建一个项目Project点击导航栏中的Products进入Project Settings项目设置打开Telemetry Ingestion Key页面点击Create Ingestion Key创建摄取密钥生成一个 Token创建成功后点击View即可查看完整的 Token 字符串。该 Token 本质上是 122 位随机 UUID只能通过 HTTP 请求头而非查询字符串传递避免泄漏到访问日志中。在 OTelIngest.ts 中还提供了一个无需写入任何数据的校验端点GET /otlp/v1/validate只要在请求头中携带x-oneuptime-token即可获得类似{ valid: true, projectId, keyType, isEnabled, isExpired }的 JSON 响应用于安装脚本或运维人员在正式上报前验证 Token 是否被接受避免数据静默丢失。第二步在应用中配置 Telemetry 服务OneUptime 使用 OpenTelemetry 标准收集应用日志目前支持以下语言 SDK 的日志/指标/Trace 摄取。请按各自官方文档完成 SDK 的初始化配置COpenTelemetry C 插桩GoJavaJavaScript / TypeScript / Node.js / BrowserPythonRubyPHPErlangRust.NET / C#Swift通过环境变量与 OneUptime 集成在应用内完成 OpenTelemetry SDK 配置后只需设置以下三个标准 OTLP 环境变量即可将数据转发到 OneUptime环境变量值OTEL_EXPORTER_OTLP_HEADERSx-oneuptime-tokenYOUR_ONEUPTIME_SERVICE_TOKENOTEL_EXPORTER_OTLP_ENDPOINThttps://oneuptime.com/otlpOTEL_SERVICE_NAMENAME_OF_YOUR_SERVICE各变量说明OTEL_EXPORTER_OTLP_HEADERS向 OneUptime 上报时携带的鉴权请求头值即第一步创建的 Ingestion Token。这是平台识别项目归属的唯一凭据OTEL_EXPORTER_OTLP_ENDPOINTOTLP 导出端点。云端版使用https://oneuptime.com/otlpSDK 会自动在该端点后追加/v1/logs、/v1/traces、/v1/metrics等路径OTEL_SERVICE_NAME服务名用于在 OneUptime 的 Telemetry 服务列表中标识你的应用最终会写入日志、Trace 的service.name资源属性。示例Bashexport OTEL_EXPORTER_OTLP_HEADERSx-oneuptime-token9c8806e0-a4aa-11ee-be95-010d5967b068 export OTEL_EXPORTER_OTLP_ENDPOINThttps://oneuptime.com/otlp export OTEL_SERVICE_NAMEmy-service配置完成后运行应用即可在 OneUptime 的 Telemetry 服务页面实时看到日志、指标与 Trace 数据。若上报失败可以先通过上文提到的/otlp/v1/validate端点快速定位 Token 问题。自托管Self-Hosted场景如果你自行部署 OneUptime请将端点改为自己实例的 OTLP 入口地址http(s)://YOUR-ONEUPTIME-HOST/otlp自托管实例同样走标准的 OTLP HTTP 协议其余环境变量保持不变。需要注意自托管模式下受网络与实例规格影响上报吞吐取决于部署的 Nginx 与 Ingest 服务配置。方案二使用 OpenTelemetry Collector 集中转发除应用直连外OneUptime 也支持通过 OpenTelemetry Collector 作为统一采集与转发网关。该方案适合多语言、多主机、Kubernetes 等需要集中式采集的生产环境应用先把数据发到本地 CollectorCollector 再批量转发给 OneUptime。在 Collector 的配置文件中配置 OneUptime 导出器即可完整示例receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 exporters: # 通过 HTTP 导出 otlphttp: endpoint: https://oneuptime.com/otlp # 必须使用 JSON 编码器而非默认的 Proto(buf) encoding: json headers: Content-Type: application/json x-oneuptime-token: ONEUPTIME_TOKEN # 你的 OneUptime Token service: pipelines: traces: receivers: [otlp] exporters: [otlphttp] metrics: receivers: [otlp] exporters: [otlphttp] logs: receivers: [otlp] exporters: [otlphttp]配置要点otlpreceiver同时监听 gRPC4317端口与 HTTP4318端口用于接收本地应用的 OTLP 数据otlphttpexporter将数据转发到 OneUptime 的/otlp端点。必须设置encoding: json因为 OneUptime 的 HTTP 摄取端点按 JSON 编码处理源码中getProductType中间件会根据Content-Type判断是否 protobuf见 OtelRequestMiddleware.tsheaders携带鉴权 Token与直连方案完全一致service.pipelines为 traces、metrics、logs 三条管道分别串联 receiver 与 exporter确保三类遥测数据都被转发。如果你的应用已经通过 Collector 集中采集了原始 stdout、syslog、journald 等明文日志建议在 Collector 侧开启多行日志合并multiline recombination具体可参考 Host OpenTelemetry Collector 指南。从日志自动提取异常ExceptionOneUptime 会自动检测日志中的异常并将其归入与 Trace 错误相同的ExceptionsIssues视图。由于每条日志都能关联到具体的服务Service或主机Host从日志提取的异常会被正确归属到对应资源并且与 Trace 上报的异常共用同一套指纹Fingerprint分组——这意味着同一个错误无论是通过 Trace 还是日志上报最终都会收敛为同一条 Issue。异常检测有两条路径显式异常属性推荐日志记录携带 OpenTelemetry 标准的exception.type、exception.message或exception.stacktrace属性时会被直接转换为异常。大多数主流日志集成Logback/Log4j appender、Serilog、Python logging 插桩等在记录异常时都会自动写入这些属性这种方式精确且与语言无关日志正文中的堆栈跟踪对于不带上述属性的 error/fatal 级别日志如原始 stdout、syslog、journaldOneUptime 会扫描日志正文识别 JavaScript、Python、Java、Go、Ruby、C#/.NET、PHP 等语言的堆栈跟踪并提取异常类型、消息与调用帧。注意多行堆栈必须作为单条日志记录到达如果采集的是纯文本日志请务必在 Collector 侧开启多行合并。该功能默认开启。自托管 OneUptime 可通过在 Ingest 服务上设置以下环境变量关闭TELEMETRY_LOG_EXCEPTION_EXTRACTION_ENABLEDfalse从源码看该开关在 Config.ts 中定义当环境变量不为false时即为开启并在 OtelLogsIngestService.ts 的日志处理热路径上生效。异常分组与去重原理源码级日志与 Trace 中提取的异常之所以能合并为同一条 Issue关键在于指纹Fingerprint机制。在 Exception.ts 中ExceptionUtil.getFingerprint()会先对异常消息与堆栈跟踪做规范化处理将 ID、时间戳等动态值替换为占位符实现位于Common/Server/Utils/Telemetry/ExceptionSanitizer.ts再以projectId primaryEntityId 规范化消息 规范化堆栈 异常类型拼接后计算 SHA-256 哈希作为指纹。相同根因的异常即便动态值不同也会得到相同的指纹从而被聚合到同一条 Issue 上。数据写入时采用批量 Upsert 策略按(projectId, primaryEntityId, fingerprint)聚合后以 500 行为一批执行INSERT ... ON CONFLICT DO UPDATE原子性地累加occuranceCount、合并firstSeenAt/lastSeenAt并且新的出现会自动将已标记为 resolved 的 Issue 重新打开。这套实现既避免了并发写入丢失计数也防止了乱序投递导致时间戳回退。摄取链路的实现细节与限制理解底层摄取链路有助于排查线上问题。以日志为例OTelIngest.ts 中的POST /otlp/v1/logs路由会依次执行TelemetryIngestionDisabled全局摄取开关用于紧急熔断parseBody读取请求体为原始 Buffer。该中间件见 OtelRequestMiddleware.ts设置了50 MiBMAX_OTLP_REQUEST_BYTES的请求体上限超限直接返回413 payload-too-large按 OTLP 规范 4xx 不会被重试避免错误配置导致重试风暴。解码gunzip protobuf被延迟到后台 Worker 执行避免阻塞 HTTP 事件循环摄取度量中间件按信号类型记录请求量、耗时与负载字节数getProductType根据 URL 识别 traces/metrics/logs/profiles 信号类型TelemetryIngest校验x-oneuptime-token认证失败返回 401非可重试错误Ingest Service解析并格式化数据后写入对应的队列如LogsQueueService由 Worker 批量落库。因此接入时若发现数据迟迟不出现可按以下顺序排查Token 是否正确用/otlp/v1/validate验证→ 端点地址是否为/otlp→ Collector 是否设置了encoding: json→ 单次请求是否超过 50 MiB。小结将 OpenTelemetry 接入 OneUptime 只需两步先在项目设置中创建 Telemetry Ingestion Token再为应用设置OTEL_EXPORTER_OTLP_HEADERS、OTEL_EXPORTER_OTLP_ENDPOINT、OTEL_SERVICE_NAME三个环境变量生产环境可进一步通过 OpenTelemetry Collector 集中转发并利用日志异常自动提取能力让 Trace 与日志中的错误在 Exceptions 视图统一收敛。以上所有端点、环境变量与源码实现均可在仓库中直接查阅验证摄取入口见 OTelIngest.ts日志摄取实现见 OtelLogsIngestService.ts异常指纹与聚合逻辑见 Exception.ts原始文档见 open-telemetry.md。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 OneUptime 接入 OpenTelemetry：日志、指标与链路追踪的完整集成指南
使用 OneUptime 接入 OpenTelemetry日志、指标与链路追踪的完整集成指南【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本指南以 OneUptime 官方文档为基础完整讲解如何通过 OpenTelemetryOTel标准将应用程序的日志Logs、指标Metrics和链路追踪Traces接入 OneUptime 平台覆盖 Telemetry Ingestion Token 的创建、OTLP 环境变量配置、OpenTelemetry Collector 转发以及日志中异常Exception自动提取为问题Issue的高级特性。读完本文你将掌握从零配置到生产级 Collector 转发的全套接入方案并能结合源码理解 OneUptime 的 OTLP 摄取Ingest链路原理。接入总览OneUptime 的 OTLP 摄取链路OneUptime 的 Telemetry遥测子系统是一个完整的 OpenTelemetry 后端实现。从 OTelIngest.ts 的源码可以看到平台暴露了标准的 OTLP HTTP 端点POST /otlp/v1/traces— 摄取链路追踪数据POST /otlp/v1/metrics— 摄取指标数据POST /otlp/v1/logs— 摄取日志数据POST /otlp/v1/profiles— 摄取性能剖析Profiles数据每条摄取请求都会依次经过TelemetryIngestionDisabled功能开关、parseBody请求体解析、摄取度量中间件、产品类型识别getProductType以及TelemetryIngestIngestion Key 鉴权等中间件最终由对应的 Ingest Service如 OtelLogsIngestService.ts处理后写入消息队列与存储。正因为 OneUptime 实现了标准 OTLP 协议任何支持 OpenTelemetry 的语言 SDK 或 Collector 都可以无缝对接无需使用专有 SDK。第一步创建 Telemetry Ingestion Token接入的第一步是在 OneUptime 中创建 Telemetry Ingestion Key遥测摄取密钥它是平台识别并隔离不同项目遥测数据的凭据。注册并登录 OneUptime创建一个项目Project点击导航栏中的Products进入Project Settings项目设置打开Telemetry Ingestion Key页面点击Create Ingestion Key创建摄取密钥生成一个 Token创建成功后点击View即可查看完整的 Token 字符串。该 Token 本质上是 122 位随机 UUID只能通过 HTTP 请求头而非查询字符串传递避免泄漏到访问日志中。在 OTelIngest.ts 中还提供了一个无需写入任何数据的校验端点GET /otlp/v1/validate只要在请求头中携带x-oneuptime-token即可获得类似{ valid: true, projectId, keyType, isEnabled, isExpired }的 JSON 响应用于安装脚本或运维人员在正式上报前验证 Token 是否被接受避免数据静默丢失。第二步在应用中配置 Telemetry 服务OneUptime 使用 OpenTelemetry 标准收集应用日志目前支持以下语言 SDK 的日志/指标/Trace 摄取。请按各自官方文档完成 SDK 的初始化配置COpenTelemetry C 插桩GoJavaJavaScript / TypeScript / Node.js / BrowserPythonRubyPHPErlangRust.NET / C#Swift通过环境变量与 OneUptime 集成在应用内完成 OpenTelemetry SDK 配置后只需设置以下三个标准 OTLP 环境变量即可将数据转发到 OneUptime环境变量值OTEL_EXPORTER_OTLP_HEADERSx-oneuptime-tokenYOUR_ONEUPTIME_SERVICE_TOKENOTEL_EXPORTER_OTLP_ENDPOINThttps://oneuptime.com/otlpOTEL_SERVICE_NAMENAME_OF_YOUR_SERVICE各变量说明OTEL_EXPORTER_OTLP_HEADERS向 OneUptime 上报时携带的鉴权请求头值即第一步创建的 Ingestion Token。这是平台识别项目归属的唯一凭据OTEL_EXPORTER_OTLP_ENDPOINTOTLP 导出端点。云端版使用https://oneuptime.com/otlpSDK 会自动在该端点后追加/v1/logs、/v1/traces、/v1/metrics等路径OTEL_SERVICE_NAME服务名用于在 OneUptime 的 Telemetry 服务列表中标识你的应用最终会写入日志、Trace 的service.name资源属性。示例Bashexport OTEL_EXPORTER_OTLP_HEADERSx-oneuptime-token9c8806e0-a4aa-11ee-be95-010d5967b068 export OTEL_EXPORTER_OTLP_ENDPOINThttps://oneuptime.com/otlp export OTEL_SERVICE_NAMEmy-service配置完成后运行应用即可在 OneUptime 的 Telemetry 服务页面实时看到日志、指标与 Trace 数据。若上报失败可以先通过上文提到的/otlp/v1/validate端点快速定位 Token 问题。自托管Self-Hosted场景如果你自行部署 OneUptime请将端点改为自己实例的 OTLP 入口地址http(s)://YOUR-ONEUPTIME-HOST/otlp自托管实例同样走标准的 OTLP HTTP 协议其余环境变量保持不变。需要注意自托管模式下受网络与实例规格影响上报吞吐取决于部署的 Nginx 与 Ingest 服务配置。方案二使用 OpenTelemetry Collector 集中转发除应用直连外OneUptime 也支持通过 OpenTelemetry Collector 作为统一采集与转发网关。该方案适合多语言、多主机、Kubernetes 等需要集中式采集的生产环境应用先把数据发到本地 CollectorCollector 再批量转发给 OneUptime。在 Collector 的配置文件中配置 OneUptime 导出器即可完整示例receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 exporters: # 通过 HTTP 导出 otlphttp: endpoint: https://oneuptime.com/otlp # 必须使用 JSON 编码器而非默认的 Proto(buf) encoding: json headers: Content-Type: application/json x-oneuptime-token: ONEUPTIME_TOKEN # 你的 OneUptime Token service: pipelines: traces: receivers: [otlp] exporters: [otlphttp] metrics: receivers: [otlp] exporters: [otlphttp] logs: receivers: [otlp] exporters: [otlphttp]配置要点otlpreceiver同时监听 gRPC4317端口与 HTTP4318端口用于接收本地应用的 OTLP 数据otlphttpexporter将数据转发到 OneUptime 的/otlp端点。必须设置encoding: json因为 OneUptime 的 HTTP 摄取端点按 JSON 编码处理源码中getProductType中间件会根据Content-Type判断是否 protobuf见 OtelRequestMiddleware.tsheaders携带鉴权 Token与直连方案完全一致service.pipelines为 traces、metrics、logs 三条管道分别串联 receiver 与 exporter确保三类遥测数据都被转发。如果你的应用已经通过 Collector 集中采集了原始 stdout、syslog、journald 等明文日志建议在 Collector 侧开启多行日志合并multiline recombination具体可参考 Host OpenTelemetry Collector 指南。从日志自动提取异常ExceptionOneUptime 会自动检测日志中的异常并将其归入与 Trace 错误相同的ExceptionsIssues视图。由于每条日志都能关联到具体的服务Service或主机Host从日志提取的异常会被正确归属到对应资源并且与 Trace 上报的异常共用同一套指纹Fingerprint分组——这意味着同一个错误无论是通过 Trace 还是日志上报最终都会收敛为同一条 Issue。异常检测有两条路径显式异常属性推荐日志记录携带 OpenTelemetry 标准的exception.type、exception.message或exception.stacktrace属性时会被直接转换为异常。大多数主流日志集成Logback/Log4j appender、Serilog、Python logging 插桩等在记录异常时都会自动写入这些属性这种方式精确且与语言无关日志正文中的堆栈跟踪对于不带上述属性的 error/fatal 级别日志如原始 stdout、syslog、journaldOneUptime 会扫描日志正文识别 JavaScript、Python、Java、Go、Ruby、C#/.NET、PHP 等语言的堆栈跟踪并提取异常类型、消息与调用帧。注意多行堆栈必须作为单条日志记录到达如果采集的是纯文本日志请务必在 Collector 侧开启多行合并。该功能默认开启。自托管 OneUptime 可通过在 Ingest 服务上设置以下环境变量关闭TELEMETRY_LOG_EXCEPTION_EXTRACTION_ENABLEDfalse从源码看该开关在 Config.ts 中定义当环境变量不为false时即为开启并在 OtelLogsIngestService.ts 的日志处理热路径上生效。异常分组与去重原理源码级日志与 Trace 中提取的异常之所以能合并为同一条 Issue关键在于指纹Fingerprint机制。在 Exception.ts 中ExceptionUtil.getFingerprint()会先对异常消息与堆栈跟踪做规范化处理将 ID、时间戳等动态值替换为占位符实现位于Common/Server/Utils/Telemetry/ExceptionSanitizer.ts再以projectId primaryEntityId 规范化消息 规范化堆栈 异常类型拼接后计算 SHA-256 哈希作为指纹。相同根因的异常即便动态值不同也会得到相同的指纹从而被聚合到同一条 Issue 上。数据写入时采用批量 Upsert 策略按(projectId, primaryEntityId, fingerprint)聚合后以 500 行为一批执行INSERT ... ON CONFLICT DO UPDATE原子性地累加occuranceCount、合并firstSeenAt/lastSeenAt并且新的出现会自动将已标记为 resolved 的 Issue 重新打开。这套实现既避免了并发写入丢失计数也防止了乱序投递导致时间戳回退。摄取链路的实现细节与限制理解底层摄取链路有助于排查线上问题。以日志为例OTelIngest.ts 中的POST /otlp/v1/logs路由会依次执行TelemetryIngestionDisabled全局摄取开关用于紧急熔断parseBody读取请求体为原始 Buffer。该中间件见 OtelRequestMiddleware.ts设置了50 MiBMAX_OTLP_REQUEST_BYTES的请求体上限超限直接返回413 payload-too-large按 OTLP 规范 4xx 不会被重试避免错误配置导致重试风暴。解码gunzip protobuf被延迟到后台 Worker 执行避免阻塞 HTTP 事件循环摄取度量中间件按信号类型记录请求量、耗时与负载字节数getProductType根据 URL 识别 traces/metrics/logs/profiles 信号类型TelemetryIngest校验x-oneuptime-token认证失败返回 401非可重试错误Ingest Service解析并格式化数据后写入对应的队列如LogsQueueService由 Worker 批量落库。因此接入时若发现数据迟迟不出现可按以下顺序排查Token 是否正确用/otlp/v1/validate验证→ 端点地址是否为/otlp→ Collector 是否设置了encoding: json→ 单次请求是否超过 50 MiB。小结将 OpenTelemetry 接入 OneUptime 只需两步先在项目设置中创建 Telemetry Ingestion Token再为应用设置OTEL_EXPORTER_OTLP_HEADERS、OTEL_EXPORTER_OTLP_ENDPOINT、OTEL_SERVICE_NAME三个环境变量生产环境可进一步通过 OpenTelemetry Collector 集中转发并利用日志异常自动提取能力让 Trace 与日志中的错误在 Exceptions 视图统一收敛。以上所有端点、环境变量与源码实现均可在仓库中直接查阅验证摄取入口见 OTelIngest.ts日志摄取实现见 OtelLogsIngestService.ts异常指纹与聚合逻辑见 Exception.ts原始文档见 open-telemetry.md。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考