投入生产环境

将 ClickStack 投入生产环境

在生产环境中部署 ClickStack 时，还需额外考虑一些事项，以确保安全性、稳定性以及配置无误。具体考虑因素会因所使用的版本——开源版或托管版——而有所不同。

托管 ClickStack

对于生产部署，建议使用托管 ClickStack。它默认采用符合行业标准的安全实践，包括增强的加密、身份验证与连接能力，以及托管访问控制；此外还提供以下优势：

• 计算资源可独立于存储自动扩缩容
• 基于对象存储的低成本、近乎无限的数据保留能力
• 能够借助仓库独立隔离读写工作负载
• 集成式身份验证
• 自动化备份
• 无缝升级

使用托管 ClickStack 时，请遵循 ClickHouse Cloud 的这些最佳实践。

​

保护摄取

默认情况下，在开源发行版之外部署 ClickStack OpenTelemetry Collector 时，它并未启用安全保护，且其 OTLP 端口无需身份验证。

要保护摄取，请在部署 collector 时通过 OTLP_AUTH_TOKEN 环境变量指定身份验证令牌。更多详情，请参阅”保护 collector”。

​

创建摄取用户

建议为 OTel collector 创建一个专用用户，用于向托管 ClickHouse 摄取数据，并确保摄取数据发送到特定数据库，例如 otel。更多详情，请参阅”创建摄取用户”。

​

配置生存时间 (TTL)

请确保已为你的托管 ClickStack 部署正确配置生存时间 (TTL)。它决定数据的保留时长——默认的 3 天通常需要调整。

​

估算资源

以下内容提供了一个模型，用于根据您预期的摄取量估算 ClickStack 部署所需的计算和存储资源。得出的数值仅为估算值，应作为初始基线参考——并非固定不变的标准答案。实际需求取决于查询复杂度、并发度、保留策略以及摄取吞吐量的波动情况。请始终监控资源使用情况，并根据需要进行扩缩容。

所有数值均基于未压缩的原始摄取数据

本页中的所有数字——吞吐量 (MB/s、TB/月) 、CPU 规模和存储——都以未压缩的原始摄取量表示，也就是应用程序生成并发送到 OpenTelemetry collector、在应用任何压缩之前的数据大小。

您应根据现有的日志、链路追踪和指标管道来估算这一数值。下表中的存储数值已经按该原始数据量套用了假设的 10x 压缩率。

部署 ClickStack 时，需要为两类相互独立的工作负载预配计算资源：摄取 和 查询。

Workload	Estimated resources
Ingest	持续摄取吞吐量每 10 MB/s 需要 1 vCPU
Query	每 1 QPS 以及每 10 MB/s 的持续摄取吞吐量需要 1 vCPU

查询与摄取的隔离

在大多数自管理部署中，摄取和查询共享同一组节点。在这种情况下，请将 Total CPUs 作为基线。隔离扩缩容——即分别为摄取和查询独立预配计算资源——在 ClickHouse Cloud 中可通过独立计算池 (也称为 Warehouses) 实现。

假设

• 存储采用 10x 压缩率——对于日志和链路追踪来说，这通常是一个较为保守的估计。
• 查询 SLA 假设为 P50 1.5 秒、P99 5 秒。
• 我们假设大多数查询都针对近期数据，遵循一种在约 1 小时处达到峰值、并延伸至约 6 小时的对数正态分布。对于较旧数据的查询，用户可能希望预配专用计算资源。在 ClickHouse Cloud 中，这部分计算资源在不使用时可以处于闲置状态 (因此不会产生费用) 。
• 虽然查询计算资源可以独立于摄取计算资源进行扩缩容，但它在本质上仍与摄取量相关。我们假设随着摄取量增加，数据密度也会提高，从而导致查询时扫描的数据量更大，因此需要更多查询计算资源。

下表给出了示例规格，基于以每秒 MB 为单位递增的摄取吞吐量，以及对应的每月 TB 数据量。这里假设 ClickStack 在所有查询类型 (搜索、仪表盘、告警) 上的持续平均值为 1 QPS。

MB/s	TB/month	Ingest CPUs	Query CPUs	Total CPUs	Total Storage (per month) (GB)
10	25.92	1	3	4	2,592
20	51.84	2	6	8	5,184
50	129.6	5	15	20	12,960
100	259.2	10	30	40	25,920
200	518.4	20	60	80	51,840
500	1,296	50	150	200	129,600
1000	2,592	100	300	400	259,200

有关如何针对你的环境进一步优化容量估算假设的更多详情，请参阅”针对你的环境细化容量假设”。

​

隔离可观测性工作负载

如果你要将 ClickStack 添加到一个现有的 ClickHouse Cloud 服务中，而该服务已经承载了其他工作负载 (例如实时应用分析) ，则强烈建议隔离可观测性流量。

使用 托管仓库 创建一个专用于 ClickStack 的子服务。这样你就可以：

• 将摄取和查询负载与现有应用隔离
• 独立扩缩容可观测性工作负载
• 防止可观测性查询影响生产分析
• 在需要时跨服务共享相同的底层数据

这种方法可确保现有工作负载不受影响，同时让 ClickStack 能随着可观测性数据的增长独立扩展。

对于更大规模的部署或需要自定义容量建议的场景，请联系支持团队以获得更精确的估算。

ClickStack 开源版

​

网络与端口安全

默认情况下，Docker Compose 会在宿主机上暴露端口，使其可从容器外部访问——即使启用了 ufw (Uncomplicated Firewall) 等工具也不例外。这一行为源于 Docker 网络栈的工作机制：若未进行显式配置，它可以绕过宿主机级别的防火墙规则。

建议：

仅开放生产环境所需的端口，通常包括 OTLP 端点、API 服务器和前端。

例如，删除或注释掉 docker-compose.yml 文件中不必要的端口映射：

ports:
  - "4317:4317"  # OTLP gRPC
  - "4318:4318"  # OTLP HTTP
  - "8080:8080"  # 仅在 API 需要时开放
# 避免暴露内部端口，如 ClickHouse 8123 或 MongoDB 27017。

有关隔离容器和加固访问控制的详细信息，请参阅 Docker 网络文档。

​

Session Secret 配置

在生产环境中，必须为 ClickStack UI (HyperDX) 的 EXPRESS_SESSION_SECRET 环境变量设置一个强随机值，以保护会话数据、防止篡改。

以下是如何将其添加到应用服务的 docker-compose.yml 文件中：

app:
    image: ${IMAGE_NAME_HDX}:${IMAGE_VERSION}
    ports:
      - ${HYPERDX_API_PORT}:${HYPERDX_API_PORT}
      - ${HYPERDX_APP_PORT}:${HYPERDX_APP_PORT}
    environment:
      FRONTEND_URL: ${HYPERDX_APP_URL}:${HYPERDX_APP_PORT}
      HYPERDX_API_KEY: ${HYPERDX_API_KEY}
      HYPERDX_API_PORT: ${HYPERDX_API_PORT}
      HYPERDX_APP_PORT: ${HYPERDX_APP_PORT}
      HYPERDX_APP_URL: ${HYPERDX_APP_URL}
      HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
      MINER_API_URL: 'http://miner:5123'
      MONGO_URI: 'mongodb://db:27017/hyperdx'
      NEXT_PUBLIC_SERVER_URL: http://127.0.0.1:${HYPERDX_API_PORT}
      OTEL_SERVICE_NAME: 'hdx-oss-api'
      USAGE_STATS_ENABLED: ${USAGE_STATS_ENABLED:-true}
      EXPRESS_SESSION_SECRET: "super-secure-random-string"
    networks:
      - internal
    depends_on:
      - ch-server
      - db1

您可以使用 openssl 生成一个高强度 Secret：

openssl rand -hex 32

避免将 Secret 提交到源代码管理系统。在生产环境中，建议使用环境变量管理工具 (例如 Docker Secrets、HashiCorp Vault 或针对特定环境的 CI/CD 配置) 。

​

安全摄取

所有数据摄取均应通过 ClickStack 发行版 OpenTelemetry (OTel) collector 所暴露的 OTLP 端口进行。默认情况下，需要使用启动时生成的安全摄取 API key。向 OTel 端口发送数据时必须提供此 key，可在 HyperDX UI 的 Team Settings → API Keys 中找到。

此外，建议为 OTLP 端点启用 TLS。

​

创建摄取用户

建议为 OTel collector 创建专用用户，用于将数据摄取到 ClickHouse，并确保摄取数据发送至指定数据库 (例如 otel) 。详情请参阅 “创建摄取用户”。

​

ClickHouse

自行管理 ClickHouse 实例的用户应遵循以下最佳实践。

​

安全最佳实践

如果您自行管理 ClickHouse 实例，务必启用 TLS、强制身份验证，并遵循访问加固的最佳实践。请参阅此博客文章，了解真实环境中的错误配置案例及其规避方法。

ClickHouse OSS 开箱即用，提供强大的安全功能。但这些功能需要进行配置：

• 通过 tcp_port_secure 和 config.xml 中的 <openSSL> 启用 TLS。参见 guides/sre/configuring-tls。
• 为 default 用户设置高强度密码，或将其禁用。
• 避免将 ClickHouse 对外暴露，除非你明确打算这样做。默认情况下，除非修改 listen_host，否则 ClickHouse 只会绑定到 localhost。
• 使用身份验证方法，例如密码、证书、SSH 密钥或外部身份验证器。
• 使用 IP 过滤和 HOST 子句来限制访问。参见 sql-reference/statements/create/user#user-host。
• 启用基于角色的访问控制 (RBAC) ，以授予细粒度权限。参见 operations/access-rights。
• 使用 配额、profile 和只读模式来实施配额与限制。
• 对静态数据进行加密，并使用安全的外部存储。请参见 operations/storing-data 和 cloud/security/CMEK。
• 避免将凭证硬编码。 请在 ClickHouse Cloud 中使用 命名集合 或 IAM 角色。
• 审核访问情况和查询，使用系统日志和会话日志。

另请参阅外部身份验证器和查询复杂度设置，了解用户管理及查询/资源限制的相关内容。

​

ClickStack UI 的用户权限

ClickStack UI 使用的 ClickHouse 用户只需具备 readonly 权限，并能够修改以下设置：

• max_rows_to_read (至少达到 100 万)
• read_overflow_mode
• cancel_http_readonly_queries_on_client_close
• wait_end_of_query

默认情况下，OSS 和 ClickHouse Cloud 中的 default 用户均已具备这些权限，但建议您另行创建一个拥有这些权限的新用户。

​

配置生存时间 (TTL)

请确保已为您的 ClickStack 部署适当配置生存时间 (TTL)。该设置控制数据的保留时长——默认值为 3 天，通常需要根据实际需求进行修改。

​

MongoDB 使用指南

请参阅官方 MongoDB 安全检查清单。