[Coordination & infra OTel] Regenerate OTel dashboards with adHocDataViews

[giorgi-imerlishvili-elastic]

Proposed commit message

WHAT

Recompiles the committed Kibana dashboard JSON for five OTel content packages — etcd_otel,
zookeeper_otel, airflow_otel, nvidia_gpu_otel, vsphere_otel — from their existing, unchanged
_dev/shared/kibana/*.yaml sources. Across 14 dashboards and 187 ES|QL Lens layers, every layer now
carries the three pieces of state a Lens ES|QL panel needs to resolve its own data view:

• state.datasourceStates.textBased.layers.<layerId>.index — the ad-hoc data view id
• state.adHocDataViews.<id> — title equal to the layer's ES|QL FROM/TS index pattern,
  timeFieldName: "@timestamp"
• state.internalReferences — the matching index-pattern reference

Counts after regeneration (1:1 on every layer, no orphans, no duplicates):

package	dashboards	ES|QL layers	layer.index	adHocDataViews	internalReferences
etcd_otel	4	51	51	51	51
zookeeper_otel	1	18	18	18	18
airflow_otel	4	31	31	31	31
nvidia_gpu_otel	1	20	20	20	20
vsphere_otel	4	67	67	67	67
total	14	187	187	187	187

Nothing else changes. A field-by-field diff against the committed 0.3.0 JSON shows the additions
above (plus the indexPatternRefs bookkeeping the compiler writes alongside them) and no other
edits: ES|QL queries, visualization types and dimensions, panel titles, layout, dashboard-level
filters, controls and drill-down links are byte-identical. manifest.yml goes 0.3.0 -> 0.3.1 with a
bugfix changelog entry per package.

WHY

On Kibana 9.3+ a Lens ES|QL panel whose layer has no index/adHocDataViews cannot resolve a data
view, so the "Explore in Discover" panel action is never registered and the panel loses its
drill-down. The failure is silent — the action is simply absent rather than erroring — so it is easy
to miss in review. Populating the three fields restores the drill-down without touching any query or
visualization.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

Author's Checklist

• Confirm the JSON diff is limited to layer.index, adHocDataViews, internalReferences and
  indexPatternRefs — no query, visualization, filter, control, title or layout changes.
• Confirm each adHocDataViews[<id>].title matches its layer's ES|QL source index pattern and
  that timeFieldName is @timestamp.
• Compiler pin: these JSON files are intentionally ahead of what the CI-pinned compiler
  (kb-dashboard-cli==0.4.1, .github/workflows/validate-yaml-dashboards.requirements.txt)
  produces — 0.4.1 emits 0 adHocDataViews. The "Validate Dashboard Compilation" workflow is a
  no-op here because no YAML changed, but the compiler fix must be released and the pin bumped
  before the next PR touches these YAML sources, or the fix will be recompiled away.
• Pre-existing, out of scope: 28 of 187 panels (27 in etcd_otel, 1 in zookeeper_otel) now
  open Discover but the handed-off query is rejected by Elasticsearch:
  [:] operator cannot operate on [data_stream.dataset] ... in non-STANDARD mode [time_series].
  Kibana appends the dashboard-level KQL filter as | WHERE `data_stream.dataset` : "..." and
  ES|QL rejects the : match operator against time_series indices for these rate/counter
  queries. The same 159-pass/28-fail split occurs when the simulation is run against the
  committed 0.3.0 JSON, so it is independent of this change — it was previously unreachable
  because the action did not exist. All four vsphere_otel dashboards have no dashboard-level
  filter and see 0 failures.

How to test this PR locally

Executed while preparing this PR (Kibana/Elasticsearch 9.5, local elastic-package stack)

Package validation — all five pass:

$ cd packages/<package> && elastic-package check -v
Package built: .../build/packages/etcd_otel-0.3.1.zip           Done   (exit 0)
Package built: .../build/packages/zookeeper_otel-0.3.1.zip      Done   (exit 0)
Package built: .../build/packages/airflow_otel-0.3.1.zip        Done   (exit 0)
Package built: .../build/packages/nvidia_gpu_otel-0.3.1.zip     Done   (exit 0)
Package built: .../build/packages/vsphere_otel-0.3.1.zip        Done   (exit 0)

vsphere_otel additionally reports 4 pre-existing SVR00002 findings ("expected filter in
dashboard") as skipped errors; they are identical on the committed 0.3.0 files and do not fail the
check.

Structural verification of all 187 layers (ids agree across layer.index, adHocDataViews and
internalReferences; data-view title equals the ES|QL source; timeFieldName == "@timestamp"; no
duplicate refs; no orphan data views): 187/187 pass, 0 failures.

Live validation on 9.5 with synthetic OTel metrics ingested into TSDB indices for all five datasets:

• All 374 panel query instances execute against Elasticsearch and return rows.
• "Explore in Discover" is present on 187/187 ES|QL panels across all 14 dashboards, with 0 panel
  render errors. Non-ES|QL panels (markdown, links) correctly do not offer it.
• A side-by-side dashboard rebuilt from the committed 0.3.0 JSON shows the action absent on all 17
  ES|QL panels of etcd_otel-overview, and present on the same 17 panels after regeneration.
• Click-throughs on at least one panel per package (TS, FROM and FORK queries) open Discover
  with the query text, index pattern, columns and time range preserved, and results matching the
  panel. No Cannot read properties of undefined (reading 'id') in the console.
• Opening panels in Lens resolves the ad-hoc data view, its fields and its time field. Dashboard
  controls populate, and dashboard-to-dashboard links preserve the time range.
• A UI save round-trip (duplicate + save) preserves layer.index, adHocDataViews and
  internalReferences on all 13 panels of the saved copy, and the action still works.
• GET /api/dashboards/<id> returns HTTP 200 for all 14 dashboards with no schema failure, and the
  panel counts, panel types and ES|QL query sets are identical before and after.

Note for 9.5 reviewers: "Explore in Discover" is a panel hover button
(embeddablePanelAction-ACTION_OPEN_IN_DISCOVER), not an entry in the panel ⋯ menu.

For the reviewer

# 1. Start a 9.3+ stack
elastic-package stack up -d -v --version 9.5.0

# 2. Build and install one of the packages
cd packages/etcd_otel && elastic-package check -v && elastic-package install -v

# 3. Open any of its dashboards in Kibana, hover an ES|QL panel, and click
#    "Explore in Discover" -> Discover opens with the panel's ES|QL query, index
#    pattern, columns and time range. Repeat on a 0.3.0 install to see the action missing.

Related issues

• Relates elastic/obs-integration-team#1148
• Relates elastic/obs-integration-team#1014

Screenshots

N/A — no UI or dashboard content changes; the panels render exactly as before. The change only
restores the "Explore in Discover" panel action, which is described under "How to test this PR
locally".

[github-actions]

✅ Elastic Docs Style Checker (Vale)

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[elastic-vault-github-plugin-prod]

✅ All changelog entries have the correct PR link.

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: 562dffd

cc @giorgi-imerlishvili-elastic