Resource Profile
Ingester is the telemetry write path. It validates, normalizes, batches, and stores incoming metrics, traces, logs, profiles, Kubernetes resource updates, and usage records. Ingestion is mostly CPU-bound. As telemetry volume increases, Ingester should generally scale horizontally rather than needing careful per-pod tuning. Memory pressure is still worth watching, but sustained CPU usage is the more common signal for ingest capacity.Autoscaling
Leave Ingester autoscaling enabled unless Metoro support recommends otherwise. The default chart values run multiple replicas and let Kubernetes add Ingester pods as telemetry volume changes. Manual changes to Ingester CPU, memory, or replica bounds should be rare. Make them only when there is sustained Ingester-specific pressure, such as persistent CPU throttling, OOM restarts, readiness failures from memory pressure, or ingest latency that is isolated to the Ingester layer.Restarts And Availability
Ingester does not own durable local state. Pods can be killed, restarted, or recreated without losing stored telemetry. Kubernetes readiness, rolling updates, and multiple replicas keep ingestion available while individual pods are replaced. If all Ingester pods are unavailable, monitored clusters cannot send telemetry to the hub until the service recovers, but existing telemetry already written to ClickHouse remains there.Before Tuning Ingester
If ingestion is slow, delayed, or dropping records, check the write path before changing Ingester resources:- ClickHouse insert latency, insert errors, merge pressure, disk pressure, and replica health.
- Incoming telemetry volume, burst size, and whether new monitored clusters were added recently.
- Dropped-record signals, readiness failures, and Ingester pod restarts.
- Ingress, load balancer, DNS, and TLS behavior on the ingestion path.
- Kubernetes node capacity, scheduling events, and CPU throttling.