使用 Fluent Bit 将日志与遥测数据接入 OneUptimeOTLP HTTP Collector 完整配置指南【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime导读本文讲解如何在 OneUptime 项目中使用 Fluent Bit 的 OpenTelemetry 输出插件把来自应用与服务的日志、指标Metrics和链路追踪Traces数据统一发送到 OneUptime 的 OpenTelemetry HTTP CollectorOTLP/HTTP 接收端并在 OneUptime Dashboard 中直接查看。读完本文你将掌握遥测摄取令牌Telemetry Ingestion Token的创建方法、Fluent Bit 的 outputs 与 inputs 配置要点、service.name资源属性的注入方式以及自托管 OneUptime 时的参数调整方法。本文主体内容来自仓库文档 App/FeatureSet/Docs/Content/de/telemetry/fluentbit.md并结合仓库中 Fluent Bit 模块与 Telemetry 服务端源码进行印证与扩展。一、方案概览Fluent Bit → OneUptime OTLP CollectorOneUptime 的服务端实现了标准的 OpenTelemetry 协议接收能力。从源码 App/FeatureSet/Telemetry/API/OTelIngest.ts 可以看到服务端注册了四条 OTLP/HTTP 摄取路由POST /otlp/v1/traces— 接收链路追踪数据POST /otlp/v1/metrics— 接收指标数据POST /otlp/v1/logs— 接收日志数据POST /otlp/v1/profiles— 接收 profiling性能剖析数据此外还提供POST /otlp/v1/validate用于校验摄取令牌是否有效详见 OTelIngest.ts。Fluent Bit 的opentelemetry输出插件正是以 OTLP/HTTP 协议、将这些端点作为目标地址发送数据的。因此整套链路为应用/基础设施日志 → Fluent Bitinput 插件收集 → opentelemetry 输出插件OTLP/HTTP携带 x-oneuptime-token → OneUptime OTLP HTTP Collector/otlp/v1/{logs,metrics,traces} → 写入后端存储 → OneUptime Dashboard 可视化Fluent Bit 支持的数据源Fluent Bit 原生支持数百种数据源几乎任何一种都可以通过上述链路接入 OneUptime。文档列举的常见来源包括Docker、Syslog、Apache、Nginx、MySQL、PostgreSQL、MongoDB、NodeJS、Ruby、Python、Java、PHP、Go、Rust 等等。这些数据源通过 Fluent Bit 的各类 input 插件如tail、syslog、docker等收集再统一进入同一套 OTLP 输出配置。二、前置准备四个步骤在配置 Fluent Bit 之前需要依次完成以下准备安装 Fluent Bit按 Fluent Bit 官方安装指引在你的系统上安装 Fluent Bit。注册 OneUptime 账号在 oneuptime.com 注册免费账号。注意账号本身免费但日志Log摄取属于付费功能。创建 OneUptime 项目登录后从 OneUptime Dashboard 创建项目。创建遥测摄取令牌Telemetry Ingestion Token用于向 OneUptime 摄取日志、指标和链路追踪数据。创建与查看遥测摄取令牌完成登录并创建项目后在导航栏点击「Products」产品然后进入「Project Settings」项目设置。在「Telemetry Ingestion Key」遥测摄取密钥页面点击「Create Ingestion Key」创建一个令牌创建完成后点击该密钥对应的「View」按钮即可查看令牌详情从密钥详情页可以看到该令牌的关键属性密钥类型Key Type分为仅用于服务器与采集器的Server类型、以及带来源校验的Browser类型、密钥值Secret Key可复制、状态Status、固定服务名称Pinned Service Name、每分钟请求限制Requests Per Minute Limit与过期时间等。令牌最终会以x-oneuptime-token请求头的形式随 OTLP 请求发送服务端 OTelIngest.ts 正是从该请求头中读取令牌并完成鉴权的。文档特别强调令牌应通过请求头发送不要放在查询字符串中以免泄漏到访问日志。三、核心配置outputs 部分Fluent Bit 的配置文件通常位于/etc/fluent-bit/fluent-bit.yaml。下面是一个 outputs 部分的示例outputs: - name: stdout match: * - name: opentelemetry match: * host: oneuptime.com port: 443 metrics_uri: /otlp/v1/metrics logs_uri: /otlp/v1/logs traces_uri: /otlp/v1/traces tls: On header: - x-oneuptime-token YOUR_TELEMETRY_INGESTION_TOKEN配置中有两个输出stdout用于本地调试将数据同时打印到控制台opentelemetry用于将数据发送到 OneUptime。各参数含义如下参数示例值说明nameopentelemetry使用 Fluent Bit 的 OpenTelemetry 输出插件match*匹配所有经过管道的数据流hostoneuptime.comOneUptime OTLP Collector 的主机地址自托管时替换为你的 OneUptime 实例地址port443HTTPS 默认端口自托管 HTTP 场景一般为80metrics_uri/otlp/v1/metrics指标摄取端点与服务端 OTelIngest.ts 注册的路由一致logs_uri/otlp/v1/logs日志摄取端点与服务端注册的/otlp/v1/logs路由一致traces_uri/otlp/v1/traces链路追踪摄取端点与服务端注册的/otlp/v1/traces路由一致tlsOn启用 TLS对oneuptime.com的 443 端口必须开启headerx-oneuptime-token TOKEN携带摄取令牌的自定义请求头用于服务端鉴权需要特别强调的是logs_uri、metrics_uri、traces_uri这三个路径必须与服务端实际注册的 OTLP 路由完全一致。仓库中 FluentBit/etc/fluent-bit.yaml 是随仓库提供的真实可用示例使用的正是/otlp/v1/metrics、/otlp/v1/logs、/otlp/v1/traces三个路径并且通过header同时注入了x-oneuptime-token与x-oneuptime-service-name两个请求头。四、配置 inputs注入 service.name 资源属性除了 outputs还需要在 inputs 部分保证日志携带正确的 OpenTelemetry 资源属性。文档要求确保 inputs 中存在opentelemetry_envelope处理器并推荐通过content_modifier处理器为每条日志注入service.name这样 OneUptime 就能按服务名对日志进行归类展示。inputs 部分示例pipeline: inputs: # 你的输入源 processors: logs: - name: opentelemetry_envelope - name: content_modifier context: otel_resource_attributes action: upsert key: service.name # 将 YOUR_SERVICE_NAME 替换为你的服务名 value: YOUR_SERVICE_NAME这里的两个处理器作用如下opentelemetry_envelope将 Fluent Bit 内部记录record包装为标准 OpenTelemetry 日志信封格式保证输出插件能够按 OTLP 规范序列化数据content_modifier以upsert动作把service.name写入otel_resource_attributes上下文相当于为日志打上服务标识。这与 OneUptime 服务端读取日志资源属性、按服务维度查询数据的实现是对应的——例如日志摄取服务 FluentLogsIngestService.ts 中会处理日志体与属性字段并默认服务名DEFAULT_SERVICE_NAME用于缺失场景兜底。如果你希望更精确地控制服务归属也可以像仓库示例 FluentBit/etc/fluent-bit.yaml 那样直接在输出端用x-oneuptime-service-name请求头指定服务名。五、完整可运行配置示例将前面两部分合并即可得到一份完整的 Fluent Bit 配置。下面的示例使用 HTTP input 插件在8888端口接收日志经处理器加工后发送到 OneUptimeservice: flush: 1 log_level: info pipeline: inputs: - name: http listen: 0.0.0.0 port: 8888 processors: logs: - name: opentelemetry_envelope - name: content_modifier context: otel_resource_attributes action: upsert key: service.name value: YOUR_SERVICE_NAME outputs: - name: stdout match: * - name: opentelemetry match: * host: oneuptime.com port: 443 metrics_uri: /otlp/v1/metrics logs_uri: /otlp/v1/logs traces_uri: /otlp/v1/traces tls: On header: - x-oneuptime-token YOUR_TELEMETRY_INGESTION_TOKEN这份配置中service.flush控制数据刷新的时间间隔秒log_level控制 Fluent Bit 自身日志级别input 使用http插件监听8888端口你可以改用tail、syslog等插件对接文件或系统日志输出端stdout便于本地确认数据是否流动opentelemetry负责真正上送。六、自托管 OneUptime 时的参数调整如果你自行托管 OneUptime需要将host替换为你的 OneUptime 实例地址。如果实例运行在 HTTP 而非 HTTPS 上则port需要改为实例监听端口通常是 80同时去掉tls或将其关闭。调整后的 outputs 示例outputs: - name: stdout match: * - name: opentelemetry match: * host: your-oneuptime-instance.com port: 80 metrics_uri: /otlp/v1/metrics logs_uri: /otlp/v1/logs traces_uri: /otlp/v1/traces header: - x-oneuptime-token YOUR_TELEMETRY_INGESTION_TOKEN注意自托管且使用 HTTP 时摄取令牌x-oneuptime-token仍必须携带鉴权逻辑与服务端配置无关属于协议层要求。七、验证与使用重启并观察数据将配置写入 Fluent Bit 配置文件后重启 Fluent Bit 服务即可生效。服务重启后Fluent Bit 收集到的遥测数据会持续发送到 OneUptime 的 HTTP 摄取源随后你可以在 OneUptime Dashboard 中看到日志、指标与链路数据。用仓库自带的 Fluent Bit 模块快速验证仓库在 FluentBit/ 目录下提供了一个开箱即用的 Fluent Bit 测试模块包含FluentBit/etc/fluent-bit.yaml使用httpinput 监听8889端口输出到 stdout 与 OneUptime OTLP 端点FluentBit/Dockerfile.tpl基于官方 Fluent Bit 镜像构建容器启动时自动加载上述 YAML 配置FluentBit/README.md本地联调说明。按 FluentBit/README.md 的指引把正确的令牌和地址写入配置文件后可执行以下命令在本地启动验证# 构建镜像 npm run force-build fluent-bit # 启动容器 npm run dev fluent-bit然后通过 curl 向容器发送一条测试日志curl -X POST -H Content-Type: application/json -d {log: This is a test log message} http://localhost:8889随后即可在 OneUptime Dashboard 中看到这条日志。校验令牌是否有效如果你不确定令牌是否正确可以使用服务端提供的POST /otlp/v1/validate端点进行校验。该端点从x-oneuptime-token请求头读取令牌并返回校验结果对于仅限浏览器使用的 Browser 类型令牌服务端还会额外检查来源Origin与信号类型限制详见 OTelIngest.ts。八、从源码看数据进入 OneUptime 后的处理链路理解服务端行为有助于你排查配置问题。从源码可以看到以下关键事实请求体上限与错误码中间件 OtelRequestMiddleware.ts 将单个 OTLP 摄取请求的上限设为 50 MiBMAX_OTLP_REQUEST_BYTES超限直接返回413 payload-too-large。由于 OTLP 规范要求导出器将 4xx 视为不可重试客户端收到 413 后会停止而非无限重试。因此如果 Fluent Bit 大批量发送被拒可以从请求大小入手排查。按 URL 识别信号类型同一中间件根据 URL 是否包含/otlp/v1/traces、/otlp/v1/logs、/otlp/v1/metrics、/otlp/v1/profiles来确定数据类型并据此路由到对应的摄取服务OtelRequestMiddleware.ts。所以配置中的 URI 路径必须一字不差。gRPC 通道除 HTTP 外服务端还在 GrpcServer.ts 中以4317端口提供 gRPC 摄取能力GRPC_PORT 4317并复用/otlp/v1/{logs|metrics|traces|profiles}路径语义。Fluent Bit 的opentelemetry插件默认走 HTTP如需 gRPC 可另作评估。日志摄取服务Fluent Bit 上报的日志最终由 FluentLogsIngestService.ts 处理包括提取日志正文、解析严重级别LogSeverity、应用日志流水线与脱敏规则并批量写入 ClickHouse该服务还允许通过service.name等资源属性区分来源服务。九、常见问题与注意事项配置后 Dashboard 无数据先确认logs_uri、metrics_uri、traces_uri与服务端路由完全一致/otlp/v1/...再确认x-oneuptime-token请求头拼写与令牌值正确可借助POST /otlp/v1/validate校验令牌。请求被 413 拒绝单次 OTLP 请求体超过 50 MiB 会被服务端拒绝请调整 Fluent Bit 的批处理/刷新参数避免单次提交过大。自托管 HTTP 场景使用端口 80 时需关闭 TLS并确认反向代理如 Nginx允许对应请求体大小通过。令牌安全摄取令牌通过请求头发送切勿写入 URL 查询参数或提交到公开仓库仓库示例 FluentBit/etc/fluent-bit.yaml 中的令牌仅为开发占位生产环境务必替换。付费提醒账号免费但日志摄取为付费功能接入前请确认你的套餐包含日志摄取能力。通过本文的配置你可以在不引入额外 Collector 组件的情况下直接利用 Fluent Bit 的轻量采集能力把日志、指标和链路追踪数据统一汇入 OneUptime并借助service.name实现按服务的可观测性分析。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 Fluent Bit 将日志与遥测数据接入 OneUptime：OTLP HTTP Collector 完整配置指南
使用 Fluent Bit 将日志与遥测数据接入 OneUptimeOTLP HTTP Collector 完整配置指南【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime导读本文讲解如何在 OneUptime 项目中使用 Fluent Bit 的 OpenTelemetry 输出插件把来自应用与服务的日志、指标Metrics和链路追踪Traces数据统一发送到 OneUptime 的 OpenTelemetry HTTP CollectorOTLP/HTTP 接收端并在 OneUptime Dashboard 中直接查看。读完本文你将掌握遥测摄取令牌Telemetry Ingestion Token的创建方法、Fluent Bit 的 outputs 与 inputs 配置要点、service.name资源属性的注入方式以及自托管 OneUptime 时的参数调整方法。本文主体内容来自仓库文档 App/FeatureSet/Docs/Content/de/telemetry/fluentbit.md并结合仓库中 Fluent Bit 模块与 Telemetry 服务端源码进行印证与扩展。一、方案概览Fluent Bit → OneUptime OTLP CollectorOneUptime 的服务端实现了标准的 OpenTelemetry 协议接收能力。从源码 App/FeatureSet/Telemetry/API/OTelIngest.ts 可以看到服务端注册了四条 OTLP/HTTP 摄取路由POST /otlp/v1/traces— 接收链路追踪数据POST /otlp/v1/metrics— 接收指标数据POST /otlp/v1/logs— 接收日志数据POST /otlp/v1/profiles— 接收 profiling性能剖析数据此外还提供POST /otlp/v1/validate用于校验摄取令牌是否有效详见 OTelIngest.ts。Fluent Bit 的opentelemetry输出插件正是以 OTLP/HTTP 协议、将这些端点作为目标地址发送数据的。因此整套链路为应用/基础设施日志 → Fluent Bitinput 插件收集 → opentelemetry 输出插件OTLP/HTTP携带 x-oneuptime-token → OneUptime OTLP HTTP Collector/otlp/v1/{logs,metrics,traces} → 写入后端存储 → OneUptime Dashboard 可视化Fluent Bit 支持的数据源Fluent Bit 原生支持数百种数据源几乎任何一种都可以通过上述链路接入 OneUptime。文档列举的常见来源包括Docker、Syslog、Apache、Nginx、MySQL、PostgreSQL、MongoDB、NodeJS、Ruby、Python、Java、PHP、Go、Rust 等等。这些数据源通过 Fluent Bit 的各类 input 插件如tail、syslog、docker等收集再统一进入同一套 OTLP 输出配置。二、前置准备四个步骤在配置 Fluent Bit 之前需要依次完成以下准备安装 Fluent Bit按 Fluent Bit 官方安装指引在你的系统上安装 Fluent Bit。注册 OneUptime 账号在 oneuptime.com 注册免费账号。注意账号本身免费但日志Log摄取属于付费功能。创建 OneUptime 项目登录后从 OneUptime Dashboard 创建项目。创建遥测摄取令牌Telemetry Ingestion Token用于向 OneUptime 摄取日志、指标和链路追踪数据。创建与查看遥测摄取令牌完成登录并创建项目后在导航栏点击「Products」产品然后进入「Project Settings」项目设置。在「Telemetry Ingestion Key」遥测摄取密钥页面点击「Create Ingestion Key」创建一个令牌创建完成后点击该密钥对应的「View」按钮即可查看令牌详情从密钥详情页可以看到该令牌的关键属性密钥类型Key Type分为仅用于服务器与采集器的Server类型、以及带来源校验的Browser类型、密钥值Secret Key可复制、状态Status、固定服务名称Pinned Service Name、每分钟请求限制Requests Per Minute Limit与过期时间等。令牌最终会以x-oneuptime-token请求头的形式随 OTLP 请求发送服务端 OTelIngest.ts 正是从该请求头中读取令牌并完成鉴权的。文档特别强调令牌应通过请求头发送不要放在查询字符串中以免泄漏到访问日志。三、核心配置outputs 部分Fluent Bit 的配置文件通常位于/etc/fluent-bit/fluent-bit.yaml。下面是一个 outputs 部分的示例outputs: - name: stdout match: * - name: opentelemetry match: * host: oneuptime.com port: 443 metrics_uri: /otlp/v1/metrics logs_uri: /otlp/v1/logs traces_uri: /otlp/v1/traces tls: On header: - x-oneuptime-token YOUR_TELEMETRY_INGESTION_TOKEN配置中有两个输出stdout用于本地调试将数据同时打印到控制台opentelemetry用于将数据发送到 OneUptime。各参数含义如下参数示例值说明nameopentelemetry使用 Fluent Bit 的 OpenTelemetry 输出插件match*匹配所有经过管道的数据流hostoneuptime.comOneUptime OTLP Collector 的主机地址自托管时替换为你的 OneUptime 实例地址port443HTTPS 默认端口自托管 HTTP 场景一般为80metrics_uri/otlp/v1/metrics指标摄取端点与服务端 OTelIngest.ts 注册的路由一致logs_uri/otlp/v1/logs日志摄取端点与服务端注册的/otlp/v1/logs路由一致traces_uri/otlp/v1/traces链路追踪摄取端点与服务端注册的/otlp/v1/traces路由一致tlsOn启用 TLS对oneuptime.com的 443 端口必须开启headerx-oneuptime-token TOKEN携带摄取令牌的自定义请求头用于服务端鉴权需要特别强调的是logs_uri、metrics_uri、traces_uri这三个路径必须与服务端实际注册的 OTLP 路由完全一致。仓库中 FluentBit/etc/fluent-bit.yaml 是随仓库提供的真实可用示例使用的正是/otlp/v1/metrics、/otlp/v1/logs、/otlp/v1/traces三个路径并且通过header同时注入了x-oneuptime-token与x-oneuptime-service-name两个请求头。四、配置 inputs注入 service.name 资源属性除了 outputs还需要在 inputs 部分保证日志携带正确的 OpenTelemetry 资源属性。文档要求确保 inputs 中存在opentelemetry_envelope处理器并推荐通过content_modifier处理器为每条日志注入service.name这样 OneUptime 就能按服务名对日志进行归类展示。inputs 部分示例pipeline: inputs: # 你的输入源 processors: logs: - name: opentelemetry_envelope - name: content_modifier context: otel_resource_attributes action: upsert key: service.name # 将 YOUR_SERVICE_NAME 替换为你的服务名 value: YOUR_SERVICE_NAME这里的两个处理器作用如下opentelemetry_envelope将 Fluent Bit 内部记录record包装为标准 OpenTelemetry 日志信封格式保证输出插件能够按 OTLP 规范序列化数据content_modifier以upsert动作把service.name写入otel_resource_attributes上下文相当于为日志打上服务标识。这与 OneUptime 服务端读取日志资源属性、按服务维度查询数据的实现是对应的——例如日志摄取服务 FluentLogsIngestService.ts 中会处理日志体与属性字段并默认服务名DEFAULT_SERVICE_NAME用于缺失场景兜底。如果你希望更精确地控制服务归属也可以像仓库示例 FluentBit/etc/fluent-bit.yaml 那样直接在输出端用x-oneuptime-service-name请求头指定服务名。五、完整可运行配置示例将前面两部分合并即可得到一份完整的 Fluent Bit 配置。下面的示例使用 HTTP input 插件在8888端口接收日志经处理器加工后发送到 OneUptimeservice: flush: 1 log_level: info pipeline: inputs: - name: http listen: 0.0.0.0 port: 8888 processors: logs: - name: opentelemetry_envelope - name: content_modifier context: otel_resource_attributes action: upsert key: service.name value: YOUR_SERVICE_NAME outputs: - name: stdout match: * - name: opentelemetry match: * host: oneuptime.com port: 443 metrics_uri: /otlp/v1/metrics logs_uri: /otlp/v1/logs traces_uri: /otlp/v1/traces tls: On header: - x-oneuptime-token YOUR_TELEMETRY_INGESTION_TOKEN这份配置中service.flush控制数据刷新的时间间隔秒log_level控制 Fluent Bit 自身日志级别input 使用http插件监听8888端口你可以改用tail、syslog等插件对接文件或系统日志输出端stdout便于本地确认数据是否流动opentelemetry负责真正上送。六、自托管 OneUptime 时的参数调整如果你自行托管 OneUptime需要将host替换为你的 OneUptime 实例地址。如果实例运行在 HTTP 而非 HTTPS 上则port需要改为实例监听端口通常是 80同时去掉tls或将其关闭。调整后的 outputs 示例outputs: - name: stdout match: * - name: opentelemetry match: * host: your-oneuptime-instance.com port: 80 metrics_uri: /otlp/v1/metrics logs_uri: /otlp/v1/logs traces_uri: /otlp/v1/traces header: - x-oneuptime-token YOUR_TELEMETRY_INGESTION_TOKEN注意自托管且使用 HTTP 时摄取令牌x-oneuptime-token仍必须携带鉴权逻辑与服务端配置无关属于协议层要求。七、验证与使用重启并观察数据将配置写入 Fluent Bit 配置文件后重启 Fluent Bit 服务即可生效。服务重启后Fluent Bit 收集到的遥测数据会持续发送到 OneUptime 的 HTTP 摄取源随后你可以在 OneUptime Dashboard 中看到日志、指标与链路数据。用仓库自带的 Fluent Bit 模块快速验证仓库在 FluentBit/ 目录下提供了一个开箱即用的 Fluent Bit 测试模块包含FluentBit/etc/fluent-bit.yaml使用httpinput 监听8889端口输出到 stdout 与 OneUptime OTLP 端点FluentBit/Dockerfile.tpl基于官方 Fluent Bit 镜像构建容器启动时自动加载上述 YAML 配置FluentBit/README.md本地联调说明。按 FluentBit/README.md 的指引把正确的令牌和地址写入配置文件后可执行以下命令在本地启动验证# 构建镜像 npm run force-build fluent-bit # 启动容器 npm run dev fluent-bit然后通过 curl 向容器发送一条测试日志curl -X POST -H Content-Type: application/json -d {log: This is a test log message} http://localhost:8889随后即可在 OneUptime Dashboard 中看到这条日志。校验令牌是否有效如果你不确定令牌是否正确可以使用服务端提供的POST /otlp/v1/validate端点进行校验。该端点从x-oneuptime-token请求头读取令牌并返回校验结果对于仅限浏览器使用的 Browser 类型令牌服务端还会额外检查来源Origin与信号类型限制详见 OTelIngest.ts。八、从源码看数据进入 OneUptime 后的处理链路理解服务端行为有助于你排查配置问题。从源码可以看到以下关键事实请求体上限与错误码中间件 OtelRequestMiddleware.ts 将单个 OTLP 摄取请求的上限设为 50 MiBMAX_OTLP_REQUEST_BYTES超限直接返回413 payload-too-large。由于 OTLP 规范要求导出器将 4xx 视为不可重试客户端收到 413 后会停止而非无限重试。因此如果 Fluent Bit 大批量发送被拒可以从请求大小入手排查。按 URL 识别信号类型同一中间件根据 URL 是否包含/otlp/v1/traces、/otlp/v1/logs、/otlp/v1/metrics、/otlp/v1/profiles来确定数据类型并据此路由到对应的摄取服务OtelRequestMiddleware.ts。所以配置中的 URI 路径必须一字不差。gRPC 通道除 HTTP 外服务端还在 GrpcServer.ts 中以4317端口提供 gRPC 摄取能力GRPC_PORT 4317并复用/otlp/v1/{logs|metrics|traces|profiles}路径语义。Fluent Bit 的opentelemetry插件默认走 HTTP如需 gRPC 可另作评估。日志摄取服务Fluent Bit 上报的日志最终由 FluentLogsIngestService.ts 处理包括提取日志正文、解析严重级别LogSeverity、应用日志流水线与脱敏规则并批量写入 ClickHouse该服务还允许通过service.name等资源属性区分来源服务。九、常见问题与注意事项配置后 Dashboard 无数据先确认logs_uri、metrics_uri、traces_uri与服务端路由完全一致/otlp/v1/...再确认x-oneuptime-token请求头拼写与令牌值正确可借助POST /otlp/v1/validate校验令牌。请求被 413 拒绝单次 OTLP 请求体超过 50 MiB 会被服务端拒绝请调整 Fluent Bit 的批处理/刷新参数避免单次提交过大。自托管 HTTP 场景使用端口 80 时需关闭 TLS并确认反向代理如 Nginx允许对应请求体大小通过。令牌安全摄取令牌通过请求头发送切勿写入 URL 查询参数或提交到公开仓库仓库示例 FluentBit/etc/fluent-bit.yaml 中的令牌仅为开发占位生产环境务必替换。付费提醒账号免费但日志摄取为付费功能接入前请确认你的套餐包含日志摄取能力。通过本文的配置你可以在不引入额外 Collector 组件的情况下直接利用 Fluent Bit 的轻量采集能力把日志、指标和链路追踪数据统一汇入 OneUptime并借助service.name实现按服务的可观测性分析。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考