可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载本指南以 OneUptime 官方自托管架构文档为核心系统讲解 OneUptime 在您自己的 Kubernetes 集群中自托管时的完整部署拓扑——包括终端用户如何通过 Ingress 访问 UI 与 API、核心服务与数据摄取管道如何协作、OneUptime 探针Probes如何同时监控内网与外网资源以及 PostgreSQL、Valkey、ClickHouse 三类数据存储各自的职责边界。读完本文您将能够理解 OneUptime 自托管部署的每一个关键组件与数据流并能结合 docker-compose.yml 与 Helm Chart 快速定位对应实现。说明本文主体来自仓库中的自托管架构文档原文位于 packages/App/FeatureSet/Docs/Content/fr/self-hosted/architecture.md同时提供 英文版 与 中文版。文中引用的源码与配置均来自当前仓库。总体架构一张图看懂自托管部署OneUptime 自托管时通常运行在您的环境例如 Kubernetes 集群中。官方文档用一张 Mermaid 流程图给出了典型拓扑下面对该图进行完整还原从图中可以提炼出自托管部署的五个逻辑层次层次组件职责边缘接入NGINX IngressTLS唯一的公网入口负责 TLS 终结与路由分发Web 与 API主页/控制台 UI、状态页面 UI、API 服务器、后台 Worker面向用户的界面与核心业务处理数据摄取管道探针摄取、OTel 摄取、日志摄取、服务器监控摄取、传入请求摄取各类监控与遥测数据的入口探针集群内 Probe Pod、网络上的可选 Probe VM/容器主动发起监控探测数据存储PostgreSQL、ValkeyRedis 7.2 的 BSD 许可分支、ClickHouse分层持久化边缘接入NGINX Ingress 如何路由流量文档明确指出终端用户通过集群的 IngressNGINX访问 OneUptimeIngress 将请求路由到 UI 与 API。这一点在仓库的 Nginx 包中有非常具体的实现印证。入口组件实现在 packages/Nginx/Index.ts其SERVICE_NAME即为ingress启动时会做健康检查检查 PostgreSQL 状态并挂载 ACME 证书写入等 Jobpackages/Nginx/Index.ts。路由规则定义在 packages/Nginx/default.conf.template由 packages/Nginx/envsubst-on-templates.sh 进行环境变量替换后生成实际生效的 nginx.conf。从 default.conf.template 可以看到若干与架构图一一对应的路由细节主页与控制台当BILLING_ENABLEDtrue时location /将请求代理到 Home营销/主页服务$backend_home否则代理到 Dashboard 应用$backend_app——自托管 on-prem 安装不需要营销页面因此直接进入控制台见 default.conf.template。状态页面location /status-page、location /status-page-api/重写为/api/status-page/以及/status-page-sso-api/、/status-page-oidc-api/、/status-page-identity-api/等分别路由到状态页面 UI 与其配套的 API见 default.conf.template。这些 location 同时启用了 WebSocket 升级proxy_http_version 1.1Upgrade/Connection头。gRPClocation ~ /opentelemetry.proto.collector*通过grpc_pass ${BACKEND_APP_GRPC_TARGET}将 OTLP gRPC 流量转发到 App 的 4317 端口见 default.conf.template与架构图中 UI → API 的 “REST/gRPC” 通信方式吻合。TLS 与证书HTTPS 监听端口 7850证书路径按$ssl_server_name动态解析StatusPageCerts/$ssl_server_name.crt并结合 ACME Challenge 路由/.well-known/acme-challenge实现证书自动签发见 default.conf.template 与 default.conf.template。从源码结构看Ingress 组件不仅是流量入口还承担了高吞吐摄取路径的代理职责——/telemetry、/otlp、/session-replay、/kubernetes-cost、/pyroscope、/security-events、/source-maps等摄取端点都定义了独立 location并支持通过NGINX_INGEST_ACCESS_LOG环境变量控制是否记录逐请求访问日志默认开启见 default.conf.template。Web 与 API 层核心服务及其数据依赖架构图将“Web 与 API”层划分为四个组件主页/控制台 UI、状态页面 UI、API 服务器、后台 Worker。其中API 服务器实现在 packages/App/Index.tsAPP_NAME为api。启动时序印证了架构图中 API 与三类数据存储的关系见 packages/App/Index.tsawait PostgresAppInstance.connect()—— 连接 PostgreSQL配置、状态、元数据await Redis.connect()—— 连接 Redis/Valkey并在启动时调用Queue.cleanAllQueuesOnStartup()清理历史 Job 计数BullMQ 队列await ClickhouseAppInstance.connect()与ClickhouseIngestInstance.connect()—— 连接 ClickHouse 的分析库与摄取库仅当RunDatabaseMigrationsOnBoot开启时才额外连接迁移池。健康检查会同时探测 ClickHouse、PostgreSQL、Redis 三者的状态见 packages/App/Index.ts。启动时依次初始化身份Identity、通知Notification、BaseAPI、MCP、前端Frontend、文档Docs、API 参考、Worker、遥测Telemetry、工作流Workflow、Runbook 等 FeatureSet 路由见 packages/App/Index.ts对应图中 “API 服务器作为所有 UI 与业务流量的汇聚点” 的角色。后台 Worker对应WORKER节点。从架构图看Worker 消费 Valkey 中的任务队列并写入三类数据存储API 进程本身也挂载了 Worker FeatureSet 路由await WorkersRoutes.init()并注册了OnCallShiftReminderListener见 packages/App/Index.ts说明“后台处理”逻辑可以随业务进程一起运行也可独立部署。Worker 的独立实现位于 packages/App/FeatureSet/Workers274 个 TS 文件承载监控事件处理、通知派发、告警升级等异步任务。主页与控制台 UI、状态页面 UI分别对应 packages/HomeEJS 营销/主页服务与 packages/App/FeatureSet/StatusPage、packages/App/FeatureSet/DashboardReact 控制台。状态页面在自托管场景下通过/status-page*路由对外提供公开的状态展示能力。数据摄取管道五类摄入路径与 ClickHouse 汇聚架构图将数据摄取管道分为五个节点这是 OneUptime 观测平台的关键设计——所有高吞吐遥测数据都经由专用摄取服务进入系统并最终落到 ClickHouse探针数据摄取Probe Ingest接收来自集群内外探针的监控结果。与其他摄取路径不同探针结果先进入Valkey 队列图中PROBEINGEST -- REDIS再由后台 Worker 消费并写入数据存储——这是监控结果可靠落库的关键缓冲层。从 docker-compose.yml 可以看到app服务与probe-1服务并列存在探针Probe作为独立服务运行。OpenTelemetry 数据摄取OTel Ingest接收 OTel Collector/Agent 上报的指标metrics、追踪traces直接写入 ClickHouse。对应 Nginx 的/otlplocation 与 App 中的 Telemetry FeatureSetpackages/App/FeatureSet/Telemetry含 81 个 TS 与 12 个 proto 文件。日志摄取Logs Ingest由 Fluentd / Fluent Bit 转发日志写入 ClickHouse。仓库中提供了完整的日志收集参考实现Examples/log-collectors/fluent-bit含 etc/*.yaml 配置与 Examples/log-collectors/fluentdfluent.conf另有 Examples/fluentd 可直接运行的 Node.js 示例。Nginx 侧对应location /fluentd/logs。服务器监控数据摄取Server Monitor Ingest接收服务器监控 Agent 上报的数据写入 ClickHouse。对应仓库中的 agents/InfrastructureAgentGo 实现采集 CPU、内存、磁盘、网络、负载等主机指标与 agents/DockerAgent、agents/KubernetesLogTailer 等 Agent 家族。传入请求数据摄取Incoming Request Ingest接收外部请求事件如 Webhook、Incoming Request 监控写入 ClickHouse。Nginx 侧对应location /incoming-request-ingestProbe 侧有对应的IncomingRequestIngressAPI见 packages/Probe/Index.ts。这种“专用摄取端点 ClickHouse 汇聚”的设计使得指标、追踪、日志与请求事件可以在同一套分析存储中统一查询而不会挤占 PostgreSQL 的 OLTP 负载。探针内外网监控的关键节点架构图中OneUptime 探针Probes是唯一同时与“集群内”和“集群外”打交道的组件部署位置探针可以运行在集群内图中 P1官方推荐方式也可以作为可选的 VM/容器部署在您网络的其它位置图中 P2。这种弹性部署允许探针贴近被监控目标。监控协议探针通过HTTPS / TCP / Ping / DNS / 自定义等协议与目标资源交互图中EXT -- P1/P2与INT -- P1/P2。监控范围内部/私有服务防火墙之后的应用、数据库、内部服务如公司内网的业务系统外部/公共资源公网网站、公开 API、SaaS 服务如对外官网、第三方 API。结果回传探针将监控结果发送到集群内的探针数据摄取端点经 Valkey 排队后由后台 Worker 处理落库。探针服务的实现位于 packages/Probe从 packages/Probe/Index.ts 的导入可以看到其职责全貌注册服务Register、获取监控列表FetchList、执行监控测试FetchMonitorTest、网络设备发现Discovery/FetchScans、NetFlow 接收NetFlowReceiver、SNMP Trap 接收SnmpTrapReceiver、Syslog 接收SyslogReceiver、私有网络监控策略PrivateNetworkMonitorPolicy与代理配置ProxyConfig等。其中PrivateNetworkMonitorPolicy与 文档 private-network-access.md 相互呼应——探针既负责监控内网也必须遵循私有网络访问策略。对于需要监控防火墙内服务的场景探针的“贴近网络部署”能力至关重要您也可以参考 agents/DockerAgent 等 Agent 以容器方式部署在目标网络中实现更细粒度的服务器监控。数据存储三库分工与外部存储说明架构图给出了清晰的数据存储分工存储数据用途定位PostgreSQL配置、状态、元数据关系型业务数据项目、监控项、告警、用户等ClickHouse指标、追踪、日志分析型列式存储承载高吞吐遥测数据Valkey缓存、队列、会话缓存与 BullMQ 任务队列Redis 7.2 的 BSD 许可分支文档特别说明如果您使用外部 PostgreSQL、Redis 或 ClickHouse 而非内置版本API/Worker/摄取服务只需将连接指向您的外部端点即可逻辑流程保持不变。仓库对此提供了充分支撑ClickHouse目录Clickhouse包含完整的部署配置主配置 Clickhouse/config.xml、集群配置 Clickhouse/config.d/cluster.xml、系统日志 TTL 策略 Clickhouse/config.d/system-log-ttl.xml以及分布式写入调优参数 Clickhouse/users.d/distributed-insert-tuning.xml。ClickHouse 相关运维指南见 Clickhouse/Docs/ClickhouseOps.md。数据库连接层API/Worker 通过Common/Server/Infrastructure/下的PostgresDatabase、ClickhouseDatabase含ClickhouseAppInstance、ClickhouseIngestInstance、ClickhouseMigrationInstance、Redis、Queue等基础设施模块统一管理连接见 packages/App/Index.ts这也解释了为何切换外部存储只需改连接端点。Kubernetes 部署若使用 Helm Chart可参考 HelmChart/Public/oneuptime/values.yaml 配置存储端点PostgreSQL 与 ClickHouse 的 Operator 迁移方案分别见 HelmChart/Docs/MigratePostgresStandaloneToOperator.md 与 HelmChart/Docs/MigrateClickhouseStandaloneToOperator.md。从架构图到实际部署Docker Compose 中的服务布局架构图中的组件在 docker-compose.yml 中均有对应服务。从该文件顶层的服务声明见 docker-compose.yml可以看到postgres、valkey、clickhouse三类存储服务appAPI/UI/Worker 一体化镜像、probe-1探针、runner代码执行 Runner、ingressNginx 入口等应用服务。这种“一个app服务承载 Web/API/Worker 独立probe服务”的编排方式与架构图中“核心服务 探针”的分层完全对应而在 Kubernetes 场景下HelmChart/Public/oneuptime 则将 API、Worker、摄取等拆分为更细的 Deployment便于水平伸缩。小结OneUptime 自托管架构可以概括为终端用户经 NGINX IngressTLS进入系统路由到主页/控制台与状态页面 UIUI 通过 REST/gRPC 调用 API 服务器API 与后台 Worker 读写 PostgreSQL配置与元数据、Valkey缓存与队列和 ClickHouse遥测分析数据集群内外的探针通过 HTTPS/TCP/Ping/DNS 等协议监控内部与外部资源结果经探针摄取进入 Valkey 队列后由 Worker 落库OTel、Fluentd/Fluent Bit、服务器 Agent 等遥测源则通过专用摄取端点直接写入 ClickHouse。这张架构图不仅是理解 OneUptime 自托管部署的入口也是排查问题流量从哪进、数据落到哪、规划高可用外部存储、多探针部署和扩展能力新增摄取端点的参照系。相关部署文档可继续阅读 HelmChart/Docs/Helm.md、HelmChart/Docs/Kubernetes.md 以及 docker-compose.yml。赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime 自托管架构全解析从 Ingress 到数据存储的完整数据流与部署拓扑OneUptime 自托管架构全解析从 Ingress 到数据存储的完整数据流与部署拓扑 导读 本篇技术指南以官方自托管架构文档为核心为你拆解 OneUpt可观测性后端运维前端云原生微服务AI AgentOneUptime 自托管架构全解从 Ingress 到数据存储的完整数据流剖析OneUptime 自托管架构全解从 Ingress 到数据存储的完整数据流剖析 本文基于 packages/App/FeatureSet/Docs/Cont可观测性后端运维前端云原生微服务AI AgentOneUptime 自托管架构深度解析从 NGINX 入口到 Probe 探针与数据存储的完整拓扑OneUptime 自托管架构深度解析从 NGINX 入口到 Probe 探针与数据存储的完整拓扑 导读 本文围绕 OneUptime 自托管场景下的整体架可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime 自托管架构详解：从 Ingress 到数据存储的完整部署拓扑
可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载本指南以 OneUptime 官方自托管架构文档为核心系统讲解 OneUptime 在您自己的 Kubernetes 集群中自托管时的完整部署拓扑——包括终端用户如何通过 Ingress 访问 UI 与 API、核心服务与数据摄取管道如何协作、OneUptime 探针Probes如何同时监控内网与外网资源以及 PostgreSQL、Valkey、ClickHouse 三类数据存储各自的职责边界。读完本文您将能够理解 OneUptime 自托管部署的每一个关键组件与数据流并能结合 docker-compose.yml 与 Helm Chart 快速定位对应实现。说明本文主体来自仓库中的自托管架构文档原文位于 packages/App/FeatureSet/Docs/Content/fr/self-hosted/architecture.md同时提供 英文版 与 中文版。文中引用的源码与配置均来自当前仓库。总体架构一张图看懂自托管部署OneUptime 自托管时通常运行在您的环境例如 Kubernetes 集群中。官方文档用一张 Mermaid 流程图给出了典型拓扑下面对该图进行完整还原从图中可以提炼出自托管部署的五个逻辑层次层次组件职责边缘接入NGINX IngressTLS唯一的公网入口负责 TLS 终结与路由分发Web 与 API主页/控制台 UI、状态页面 UI、API 服务器、后台 Worker面向用户的界面与核心业务处理数据摄取管道探针摄取、OTel 摄取、日志摄取、服务器监控摄取、传入请求摄取各类监控与遥测数据的入口探针集群内 Probe Pod、网络上的可选 Probe VM/容器主动发起监控探测数据存储PostgreSQL、ValkeyRedis 7.2 的 BSD 许可分支、ClickHouse分层持久化边缘接入NGINX Ingress 如何路由流量文档明确指出终端用户通过集群的 IngressNGINX访问 OneUptimeIngress 将请求路由到 UI 与 API。这一点在仓库的 Nginx 包中有非常具体的实现印证。入口组件实现在 packages/Nginx/Index.ts其SERVICE_NAME即为ingress启动时会做健康检查检查 PostgreSQL 状态并挂载 ACME 证书写入等 Jobpackages/Nginx/Index.ts。路由规则定义在 packages/Nginx/default.conf.template由 packages/Nginx/envsubst-on-templates.sh 进行环境变量替换后生成实际生效的 nginx.conf。从 default.conf.template 可以看到若干与架构图一一对应的路由细节主页与控制台当BILLING_ENABLEDtrue时location /将请求代理到 Home营销/主页服务$backend_home否则代理到 Dashboard 应用$backend_app——自托管 on-prem 安装不需要营销页面因此直接进入控制台见 default.conf.template。状态页面location /status-page、location /status-page-api/重写为/api/status-page/以及/status-page-sso-api/、/status-page-oidc-api/、/status-page-identity-api/等分别路由到状态页面 UI 与其配套的 API见 default.conf.template。这些 location 同时启用了 WebSocket 升级proxy_http_version 1.1Upgrade/Connection头。gRPClocation ~ /opentelemetry.proto.collector*通过grpc_pass ${BACKEND_APP_GRPC_TARGET}将 OTLP gRPC 流量转发到 App 的 4317 端口见 default.conf.template与架构图中 UI → API 的 “REST/gRPC” 通信方式吻合。TLS 与证书HTTPS 监听端口 7850证书路径按$ssl_server_name动态解析StatusPageCerts/$ssl_server_name.crt并结合 ACME Challenge 路由/.well-known/acme-challenge实现证书自动签发见 default.conf.template 与 default.conf.template。从源码结构看Ingress 组件不仅是流量入口还承担了高吞吐摄取路径的代理职责——/telemetry、/otlp、/session-replay、/kubernetes-cost、/pyroscope、/security-events、/source-maps等摄取端点都定义了独立 location并支持通过NGINX_INGEST_ACCESS_LOG环境变量控制是否记录逐请求访问日志默认开启见 default.conf.template。Web 与 API 层核心服务及其数据依赖架构图将“Web 与 API”层划分为四个组件主页/控制台 UI、状态页面 UI、API 服务器、后台 Worker。其中API 服务器实现在 packages/App/Index.tsAPP_NAME为api。启动时序印证了架构图中 API 与三类数据存储的关系见 packages/App/Index.tsawait PostgresAppInstance.connect()—— 连接 PostgreSQL配置、状态、元数据await Redis.connect()—— 连接 Redis/Valkey并在启动时调用Queue.cleanAllQueuesOnStartup()清理历史 Job 计数BullMQ 队列await ClickhouseAppInstance.connect()与ClickhouseIngestInstance.connect()—— 连接 ClickHouse 的分析库与摄取库仅当RunDatabaseMigrationsOnBoot开启时才额外连接迁移池。健康检查会同时探测 ClickHouse、PostgreSQL、Redis 三者的状态见 packages/App/Index.ts。启动时依次初始化身份Identity、通知Notification、BaseAPI、MCP、前端Frontend、文档Docs、API 参考、Worker、遥测Telemetry、工作流Workflow、Runbook 等 FeatureSet 路由见 packages/App/Index.ts对应图中 “API 服务器作为所有 UI 与业务流量的汇聚点” 的角色。后台 Worker对应WORKER节点。从架构图看Worker 消费 Valkey 中的任务队列并写入三类数据存储API 进程本身也挂载了 Worker FeatureSet 路由await WorkersRoutes.init()并注册了OnCallShiftReminderListener见 packages/App/Index.ts说明“后台处理”逻辑可以随业务进程一起运行也可独立部署。Worker 的独立实现位于 packages/App/FeatureSet/Workers274 个 TS 文件承载监控事件处理、通知派发、告警升级等异步任务。主页与控制台 UI、状态页面 UI分别对应 packages/HomeEJS 营销/主页服务与 packages/App/FeatureSet/StatusPage、packages/App/FeatureSet/DashboardReact 控制台。状态页面在自托管场景下通过/status-page*路由对外提供公开的状态展示能力。数据摄取管道五类摄入路径与 ClickHouse 汇聚架构图将数据摄取管道分为五个节点这是 OneUptime 观测平台的关键设计——所有高吞吐遥测数据都经由专用摄取服务进入系统并最终落到 ClickHouse探针数据摄取Probe Ingest接收来自集群内外探针的监控结果。与其他摄取路径不同探针结果先进入Valkey 队列图中PROBEINGEST -- REDIS再由后台 Worker 消费并写入数据存储——这是监控结果可靠落库的关键缓冲层。从 docker-compose.yml 可以看到app服务与probe-1服务并列存在探针Probe作为独立服务运行。OpenTelemetry 数据摄取OTel Ingest接收 OTel Collector/Agent 上报的指标metrics、追踪traces直接写入 ClickHouse。对应 Nginx 的/otlplocation 与 App 中的 Telemetry FeatureSetpackages/App/FeatureSet/Telemetry含 81 个 TS 与 12 个 proto 文件。日志摄取Logs Ingest由 Fluentd / Fluent Bit 转发日志写入 ClickHouse。仓库中提供了完整的日志收集参考实现Examples/log-collectors/fluent-bit含 etc/*.yaml 配置与 Examples/log-collectors/fluentdfluent.conf另有 Examples/fluentd 可直接运行的 Node.js 示例。Nginx 侧对应location /fluentd/logs。服务器监控数据摄取Server Monitor Ingest接收服务器监控 Agent 上报的数据写入 ClickHouse。对应仓库中的 agents/InfrastructureAgentGo 实现采集 CPU、内存、磁盘、网络、负载等主机指标与 agents/DockerAgent、agents/KubernetesLogTailer 等 Agent 家族。传入请求数据摄取Incoming Request Ingest接收外部请求事件如 Webhook、Incoming Request 监控写入 ClickHouse。Nginx 侧对应location /incoming-request-ingestProbe 侧有对应的IncomingRequestIngressAPI见 packages/Probe/Index.ts。这种“专用摄取端点 ClickHouse 汇聚”的设计使得指标、追踪、日志与请求事件可以在同一套分析存储中统一查询而不会挤占 PostgreSQL 的 OLTP 负载。探针内外网监控的关键节点架构图中OneUptime 探针Probes是唯一同时与“集群内”和“集群外”打交道的组件部署位置探针可以运行在集群内图中 P1官方推荐方式也可以作为可选的 VM/容器部署在您网络的其它位置图中 P2。这种弹性部署允许探针贴近被监控目标。监控协议探针通过HTTPS / TCP / Ping / DNS / 自定义等协议与目标资源交互图中EXT -- P1/P2与INT -- P1/P2。监控范围内部/私有服务防火墙之后的应用、数据库、内部服务如公司内网的业务系统外部/公共资源公网网站、公开 API、SaaS 服务如对外官网、第三方 API。结果回传探针将监控结果发送到集群内的探针数据摄取端点经 Valkey 排队后由后台 Worker 处理落库。探针服务的实现位于 packages/Probe从 packages/Probe/Index.ts 的导入可以看到其职责全貌注册服务Register、获取监控列表FetchList、执行监控测试FetchMonitorTest、网络设备发现Discovery/FetchScans、NetFlow 接收NetFlowReceiver、SNMP Trap 接收SnmpTrapReceiver、Syslog 接收SyslogReceiver、私有网络监控策略PrivateNetworkMonitorPolicy与代理配置ProxyConfig等。其中PrivateNetworkMonitorPolicy与 文档 private-network-access.md 相互呼应——探针既负责监控内网也必须遵循私有网络访问策略。对于需要监控防火墙内服务的场景探针的“贴近网络部署”能力至关重要您也可以参考 agents/DockerAgent 等 Agent 以容器方式部署在目标网络中实现更细粒度的服务器监控。数据存储三库分工与外部存储说明架构图给出了清晰的数据存储分工存储数据用途定位PostgreSQL配置、状态、元数据关系型业务数据项目、监控项、告警、用户等ClickHouse指标、追踪、日志分析型列式存储承载高吞吐遥测数据Valkey缓存、队列、会话缓存与 BullMQ 任务队列Redis 7.2 的 BSD 许可分支文档特别说明如果您使用外部 PostgreSQL、Redis 或 ClickHouse 而非内置版本API/Worker/摄取服务只需将连接指向您的外部端点即可逻辑流程保持不变。仓库对此提供了充分支撑ClickHouse目录Clickhouse包含完整的部署配置主配置 Clickhouse/config.xml、集群配置 Clickhouse/config.d/cluster.xml、系统日志 TTL 策略 Clickhouse/config.d/system-log-ttl.xml以及分布式写入调优参数 Clickhouse/users.d/distributed-insert-tuning.xml。ClickHouse 相关运维指南见 Clickhouse/Docs/ClickhouseOps.md。数据库连接层API/Worker 通过Common/Server/Infrastructure/下的PostgresDatabase、ClickhouseDatabase含ClickhouseAppInstance、ClickhouseIngestInstance、ClickhouseMigrationInstance、Redis、Queue等基础设施模块统一管理连接见 packages/App/Index.ts这也解释了为何切换外部存储只需改连接端点。Kubernetes 部署若使用 Helm Chart可参考 HelmChart/Public/oneuptime/values.yaml 配置存储端点PostgreSQL 与 ClickHouse 的 Operator 迁移方案分别见 HelmChart/Docs/MigratePostgresStandaloneToOperator.md 与 HelmChart/Docs/MigrateClickhouseStandaloneToOperator.md。从架构图到实际部署Docker Compose 中的服务布局架构图中的组件在 docker-compose.yml 中均有对应服务。从该文件顶层的服务声明见 docker-compose.yml可以看到postgres、valkey、clickhouse三类存储服务appAPI/UI/Worker 一体化镜像、probe-1探针、runner代码执行 Runner、ingressNginx 入口等应用服务。这种“一个app服务承载 Web/API/Worker 独立probe服务”的编排方式与架构图中“核心服务 探针”的分层完全对应而在 Kubernetes 场景下HelmChart/Public/oneuptime 则将 API、Worker、摄取等拆分为更细的 Deployment便于水平伸缩。小结OneUptime 自托管架构可以概括为终端用户经 NGINX IngressTLS进入系统路由到主页/控制台与状态页面 UIUI 通过 REST/gRPC 调用 API 服务器API 与后台 Worker 读写 PostgreSQL配置与元数据、Valkey缓存与队列和 ClickHouse遥测分析数据集群内外的探针通过 HTTPS/TCP/Ping/DNS 等协议监控内部与外部资源结果经探针摄取进入 Valkey 队列后由 Worker 落库OTel、Fluentd/Fluent Bit、服务器 Agent 等遥测源则通过专用摄取端点直接写入 ClickHouse。这张架构图不仅是理解 OneUptime 自托管部署的入口也是排查问题流量从哪进、数据落到哪、规划高可用外部存储、多探针部署和扩展能力新增摄取端点的参照系。相关部署文档可继续阅读 HelmChart/Docs/Helm.md、HelmChart/Docs/Kubernetes.md 以及 docker-compose.yml。赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime 自托管架构全解析从 Ingress 到数据存储的完整数据流与部署拓扑OneUptime 自托管架构全解析从 Ingress 到数据存储的完整数据流与部署拓扑 导读 本篇技术指南以官方自托管架构文档为核心为你拆解 OneUpt可观测性后端运维前端云原生微服务AI AgentOneUptime 自托管架构全解从 Ingress 到数据存储的完整数据流剖析OneUptime 自托管架构全解从 Ingress 到数据存储的完整数据流剖析 本文基于 packages/App/FeatureSet/Docs/Cont可观测性后端运维前端云原生微服务AI AgentOneUptime 自托管架构深度解析从 NGINX 入口到 Probe 探针与数据存储的完整拓扑OneUptime 自托管架构深度解析从 NGINX 入口到 Probe 探针与数据存储的完整拓扑 导读 本文围绕 OneUptime 自托管场景下的整体架可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考