Creating and Validating a Kibana Data View Against Elasticsearch

Problem: Turning Raw Indexes into a Queryable Entry Point

You have application logs spread across time-based indices such as app-logs-2026.10.01, app-logs-2026.10.02, and so on. Discover, Dashboard, and Lens cannot usefully query a rolling list of index names. A Kibana data view—the modern replacement for the legacy index pattern—maps one or more Elasticsearch indices, aliases, or data streams into a single saved object that those apps can query. The practical takeaway: define the narrowest target that covers your data, select the correct timestamp field, and verify both the index match and time-based behavior before sharing the data view with other users.

Prerequisites and Access Model

Before you begin, confirm the following:

• Kibana version: Data views are the standard terminology in Kibana 8.x and late 7.x releases. In older versions the same underlying saved object may still be labeled index pattern in the UI.
• Kibana privileges: You need the Data Views feature privilege under Stack Management, typically granted via a role with kibana_admin or a custom role.
• Elasticsearch privileges: Your Elasticsearch role must have read and view_index_metadata on the target indices, aliases, or data streams. Kibana feature privileges alone are not enough.
• Space awareness: Data views are saved objects scoped to a Kibana space. A data view created in the Default space is not automatically visible in other spaces.

Choosing the Target: Indices, Aliases, and Data Streams

A data view can point at three kinds of Elasticsearch targets. The choice affects lifecycle management and query behavior.

Example decision: If your logs are written to a new index each day and an ILM policy handles rollover, point the data view at an alias such as app-logs rather than a wildcard. This keeps dashboards stable when old indices are deleted.

Verifying the Target Before You Create the Data View

Run the following in Kibana Dev Tools > Console (or any Elasticsearch client) using an account with monitor or view_index_metadata privileges:

GET _cat/indices/app-logs-*?v

Expected check: A table listing the matching indices with health, document count, and storage size. If the response is empty, the pattern is wrong or the indices do not exist. For an alias target, substitute _cat/aliases/app-logs?v and confirm the alias resolves to at least one index.

Risk: Running the command with * will list system indices as well. Avoid confirming a wildcard that broad before you commit it to a data view.

Creating the Data View

1. In Kibana, open Stack Management > Data Views (or Kibana > Stack Management in older layouts).
2. Click Create data view.
3. Enter a descriptive name, for example Application logs. Names must be unique within the current space.
4. In the index pattern field, enter the target: an index pattern such as app-logs-*, an alias name such as app-logs, or a data stream name.
5. Select the timestamp field from the dropdown. This is usually @timestamp or a custom date field such as event.created. If your documents have no date field, you may leave it unset, but time-range filters and date histograms will be unavailable.
6. Optionally expand advanced options to add runtime fields—fields computed at query time without reindexing. Review performance and security implications before adding them.
7. Save the data view.

Expected Checks After Creation

A saved data view is not proof of correctness. Validate it with these checks:

• Discover smoke test: Open Discover with the new data view. Confirm the document count and field list match what you saw in the _cat output. An empty result usually means the pattern matched nothing or privileges are missing.
• Time-range proof: Apply a known relative time range (for example, last 24 hours) and verify the histogram updates. If the histogram is flat or empty despite documents existing, the timestamp field is likely wrong or not mapped as a date type.
• Saved object inspection: Go to Stack Management > Saved Objects, filter by type index-pattern, and confirm the data view appears with the expected space assignment and referenced pattern.
• Privilege test: Share the data view with a non-privileged user. Confirm that Elasticsearch document-level and field-level security are enforced; the user should see only permitted documents and fields.

Recovery Options for Common Misconfigurations

No Indices Matched

If Discover shows no documents, edit the data view and correct the index pattern. Re-run the _cat command above to confirm the new pattern resolves. The saved object itself remains intact; only the pattern reference needs repair.

Wrong Timestamp Field

Changing the time field after dashboards and saved searches depend on the data view can break existing visualizations or produce misleading time-based aggregations. If you must change it, first identify dependent saved objects in Saved Objects, then edit the data view and re-check affected dashboards.

Permission Failures

A user who can see the data view but gets empty results or errors likely lacks Elasticsearch read privileges on the backing indices. Grant read on the specific indices, aliases, or data streams—not on *—and re-test.

Name Conflicts Across Spaces

Because names are unique per space, exporting and importing data views can create duplicates or collisions. If an import fails, rename the data view in the target space or delete the conflicting object before retrying.

Limitations to Keep in Mind

• Runtime fields are Kibana-scoped: A runtime field defined on a data view is not available in direct Elasticsearch queries outside Kibana. Downstream consumers must replicate the logic.
• Wildcard scope: Overly broad patterns can match system indices and degrade query performance. Prefer aliases or narrowly scoped patterns.
• Time-field immutability: Treat the timestamp field as a contract. Changing it late is a breaking change for time-based analytics.

Practical Way to Confirm Success

Open Discover, select the data view, set the time range to a period you know contains data, and confirm that both the document count and the histogram reflect that period. Then open a saved dashboard that uses the data view and verify the visualizations render without field-type warnings. If both pass, the data view is correctly mapped, privileged, and time-aware.