#Log Component Capacity Planning

The log storage components hold logs, events, and audit records collected from one or more clusters. Estimate your log scale before install and size the storage cluster using the profiles below.

#Common components

All backends share these components:

#ClickHouse profiles

The ClickHouse backend is the recommended choice for high throughput and cost-sensitive retention.

#Single node — evaluation only, up to ~18,000 logs/s

#Three nodes — up to ~20,000 logs/s

#Six nodes — up to ~40,000 logs/s

#Nine nodes — up to ~69,000 logs/s

#OpenSearch profiles

The OpenSearch backend is the recommended choice when Lucene-style search experience matters more than raw ingest throughput.

#Small — three data nodes, up to ~9,000 logs/s

#Medium — three master, five data nodes, up to ~25,000 logs/s

#Large — three master, seven data nodes, up to ~30,000 logs/s

#Elasticsearch profiles (legacy)

The Elasticsearch backend remains available for existing customers. The classic ACP 4.3 pipeline (Filebeat → Kafka → Lanaya → Elasticsearch) is unchanged; the sizing tables below are reproduced for reference.

#Small — three nodes, up to ~6,300 logs/s

#Small — five nodes, up to ~9,900 logs/s

#Large — three master, five data nodes, up to ~25,000 logs/s

#Large — three master, seven data nodes, up to ~30,000 logs/s

#Sizing notes

• Set PlatformLogForward.spec.aggregateVector.replicas and spec.razor.replicas to match the profile you deploy. The CRD defaults (3 and 2) suit the medium and large profiles; drop them to 1 on a single-node evaluation cluster.
• Raise spec.razor.resources.limits.cpu above the profile default when the collector-side buffer grows during traffic bursts and Razor CPU sits at its limit. See How to size Razor for burst traffic once that page is published.
• Kafka broker sizing is separate from the storage backend sizing. Follow the Alauda Container Platform Kafka capacity guide for broker-side numbers.