上线生产环境

在生产环境部署 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 天，通常需要进行调整。

资源估算

在部署 Managed ClickStack 时，务必预配足够的计算资源，以同时处理摄取和查询工作负载。以下估算值根据您计划摄取的可观测性数据量，提供了一个基准起点。

每月摄取量	推荐计算资源
< 10 TB / 月	2 vCPU × 3 个副本
10–50 TB / 月	4 vCPU × 3 个副本
50–100 TB / 月	8 vCPU × 3 个副本
100–500 TB / 月	30 vCPU × 3 个副本
1 PB+ / 月	59 vCPU × 3 个副本

这些建议基于以下假设：

• 数据量指每月未压缩摄取量，同时适用于日志和链路追踪。
• 查询模式符合典型的可观测性使用场景，大多数查询都针对近期数据，通常为最近 24 小时内的数据。
• 摄取在整个月内相对均匀。如果您预计会出现突发流量或峰值，则应预留额外余量。
• 存储通过 ClickHouse Cloud 对象存储单独处理，因此不会成为保留期限的限制因素。我们假设保留时间较长的数据不会被频繁访问。

对于经常查询更长时间范围、执行高强度聚合，或需要支持大量并发用户的访问模式，可能需要更多计算资源。

尽管对于给定的摄取吞吐量而言，两个副本即可满足 CPU 和内存需求，但我们仍建议在条件允许时使用三个副本，以实现相同的总容量并提升服务冗余性。

注意

这些数值仅为估算，应作为初始基准使用。实际需求取决于查询复杂度、并发度、保留策略以及摄取吞吐量的波动。请始终监控资源使用情况，并按需扩缩容。

隔离可观测性工作负载

如果你在一个已经支持其他工作负载 (例如实时应用分析) 的现有 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 安全检查清单。