Elastic Certified Observability Engineer common mistakes
Elastic Certified Observability Engineer · Understand the traps and how to avoid them.
Building a standalone Logstash pipeline or Filebeat config from scratch instead of using the Elastic Agent integration, then failing tasks that ask for data to be shipped with an agent policy and visible in Fleet.
Candidates with prior Elasticsearch experience default to the tooling they already know. The exam is framed around Fleet-managed Elastic Agents, and hand-rolled beat configs bypass the policy, integration, and data-stream naming that the tasks expect.
What to do instead
Practise the Fleet workflow end to end: add an integration, assign it to an agent policy, enrol an agent, verify the data stream appears in Discover with the expected dataset name (for example logs-nginx.access-*), then inspect the integration's ingest pipeline. Treat standalone beats as a fallback only.
Assuming data is searchable the moment an agent reports healthy, and then writing queries against an index pattern that does not match the actual data stream name.
Agent health and ingest success are different signals. A policy can be healthy while an integration is misconfigured, and the resulting documents land under a dataset name the candidate did not anticipate.
What to do instead
Verify ingestion before querying: check Fleet agent logs, the integration's data stream list, and the document count in Discover. Confirm the exact index or data stream pattern with GET _cat/indices/*pattern* or the index management view before building any saved search or visualization.
Writing a KQL query that silently matches nothing because of field-name or type assumptions, then concluding the data is missing.
KQL differs from Lucene and from query DSL: unquoted values, wildcards, and nested versus flat field names behave differently, and text versus keyword fields change what a phrase match does. Candidates also forget that KQL is the default in Discover while DSL is needed in some rule contexts.
What to do instead
Inspect the field list and its types in Discover first, then test the query interactively and confirm the hit count changes as expected. Use quoted phrases for exact text, field.keyword for exact keyword matching where relevant, and switch to the DSL tab when a rule or transform requires query DSL syntax.
Creating a log threshold rule without configuring the group-by, the rule schedule, and the look-back window coherently, so the alert either never fires or fires constantly.
Alerting in Kibana combines a query, a threshold, a grouping key, and a time window. A threshold evaluated over a window shorter than the schedule, or grouped by a high-cardinality field, produces noisy or silent alerts that look like a broken rule.
What to do instead
Set the look-back window to at least the rule interval, group by a stable low-cardinality field such as host.name or service.name, and test with a deliberately low threshold to confirm the rule fires. Then check the alert appears in the alerts view and that an action (connector) is attached if the task asks for notification.
Treating an ingest pipeline and a Logstash filter as interchangeable, and putting grok or date parsing in the wrong layer so documents arrive with unparsed timestamps or missing fields.
Both layers can transform events, but the exam tasks specify where the processing should live. A common symptom is an @timestamp that reflects ingest time rather than the event time in the log line, which then breaks time-based analysis.
What to do instead
When processing belongs to the integration, add processors to the integration's ingest pipeline and use the date processor to set @timestamp from the parsed field. When a Logstash pipeline is explicitly required, use the date filter with the correct pattern and timezone. Always re-check the parsed @timestamp in Discover after the change.
Building metrics dashboards from the wrong field or aggregation, for example averaging a counter or using a terms aggregation on a numeric field, and then failing to reproduce the expected chart.
Infrastructure metrics arrive as counters and gauges with specific field types. Candidates reach for the default aggregation without checking whether the field is a counter that needs a derivative or rate, or a keyword that should not be averaged.
What to do instead
Confirm the field type and semantics in the index mapping or the integration docs. Use average or max for gauges such as CPU percentage, and rate or derivative style calculations for counters. Verify the Lens chart shows plausible values against a known host before saving it to a dashboard.
Ignoring the system integration's metric sets and expecting host metrics to appear without enabling the specific dataset, then troubleshooting a problem that is really an unselected checkbox.
The system integration ships several distinct metric sets (CPU, memory, disk, network, process, load) and only the ones you enable produce documents. Candidates enable the integration but not the dataset the task depends on.
What to do instead
During practice, enable each metric set deliberately and note the resulting data stream names. In the exam, read the task for which metric is required, confirm the corresponding dataset is enabled in the policy, and verify documents exist for that dataset before building the visualization.
Instrumenting or inspecting APM data without checking that the service is actually reporting, and then querying transaction fields that do not exist because only metrics were collected.
APM can send transaction, span, error, and metric documents, and the sampling or agent configuration determines which. Candidates assume full trace data is present and write queries or service maps that return nothing.
What to do instead
Confirm the agent is connected by checking the APM app's service inventory and the agent status, then look at an actual trace to see which document types exist. Query the correct fields (transaction.name, transaction.duration.us, span.destination.service.resource) and verify the time range covers the reported data.
Analysing a distributed trace without using the trace ID and parent-child relationships, so the candidate cannot answer which service or span caused the latency.
Traces are hierarchical; the slow span is often a downstream call, not the entry transaction. Candidates read the top-level transaction duration and stop, or filter by service name and lose the cross-service view.
What to do instead
Open the full trace from the APM UI or filter on trace.id, then walk the span waterfall to find the span with the largest self-time. Use span.duration.us and the parent span reference to attribute latency, and cross-check with service-level transaction duration percentiles.
Configuring a synthetic monitor or uptime check and assuming a green status means the assertion passed, without verifying the monitor's schedule, locations, and the specific journey step that is asserted.
Digital experience monitoring tasks depend on both the monitor definition and its execution. A monitor can be enabled but scheduled far in the future, run from a location that cannot reach the endpoint, or assert on a selector that no longer exists.
What to do instead
After creating the monitor, check its next run time, the locations selected, and the result of the first execution in the monitor's history. For browser monitors, confirm each journey step's selector and assertion individually, and inspect the screenshot or error detail on failure rather than relying on the summary status.