#日志模块架构

#概述

Logging 模块有三个职责：

1. 日志收集：在每个收集器节点上读取日志、事件和审计记录。
2. 日志存储：将这些记录持久化到可扩展的后端（ClickHouse 或 OpenSearch）。ACP 4.4 不再提供 Elasticsearch；从早期版本中使用 Elasticsearch 升级的客户将迁移到这两个后端之一。
3. 日志查询和可视化：通过存储的数据为 ACP 控制台提供查询服务。

这些职责分布在三个集群组件中——两个插件（Log Essentials、Log Collector）和一个 operator（Log Storage Management）——它们与 SRE 在安装前准备的两个外部系统通信：一个 Kafka 集群以及一个 ClickHouse 或 OpenSearch 集群。请参阅安装。Log Storage Management operator 同时支持 ClickHouse 和 OpenSearch 后端；后端的选择在 PlatformLogForward CR 中指定。

log-storage-operator 根据单个 PlatformLogForward/platform-default CR 对存储侧工作负载（Razor、aggregate-vector、一次性 schema-migrations Job 以及辅助资源）执行协调。SRE 无需手动应用 Razor 或 aggregate-vector Deployments。

#日志收集

#组件占用

nevermore 以 DaemonSet 形式安装在每个收集器集群的 cpaas-system 命名空间中。每个 Pod 包含四个容器：

#数据流

每个容器都会写入 Pod 内的队列，Vector 从中读取数据。Vector 根据路径执行路由，添加集群、命名空间和 Pod 元数据，然后通过 HTTP 携带回调令牌推送到存储集群的 Razor 端点。

#日志接收与缓冲

#Razor

Razor 是存储侧的 HTTP 端点。它会针对平台的令牌服务对每个请求进行身份验证；验证成功后，将记录写入匹配的 Kafka topic（ALAUDA_LOG_TOPIC、ALAUDA_EVENT_TOPIC 或 ALAUDA_AUDIT_TOPIC）。

Razor 是无状态 Deployment。早期版本将其作为带有每 Pod 一个 Vector sidecar 的 StatefulSet 运行；该布局已取消。

#Kafka

Kafka 在 Razor 与存储后端之间缓冲记录。ClickHouse 和 OpenSearch 后端都需要 Kafka。Kafka 以 KRaft 模式运行，因此不会部署 Zookeeper。

SRE 负责 Kafka 集群、SASL 账户、三个 topic 及其 ACL。log-storage-operator 仅在允许 aggregate-vector 和 Razor 发布前，验证连接 Secret（platform-default-mq-conn 及其必需的键）；broker 侧的 ACL 和 topic 则在运行时通过这些消费者报告的 SASL / GroupAuthorization 错误进行验证。确切要求请参阅安装中的 Kafka 先决条件。

#日志存储

#aggregate-vector

aggregate-vector 是一个 Vector Deployment，从三个 Kafka topic 中消费数据，应用 Vector Remap Language (VRL) 转换来重塑记录以适配所选后端，并将数据写入 ClickHouse 或 OpenSearch。它取代了 ACP 4.3 中用于 ClickHouse 的每 Pod Vector sidecar，并接管了 Lanaya 过去为 Elasticsearch 承担的接收职责。

log-storage-operator 根据 PlatformLogForward spec 推导 VRL 转换和 sink 参数。Operator 可以通过 PLF 调整批处理、重试和背压参数；有关可调配置项，请参阅如何调整 aggregate-vector Sink；如果所需字段不在 CR 中，请参阅如何覆盖 aggregate-vector 配置了解可用的应急方式。

#ClickHouse

当 PlatformLogForward.spec.externalStorage.type 为 clickhouse 时，aggregate-vector 通过 HTTP 接口将数据写入 ClickHouse observability 数据库（默认名称）。表布局由 log-storage-operator 根据 PLF 推导出的单次运行 schema-migrations Job 进行配置；每种日志类型的 TTL 和分层存储策略也会写入同一个 Job。

#OpenSearch

当 PlatformLogForward.spec.externalStorage.type 为 opensearch 时，aggregate-vector 按日志类型写入滚动索引。可组合索引模板和 ISM 策略由 log-storage-operator 根据 PLF 推导出的 opensearch-index-init Job 进行配置。

#Elasticsearch（以前的版本，ACP 4.4 不提供）

Elasticsearch 存储后端在早期版本中通过基于 chart 的流水线（Filebeat → Kafka → Lanaya → Elasticsearch）提供。ACP 4.4 不提供该后端——在全新安装期间无法选择它，并且 PlatformLogForward CR 没有用于该后端的代码路径。从 ACP 4.2 或 4.3 上使用 Elasticsearch 的客户升级时，会在升级过程中迁移到 ClickHouse 或 OpenSearch；请参阅从 Elasticsearch 日志存储升级和历史数据迁移。

#日志可视化

ACP 控制台通过 global 集群上由 Alauda Container Platform Log Essentials 发布的查询 API 读取数据：

razor-api（Log Essentials plugin 在 global 上的 Deployment；ModuleInfo log-api）接收请求，根据请求选择存储集群，并将查询转发到该集群的 Razor。Razor 针对本地 ClickHouse 或 OpenSearch endpoint 执行查询并返回结果。