#如何验证全新安装的日志堆栈

当安装报告所有插件均已安装后，请按照此检查清单进行确认，以验证写入路径和读取路径均正常工作。每个步骤最终都会产生一个明确的信号，因此可以在发现第一个问题时轻松停止，并跳转到故障排除。

此检查清单适用于任何存储后端。仅适用于某个后端的检查项会在相应位置特别说明。

#1. PlatformLogForward/platform-default 为 Ready

整个存储集群唯一的顶层就绪信号是：

kubectl -n cpaas-system get platformlogforward platform-default -o jsonpath='{.status.conditions}' | jq

每个条件都应为 status: "True"。唯一的顶层信号是 Ready=True，原因为 AllComponentsReady。在该信号下，全新安装过程中依次完成的子条件包括：MessageQueueReady（Kafka SASL 和主题列表已验证）、StorageReady（外部 ClickHouse 或 OpenSearch 端点可访问，且其 schema 已初始化）、CollectorReady（aggregate-vector Deployment 已达到全部 ready-replicas）、RazorReady（razor Deployment 已达到全部 ready-replicas），以及 SchemaMigrated（自动迁移 Runnable 已收敛）。如果其中任何一个为 False，则 message 会指出尚未完成的子步骤 — 请参阅故障排除：PlatformLogForward 一直处于 Provisioning 状态。

#2. 数据平面 Pod 全部运行

即使 PLF 已处于 Ready 状态，单个组件仍可能正在进行软重启。一次性检查命令为：

kubectl -n cpaas-system get pods -l 'app in (aggregate-vector,razor)' -o wide

每个 Pod 都应为 1/1 Running。此时，aggregate-vector 上的 CrashLoopBackOff 几乎总是由 schema-migrations init-container（ClickHouse）或 OpenSearch 模板 PUT（OpenSearch）导致 — 请参阅故障排除中的对应条目。

在采集集群上（该集群可能与存储集群相同，也可能不同）：

kubectl -n cpaas-system get pods -l app=nevermore -o wide

Log.Kubernetes=true 采集范围内的每个节点都应有一个处于 Running 状态的 nevermore Pod。

#3. log-center Feature CR 位于存储集群上

Log Storage operator 会在其安装所在的存储集群的 cpaas-system 中创建一个 Feature/log-center CR。global 集群的 razor-api 会读取此 Feature（通过 cluster-transformer 同步），以发现每个存储集群的端点。在存储集群上：

kubectl get feature log-center -o jsonpath='{.spec}' | jq

应填充以下字段：

• spec.type — clickhouse 或 opensearch，与您安装的存储后端匹配。
• spec.secureAddress — 存储集群的本地 ALB 端点（不是全局平台 URL）。如果此字段指向全局平台 URL，请升级 operator；早期版本的 operator 构造了错误的值（Bug 134）。
• spec.secretRef — 存储集群上 cpaas-system 中回调 secret 的名称；razor-api 使用它进行跨集群身份验证。

#4. 存储 schema 存在

#ClickHouse 后端

每次安装时，schema-migrations Job 运行一次，并使用目标版本标记 schema_migrations 表。

kubectl -n cpaas-system exec -it deploy/razor -- \
  clickhouse-client -h <ch-endpoint> --database <log-db> \
  --query "SELECT version, dirty FROM schema_migrations"

dirty 应为 0。version 应等于您部署的 operator 镜像中 internal/migrations 的最高编号（迁移内容会在构建时嵌入 operator 二进制文件）。

#OpenSearch 后端

opensearchinit runner Job 会 PUT 可组合模板和 ISM 策略。验证两者：

# composable template
curl -sk -u admin:admin https://<os-endpoint>/_index_template/cpaas-native-log-center | jq '.index_templates[0].name'
# ISM policy
curl -sk -u admin:admin https://<os-endpoint>/_plugins/_ism/policies/cpaas-native-log-center | jq '.policy.policy_id'

两者都应回显对象名称。如果任一请求返回 404，则 runner Job 尚未完成 — 请参阅故障排除中的 OpenSearch 条目。

#5. Kafka 正在接收记录

采集管道的末端会将数据推送到 Kafka。如果 aggregate-vector 处于空闲状态，则记录卡在上游（nevermore 中，或采集器侧的 Kafka producer 中）。

kubectl -n cpaas-system exec sts/cpaas-kafka -- \
  bin/kafka-run-class.sh kafka.tools.GetOffsetShell \
    --bootstrap-server localhost:9092 \
    --topic ALAUDA_LOG_DATA \
    --time -1

30 秒后再次执行。offset 应不断增加。如果没有增加，则 nevermore 未在产生日志 — 请检查采集集群上的 kubectl -n cpaas-system logs -l app=nevermore --tail=200。

#6. 端到端出现合成日志

完整的管道信号是：发出日志，等待，然后查询该日志。对任意已采集的集群执行带有明显标记的操作：

kubectl -n default run smoketest --restart=Never --image=busybox --rm -it -- \
  sh -c 'echo "logging-smoketest-$(date +%s)"; sleep 3'

等待约一分钟。在 global 集群上，查询 razor-api 中的标记：

kubectl -n cpaas-system exec -it deploy/razor-api -- \
  curl -sG 'http://localhost:8080/platform/logging.alauda.io/v2/logs' \
    --data-urlencode 'q=logging-smoketest' \
    --data-urlencode 'projects=default'

响应中应至少包含一个命中项。如果命中数为零，请从上到下检查诊断入口列表。

#7. 审计和事件流也会落盘

日志记录与事件和审计记录使用相同的主题，但属于不同的表系列。确认两者都已到达存储端：

# ClickHouse
kubectl -n cpaas-system exec -it deploy/razor -- \
  clickhouse-client -h <ch-endpoint> --database <log-db> \
  --query "SELECT count() FROM audit_data WHERE timestamp > now() - INTERVAL 5 MINUTE"

# OpenSearch
curl -sk -u admin:admin 'https://<os-endpoint>/audit-*/_count?q=timestamp:>=now-5m'

在任何活跃平台上，两者都应返回非零值。对于 ClickHouse 后端，audit_data 为零而日志计数正常，通常意味着某个写入路径 reshape 被跳过（请参阅 operator 已知问题说明中的 Bug 169 aggvec CH reshape 系列）。OpenSearch 的 audit-* 为零而日志计数正常，则意味着 aggregate-vector 事件/审计 VRL 正在丢弃记录——同样需要检查 operator 的 OpenSearch reshape 分支。

#发布检查清单中需要记录的内容

上述每个步骤都返回正常状态后，记录以下信息，作为今后比较时的安装基线：

• operator image tag 和 razor image tag。
• PlatformLogForward.status.storageIdentity — 此快照将正在运行的安装与其写入的确切 ClickHouse 数据库或 OpenSearch tenant 关联起来。
• 日志主题的 kafka --describe 输出，以便将来分区数量发生变化时进行可比较的差异分析。

如果客户重视按项目设置保留策略，请验证全新安装是否遵循该策略。在 ClickHouse 上，这使用 log-policy-config ConfigMap 和 razor-api cron；在 OpenSearch 上则完全不会生效 — 交付前请参阅已知 OpenSearch 后端限制。