Elastic Certified Observability Engineer study materials
Elastic Certified Observability Engineer study resources

Elastic Certified Observability Engineer: Metrics, infrastructure monitoring, and Elastic Agent

Elastic Certified Observability Engineer · Work through your exam, one topic at a time.

All guide sections

Metrics, infrastructure monitoring, and Elastic Agent

Domain 3: Metrics, infrastructure monitoring, and Elastic Agent

This domain tests how metrics get collected, stored efficiently, and used for infrastructure views and alerts. It covers Fleet and Elastic Agent, integration policies, the metrics data model, TSDS, and the Infrastructure UI.

Elastic Agent and Fleet

Elastic Agent is the single shipper for logs, metrics, traces, and synthetic data. In Fleet mode it enrolls with a Fleet Server using an enrollment token; the policy defines integrations and outputs. Agent status appears healthy, degraded, or offline. A standalone agent uses elastic-agent.yml instead of Fleet. Integrations such as System, Kubernetes, Docker, AWS, and custom HTTP ship with assets: index templates, ingest pipelines, dashboards, and fields.

The metrics data model

Metrics are numeric samples tied to dimensions. A time series data stream (TSDS) requires at least one time_series_dimension field (keyword or IP) and each metric field declares metric_type: gauge or counter. Dimensions identify the series - host.name, service.name, container.id - and must not include unbounded values. Counters increase monotonically and reset on restart; gauges can rise and fall. Downsampling reduces storage by keeping statistical summaries over time. ILM applies separately to metrics data streams.

Infrastructure monitoring

The Infrastructure UI inventories hosts, pods, and containers and shows CPU, memory, disk, and network metrics. Metrics Explorer builds ad hoc charts by metric and dimension. Alerts use index threshold or custom query rules evaluated on a schedule. Anomaly detection can model metric seasonality where a static threshold would be noisy.

Worked example

A team wants a custom TSDS for application memory, dimensioned by service.name and host.name, with memory.used.pct as a gauge. Reasoning: create a component template that maps service.name and host.name as keyword with time_series_dimension: true; map memory.used.pct as double with metric_type: gauge; map @timestamp as date; create an index template matching metrics-app.memory-* with data_stream: {} and the TSDS settings; write documents to metrics-app.memory-production. Add a threshold rule on memory.used.pct > 0.9 averaged over five minutes per host.

Traps

Using text for a dimension fails TSDS validation; a high-cardinality field such as url or user.id as a dimension explodes the series count. Mapping a counter as a gauge hides resets. Fleet policy changes do not reach an offline agent. Integration assets are installed by Fleet; if the index template is missing, check the integration package version and policy. Sending metrics with @timestamp in the future breaks rollover and queries.