上线生产环境

在生产环境部署 ClickStack 时，为确保安全性、稳定性以及正确配置，还需要额外考虑若干事项。这些事项会因所使用的分发方式——开源或托管——而有所不同。

托管版 ClickStack

对于生产环境部署，推荐使用 Managed ClickStack。它默认采用业界标准的安全实践，包括增强的加密、身份验证与连接能力以及托管访问控制，并同时提供以下优势：

• 计算资源可独立于存储自动伸缩
• 基于对象存储的低成本且几乎无限的数据保留能力
• 能够使用 Warehouses 将读写工作负载进行独立隔离
• 集成身份验证
• 自动化备份
• 无缝升级

在使用 Managed ClickStack 时，请遵循适用于 ClickHouse Cloud 的这些最佳实践。

保护摄取安全

默认情况下，当在开源发行版之外部署时，ClickStack OpenTelemetry Collector 未进行安全加固，并且在其 OTLP 端口上不要求身份验证。

要实现安全摄取，请在使用 OTLP_AUTH_TOKEN 环境变量部署 collector 时指定身份验证令牌。有关更多详细信息，请参见“Securing the collector”。

创建摄取用户

建议为 OTel collector 创建一个专用用户，用于向 Managed ClickHouse 进行摄取，并确保摄取数据被发送到特定的数据库，例如 otel。有关更多详细信息，请参见“Creating an ingestion user”。

配置生存时间 (TTL)

请确保为你的 Managed ClickStack 部署生存时间 (TTL)进行了适当配置。这将控制数据的保留时长——默认值为 3 天，通常需要进行调整。

资源估算

以下内容基于您预期的摄取量，提供了一个用于估算 ClickStack 部署所需计算和存储资源的模型。得出的数值仅为估算值，应作为初始基线使用，而非固定结论。实际需求取决于查询复杂度、并发度、保留策略以及摄取处理量的波动。请始终监控资源使用情况，并按需扩缩容。

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

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

这就是您应根据现有日志、链路追踪和指标管道来估算的数值。下表中的存储数值已在该原始数据量基础上应用了假定的 10x 压缩率。

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

工作负载	预估资源
摄取	每 10 MB/s 的持续摄取处理量需要 1 个 vCPU
查询	每 1 QPS 以及每 10 MB/s 的持续摄取处理量需要 1 个 vCPU

查询与摄取隔离

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

假设

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

下表基于逐步增加的每秒摄取处理量 (单位为 MB) 给出了示例配置，同时列出了对应的每月数据量 (单位为 TB) 。这假设 ClickStack 在所有查询类型 (搜索、仪表板、告警) 上的持续平均负载为 1 QPS。

MB/s	TB/月	摄取 CPU	查询 CPU	总 CPU	总存储 (每月) (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

有关如何进一步细化适用于你环境的容量估算假设的更多详细信息，请参见“Refining sizing assumptions for your environment”。

隔离可观测性工作负载

如果你在一个已经支持其他工作负载 (例如实时应用分析) 的现有 ClickHouse Cloud 服务中新增 ClickStack，强烈建议将可观测性流量进行隔离。

使用 Managed Warehouses 创建一个专用于 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"  # Only if needed for the API
# Avoid exposing internal ports like ClickHouse 8123 or 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 生成强密钥:

openssl rand -hex 32

避免将密钥提交到源代码控制系统。在生产环境中,请考虑使用环境变量管理工具(例如 Docker Secrets、HashiCorp Vault 或特定环境的 CI/CD 配置)。

安全摄取

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

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

创建摄取用户

建议为 OTel collector 创建专用用户以便将数据摄取到 ClickHouse，并确保将摄取的数据发送到特定的数据库，例如 otel。有关更多详细信息，请参阅"Creating an ingestion user"。

ClickHouse

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

安全最佳实践

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

ClickHouse OSS 开箱即用提供了强大的安全功能。但是,这些功能需要配置:

• 使用 TLS，在 config.xml 中通过配置 tcp_port_secure 和 <openSSL> 实现。参见 guides/sre/configuring-tls。
• 为 default 用户设置强密码，或将其禁用。
• 避免将 ClickHouse 对外暴露，除非明确需要这样做。默认情况下，除非修改 listen_host，ClickHouse 只绑定到 localhost。
• 使用身份验证方式，例如密码、证书、SSH 密钥或外部身份验证器。
• 限制访问，使用 IP 过滤和 HOST 子句。参见 sql-reference/statements/create/user#user-host。
• 启用基于角色的访问控制 (RBAC) 以授予更细粒度的访问权限。请参阅 operations/access-rights。
• 使用 quotas、settings profiles 和只读模式强制执行配额和限制。
• 对静态数据进行加密，并使用安全的外部存储。请参阅 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 安全检查清单。