Kibana Lens: inspect the query before you trust the chart

The problem: a chart is a query, not a picture

Most bad Kibana dashboards are not caused by bad taste in colors. They are caused by a visualization quietly asking Elasticsearch for too many buckets, the wrong aggregation, or a sampled result set. The useful takeaway is simple: treat every Kibana Lens chart as a generated Elasticsearch query. Build it by dragging fields, then open the Debug panel and confirm the query matches the question you meant to ask.

This guidance targets Kibana 8.x and later, where Lens is the default visualization editor and data views are the normal way to select indices. In older 7.x stacks, the same ideas apply, but the UI may label data views as index patterns.

What Lens actually does with your drag-and-drop

Lens suggests aggregations based on field type. A numeric field may offer count, sum, average, or cardinality; a date field usually becomes a time axis; a keyword field often becomes a breakdown or filter. When you switch between bar, line, area, pie, heatmap, or scatter, Lens preserves the field mapping and rewrites the visualization configuration rather than forcing you to rebuild the chart.

Under the hood, those shelf selections become an Elasticsearch DSL query. That is the key engineering detail: the drag-and-drop interface is a query builder, not a separate rendering engine. You can inspect the generated DSL, understand why the chart is slow, and decide whether the default aggregation is acceptable.

Worked example: average bytes over time

Suppose you have a data view named logs-* with a date field @timestamp and a numeric field bytes. A useful first chart is average response size over time.

1. Open Kibana and go to the Lens app.
2. Select the logs-* data view.
3. Drag @timestamp to the horizontal axis.
4. Drag bytes to the vertical axis and choose the average aggregation.
5. Set the chart type to line.
6. Open the Debug panel using the bottom-left icon.

The practical check is to look for two things in the generated DSL: a date histogram on the time field and an average metric on bytes. If the chart shows a flat count instead of an average, stop and check the field mapping. A numeric-looking field stored as keyword or text will not produce a meaningful average. If the Debug panel shows a very large terms bucket count, narrow the time range or add a KQL filter before saving.

When the chart looks correct, save it with a specific name such as Average bytes over time. Then verify it under Stack Management or Management, depending on your Kibana version, by opening Saved Objects, filtering by type visualization, and confirming the name appears. If you want to confirm the drag-and-drop mapping, edit a term clause in the Debug panel and watch the chart update; that demonstrates the UI is rewriting the query rather than hiding it.

Lens, Visualize editor, or Vega-Lite: choose by failure mode

Lens covers most everyday analytics, but it is not the right tool for every visualization. The decision should be based on what breaks first.

Option	Best fit	Common limitation
Lens	Fast interactive charts from existing fields	May sample very large result sets; limited for scripted calculations
Visualize editor	Aggregation-based visualizations with more manual control	More JSON editing; less drag-and-drop convenience
Vega-Lite	Highly custom layouts, calculations, or marks	Requires Vega-Lite syntax and more maintenance

If you need scripted fields, complex calculations, or a custom visual grammar, build the visualization outside Lens. If you need a quick dashboard panel that another engineer can inspect and modify, Lens is usually the better default.

Sampling, saved objects, and rollback

For very large result sets, Lens may sample data to keep the UI responsive. That can hide rare outliers. Where your Kibana version exposes a sampling setting, disable it for investigations where completeness matters, then re-check the Debug panel and the chart totals. Do not assume a saved dashboard panel is exhaustive if the underlying result set is large.

Lens visualizations are saved as Kibana saved objects. They can be added to dashboards, shared through Spaces, and exported as PNG or CSV for reporting. That makes them easy to reuse, but also means a bad chart can spread quickly. Saving a visualization changes state, so treat the first save as a test artifact until the query is verified.

Rollback is straightforward: remove the panel from any dashboard that references it, then delete the visualization saved object from Saved Objects. Kibana may warn about references; deleting the dashboard panel first gives a cleaner rollback. If the object was shared through a Space, confirm whether other users depend on it before removing it.

Actionable closing

• Start in Lens, but finish by reading the Debug panel.
• Confirm field types before trusting an average, sum, or cardinality result.
• Narrow time ranges or add filters before saving charts with large bucket counts.
• Disable sampling only when the investigation requires complete results.
• Move to the Visualize editor or Vega-Lite when Lens cannot express the calculation.

The engineering habit that pays off is not memorizing chart types. It is treating every Lens panel as a query with an owner, a scope, and a verification step.