Logging Docs
  • English

    • Log Module Architecture

    TOC

    OverviewLog CollectionComponent footprintData flowLog Ingest and BufferingRazorKafkaLog Storageaggregate-vectorClickHouseOpenSearchElasticsearch (previous release, not available on ACP 4.4)Log Visualization

    Overview

    The Logging module has three responsibilities:

    1. Log collection — read logs, events, and audit records on every collector node.
    2. Log storage — persist those records into a scalable backend (ClickHouse or OpenSearch). Elasticsearch is no longer offered on ACP 4.4; customers upgrading from earlier releases on Elasticsearch migrate to one of these two.
    3. Log query and visualization — serve queries from the ACP console over the stored data.

    These responsibilities are split across three cluster components — two plugins (Log Essentials, Log Collector) and one operator (Log Storage Management) — that talk to two external systems the SRE prepares before install: a Kafka cluster and either a ClickHouse or an OpenSearch cluster. See Installation. The Log Storage Management operator covers both ClickHouse and OpenSearch backends; the backend choice is made in the PlatformLogForward CR.

    log-storage-operator reconciles the storage-side workloads (Razor, aggregate-vector, one-shot schema-migrations Job, side resources) from a single PlatformLogForward/platform-default CR. The SRE never applies Razor or aggregate-vector Deployments by hand.

    Log Collection

    Component footprint

    nevermore is installed as a DaemonSet in the cpaas-system namespace of every collector cluster. Each pod contains four containers:

    ContainerFunction
    auditCollects audit data from /var/log/kubernetes/audit (path may vary).
    eventWatches the Kubernetes event stream.
    logCollects standard-output and file logs. Runs Vector as its data path engine.
    node-problem-detectorCollects node-level abnormality signals.

    Data flow

    Each container writes into an in-pod queue that Vector reads. Vector applies path-based routing, adds cluster / namespace / pod metadata, and pushes to the storage cluster's Razor endpoint over HTTP with a callback token.

    Log Ingest and Buffering

    Razor

    Razor is the storage-side HTTP endpoint. It authenticates every request against the platform's token service and, on success, produces the record into the matching Kafka topic (ALAUDA_LOG_TOPIC, ALAUDA_EVENT_TOPIC, or ALAUDA_AUDIT_TOPIC).

    Razor is a stateless Deployment. Earlier releases ran it as a StatefulSet with a per-pod Vector sidecar; that layout is gone.

    Kafka

    Kafka buffers records between Razor and the storage backend. Both ClickHouse and OpenSearch backends require it. Kafka runs in KRaft mode, so no Zookeeper is deployed.

    The SRE owns the Kafka cluster, the SASL account, the three topics, and their ACLs. log-storage-operator verifies only the connection Secret (platform-default-mq-conn, its required keys) before it lets aggregate-vector and Razor roll out; the broker-side ACL and topics are validated at runtime through the SASL / GroupAuthorization errors those consumers surface. See the Kafka prerequisites in Installation for the exact requirements.

    Log Storage

    aggregate-vector

    aggregate-vector is a Vector Deployment that consumes from the three Kafka topics, applies Vector Remap Language (VRL) transforms to reshape records for the chosen backend, and writes into ClickHouse or OpenSearch. It replaces the per-pod Vector sidecar used in ACP 4.3 for ClickHouse and takes over the ingest role that Lanaya used to play for Elasticsearch.

    The VRL transforms and sink parameters are derived by log-storage-operator from the PlatformLogForward spec. Operators can tune batching, retry, and backpressure knobs through the PLF; see How to Tune the aggregate-vector Sink for the tuning surface and How to Override the aggregate-vector Configuration for the escape hatch when a needed field is not on the CR.

    ClickHouse

    When PlatformLogForward.spec.externalStorage.type is clickhouse, aggregate-vector writes into the ClickHouse observability database (default name) through the HTTP interface. Table layout is provisioned by the one-shot schema-migrations Job that log-storage-operator derives from the PLF; per-log-type TTLs and tiered-storage policies land in the same Job.

    OpenSearch

    When PlatformLogForward.spec.externalStorage.type is opensearch, aggregate-vector writes into rolling indices per log type. Composable index templates and ISM policies are provisioned by an opensearch-index-init Job that log-storage-operator derives from the PLF.

    Elasticsearch (previous release, not available on ACP 4.4)

    The Elasticsearch storage backend shipped in earlier releases through a chart-based pipeline (Filebeat → Kafka → Lanaya → Elasticsearch). It is not offered on ACP 4.4 — you cannot pick it during a fresh install, and the PlatformLogForward CR has no code path for it. Customers upgrading from ACP 4.2 or 4.3 on Elasticsearch migrate to ClickHouse or OpenSearch as part of the upgrade; see Upgrade from Log Storage for Elasticsearch and Historical Data Migration.

    Log Visualization

    The ACP console reads through the query APIs published by Alauda Container Platform Log Essentials on the global cluster:

    Query typeAPI path
    Log query/platform/logging.alauda.io/v2/logs
    Event query/platform/events.alauda.io/v1
    Audit query/platform/audits.alauda.io/v1

    razor-api (the Log Essentials plugin's Deployment on global; ModuleInfo log-api) receives the request, picks the storage cluster from the request, and forwards the query to that cluster's Razor. Razor executes it against the local ClickHouse or OpenSearch endpoint and returns the results.