日志组件选择指南

在 ACP 4.4 上安装 Logging 模块时,需要为每个存储集群选择两个存储后端之一:

  • ClickHouse(通过 Alauda Container Platform Log Storage Management 全新安装)——推荐用于高吞吐量和对成本敏感的保留场景。
  • OpenSearch(通过 Alauda Container Platform Log Storage Management 全新安装)——推荐用于重视 Lucene 风格查询体验的场景。

两者使用相同的 operator——Alauda Container Platform Log Storage Management——并在 PlatformLogForward.spec.externalStorage.type 中选择后端。

早期版本提供的 Elasticsearch 后端在 ACP 4.4 上已不再提供。从 ACP 4.2 或 4.3 上的 Elasticsearch 升级的客户必须在升级过程中将数据迁移到 ClickHouse 或 OpenSearch——请参阅升级指南。下方的比较表仍列出 Elasticsearch,以便升级客户权衡迁移目标。

本页面会比较这些选项,帮助您在安装前做出选择。

WARNING
  • 每个存储集群选择一个后端。不要在同一存储集群上同时部署 ClickHouse 和 OpenSearch。
  • DevOps 产品目前不支持将 Jenkins pipeline 执行记录归档到 ClickHouse 或 OpenSearch。如果 Jenkins pipeline 归档是硬性要求,则 ACP 4.4 平台目前无法满足该要求;请在规划迁移前与平台团队沟通。
  • ServiceMesh 产品目前仅与 Elasticsearch 后端集成。如果 ServiceMesh 日志集成是硬性要求,则 ACP 4.4 平台目前同样无法满足该要求;请在规划迁移前与平台团队沟通。
  • ClickHouse 后端不支持仅 IPv6 或 IPv6 双栈工作负载集群。

架构概览

ClickHouse

用于 OLAP 工作负载的列式数据库。压缩效果好,聚合速度快,并且可以与 S3 良好配合,实现分层冷存储。权衡之处在于:没有倒排索引,因此关键字搜索是 LIKE 风格的扫描。

OpenSearch

从 Elasticsearch 分叉而来的分布式搜索引擎。对日志记录执行基于倒排索引的搜索;支持关键字高亮和分面查询,临时查询体验出色。权衡之处在于:对于相同的摄取量,每条记录占用的存储空间更大,并且需要更多 CPU。

Elasticsearch(仅供升级参考)

早期版本使用的 Lucene 后端。无法在 ACP 4.4 上安装;下方比较中保留该行,以便从 ACP 4.3 Elasticsearch 迁移的客户将其作为与两个受支持后端进行同类比较的参考。

功能比较

ClickHouseOpenSearchElasticsearch(上一版本)备注
可用于全新安装 4.4是是否升级期间仍可读取 Elasticsearch;必须迁移到 ClickHouse 或 OpenSearch。
高可用性是是是
水平扩展是是是
查询体验弱(仅支持 SQL)强(Lucene DSL)强(Lucene DSL)OpenSearch 和 Elasticsearch 提供 Lucene 风格的搜索;ClickHouse 仅提供 SQL。
每个摄取单元的资源使用量低中高经验法则:要维持 20,000 条日志/秒,大约需要 3 个 ClickHouse 副本(2C/4G),或一个包含 3 个主节点 + 5 个数据节点的 OpenSearch 集群(2C/4G + 8C/16G),或一个规模相近的 Elasticsearch 集群。
每个节点的摄取吞吐量高中中有关 ACP 测试的配置,请参阅日志组件容量规划。
S3 分层存储是(通过 PLF.spec.clickhouse.tieredPolicy 实现热/冷分层)OpenSearch 上的 ISM 策略Elasticsearch 上的 ILM 策略只有 ClickHouse 能够作为 ACP 管理的功能将冷数据推送到 S3;OpenSearch 和 Elasticsearch 的分层由自行管理的策略负责。
中文全文搜索子字符串匹配analysis-ik 插件(ACP OpenSearch 必需)analysis-ik 插件OpenSearch 安装必须包含 analysis-ik;否则,平台的日志查询页面会返回 400。
Community 活跃度不断增长活跃(由 Amazon 主导的分支)活跃(由 Elastic 主导)
仅 IPv6 工作负载集群不支持支持支持

建议

  • 您希望为大量日志选择最具成本效益的后端,并且可以接受仅使用 SQL 搜索。安装 Alauda Container Platform 日志存储管理,并设置 PlatformLogForward.spec.externalStorage.type: clickhouse。如果较长的保留时间推高了存储费用,请启用 S3 分层存储。

  • 您依赖 Lucene 风格的关键词搜索、突出显示或分面查询,或者已经熟悉 Elasticsearch DSL。安装 Alauda Container Platform 日志存储管理,并设置 PlatformLogForward.spec.externalStorage.type: opensearch。应用 PLF 之前,请确保每个 OpenSearch 节点上都已安装 analysis-ik 插件。

  • 您正在从基于 Elasticsearch 的 ACP 4.2 或 4.3 升级。ACP 4.4 不提供 Elasticsearch 后端,因此您必须进行迁移。请在上方选择 ClickHouse 或 OpenSearch,并按照从 Elasticsearch 日志存储升级和历史数据迁移中的说明执行具体迁移。

已知的 OpenSearch 后端限制

以下行为已在实际运行的 OpenSearch 后端安装中观察到。ClickHouse 后端不存在这些问题。在为生产工作负载选择 OpenSearch 之前,请权衡这些问题与“Lucene 风格查询”的优势;如果其中任何一项构成阻碍,请选择 ClickHouse。

区域OpenSearch 上的表现影响
记录时间戳Kafka 源会使用摄取时间覆盖记录时间戳。日志、事件和审计都会受到影响。控制台中显示的时间戳是记录到达 aggregate-vector pod 的时间,而不是应用程序生成日志的时间。针对源时间的时间范围查询(例如“显示事件发生前 5 分钟发生的情况”)会漏掉记录。
bulk breaker 的背压在随附的默认配置中,OpenSearch sink 没有用于逐项拒绝的 retry_partial。bulk breaker 触发时(429 / rejected_execution_exception),整个批次会被静默丢弃。某个实际集群在一次事故中丢失了约 ~79k 条记录。设置 spec.aggregateVector.sinks.opensearch.retryPartial: true——这是较新构建版本当前的基线默认值,但请在即将安装的集群上重新确认。
项目级保留项目范围的日志保留覆盖设置(cpaas.io/project.hotDataRetentionDays、cpaas.io/project.logPolicyEnabled)在 OpenSearch 上不会生效。operator 会跳过 log-policy-config,而用于协调 ISM 策略的 razor-api cron job 只读取、从不写入。每个项目都会保留平台默认的时间。如果按项目设置保留时间是合规要求,请不要选择 OpenSearch。请参阅如何设置项目冷数据的保留时间。
审计 topic 自愈如果删除审计 KafkaTopic,OpenSearch 数据路径不会自动自愈——必须重新创建 topic 并重启 aggregate-vector 审计 consumer 后,审计摄取才会恢复。审计 topic 发生 operator 侧事故时需要手动干预。
索引副本即使 PLF 或模板似乎声明了 1,可组合索引模板仍会附带 number_of_replicas: 0。应按索引(GET /_cat/indices?v)验证 OpenSearch 副本的高可用性声明,而不要仅依据 PLF 规范进行判断。

这些问题会作为 operator 侧的独立后续事项进行跟踪,可能会在后续的 log-storage-operator 版本升级中关闭;以上列表反映的是截至 2026-09 的状态。

诊断路径

最常见的首个表现是“按应用程序时间戳附近的时间范围进行筛选时,查询返回零条结果”。这属于上述时间戳覆盖问题,而不是查询问题。在判定数据缺失之前,请将 SELECT count() FROM ... WHERE timestamp BETWEEN a AND b 与不受时间范围限制的 SELECT count() 进行比较。