Skip to main content
Reading raw JSON from curl is no way for a team to investigate issues efficiently. Take Bob’s cluster. It’s Monday morning and support reports that USER1 had a rough weekend on the website. The raw JSON that Elasticsearch stores looks like this:
Kibana has the data — but answering questions with curl is tedious. Bob must remember the search endpoint, construct a long URL, add a size parameter so results aren’t truncated, and then scan a wall of JSON for timestamps.
A teammate leans over and asks, “Can you check USER3 too?” and the whole process repeats. Without meaning to, Bob has become the team’s search engine. That does not scale. What the team needs is a UI that sits in front of Elasticsearch, accepts human-friendly queries, and shows answers as rows and charts instead of raw JSON. That tool is Kibana. Kibana is a web application — a page in your browser that asks Elasticsearch questions on your behalf. Kibana does not store log documents itself; it queries Elasticsearch’s REST API and renders the results.
A simple diagram titled "Just a Web Page" showing a user labeled Bob sending requests to Kibana which then forwards to Elasticsearch. A small mock browser panel at the bottom left shows search/log entries for "USER1" with timestamps.
Every search in Kibana results in an HTTP request to Elasticsearch (port 9200). Kibana simply formats the results and displays them in the browser. Where does Kibana run inside the cluster? Because Kibana doesn’t hold log data, it does not require persistent storage or fixed network identity. If a Kibana pod crashes, Elasticsearch remains intact — a new Kibana pod can start and reconnect. For that reason, Kibana is commonly deployed as a Deployment (one replica is often sufficient), while Elasticsearch runs as a StatefulSet with persistent storage. In this lab Bob’s deployment is named kibana, runs in the elastic-stack namespace, uses Kibana 7.1.0, and listens on port 5601 (Kibana’s default).
A stylized diagram titled "Bob's Kibana Deployment" showing a Kibana instance (kibana:7.1.0) inside an elastic-stack box with Port 5601 labeled.
A running Kibana pod is not automatically reachable from a browser outside the cluster. To expose it, Bob uses a Kubernetes Service. In the lab this is a NodePort Service, which opens a fixed port on each node and forwards traffic to port 5601 on the Kibana pod. Bob types the node’s address and the NodePort into his browser:
Now Kibana is available, but it still needs to know which logs to search. Elasticsearch contains many indices. Fluentd creates daily indices named with a prefix and the date (for example fluentd-2026.10.12), so you get new indices every day.
A presentation slide titled "The Index Pattern" showing a Kibana icon with a "Which logs?" callout on the left. On the right is a cylindrical database icon labeled "fluentd-2026.10.12."
Bob creates an index pattern so Kibana knows which indices to query. For example: fluentd-* He also configures the timestamp field so results can be sorted and filtered by time. That saved configuration is called an index pattern and it lets Kibana search across many time-based indices as a single logical dataset.
Create an index pattern (for example fluentd-*) and set the time field (usually @timestamp) so Discover, Visualize, and Dashboards can filter and sort logs by time.
With the index pattern saved, Bob opens Discover. Discover is a scrolling list of log documents (newest first), with a search bar on top and a time picker beside it. The search bar accepts KQL (Kibana Query Language), which is easier and more expressive than crafting raw Elasticsearch URLs. Bob types log:USER1, presses Update, and Discover returns only USER1 events:
Change the query to log:USER3 and the list updates instantly. What took minutes with curl now takes seconds, and anyone with access to the Kibana page can run the same query. Discover is for reading individual lines, but Kibana can also convert searches into visualizations — e.g., a bar chart that counts occurrences of each user. Visualizations can be pinned to dashboards that teams keep open to monitor trends. Dashboards can be exported and imported as NDJSON files, making it easy to share saved dashboards.
A dark-themed slide titled "Charts and Dashboards" with a large "Lines per User" bar chart for USER1–USER4 on the left. On the right is a four-panel dashboard of small bar charts and an "export.ndjson" file icon beneath.
Security caveat: in this lab anyone who can reach the NodePort can view all logs because there is no authentication. That is acceptable for a private lab, but not for production. Protect Kibana using an authenticated reverse proxy, an Ingress with TLS and authentication, or Kibana’s built-in security features.
Exposing Kibana via a NodePort without authentication lets anyone who can reach the node port view and query all logs. Do not use an unauthenticated NodePort in production; instead use an authenticated reverse proxy, an Ingress with TLS and authentication, or Kibana’s security features.
When should you use Kibana? If you are the only person reading logs and you always know the exact line to fetch, curl is fine. The moment a second person wants to ask their own question, or you need to spot patterns over time instead of fetching a single line, put Kibana in front of Elasticsearch. Bob’s team crossed that line on Monday morning: the manual curl that once answered questions is now replaced by a shared, searchable, visual interface. Links and References

Watch Video