Most observability dashboards wait for an operator to know what to search for. This package takes the opposite approach: it uses the telemetry already stored in Elastic to discover services, evaluate reliability, detect abnormal behavior, surface emerging log patterns, and create an evidence-grounded operational briefing.
Use it when teams have ECS or Elastic-mapped OpenTelemetry traces and logs but still spend too much time moving between dashboards to answer a basic question: what changed, which services are affected, and what should we investigate first?
Why this is more than another dashboard
A single signal rarely explains an incident. An SLO can show that user impact is accumulating without identifying the cause. Machine Learning can reveal that latency or failure behavior departed from its learned baseline without proving business impact. Change-point and log-pattern analysis can expose a new behavior, while the APM service map shows where that behavior sits in the dependency path.
The package installs and connects those layers. Its dashboard leads with discovered services, objective risk, ML findings, anomaly severity, active alerts, and automation health. It then provides the native evidence behind those conclusions: SLO posture, scoped APM anomalies, failure-rate change points, log categories, unusual log-rate contributors, service topology, and persisted AI operational briefings.
What Elastic discovers automatically
- Service and business-service candidates: a continuous transform groups existing
traces-*data by standard service, namespace, environment, and Kubernetes dimensions. Inferred identities remain visibly marked as inferred. - Bootstrap reliability posture: grouped availability and latency objectives make error-budget mechanics immediately visible. They are deliberately labelled as provisional because telemetry cannot infer the promise a service owner intended to make.
- Adaptive anomalies: package-owned ML jobs learn latency and failure-ratio behavior per service. The dashboard also reuses native Elastic APM ML jobs while excluding unrelated Security or custom jobs.
- Behavioral changes: ES|QL change-point detection looks for statistically meaningful shifts in service failure rate instead of relying only on fixed thresholds.
- New failure signatures: CATEGORIZE and log-rate analysis group unfamiliar messages and identify the field/value combinations driving a spike or dip.
- Likely blast radius: the APM service map provides upstream and downstream context for affected services.
- Prioritized briefing: an Elastic Workflow gathers bounded SLO, ML, change-point, and pattern evidence. The Elastic AI Agent ranks the strongest findings, states missing signals, estimates likely blast radius, and recommends verification steps. Its output is stored in a package-owned findings index.
What is included
- A findings-first Kibana dashboard and its required data views.
- An index template, normalization pipeline, and continuous service-health transform.
- Package-owned ML anomaly jobs and datafeeds for latency and failure ratio.
- Grouped bootstrap availability and latency SLO definitions.
- SLO-burn and critical-anomaly alert rules that invoke the synthesis workflow.
- A scheduled Elastic Workflow with a one-time installation run and a deterministic no-AI fallback.
- A findings index for persisted operational briefings.
- README, compatibility notes, lifecycle behavior, and CC BY 4.0 license.
How to use the package
- Deploy the ZIP through Elastic Content Share. The installer creates package resources in dependency order, opens and starts ML jobs, starts the continuous transform, creates SLOs and alert rules, installs the workflow, and runs the first synthesis automatically.
- Open “[ECS] Global IT Health — Native Findings”. Begin with the headline row to see evaluated services, accelerating objective burn, anomaly count and severity, active alerts, and failed workflow executions.
- Confirm user impact in the SLO panel. A violated or rapidly burning objective tells you why a technical deviation deserves attention. Treat the packaged objectives as orientation until an owner confirms the real target and latency threshold.
- Compare independent evidence. Open the ML table for departures from learned behavior, then check change points and log patterns around the same time. Agreement between independent signals increases confidence; disagreement tells you what evidence is still missing.
- Follow the dependency path. Use the service map to identify callers and downstream systems that may share the impact. The map provides investigation scope, not proof of causality.
- Read and verify the operational briefing. The AI summary is grounded in bounded Elastic evidence, but deterministic panels remain the source of truth. Verify recommendations before remediation.
- Promote useful bootstrap objectives. Once service owners confirm boundaries, exclusions, targets, and paging policy, replace provisional objectives with the organization’s real SLO commitments.
Compatibility and prerequisites
This release was validated end to end on Elasticsearch and Kibana 9.5.3 with data under traces-* and logs-*. It expects standard service.name values for per-service grouping. The full experience requires the Elastic subscription and privileges needed for SLOs, Machine Learning, AIOps, alerting, Workflows, Agent Builder, index templates, transforms, and source-index access.
The deterministic dashboard remains useful when AI model access is unavailable. A new environment also needs time to learn: ML jobs require baseline history, and CHANGE_POINT needs at least 22 aggregated values. These states are shown as warm-up or insufficient-history messages and must not be interpreted as proof of health.
Where this fits in an end-to-end observability strategy
This package provides the findings and prioritization layer. The End-to-End Observability guide explains why user journeys, application traces, asynchronous correlation keys, network evidence, and platform health still need to be stitched together. Open that guide when the Global IT Health dashboard identifies an affected service and you need to continue from the finding into the complete cross-layer investigation path.
Source, safety, and license
This is an original Elastic Content Share community package built with public Elastic APIs and portable ECS/OpenTelemetry fields. See the Elastic Observability documentation to understand the product features used by the package and the subscription requirements that apply to them.
The package is licensed under Creative Commons Attribution 4.0 International. It generates investigation guidance but does not restart services, change infrastructure, close alerts, or declare an autonomous root cause.
| Tested versions | 9.5.3 |
| ECS compliant | |
| Tested versions |
You must log in to submit a review.