企业官网建设流程全解析

OneUptime 自托管容量规划指南：Kubernetes/Helm 部署的数据库与计算资源尺寸估算

【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime

自托管 OneUptime（开源监控与可观测性平台）时，合理的容量规划直接决定了平台的稳定性与成本。本文以 OneUptime 官方《 اندازه‌گذاری و برنامه‌ریزی ظرفیت》（容量规划与测量）文档为核心，完整覆盖其 PostgreSQL、Valkey、ClickHouse 三大数据存储的驱动因素、存储计算公式、分档建议、高可用配置与保留期策略，并结合仓库中的 HelmChart/Public/oneuptime/values.yaml 与 TelemetryRetentionConfig.ts 等源码给出可落地验证的配置依据。读完后，你将能够为自己的集群规模选型出合理的 vCPU/内存/磁盘配置，并建立一套"先测量、后扩容"的容量管理方法。

动手之前先记住一点：OneUptime 的 Helm 图表默认不设置任何 CPU/内存 requests/limits，PostgreSQL 与 ClickHouse 的持久卷默认只有25 GiB。这些默认值只是为了保证图表在任何集群上都能安装运行，绝不是生产级尺寸。除快速试用外，务必按下文的推荐值显式配置资源与存储。

如果采用单机 Docker Compose 部署，容量规划要简单得多——参考 Docker Compose 安装指南（官方推荐：16 GB RAM、8 核、400 GB 磁盘）。

三个数据存储各自的规模驱动因素

OneUptime 在生产环境依赖三个数据存储，它们的扩容驱动因素完全不同，因此必须独立规划，不能用一个统一公式套用：

对象存储（S3/MinIO）并非运行 OneUptime 的必需组件。它仅可选地用于数据库备份（PostgreSQL 经 CloudNativePG 的 Barman 插件，或 ClickHouse 的clickhouse-backup）。OneUptime不会把遥测数据分层（tiering）到对象存储——这一点直接影响下面的保留期规划（详见"保留期及其对存储的影响"一节）。

在仓库的 values.yaml 中可以看到三个存储的默认配置：

• postgresql：内置 PostgreSQL StatefulSet，默认持久卷25Gi，max_connections = 500；
• clickhouse：内置 ClickHouse StatefulSet，默认持久卷25Gi，固定镜像版本26.7；
• valkey：内存缓存/队列后端，持久化默认关闭（appendonly no、save ""），镜像为valkey/valkey:9.1-alpine。

三个组件都支持通过postgresql.enabled、clickhouse.enabled、valkey.enabled关闭并切换到外部托管服务（externalPostgres、externalClickhouse、externalValkey）。

ClickHouse——存储的主导者

几乎全部磁盘空间和相当大比例的 RAM 都归 ClickHouse 所有，因为每一行日志、每一个指标点、每一条追踪 span 和异常记录都存在这里。

存储计算公式

ClickHouse disk ≈ (daily raw telemetry GB ÷ compression) × retention days × replicas × 1.3 (headroom)

其中压缩比（compression）因信号类型而异：

• 日志：压缩效果好，约为5:1；
• 指标：压缩效果较差，约为2:1，且高基数标签（high-cardinality labels）会同时加速磁盘与内存的消耗，比原始体量增长更快——请严格控制标签基数；
• 追踪：取决于 span 的特征，介于两者之间。

实际测算示例

以一个10 个集群的舰队为例，每个集群约 10 个节点 / 100 个 Pod，日志级别为 INFO，每集群 30 天约产生50~150 GB 原始日志（每集群每天约 1.7~5 GB）。加上指标与追踪，压缩后整个舰队每天的压缩遥测数据预算约为5~15 GB/天：

注意存储随保留期线性增长——90 天窗口的成本约为 30 天窗口的 3 倍。

RAM 与磁盘类型

• 必须使用 NVMe/SSD：遥测写入密集、聚合读取突发性强，ClickHouse 在机械盘上会严重性能退化；
• 给 ClickHouse 充足的 RAM：聚合查询非常吃内存。经验法则：RAM 取压缩后的热数据集（近期被查询的数据）的 25%~50%，且任何真实的生产舰队最低 16 GB；
• 对指标基数进行治理：这是影响 ClickHouse 内存与磁盘的最大杠杆。在采集层强制低基数的标签约定，并持续监测活跃序列数（active series）。

PostgreSQL——配置与状态

PostgreSQL 存储配置与运行状态（而非遥测数据），因此增长平缓，规模远小于 ClickHouse。即使是大型部署，通常也只有几十 GB 的量级。默认的25 GiB适合小型安装；较大规模建议按50~100 GB规划，为事件/告警历史预留余量。

如果运行了很多应用、Worker 与 Probe 副本，数据库连接数可能比存储更早成为瓶颈。为此，OneUptime 的 Helm 图表内置了可选的PgBouncer连接池（pgbouncer.enabled）——多副本部署应启用它。

仓库中的相关配置印证了这一点：

• postgresql.primary.configuration默认max_connections = 500，注释明确说明该值必须大于"（DATABASE_MAX_OPEN_CONNECTIONS× 连接 PostgreSQL 的 Pod 数）+ 复制/超级用户/启动迁移的余量"（values.yaml）；
• 应用层通过deployment.databaseMaxOpenConnections（默认每 Pod 池上限 50）控制单 Pod 连接数；接入 PgBouncer 后应调低该值，避免每个 Pod 各自持有 50 个后端连接（values.yaml）；
• pgbouncer块默认poolMode: transaction、defaultPoolSize: 400、maxDbConnections: 450，与后端max_connections = 500配套，给复制、超级用户与迁移留出约 100 个连接余量（values.yaml）；
• 图表同时为 PostgreSQL 预置了 SSD 友好的调优参数：random_page_cost = 1.1、effective_io_concurrency = 200、work_mem = 16MB、maintenance_work_mem = 256MB、max_wal_size = 4GB、lock_timeout = '3s'。

Valkey——缓存、队列与会话

缓存层运行 Valkey——Redis 7.2 的 BSD 许可分支——同时承担缓存、任务队列与会话存储的角色。任何兼容 Redis 协议的服务器都可以替代它；下面的尺寸建议依然适用。

Valkey受内存约束，持久化默认关闭（这里的 Redis 不是事实来源，可以重建）。应基于预期队列深度与并发会话数来规划，2~8 GB 内存可覆盖大多数部署。注意默认驱逐策略是noeviction（maxmemory-policy noeviction，见 values.yaml）——如果持续负载下队列不断堆积，请密切监控 Redis 内存，否则写入会在内存满时被拒绝。

应用层计算资源

除了数据存储，还需要为无状态工作负载（ingress、Web/API、Worker、Probe）规划资源。它们默认都只有1 个副本且无资源限制——请显式配置。

图表内置了KEDA，可让 Worker 和 Probe 依据自身队列深度自动扩缩容；负载波动时应启用。扩容逻辑：Worker 随遥测处理/摄取量扩容，Probe 随活跃监控项数量扩容。

仓库实现细节（values.yaml）：

• app与worker均提供workerConcurrency: 100、telemetryConcurrency: 100，以及遥测扇入写入器（fan-in writer）参数：telemetryFanInMaxBatchRows: 100000、telemetryFanInMaxConcurrentInserts: 4、telemetryFanInMaxPendingRows: 200000——批量写入 ClickHouse，避免横向扩容时插入并发爆炸；
• worker.enabled可将队列消费拆分为独立 Deployment，避免重遥测处理阻塞 API 事件循环；
• telemetryWriter.enabled提供固定规模的写入层，使 ClickHouse 插入负载恒定为replicaCount × telemetryFanInMaxConcurrentInserts，与 Worker 舰队规模解耦；
• 各服务的keda块（queueSizeThreshold、pollingInterval、cooldownPeriod、fallback）依据 BullMQ 队列积压自动扩缩，fallback.replicas可在 KEDA 指标不可读时防止 HPA 抖动；
• 全局autoscaling块（默认 CPU/内存目标 80%）与podDisruptionBudget（默认maxUnavailable: 1）为有状态服务之外的负载提供通用扩缩与中断保护。

起步分档（Sizing Tiers）

选择最接近你环境的一档作为起点，然后持续观测真实消耗（kubectl top pods、ClickHouse/Postgres 磁盘增长），再行调整。

• 小型 / 概念验证（PoC）——1~3 个集群，最多 30 个节点，每天最多 5 GB 原始遥测，保留 30 天。
• 中型 / 生产舰队——约 10 个集群、约 100 个节点，每天 10~30 GB 原始遥测，保留 30~90 天。
• 大型 / 多舰队——超过 50 个集群、超过 500 个节点，每天超过 100 GB 原始遥测，保留 90 天。

这些尺寸只覆盖 OneUptime后端。运行在每个被监控集群上的 OneUptime 采集器（collectors）需要单独规划——参见 Kubernetes 采集器（kubernetes-agent） 的尺寸分档。

高可用（HA）配置

图表内置的数据存储默认是单实例运行。生产级 HA 需要：

• PostgreSQL——启用随图表附带的 CloudNativePG 运算符（postgresOperator.cnpg.enabled），配置3 个实例（1 主 + 2 热备）实现自动故障转移。相关参数在 values.yaml：instances、synchronousReplicas（同步法定人数复制，>0 时每次提交需等待 N 个备库确认）、backup（基于 CSI 卷快照，默认每天 03:00）；
• ClickHouse——启用随图表附带的 Altinity 运算符（clickhouseOperator.altinity.enabled），每分片至少 2 副本，并配置3 个 ClickHouse Keeper 节点组成法定人数；当单个节点的磁盘或 RAM 触顶时，增加分片。相关配置见 values.yaml：cluster.shardsCount、cluster.replicasCount、keeper.replicas（默认 3、持久卷 10 GiB）、zookeeper.nodes（自带 ZooKeeper/Keeper 的替代方案）；
• Valkey——图表没有内置的图表内复制机制。如需 HA，请将 OneUptime 指向外部托管 Redis（或集群化部署）。

注意：启用 CNPG 或 Altinity 运算符会引导一个全新的空集群，不会从现有 StatefulSet 迁移数据——具体迁移步骤参见 HelmChart/Docs/Postgres.md 与 HelmChart/Docs/Clickhouse.md。

保留期及其对存储的影响

遥测保留期以ClickHouse 中的 TTL（按天）方式实施，按项目配置，并可按信号类型（日志、指标、追踪、剖析）与分桶（如按日志严重级别）进行细粒度覆盖。硬编码默认值为 15 天。

这一点在源码中有明确证据：Common/Types/Telemetry/TelemetryRetentionConfig.ts 定义了HARDCODED_DEFAULT_TELEMETRY_RETENTION_IN_DAYS = 15，并实现了完整的保留期解析链（由窄到宽）：

1. 服务级service[pillar].byX[bucketKey]（如按日志严重级别 / span 状态分桶）；
2. 服务级service[pillar].default；
3. 服务级service.retainTelemetryDataForDays；
4. 项目级project[pillar].byX[bucketKey]；
5. 项目级project[pillar].default；
6. 项目级project.defaultTelemetryRetentionInDays；
7. 兜底硬编码15 天。

由于保留期会直接乘上 ClickHouse 存储，请在规划磁盘之前先决定保留策略。OneUptime不会自动把旧遥测归档或分层到对象存储——若要满足多年的合规保留，请拉长保留窗口并按比例扩容 ClickHouse 存储（或自行导出到你选定的外部归档系统）。

先测量，后承诺

遥测体量因应用日志级别、命名空间数量、抓取间隔以及是否在局部开启了 DEBUG 日志而差异极大。请把上面的分档当作起点：

至少对生产环境做四周的插桩观测，测量每个信号每天的真实 GB 数，然后基于真实数据规划保留期与存储——而不是靠估算直接下单。

相关文档

• Docker Compose 安装——单机尺寸建议
• 自托管架构——各组件如何协同
• Kubernetes 采集器——采集器（数据面）尺寸分档
• Helm 生产检查清单——部署前逐项核对
• HelmChart 数据库说明——三种数据存储的运维细节

【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime