Kibana

## What a data view actually is A **data view** is a Kibana saved object that answers one question for every other surface in the product: *which indices may this search touch, and what fields do they have?* It carries three things and no documents at all: - a **title** — the index name, alias, comma-separated list or wildcard it resolves, such as `court-hearings-*`; - an optional **time field** — the name of a single date field present in those indices; - **Kibana-side field metadata** — display labels, value formatters, and runtime fields that exist only in Kibana. The field list you see is not stored in the view. Kibana asks the cluster which fields the matching indices have and merges the answers, so the list changes on its own as indices are rolled and deleted. Older Kibana versions call the same object an *index pattern*, and its saved-object type is still `index-pattern` — worth recognising when you read an export file or an older runbook. ## Why nothing can be explored before one exists Every Kibana surface that offers you a field needs the field list before it can render: Discover's column picker, the filter editor's field drop-down, the query bar's autocomplete, and every field selector in a Lens visualization. Kibana does not guess a pattern, and it will not run a bare search across whatever the cluster happens to hold. That makes the data view the first thing to check when data "is not in Kibana". When a new region of a courtroom-scheduling platform is brought up with no instrumentation and its shippers are finally switched on, the usual symptom is not an empty chart — it is that the region's new indices are matched by no data view at all, so nobody can even see whether documents arrived. Two minutes of creating a view settles what an hour of arguing about the pipeline will not. ## What nominating a time field changes | With a time field | With none | | --- | --- | | The global time picker filters every query built on the view | The picker is ignored and each search covers the whole pattern | | Discover renders its document-count histogram | Discover shows a plain list with no histogram | | Documents come back newest first by default | Ordering falls back to whatever the query returns | | Right for logs, traces, events — anything append-only | Right for small reference data: a courtroom list, a service catalogue | Which date field you nominate is a real decision, not a formality. Event time and ingest time diverge exactly when you care most: a batch of hearing records that arrived late lands under "now" if the view is bound to ingest time, and back at the moment the hearing actually happened if it is bound to event time. Every dashboard, alert and investigation built on the view inherits that choice, and changing it later moves every historical chart. ## When the pattern spans indices that disagree 1. Kibana merges the field lists of every index the pattern currently matches. 2. Where two matched indices give the same field different types, the merged field is shown with the type `conflict`. 3. A conflicting field cannot be used anywhere a type is required — as an aggregation, a range, or a chart axis. Kibana refuses rather than guessing which index was right. 4. The documents themselves are fine. It is only the merged view that is ambiguous. Worked example: `court-hearings-*` matches 41 daily indices holding 6.4 million records. The mature region writes `room` as a string (`"412-annex"`); the region brought up later writes it as a number (`412`). The moment both generations are in range, the room-breakdown panel goes blank and the field shows as a conflict. Three honest responses: - **Narrow the view.** Point one data view at the generation that agrees and keep a second for the rest. Fast, and it splits every dashboard in two. - **Fix the producer.** The only permanent answer, and the only one that stops the next field disagreeing the same way. - **Wait, where retention allows.** With a 96-hour retention floor the older generation ages out in four days and the conflict clears itself. A legitimate call for a one-off, and a bad habit as a policy. ## Practical notes - **A data view is not an access-control boundary.** Anyone who can query the underlying indices can build their own view over a wider pattern; restricting what a person may read is a cluster-level concern. - **Views are cheap — have several.** A narrow view per team reads far better than one `*` view that puts thousands of fields in every drop-down. - **The field list is cached.** A field added upstream does not appear until the view's field list is refreshed. - **Runtime fields belong to the view, not the index.** They are computed while the search runs, which is why they can rescue a field nobody extracted at ingest, and why each one costs CPU on every query that touches it.