Grafana or Kibana - Help me decide

By Alexey Klochay

Context

The observability of applications is an aspect growing in importance every day for software development teams. More observable applications result in improved the productivity of software teams and software organizations as a whole. The benefits of observable applications include:

• Less time debugging, because more debug information is already available.
• Resolving issues and incidents faster.
• Improved awareness of changes in the environment, from operational load to customer behavior.

Two approaches for creating observable applications are monitoring and log analysis.

The monitoring of applications is usually performed by analyzing the changes in discrete data points describing the state of the system at a given moment, called metrics. Metrics are usually submitted directly to the monitoring system by the running instance of an application. That instance can be a database instance, a web server, or any other part of the web service Monitoring systems are generally focused on real-time metrics.

Logs are information about the specific events that took place at a certain moment in time. Log analysis is a post-event inquiry into the log entries, and therefore past events, that a running application produced. Due to the decreasing latency in log processing over the past years, you can now accomplish log analysis in near-real-time.

In this Stackup we look at one tool from each of the two sides: Grafana, a monitoring solution, and Kibana, a log analysis solution that is part of the Elasticsearch, Logstash, and Kibana stack, or ELK.

Use cases

At their core, Grafana and Kibana cover two different use cases and sets of functionality.

Grafana is a monitoring tool, and its functionality is optimized for monitoring tasks and time series data. The data sources it supports are those most commonly used for storing application metrics and Grafana produces alerts in real time.

Kibana, is a data visualization tool. It was created to facilitate log analysis in combination with the popular Elasticsearch and Logstash. The three tools allow you to query and parse relevant information out of the collected logs and display it in different ways.

What's the difference between the two use cases? Grafana focuses on efficiently displaying a defined set of metrics in real time. Kibana focuses on the exploration of available data and the flexibility of extracting metrics from raw log lines.

Comparison

Data sources

Both Grafana and Kibana support Elasticsearch as a data source.

Apart from Elasticsearch, Grafana supports sourcing metrics from:

• Graphite
• Prometheus
• InfluxDB
• OpenTSDB
• MySQL, PostgreSQL, Microsoft SQL Server
• AWS Cloudwatch

Kibana focuses on Elasticsearch and doesn't support any data sources besides Elasticsearch. However, Kibana offers more functionality for the Elasticseach source, like exploring available data and performing a full-text search on the logs.

Querying

With Kibana, you query log lines to produce metrics that you are looking for. For example, if the log lines contain information on HTTP requests:

method=post api=books result=201
method=get api=books result=200
method=get api=bookshelves result=404

If you want to present the amount of successful HTTP queries vs those that didn't return valid results, you do the following:

• On the machine that produces the example logs above, set up Logstash to process the logs and write them to Elasticsearch.
• In Kibana, create a time series view that looks for the items that have your desired HTTP statuses.

A full breakdown of HTTP requests by status, country, OS and other factors in Kibana. Source: elastic.co

Every time the dashboard needs to update, the query runs and produces the most recent counts for the different HTTP statuses.

The main area of the Kibana user interface includes a search box where you can try any Elasticsearch queries, visualize the results, and save the queries that produce the results you are looking for to dashboards.

On dashboards, it is possible to refine the set of data presented by using additional search parameters introduced via a search box (another Elasticsearch query).

Grafana's interface is not optimized for exploring data, but for setting up dashboards once and using them for a long time. Grafana's interface is optimized for time series data, which is the most common visualization type in monitoring systems.

A Grafana dashboard. Source: grafana.org

Like Kibana, Grafana allows you to narrow down the content of the dashboards with variables, a pre-set list of values you can use to filter the output of the visualizations.

Visualizations

Both Grafana and Kibana offer multiple types of data visualizations which you can use on dashboards. While both systems offer visualizations for most common use cases, Kibana goes further and also provides specialized visualizers like maps and tag clouds. Kibana also allows you to embed graphs created with the Vega framework.

You can find the most common visualization types and their availability in both Grafana and Kibana in the table below.

Find more details about the supported visualizations in the Grafana and Kibana docs respectively:

• http://docs.grafana.org/features/panels/graph/
• https://www.elastic.co/guide/en/kibana/current/createvis.html

Alerting

Grafana has a built-in alerting engine. You can configure alerts for any metric displayed as a time series, and you set via a query like this:

avg() OF query(A, 5m, now) IS BELOW 14

Where A references a metric available in Grafana.

The engine allows handling of special cases like no data available or a failed database connection. If the alert is triggered, Grafana can notify Slack, PagerDuty and other services, or send a generic webhook.

You can find out more about alerting in Grafana in the docs.

Kibana doesn't handle alerts directly but requires you to configure them in Elasticsearch via data watchers. Watchers are functions that run a query periodically and act on the result. You can currently only configure watchers via the API.

Kibana and Elasticsearch currently offer limited documentation on configuring watchers that integrate with third-party services for alerting. Example watchers currently look like this:

https://gist.github.com/skearns64/773dfd64c51d3007baf489be83549e0c

You can find more details about the Elasticsearch Watcher APIs in the documentation.

Conclusion

While monitoring and log analysis solutions contribute to the observability of applications, the tools from the two camps solve different problems and are complementary.

Collecting metrics allows the teams responsible for applications to gain visibility into the current state of a system in real time. The application needs to submit these metrics, and changing the exact metrics submitted generally requires application changes. Collecting metrics is not always possible for legacy or closed-source applications where the team operating the system doesn't have access to the code. But if you can build metrics collection into your application, then collecting and visualizing metrics is where Grafana excels.

Log analysis makes it possible to analyze events produced by the application, which is sometimes the only way to gain insight into the state of a closed system that does not produce relevant metrics. For applications that do produce metrics, log analysis can allow operators to find new trends in the system behavior and iterate on the metrics quickly without application changes. When used as part of the ELK stack, this is where Kibana excels.