Logging Docs
  • English

    • Log Component Selection Guide

    When installing the Logging module on ACP 4.4 you pick one of two storage backends per storage cluster:

    • ClickHouse (fresh install via Alauda Container Platform Log Storage Management) — recommended for high throughput and cost-sensitive retention.
    • OpenSearch (fresh install via Alauda Container Platform Log Storage Management) — recommended when Lucene-style query experience matters.

    The operator is the same for both — Alauda Container Platform Log Storage Management — and the backend is selected in PlatformLogForward.spec.externalStorage.type.

    The Elasticsearch backend that earlier releases shipped is no longer offered on ACP 4.4. Customers upgrading from ACP 4.2 or 4.3 on Elasticsearch must migrate their data to ClickHouse or OpenSearch as part of the upgrade — see the upgrade guide. The comparison table below still lists Elasticsearch so upgrading customers can weigh a target for the migration.

    This page compares the options so you can pick one before you install.

    WARNING
    • Pick one backend per storage cluster. Do not stack ClickHouse and OpenSearch on the same storage cluster.
    • The DevOps product does not currently support archiving Jenkins pipeline execution records into ClickHouse or OpenSearch. If Jenkins pipeline archival is a hard requirement, the ACP 4.4 platform cannot serve it today; raise this with the platform team before you plan the migration.
    • The ServiceMesh product currently integrates with the Elasticsearch backend only. If ServiceMesh log integration is a hard requirement, the ACP 4.4 platform cannot serve it today either; raise this with the platform team before you plan the migration.
    • The ClickHouse backend does not support IPv6-only or IPv6 dual-stack workload clusters.

    TOC

    Architecture at a glanceClickHouseOpenSearchElasticsearch (upgrade-only reference)Feature comparisonRecommendationsKnown OpenSearch backend limitations

    Architecture at a glance

    ClickHouse

    A columnar database for OLAP workloads. Compresses well, aggregates fast, and pairs cleanly with S3 for tiered cold storage. Trade-off: no inverted index, so keyword search is a LIKE-style scan.

    OpenSearch

    A distributed search engine forked from Elasticsearch. Inverted-index search over log records; strong ad-hoc query experience with keyword highlighting and faceted queries. Trade-off: heavier per-record storage and more CPU for the same ingest volume.

    Elasticsearch (upgrade-only reference)

    The Lucene backend used in earlier releases. Not installable on ACP 4.4; the row is kept in the comparison below so customers migrating off ACP 4.3 Elasticsearch have a like-for-like reference against the two supported backends.

    Feature comparison

    ClickHouseOpenSearchElasticsearch (previous release)Notes
    Available for fresh 4.4 installYesYesNoElasticsearch remains readable during upgrade; the migration to ClickHouse or OpenSearch is required.
    High availabilityYesYesYes
    Horizontal scalabilityYesYesYes
    Query experienceWeak (SQL only)Strong (Lucene DSL)Strong (Lucene DSL)OpenSearch and Elasticsearch expose Lucene-style search; ClickHouse offers SQL only.
    Resource usage per ingest unitLowMediumHighRule of thumb: to sustain 20,000 logs/s you need roughly 3 ClickHouse replicas (2C/4G), or an OpenSearch cluster with 3 master + 5 data (2C/4G + 8C/16G), or an Elasticsearch cluster of similar shape.
    Ingest throughput per nodeHighMediumMediumSee Log Component Capacity Planning for the ACP-tested profiles.
    S3 tiered storageYes (hot / cold via PLF.spec.clickhouse.tieredPolicy)ISM policy on OpenSearchILM policy on ElasticsearchOnly ClickHouse can push cold data to S3 as an ACP-managed feature; OpenSearch and Elasticsearch tiering is a self-managed policy.
    Chinese full-text searchSubstring matchanalysis-ik plugin (required for ACP OpenSearch)analysis-ik pluginThe OpenSearch install must include analysis-ik; without it the platform's log query page returns 400.
    Community activityGrowingActive (Amazon-led fork)Active (Elastic-led)
    IPv6-only workload clustersNot supportedSupportedSupported

    Recommendations

    • You want the most cost-effective backend for large log volume and can accept SQL-only search. Install Alauda Container Platform Log Storage Management and set PlatformLogForward.spec.externalStorage.type: clickhouse. Enable S3 tiered storage if long retention drives your storage bill.

    • You rely on Lucene-style keyword search, highlighting, or faceted queries, or you are already familiar with the Elasticsearch DSL. Install Alauda Container Platform Log Storage Management and set PlatformLogForward.spec.externalStorage.type: opensearch. Make sure the analysis-ik plugin is installed on every OpenSearch node before you apply the PLF.

    • You are upgrading from ACP 4.2 or 4.3 on Elasticsearch. The Elasticsearch backend is not offered on ACP 4.4, so you must migrate. Pick either ClickHouse or OpenSearch above and follow Upgrade from Log Storage for Elasticsearch plus Historical Data Migration for the concrete migration path.

    Known OpenSearch backend limitations

    The following behaviors have been observed on the OpenSearch backend in live installations. They are not present on the ClickHouse backend. Weigh them against the "Lucene-style query" upside before choosing OpenSearch for a production workload; if any of them is a blocker, pick ClickHouse.

    AreaWhat happens on OpenSearchImpact
    Record timestampThe Kafka source overwrites the record timestamp with the ingest time. Log, event, and audit are all affected.The timestamp shown in the console equals when the record hit the aggregate-vector pod, not when the application emitted the log. Time-range queries against the origin time (for example "show me what happened 5 minutes before the incident") miss records.
    Backpressure on the bulk breakerThe OpenSearch sink has no retry_partial for item-level rejections in the shipped default.On a bulk breaker trip (429 / rejected_execution_exception) the whole batch is dropped silently. A live cluster lost ~79k records in one incident. Set spec.aggregateVector.sinks.opensearch.retryPartial: true — this is the current baseline default in newer builds, but re-check on the cluster you are about to install.
    Project-level retentionThe project-scoped log retention override (cpaas.io/project.hotDataRetentionDays, cpaas.io/project.logPolicyEnabled) does not take effect on OpenSearch. The operator skips log-policy-config, and the razor-api cron job that reconciles the ISM policy only reads, never writes.Every project keeps the platform-default retention. If per-project retention is a compliance requirement, do not choose OpenSearch. See How to Set the Retention Time of Cold Data for a Project.
    Audit topic self-healingIf the audit KafkaTopic is deleted, the OpenSearch data path does not self-heal — audit ingest stops until the topic is re-created and the aggregate-vector audit consumer is restarted.An operator-side incident on the audit topic requires manual intervention.
    Index replicasThe composable index template ships with number_of_replicas: 0 even when the PLF or the template appears to declare 1.HA claims for OpenSearch replicas should be verified per-index (GET /_cat/indices?v) rather than trusted from the PLF spec.

    These are tracked as separate follow-ups on the operator side and may be closed by a later log-storage-operator bump; the list above reflects the state as of 2026-09.

    Diagnosis path

    The symptom that most often surfaces first is "queries return zero when I filter by a time range around the application timestamp." That is the timestamp-overwrite issue above, not a query problem. Compare SELECT count() FROM ... WHERE timestamp BETWEEN a AND b with an unbounded SELECT count() before you conclude the data is missing.