Spaces, Alerting & Advanced Queries

Spaces & Security

Spaces isolate saved objects (dashboards, visualizations) so multiple teams can share one Kibana instance without cluttering each other's UI. Important caveat: a Space controls what's visible in the UI, NOT what underlying Elasticsearch documents a user's queries can actually read — real data-level isolation between teams requires Elasticsearch role-based access control configured separately, not just Space membership.

Alerting

Alert rules define a condition (e.g. error rate above a threshold over 5 minutes) and a connector (email, Slack, PagerDuty) to notify when it fires — turning Kibana from a passive dashboard into active monitoring.

Runtime Fields

// Data view -> Add field -> Runtime field
// Computed at QUERY time from existing fields — no reindexing needed
// to retroactively add a derived field to potentially huge historical indices
emit(doc['user_agent.raw'].value.contains('Mobile') ? 'mobile' : 'desktop')

// Trade-off: computed fresh on every query (cost), vs. the one-time
// (but potentially very expensive) cost of reindexing to store it physically.

High-Cardinality Pitfall

Building a terms aggregation on a very high-cardinality field (a UUID, a raw user-agent string) is expensive and, by default, returns only an approximate top-N — the resulting chart can silently omit a long tail of values with no obvious indication it's incomplete. Bucket by a lower-cardinality categorical field, or pre-aggregate at ingestion time, instead.

Index Lifecycle Management (ILM)

ILM policies move indices through hot/warm/cold/delete phases based on age or size. This directly determines what historical range is still queryable in a dashboard — data that seems to have "disappeared" from Kibana has usually just aged out per an ILM policy, not a Kibana bug.