#核心概念

#开源组件

#Vector

定位：高性能可观测性数据管道
描述：ACP Logging 使用的单二进制文件智能体，承担两种不同角色：

• 在采集器集群中的每个 nevermore pod 内，作为本地管道监视日志文件、应用转换，并将数据推送到存储集群。
• 在每个存储集群上作为名为 aggregate-vector 的 Deployment 运行，从 Kafka 消费数据，应用路由／重塑（Vector Remap Language，VRL），并将数据写入 ClickHouse 或 OpenSearch。

#Kafka

定位：分布式消息队列
描述：位于采集器与存储后端之间的缓冲层。Kafka 从 Razor 接收记录，并将其保留，直到 aggregate-vector 消费这些记录。这样可以将采集侧的突发流量与存储后端的写入吞吐解耦，并使采集器在后端恢复期间继续推进。Kafka 以 KRaft 模式运行；无需 Zookeeper。

#ClickHouse

定位：列式分析数据库
描述：一种面向 OLAP 场景设计的高性能列式存储数据库，使用 MergeTree 引擎存储日志数据。支持高速聚合查询、按时间分区、基于 TTL 的生命周期管理，以及由 S3 支持的存储放置。推荐用于日志量较大且注重保留成本的场景。

#OpenSearch

定位：分布式搜索和分析引擎
描述：从 Elasticsearch 分支而来的开源分布式搜索引擎和分析套件，使用倒排索引对日志数据进行近实时关键词搜索。当搜索体验（Lucene 风格的 DSL、关键词高亮、分面查询）比原始数据摄取吞吐量更重要时，推荐使用此组件。

#Elasticsearch

定位：分布式搜索和分析引擎（之前的后端，ACP 4.4 不再提供）
描述：ACP Logging 在早期版本中使用的基于 Lucene 的后端。在 ACP 4.4 上进行全新安装时无法选择 Elasticsearch。 使用 Elasticsearch 后端、从 ACP 4.2 或 4.3 升级的客户必须在升级过程中切换到 ClickHouse 或 OpenSearch — 迁移路径请参阅升级指南。

#ACP 日志组件

#nevermore

定位：节点级日志采集器
描述：在采集器集群的每个节点上运行的 DaemonSet。nevermore 读取容器的标准输出日志、配置的主机路径中的文件日志、Kubernetes 事件和审计记录；为这些记录添加集群 / 命名空间 / Pod 元数据；并通过 HTTP 将其转发到存储集群。nevermore 在内部使用 Vector 作为数据路径引擎。它取代了 Filebeat，后者是 ACP 4.3 及更早版本使用的采集器。

#log-storage-operator

定位：运行存储侧数据路径的 Kubernetes operator
描述：由 Alauda Container Platform Log Storage Management operator 安装（一个 operator，同时覆盖 ClickHouse 和 OpenSearch 后端）。它监视 PlatformLogForward，并派生存储侧所需的全部资源：aggregate-vector Deployment、razor Deployment、一次性 schema-migrations Job、RBAC 以及附属资源（Feature/log-center、日志策略 ConfigMap）。SRE 构建外部 ClickHouse / OpenSearch / Kafka 集群；该 operator 仅通过连接 Secret 使用这些集群的端点。后端选择位于 PlatformLogForward.spec.externalStorage.type 中，而不在 operator 安装表单中。

#Razor

定位：日志摄取和身份验证服务
描述：存储侧的 HTTP 端点，nevermore 会向其推送数据。Razor 针对平台对每个请求进行身份验证，然后将记录写入 Kafka。它以无状态 Deployment 的形式部署（在早期版本中，它是带有 Vector sidecar 的 StatefulSet）。它还充当查询代理，从 ClickHouse 读取数据，以支持平台的日志查询 API。

#aggregate-vector

定位：Kafka 到存储的接收器 Deployment
描述：用于从三个 Kafka topic（ALAUDA_LOG_TOPIC、ALAUDA_EVENT_TOPIC、ALAUDA_AUDIT_TOPIC）消费数据的 Vector Deployment，通过 VRL 转换为记录应用整形处理，以适配所选后端，然后将数据写入 ClickHouse 或 OpenSearch。它取代了 ACP 4.3 中用于 ClickHouse 的每 Pod Vector sidecar，并接替了 Lanaya 过去为 Elasticsearch 提供的职责。

#razor-api

定位：日志查询 API
描述：Alauda Container Platform Log Essentials 插件在 global 集群上发布 razor-api（ModuleInfo log-api）。razor-api 为 ACP 控制台使用的日志、事件和审计查询端点提供前端，并将底层查询路由到相应存储集群的 Razor。

#自定义资源

#PlatformLogForward (PLF)

描述：描述 Logging 安装存储侧的集群范围 CR。始终命名为 platform-default；每个存储集群恰好有一个。其 spec.externalStorage 指定 ClickHouse 或 OpenSearch 端点（通过连接 Secret），spec.externalMessageQueue 指定 Kafka 端点（通过连接 Secret），可选字段涵盖保留期（spec.clickhouse.ttl）、分层存储（spec.clickhouse.tieredPolicy / spec.clickhouse.coldTTL）和组件规格（spec.aggregateVector.replicas、spec.razor.replicas）。log-storage-operator 监视此 CR，并据此构建存储侧工作负载。

#LogForward (LF)

描述：一种命名空间范围的 CR，允许租户将自己的日志流转发到外部端点（syslog、HTTP 或 Kafka），独立于平台内置的存储 operator。每个 LogForward 描述一个输入过滤器（命名空间 / 工作负载 / 日志类型）以及一个或多个输出接收器。log-storage-operator 将 CR 渲染为每个 LogForward 专用的 Vector Deployment。

#核心概念

#日志采集管道

描述：从日志数据生成到存储的完整链路，包含三个阶段：Collection → Ingest & Buffering → Storage。

• 采集：每个采集器节点上的 nevermore 读取容器日志、主机文件、事件和审计记录。
• 摄取与缓冲：nevermore 通过 HTTP 推送到 Razor；Razor 进行身份验证并将数据写入 Kafka。
• 存储：aggregate-vector 从 Kafka 消费数据，并将其写入 ClickHouse 或 OpenSearch。

对于两个后端，Kafka 缓冲都是必需的；早期版本中的直接写入和缓冲模式拆分不再适用。

#索引（OpenSearch / Elasticsearch）

描述：OpenSearch 和 Elasticsearch 中的逻辑数据分区单元，类似于关系数据库中的表。支持基于时间滚动创建索引（例如 log-workload-2026.03.05），并通过 OpenSearch 上的 Index State Management (ISM) 或 Elasticsearch 上的 Index Lifecycle Management (ILM) 实现自动化分层生命周期管理。

#分片和从节点

描述：

• 分片：对索引（OpenSearch / Elasticsearch）或表（ClickHouse）进行水平拆分后形成的物理存储单元，支持分布式扩展。
• 从节点：每个分片的副本，提供高可用性和查询负载均衡。

#列式存储（ClickHouse）

描述：ClickHouse 的核心存储机制，数据按列压缩和存储，可显著降低 I/O 消耗。支持：

• 向量化查询执行引擎
• 数据分区和分片
• 用于预聚合的物化视图

#存储策略（ClickHouse）

描述：控制表数据存放位置的 ClickHouse 存储放置模型。在 ACP Logging 中，ClickHouse 支持：

• 默认：表数据存储在本地主机路径或 StorageClass 上。
• 冷热分离：近期数据存储在本地存储，冷数据存储在 S3 上。通过 spec.clickhouse.tieredPolicy、spec.clickhouse.coldTTL 和 spec.clickhouse.s3ColdSecretRef 在 PlatformLogForward 上进行配置。

#冷热分离

描述：ClickHouse 的分层存储模型。记录处于活跃状态时保留在本地磁盘上；热 TTL 到期后移至 S3，并持续可查询，直到冷 TTL 将其删除。在 PLF 中按日志类型启用。

#关键技术术语

#消费者组

描述：Kafka 的并行消费机制。同一消费者组中的多个实例可以并行消费来自不同分区的消息。ACP Logging 使用三个消费者组——alauda_log、alauda_event、alauda_audit——每个 Kafka topic 使用一个。

#TTL（生存时间）

描述：数据生命周期策略，按后端分别实现：

• ClickHouse：表级别的 TTL 表达式；删除已过期的行，或将其移至冷存储。
• OpenSearch / Elasticsearch：索引级别的策略（ISM / ILM）；删除已过期的索引。

#复制因子

描述：Kafka topic 级别的数据冗余配置，用于定义消息副本在不同 broker 上的数量。

#数据流模型