OneUptime 自托管架构深度解析从 Kubernetes 集群部署到探针监控的数据流全貌【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本文以 OneUptime 官方自托管架构图文档App/FeatureSet/Docs/Content/de/self-hosted/architecture.md为主体系统拆解这套开源监控与可观测性平台在用户自有环境以 Kubernetes 集群为例中的典型部署形态入口路由、核心服务、摄取管道、探针与数据存储如何各司其职以及监控结果、遥测数据如何沿管道流转落库。读完本文你将掌握 OneUptime 自托管部署的组件全景与数据流原理并能结合仓库源码定位每个组件的实现入口为后续部署、排障和二次定制打下基础。架构总览一张图看懂自托管部署OneUptime 自托管时运行在用户自己的环境例如 Kubernetes 集群中。官方文档用一张 Mermaid 流程图完整描述了其典型拓扑本文将这张图完整保留并逐层展开从图例可以看出整套体系按职责划分为五类角色边缘入口蓝、Web 与 API 核心服务绿、摄取管道紫、探针橙和数据存储黄集群外部的监控目标与数据源则以虚线灰色表示。边缘层NGINX Ingress 统一收口外部流量终端用户通过浏览器访问 OneUptime 时所有 HTTPS 请求首先到达集群入口NGINX IngressTLS由其统一承担 TLS 终结和路由转发请求被分发到Home / DashboardUI与Status PagesUI等前端页面API 类请求被转发到API Server前端页面通过REST/gRPC协议与 API Server 通信。NGINX 在仓库中对应独立的 ingress 服务。从 Nginx/Index.ts 可以看到它的启动逻辑服务名固定为ingress通过checkStatusWithRetry对 PostgreSQL 做就绪检查ClickHouse 与 Redis 不在检查范围内并初始化三个证书相关 Job ——AcmeWriteCertificatesJobACME/Lets Encrypt 证书写入、WriteCustomCertsToDiskJob自定义证书落盘、WriteServerCertToDiskJob服务端证书落盘。也就是说入口层不仅做流量路由还承担了 TLS 证书的签发与轮换管理职责。在部署编排上docker-compose.yml 使用oneuptime/nginx:${APP_TAG}镜像启动ingress服务其就绪依赖 PostgreSQL、Valkey 与 ClickHouse 三者健康docker-compose.base.yml 则注入HTTP_PROTOCOL、SERVER_APP_HOSTNAME: app、SERVER_HOME_HOSTNAME: home等路由相关环境变量明确 ingress 向后端app与home主机名分发请求。Web 与 API 层UI、API Server 与后台 Worker集群内运行着四个核心应用角色角色职责Home / Dashboard (UI)面向管理员与用户的主控制台前端Status Pages (UI)面向公众的公开状态页面前端API Server提供 REST/gRPC 接口承载全部业务逻辑Background Worker消费队列中的任务异步处理监控结果等负载API Server是系统的业务中枢。从 App/Index.ts 的初始化流程看它启动时会依次连接 PostgreSQL配置/状态/元数据、Redis缓存/队列/会话和 ClickHouse指标/追踪/日志三类存储并通过InfrastructureStatus.checkStatusWithRetry分别对数据库、缓存和分析数据库做就绪探针随后挂载实时通信Realtime.init()、应用级 Metrics 端点供 KEDA 等 HPA 组件消费以及/api/admin/health管理健康接口最后初始化 Identity、Notification、BaseAPI、MCP、Frontend、Docs、APIReference、Workers、Telemetry、Workflow、Runbook 共十一个 FeatureSet 路由模块。图中 API 同时连接 PG、REDIS、CH 三条数据链路与该实现完全吻合。Background Worker则扮演异步消化者它从 Valkey 队列消费任务将处理结果写入各数据存储。图中REDIS -- WORKER明确刻画了这一队列 → 消费 → 落库的模式Probe 监控结果正是沿着这条链路完成最终持久化。摄取管道五条专用数据通道自托管架构中有一个非常值得关注的设计 —— 独立的Ingest Pipeline摄取管道。它包含五个专用摄取服务按数据类型分流避免所有写入请求都压向 API ServerProbe Ingest接收探针上报的监控结果先写入 Valkey 队列再由 Background Worker 异步处理OpenTelemetry Ingest接收 OTel Collector/Agent 上报的指标、追踪数据直接写入 ClickHouseLogs IngestFluent Bit接收 Fluentd / Fluent Bit 转发而来的日志写入 ClickHouseServer Monitor Ingest接收服务器监控 Agent 的数据写入 ClickHouseIncoming Request Ingest接收传入请求心跳/入站请求类监控数据写入 ClickHouse。从图中可以看到摄取管道内部的两条差异化落库路径只有探针结果走 Probe Ingest → Valkey 队列 → Worker 处理 的异步链路其余四类OTel、日志、服务器监控、入站请求则直接写入 ClickHouse。这种热路径队列削峰与冷路径直写分析库分离的设计既保障了高频监控结果的可控性又让遥测类数据能以低延迟直达分析引擎。仓库中对应探针侧的实现位于 Probe/Index.ts探针启动后通过Register.registerProbe()向服务端注册并启动若干后台任务——AliveJob心跳、FetchMonitorList拉取监控任务、FetchMonitorTestList、FetchDiscoveryScans网络发现扫描、FetchNetworkDeviceList与FetchNetworkDeviceDiagnostics。此外探针还支持可选的 SNMP Trap 接收、Syslog 接收和 NetFlow v5 接收以及一个独立的 ingress 监听器PROBE_INGRESS_PORT用于在不暴露探针状态/Metrics 端口的前提下为 IncomingRequest心跳类监控单独开放专用端口——这与图中 Incoming Request Ingest 的存在互为印证。探针内外双栖的监控执行体OneUptime Probes是实际发起监控请求的执行单元架构图给出了两种部署形态P1集群内的 Probe Pod推荐—— 作为 Pod 运行在自托管集群中P2网络其他位置的探针 VM/容器可选—— 部署在集群外、用户网络的任意位置。无论部署在哪里探针都能同时监控两类目标内部/私有资源INT防火墙之后的私有应用、数据库、内部服务外部/公共资源EXT互联网上的公开网站、API、SaaS 服务。监控协议覆盖HTTPS / TCP / Ping / DNS / 自定义图中用双向箭头EXT -- P1、INT -- P1等表示探针与目标之间存在持续的监控探测交互。所有监控结果最终统一上报到集群内的Probe Ingest。从源码看Probe/Index.ts 支持多类监控能力的并发调度启动日志会输出监控 Worker 数PROBE_MONITORING_WORKERS、监控拉取上限PROBE_MONITOR_FETCH_LIMIT、合成监控并发度PROBE_SYNTHETIC_MONITOR_MAX_CONCURRENCY以及脚本超时、磁盘/RSS 限制等参数对于浏览器合成监控还专门处理了 Chromium seccomp 沙箱开关PROBE_SYNTHETIC_MONITOR_CHROMIUM_SANDBOX_ENABLED未开启时会打印安全警告建议安装 Playwright 兼容的 seccomp profile 以纵深防御——仓库根目录下的 Probe/seccomp_profile.json 正是为此准备的。这些细节说明自定义与合成类监控在探针端有完整的资源隔离与安全防护机制。数据存储三类数据库各司其职OneUptime 自托管架构使用三套数据存储职责划分清晰存储角色定位承载内容PostgreSQL系统元数据库配置、状态、元数据业务实体Valkey缓存与队列缓存、队列、会话ClickHouse分析型数据库指标、追踪、日志时序遥测数据其中Valkey是 BSD 许可证的 Redis 7.2 分支作为缓存、队列和会话存储ClickHouse承载全部时序类遥测数据其列式存储特性非常适合指标/追踪/日志的高吞吐写入与聚合查询。这一关系库管状态、队列库管流转、分析库管遥测的分层在 docker-compose.base.yml 中有直观体现DATABASE_*系列变量配置 PostgreSQL 连接含DATABASE_SSL_CA/KEY/CERT/REJECT_UNAUTHORIZED全套 TLS 选项VALKEY_*系列变量配置 Valkey 连接并保留REDIS_*旧变量名作为向后兼容回退注释明确说明这是为了让重命名前写好的 config.env 无需改动即可继续工作ClickHouse 则承载 OTLP 与日志摄取链路。生产环境需要时用户完全可以用托管的云数据库替换内置实例。外部存储替换逻辑流程保持不变官方文档特别强调了一个重要特性如果用户使用外部的 PostgreSQL、RedisValkey或 ClickHouse 而非内置实例API / Worker / 各 Ingest 服务的连接会指向用户的外部端点但逻辑流程保持不变。这意味着自托管部署具备良好的存储解耦能力数据链路方向不变API 与 Worker 依旧读写三类存储Ingest 依旧按数据类型落库只是物理端点发生变化内置容器 → 外部托管服务对高可用与容灾要求高的场景可借此接入云厂商托管的 PostgreSQL/Redis/ClickHouse或将 ClickHouse 替换为分析型数据库集群。从 App/Index.ts 的实现看数据库连接通过统一的 Infrastructure 层PostgresAppInstance、ClickhouseAppInstance、Redis、Queue封装连接目标全部来自环境配置这为内置/外部存储无缝切换提供了代码级支撑。与部署编排的对应关系自托管部署的组件在 docker-compose.yml 中一一对应valkey、clickhouse、postgres三套数据存储加上app合并了 UI 与 API、probe-1探针、runner自动化执行器和ingressNGINX 入口共同构成一个完整集群x-common-depends-on锚点确保app、probe-1、runner、ingress都等待三个存储服务健康后再启动与架构图中核心服务依赖数据存储的拓扑一致。生产环境如 Kubernetes部署时各角色分别以独立 Deployment/Pod 运行探针既可以是集群内 Pod也可以是网络中的独立 VM/容器完全对应架构图中 P1/P2 的部署形态。小结OneUptime 的自托管架构可以概括为一个入口、四类角色、五条摄取通道、三套存储NGINX Ingress统一终结 TLS 并路由 UI/API 流量同时管理证书签发Web 与 API 层Dashboard、Status Pages、API Server、Background Worker承载全部业务逻辑与异步处理摄取管道按数据类型分流探针结果走队列异步链路OTel/日志/服务器监控/入站请求直写 ClickHouse探针可在集群内外双栖部署同时监控内部私有资源与外部公共资源PostgreSQL状态 Valkey缓存/队列 ClickHouse遥测三库分工且支持整体替换为外部托管实例而不改变逻辑流程。对运维与开发人员而言这张架构图既是部署时的组件清单也是排障时的路径地图——任何一条数据流的断裂都可以沿着入口 → 服务 → 摄取 → 队列 → 存储的链路快速定位。深入阅读 Probe/Index.ts、App/Index.ts、Nginx/Index.ts 以及 docker-compose.base.yml 等实现文件可以进一步掌握每个组件的配置项与启动细节。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime 自托管架构深度解析：从 Kubernetes 集群部署到探针监控的数据流全貌
OneUptime 自托管架构深度解析从 Kubernetes 集群部署到探针监控的数据流全貌【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本文以 OneUptime 官方自托管架构图文档App/FeatureSet/Docs/Content/de/self-hosted/architecture.md为主体系统拆解这套开源监控与可观测性平台在用户自有环境以 Kubernetes 集群为例中的典型部署形态入口路由、核心服务、摄取管道、探针与数据存储如何各司其职以及监控结果、遥测数据如何沿管道流转落库。读完本文你将掌握 OneUptime 自托管部署的组件全景与数据流原理并能结合仓库源码定位每个组件的实现入口为后续部署、排障和二次定制打下基础。架构总览一张图看懂自托管部署OneUptime 自托管时运行在用户自己的环境例如 Kubernetes 集群中。官方文档用一张 Mermaid 流程图完整描述了其典型拓扑本文将这张图完整保留并逐层展开从图例可以看出整套体系按职责划分为五类角色边缘入口蓝、Web 与 API 核心服务绿、摄取管道紫、探针橙和数据存储黄集群外部的监控目标与数据源则以虚线灰色表示。边缘层NGINX Ingress 统一收口外部流量终端用户通过浏览器访问 OneUptime 时所有 HTTPS 请求首先到达集群入口NGINX IngressTLS由其统一承担 TLS 终结和路由转发请求被分发到Home / DashboardUI与Status PagesUI等前端页面API 类请求被转发到API Server前端页面通过REST/gRPC协议与 API Server 通信。NGINX 在仓库中对应独立的 ingress 服务。从 Nginx/Index.ts 可以看到它的启动逻辑服务名固定为ingress通过checkStatusWithRetry对 PostgreSQL 做就绪检查ClickHouse 与 Redis 不在检查范围内并初始化三个证书相关 Job ——AcmeWriteCertificatesJobACME/Lets Encrypt 证书写入、WriteCustomCertsToDiskJob自定义证书落盘、WriteServerCertToDiskJob服务端证书落盘。也就是说入口层不仅做流量路由还承担了 TLS 证书的签发与轮换管理职责。在部署编排上docker-compose.yml 使用oneuptime/nginx:${APP_TAG}镜像启动ingress服务其就绪依赖 PostgreSQL、Valkey 与 ClickHouse 三者健康docker-compose.base.yml 则注入HTTP_PROTOCOL、SERVER_APP_HOSTNAME: app、SERVER_HOME_HOSTNAME: home等路由相关环境变量明确 ingress 向后端app与home主机名分发请求。Web 与 API 层UI、API Server 与后台 Worker集群内运行着四个核心应用角色角色职责Home / Dashboard (UI)面向管理员与用户的主控制台前端Status Pages (UI)面向公众的公开状态页面前端API Server提供 REST/gRPC 接口承载全部业务逻辑Background Worker消费队列中的任务异步处理监控结果等负载API Server是系统的业务中枢。从 App/Index.ts 的初始化流程看它启动时会依次连接 PostgreSQL配置/状态/元数据、Redis缓存/队列/会话和 ClickHouse指标/追踪/日志三类存储并通过InfrastructureStatus.checkStatusWithRetry分别对数据库、缓存和分析数据库做就绪探针随后挂载实时通信Realtime.init()、应用级 Metrics 端点供 KEDA 等 HPA 组件消费以及/api/admin/health管理健康接口最后初始化 Identity、Notification、BaseAPI、MCP、Frontend、Docs、APIReference、Workers、Telemetry、Workflow、Runbook 共十一个 FeatureSet 路由模块。图中 API 同时连接 PG、REDIS、CH 三条数据链路与该实现完全吻合。Background Worker则扮演异步消化者它从 Valkey 队列消费任务将处理结果写入各数据存储。图中REDIS -- WORKER明确刻画了这一队列 → 消费 → 落库的模式Probe 监控结果正是沿着这条链路完成最终持久化。摄取管道五条专用数据通道自托管架构中有一个非常值得关注的设计 —— 独立的Ingest Pipeline摄取管道。它包含五个专用摄取服务按数据类型分流避免所有写入请求都压向 API ServerProbe Ingest接收探针上报的监控结果先写入 Valkey 队列再由 Background Worker 异步处理OpenTelemetry Ingest接收 OTel Collector/Agent 上报的指标、追踪数据直接写入 ClickHouseLogs IngestFluent Bit接收 Fluentd / Fluent Bit 转发而来的日志写入 ClickHouseServer Monitor Ingest接收服务器监控 Agent 的数据写入 ClickHouseIncoming Request Ingest接收传入请求心跳/入站请求类监控数据写入 ClickHouse。从图中可以看到摄取管道内部的两条差异化落库路径只有探针结果走 Probe Ingest → Valkey 队列 → Worker 处理 的异步链路其余四类OTel、日志、服务器监控、入站请求则直接写入 ClickHouse。这种热路径队列削峰与冷路径直写分析库分离的设计既保障了高频监控结果的可控性又让遥测类数据能以低延迟直达分析引擎。仓库中对应探针侧的实现位于 Probe/Index.ts探针启动后通过Register.registerProbe()向服务端注册并启动若干后台任务——AliveJob心跳、FetchMonitorList拉取监控任务、FetchMonitorTestList、FetchDiscoveryScans网络发现扫描、FetchNetworkDeviceList与FetchNetworkDeviceDiagnostics。此外探针还支持可选的 SNMP Trap 接收、Syslog 接收和 NetFlow v5 接收以及一个独立的 ingress 监听器PROBE_INGRESS_PORT用于在不暴露探针状态/Metrics 端口的前提下为 IncomingRequest心跳类监控单独开放专用端口——这与图中 Incoming Request Ingest 的存在互为印证。探针内外双栖的监控执行体OneUptime Probes是实际发起监控请求的执行单元架构图给出了两种部署形态P1集群内的 Probe Pod推荐—— 作为 Pod 运行在自托管集群中P2网络其他位置的探针 VM/容器可选—— 部署在集群外、用户网络的任意位置。无论部署在哪里探针都能同时监控两类目标内部/私有资源INT防火墙之后的私有应用、数据库、内部服务外部/公共资源EXT互联网上的公开网站、API、SaaS 服务。监控协议覆盖HTTPS / TCP / Ping / DNS / 自定义图中用双向箭头EXT -- P1、INT -- P1等表示探针与目标之间存在持续的监控探测交互。所有监控结果最终统一上报到集群内的Probe Ingest。从源码看Probe/Index.ts 支持多类监控能力的并发调度启动日志会输出监控 Worker 数PROBE_MONITORING_WORKERS、监控拉取上限PROBE_MONITOR_FETCH_LIMIT、合成监控并发度PROBE_SYNTHETIC_MONITOR_MAX_CONCURRENCY以及脚本超时、磁盘/RSS 限制等参数对于浏览器合成监控还专门处理了 Chromium seccomp 沙箱开关PROBE_SYNTHETIC_MONITOR_CHROMIUM_SANDBOX_ENABLED未开启时会打印安全警告建议安装 Playwright 兼容的 seccomp profile 以纵深防御——仓库根目录下的 Probe/seccomp_profile.json 正是为此准备的。这些细节说明自定义与合成类监控在探针端有完整的资源隔离与安全防护机制。数据存储三类数据库各司其职OneUptime 自托管架构使用三套数据存储职责划分清晰存储角色定位承载内容PostgreSQL系统元数据库配置、状态、元数据业务实体Valkey缓存与队列缓存、队列、会话ClickHouse分析型数据库指标、追踪、日志时序遥测数据其中Valkey是 BSD 许可证的 Redis 7.2 分支作为缓存、队列和会话存储ClickHouse承载全部时序类遥测数据其列式存储特性非常适合指标/追踪/日志的高吞吐写入与聚合查询。这一关系库管状态、队列库管流转、分析库管遥测的分层在 docker-compose.base.yml 中有直观体现DATABASE_*系列变量配置 PostgreSQL 连接含DATABASE_SSL_CA/KEY/CERT/REJECT_UNAUTHORIZED全套 TLS 选项VALKEY_*系列变量配置 Valkey 连接并保留REDIS_*旧变量名作为向后兼容回退注释明确说明这是为了让重命名前写好的 config.env 无需改动即可继续工作ClickHouse 则承载 OTLP 与日志摄取链路。生产环境需要时用户完全可以用托管的云数据库替换内置实例。外部存储替换逻辑流程保持不变官方文档特别强调了一个重要特性如果用户使用外部的 PostgreSQL、RedisValkey或 ClickHouse 而非内置实例API / Worker / 各 Ingest 服务的连接会指向用户的外部端点但逻辑流程保持不变。这意味着自托管部署具备良好的存储解耦能力数据链路方向不变API 与 Worker 依旧读写三类存储Ingest 依旧按数据类型落库只是物理端点发生变化内置容器 → 外部托管服务对高可用与容灾要求高的场景可借此接入云厂商托管的 PostgreSQL/Redis/ClickHouse或将 ClickHouse 替换为分析型数据库集群。从 App/Index.ts 的实现看数据库连接通过统一的 Infrastructure 层PostgresAppInstance、ClickhouseAppInstance、Redis、Queue封装连接目标全部来自环境配置这为内置/外部存储无缝切换提供了代码级支撑。与部署编排的对应关系自托管部署的组件在 docker-compose.yml 中一一对应valkey、clickhouse、postgres三套数据存储加上app合并了 UI 与 API、probe-1探针、runner自动化执行器和ingressNGINX 入口共同构成一个完整集群x-common-depends-on锚点确保app、probe-1、runner、ingress都等待三个存储服务健康后再启动与架构图中核心服务依赖数据存储的拓扑一致。生产环境如 Kubernetes部署时各角色分别以独立 Deployment/Pod 运行探针既可以是集群内 Pod也可以是网络中的独立 VM/容器完全对应架构图中 P1/P2 的部署形态。小结OneUptime 的自托管架构可以概括为一个入口、四类角色、五条摄取通道、三套存储NGINX Ingress统一终结 TLS 并路由 UI/API 流量同时管理证书签发Web 与 API 层Dashboard、Status Pages、API Server、Background Worker承载全部业务逻辑与异步处理摄取管道按数据类型分流探针结果走队列异步链路OTel/日志/服务器监控/入站请求直写 ClickHouse探针可在集群内外双栖部署同时监控内部私有资源与外部公共资源PostgreSQL状态 Valkey缓存/队列 ClickHouse遥测三库分工且支持整体替换为外部托管实例而不改变逻辑流程。对运维与开发人员而言这张架构图既是部署时的组件清单也是排障时的路径地图——任何一条数据流的断裂都可以沿着入口 → 服务 → 摄取 → 队列 → 存储的链路快速定位。深入阅读 Probe/Index.ts、App/Index.ts、Nginx/Index.ts 以及 docker-compose.base.yml 等实现文件可以进一步掌握每个组件的配置项与启动细节。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考