Grafana vs Kibana – Patterns and Anti-Patterns

Quite often in my interactions with developers when it comes to monitoring and alerting, a common discussion is Grafana vs Kibana. No surprise here, since these are very popular open-source visualization tool (Grafana scoring higher after its 7.x release)

In this article, I will summarize few patterns and anti-patterns based and also present a case for having Grafana and Kibana in your monitoring stack.

Let us start with some basic information. Kibana is from Elastic and only supports their flagship text-search database Elasticsearch. Grafana on other hand is built to support multiple datasources with focus on time-series metrics (generic dashboard tool).

Since Kibana has only one datasource to support, it is intelligent enough to understand Elasticsearch and provides easier way to discover data. Besides, creating dashboard in Kibana is also easier because it does lot of low level work for you. Grafana, which started as a fork from Kibana by Torkel Ă–degaard, requires some learning because of its design to support querying multiple data sources to built unified visualization.

Quite often developers end up comparing both on the basis of building dashboard backed by Elasticsearch. This is flawed comparison because as mentioned, Kibana will win hands-down here (as expected). However, Grafana scores in its ability to build custom plugins, alerting, RBAC and multi-tenancy, something which requires x-pack in Kibana.


  • Patterns
    • You have multiple data sources having variety of data (metrics, alarm, logs, traces, events) from your stack and want to consolidate monitoring.
    • You want to analyze data from both on-prem and cloud (e.g. AWS Cloudwatch).
    • You want out of the box support to configure alerts and send these alerts to 3rd party (e.g. Kafka, Slack, PagerDuty).
    • Your are looking to build an Observability framework.
  • Anti-Patterns
    • You are looking for a quick way to visualize metrics with variety of charts.
    • You are using Elasticsearch as your go-to datasource and mostly interested in data visualization


  • Patterns
    • Elasticsearch is your primary database on top of which you require visualization capabilities.
    • Text analysis is your primary use case and Elasticsearch is centralized DB for all such textual information (e.g. logs, events)
  • Anti-Patterns
    • You want to build a unified monitoring without building connectors for various DB
    • You want to configure and send alerts to 3rd party (requires x-pack)
    • You want out-of-box support for RBAC in dashboard (requires x-pack)

Most teams, use and maintain multiple DBs for variety of use cases since the day of having a central Relational DB having all information is long gone. So, it is very common to have both serving users where Grafana is for a secure, unified, single pane for monitoring and alerting (due to its support for multiple data sources), where as Kibana for quick visualization and analysis of text data (logs, events).

Hope this was useful, welcome your feedback.

Categories: observability

Tagged as: , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s