Observed Assets Inventory Dashboard for Elastic

See every host, service, and Kubernetes pod your Elastic cluster has actually observed from ECS or OpenTelemetry telemetry — with the asset’s identity, which signals it emits, and whether it looks healthy. Import the dashboards and they run immediately against logs-*, metrics-*, and traces-*. No extra index, ingest pipeline, or custom labels.

This pack is a Lens ES|QL catalog, not an event-volume dashboard. KPIs, donuts, treemaps, and tables count assets. A host with a million logs and a host with fifty logs both appear as one row, with yes/no coverage for logs, metrics, and traces, plus OS, cloud, region, environment, running services, and last seen.

Use it when Infrastructure Hosts, APM, and the inventory waffle each show one entity type well, but you still cannot answer “what did we observe across the estate, and what is missing on each asset?” Click a host.name or service.name cell to filter, then open Elastic’s out-of-the-box Observability apps with the same name.

When to use it

Use after Elastic Agent, APM, or OpenTelemetry is already shipping into Elastic data streams. Typical jobs:

• Onboarding: prove which hosts and services are emitting which signals before you build SLOs.
• Incident start: see which assets are alerting or showing failures, then drill into one asset instead of guessing an index.
• Coverage gaps: treemap and heatmap show hosts with metrics but no logs, or services with logs but no traces — as asset profiles, not stacked event counts.

Do not use it as a Business Critical Service scoreboard. For UX/CDN/origin health across async layers, use the BCS health dashboard — that pack answers “is the service healthy?”; this pack answers “which technical assets were observed, and what do we know about each one?”

What you get

Two Kibana dashboards built as Lens visualizations on ES|QL (metric, donut, treemap, heatmap, datatable, bar, waffle, tag cloud):

• dashboard/observed-assets-inventory.ndjson — Observed Assets Inventory (estate catalog) and Observed Assets Investigation (filtered drill-down). Import and open; the queries already read logs-*, metrics-*, and traces-*.
• KPI row of observed hosts / services / pods with a secondary “not healthy” count, plus how many hosts still have incomplete signal coverage.
• Host health donut, coverage treemap, and coverage×health heatmap — all sized by number of hosts.
• Tables of asset content: identity, Status, Coverage, Logs/Metrics/Traces yes-no, OS, cloud, region, environment, related services, agent, last seen.
• Composition charts: hosts by coverage profile, services that have traces, hosts by environment (waffle), hosts by cloud (tag cloud).
• Investigation dashboard: filtered host/service tables, host↔service relationships, and the datasets talking about the current filter.
• In-dashboard links into Infrastructure Hosts, inventory waffle, APM, Logs Explorer, and Observability alerts. URL patterns are also in guides/OOTB_LINKS.md.
• esql/ — the same entity queries for Discover / Dev Tools, including ECS + native OTel pod names via COALESCE.

Optional sample documents in sample-data/ exist only if you want a playground on an empty cluster. Production and demo environments that already have OTel or ECS data do not need them.

How to use it after import

1. Import dashboard/observed-assets-inventory.ndjson (Saved Objects, include related objects). There is no data view to retarget and no demo index to create.
2. Open Observed Assets Inventory. Set the time picker to Last 24 hours or your incident window. Panels use ?_tstart / ?_tend so the picker drives every Lens query.
3. Read the KPI row as estate size and health, then the donut/treemap/heatmap as how the estate is composed (healthy vs errors, full vs partial coverage).
4. Scroll to the host table. Each row is one host: metadata, yes/no coverage, status. Click host.name to filter the rest of the dashboard to that asset.
5. Use the service and pod tables the same way. A service with Traces = no is a tracing gap, not a low event count.
6. Open Observed Assets Investigation (or follow the in-dashboard link) while the filter is still on. That dashboard shows related services, datasets, and coverage for the selected asset.
7. From either dashboard, open Infrastructure Hosts for a host, APM for a service, Logs Explorer for the log stream, or Observability alerts for rules that already fired.

Click-to-filter works on Kibana Basic. Markdown links into Observability apps work on every license; paste the asset name in the destination app if the session filter does not carry over.

ECS and OpenTelemetry

Queries group on ECS identity fields Elastic already maps from OpenTelemetry (host.name, service.name, service.environment, kubernetes.pod.name, cloud.*, data_stream.type). Host and service panels therefore light up on Agent, APM, and Elastic-mapped OTel with no customer-side field aliases.

Pod panels also COALESCE native OTel names (k8s.pod.name, k8s.namespace.name) so mixed clusters still catalog pods. If a cluster has no Kubernetes fields at all, host and service Lens panels still work; only the pod chart is empty or unused.

How this stitches with other packs

One catalog is not a full observability practice. Use this pack to pick the asset and see its coverage, then continue:

• Kubernetes Observability hub — Why: when the clicked asset is a pod or node and you need cluster/SLO evidence rather than a single container row.
• Distributed tracing investigation pack — Why: when the service row shows Traces = yes (or Status = errors) and you need dependency/span ES|QL after APM overview.
• End-to-End Observability hub — Why: when the question is Business Critical Service health across UX, CDN, origin, network, and platform, not a host/service inventory.
• E2E Observability Correlation Keys — Why: keep service.name / host names aligned with BCS labels so this catalog joins the same critical service.
• Network Observability hub — Why: when the host and APM service look healthy but the path, DNS, or TLS layer is the next place to look.

Compatibility

Kibana 8.16+ / 9.x Saved Objects import of Lens ES|QL dashboards. Queries assume Elastic data streams (data_stream.type of logs, metrics, or traces) and ECS identity fields. Alerting status uses event.kind: alert and event.outcome: failure on those streams; Elastic rule alerts in hidden .alerts-observability.* indices are not required for the catalog to load.

Source and license

Original Elastic Content Share pack (CC BY 4.0). After download, README.md and guides/ in the ZIP are the operational source. Product deep links follow Elastic Observability: Observability documentation for Infrastructure Hosts, APM, Logs Explorer, and Inventory.

Download Now

Tested versions	9.x
ECS compliant
Tested versions	9.x