上线生产环境
在生产环境部署 ClickStack 时，为确保安全性、稳定性以及正确配置，还需要额外考虑若干事项。这些事项会因所使用的分发方式——开源或托管——而有所不同。
- 托管版 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 时，必须预留足够的计算资源来同时处理摄取和查询工作负载。下述估算基于你计划摄取的可观测性数据量，提供一个基准起点。
这些建议基于以下假设：
- 数据量是指每月的未压缩摄取量，适用于日志和追踪。
- 查询模式是典型的可观测性用例，大多数查询针对最近的数据，通常是过去 24 小时。
- 摄取在整个月内相对均匀。如果预计会有突发流量或峰值，应预留额外余量。
- 存储通过 ClickHouse Cloud 对象存储单独处理，不会对保留时长构成限制。我们假设长时间保留的数据被访问的频率较低。
对于经常查询长时间范围、执行重型聚合或需要支持大量并发用户的访问模式，可能需要更多计算资源。
推荐基线规格
| 每月摄取量 | 推荐计算资源 |
|---|---|
| < 10 TB / month | 2 vCPU × 3 个副本 |
| 10–50 TB / month | 4 vCPU × 3 个副本 |
| 50–100 TB / month | 8 vCPU × 3 个副本 |
| 100–500 TB / month | 30 vCPU × 3 个副本 |
| 1 PB+ / month | 59 vCPU × 3 个副本 |
这些数值仅为估算值，应作为初始基线使用。实际需求取决于查询复杂度、并发度、保留策略以及摄取吞吐量的波动情况。请始终监控资源使用情况，并按需扩缩容。
隔离可观测性工作负载
如果你在一个已经支持其他工作负载（例如实时应用分析）的现有 ClickHouse Cloud 服务中新增 ClickStack，强烈建议将可观测性流量进行隔离。
使用 Managed Warehouses 创建一个专用于 ClickStack 的子服务。这样可以：
- 将摄取和查询负载与现有应用相互隔离
- 独立扩缩可观测性工作负载
- 防止可观测性查询影响生产分析
- 在需要时在服务之间共享相同的底层数据集
这种方式可以确保你现有的工作负载不受影响，同时允许 ClickStack 随着可观测性数据的增长而独立伸缩。
对于更大规模的部署或定制规格建议，请联系支持以获取更精确的评估。
网络和端口安全
默认情况下,Docker Compose 会在主机上暴露端口,使其可从容器外部访问——即使启用了 ufw(Uncomplicated Firewall)等工具。这是因为 Docker 网络栈可以绕过主机级防火墙规则,除非进行显式配置。
建议：
仅暴露生产使用所必需的端口。通常包括 OTLP 端点、API 服务器和前端。
例如,在 docker-compose.yml 文件中删除或注释掉不必要的端口映射:
有关隔离容器和加强访问控制的详细信息,请参阅 Docker 网络文档。
Session Secret 配置
在生产环境中,必须为 ClickStack UI (HyperDX) 的 EXPRESS_SESSION_SECRET 环境变量设置强随机值,以保护会话数据并防止篡改。
以下是将其添加到应用服务的 docker-compose.yml 文件的方法：
您可以使用 openssl 生成强密钥:
避免将密钥提交到源代码控制系统。在生产环境中,请考虑使用环境变量管理工具(例如 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。有关更多详细信息，请参阅"创建摄取用户"。
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_modecancel_http_readonly_queries_on_client_closewait_end_of_query
默认情况下，OSS 和 ClickHouse Cloud 中的 default 用户会拥有这些权限，但建议创建一个具有这些权限的新用户。
配置生存时间 (TTL)
确保已为您的 ClickStack 部署适当配置生存时间 (TTL)。这控制着数据的保留时长——默认的 3 天通常需要修改。
MongoDB 使用指南
请遵循官方 MongoDB 安全检查清单。
