Grafana
Grafana builds dashboards and alerts over metrics, logs and traces from many data sources such as Prometheus. Learn how teams use it for observability.
Overview
Grafana is an open-source tool for building dashboards and alerts on top of data that lives somewhere else. It does not usually store your metrics, logs or traces itself. Instead it connects to data sources such as Prometheus, Loki, Tempo, PostgreSQL, Elasticsearch or cloud monitoring services, runs queries against them, and shows the results as graphs, tables, heatmaps and other panels. It can also evaluate rules and send notifications when values cross thresholds.
An everyday picture is a car dashboard. The speedometer, fuel gauge and engine temperature light each read from a different sensor somewhere in the car. The dashboard does not make petrol or measure the engine; it brings the readings into one place you can glance at while driving, and it lights a warning when something needs attention. Grafana is that dashboard for software systems.
For AI and data teams, Grafana is often the screen everyone looks at during an incident: request rates and latency for model endpoints, GPU memory, queue depth, data pipeline lag, and error logs side by side. Because one dashboard can mix sources, it helps connect a latency spike in metrics with the log lines and traces that explain it.
What it is
Grafana's main building blocks are these.
| Part | What it is |
|---|---|
| Data source | A configured connection to a back end, with its own query language (PromQL, LogQL, SQL and so on) |
| Dashboard | A page of panels with shared time range and variables, stored as JSON |
| Panel | One visualisation driven by one or more queries: time series, stat, table, heatmap, logs and others |
| Variable | A dropdown or text value that changes queries across a dashboard, such as cluster or model name |
| Explore | A free-form query view for investigating without building a dashboard |
| Alerting | Rules evaluated on a schedule, with contact points and notification policies |
| Plugins | Extensions adding data sources, panels or apps |
Grafana is developed by Grafana Labs, which also builds related open-source back ends: Loki for logs, Tempo for traces and Mimir for long-term Prometheus-compatible metrics. Together these are often called the LGTM stack (Loki, Grafana, Tempo, Mimir). Grafana itself is licensed under the GNU Affero General Public License v3 (AGPLv3) since 2021; it was previously Apache 2.0. A hosted service, Grafana Cloud, and a commercial Grafana Enterprise edition also exist.
Where it came from
Torkel Ödegaard released Grafana in January 2014. It grew out of work on dashboards for Graphite, and its early interface was based on Kibana 3; the name blends Graphite and Kibana. Over time it added many more data sources and became a general observability front end.
Grafana Labs was founded in 2014, originally under the name Raintank. In April 2021 Grafana and its sister projects moved from Apache 2.0 to AGPLv3. Loki was started in 2018, Tempo announced in 2020 and Mimir in 2022 as a successor to Cortex.
Grafana 12 arrived in 2025. Grafana 13 was announced at GrafanaCON in April 2026, with features including suggested dashboards for connected data sources, dynamic dashboards becoming generally available, and Git Sync for managing dashboards as code with GitOps workflows. Check the release notes for the exact version you run, as minor releases follow regularly.
How it works
1. Connect data sources
An administrator adds data sources with URLs and credentials. Each source plugin knows how to send queries in that system's language and turn responses into data frames, Grafana's common table-like format.
2. Build panels
A panel holds one or more queries, a visualisation type and display options such as units, thresholds and colours. Transformations can join, filter or compute fields after the query returns.
3. Compose dashboards
Panels are arranged on a dashboard with a shared time picker. Variables, such as $namespace or $model, are substituted into every query, so one dashboard serves many services.
4. Query on demand
When someone opens a dashboard, Grafana's back end sends the queries to each data source for the chosen time range and renders the results in the browser. Data is fetched live; Grafana caches little by default.
5. Alert
Alert rules run queries on a schedule and evaluate conditions. When a condition holds for the pending period, the alert fires and notification policies route it to contact points such as email, chat or paging tools.
6. Correlate
Links between signals let a user jump from a latency spike on a metrics panel to matching logs in Loki and to a trace in Tempo, using shared labels and trace IDs. This is where OpenTelemetry instrumentation pays off.
7. Manage as code
Dashboards are JSON. Teams keep them in Git and provision them through files, the HTTP API, Terraform or Git Sync, so changes are reviewed like code.
Key concepts and terms
| Term | Meaning |
|---|---|
| Data source | A connection to a back end that Grafana queries. |
| Dashboard | A page of panels sharing time range and variables. |
| Panel | One visualisation with its queries and options. |
| Data frame | Grafana's internal tabular format for query results. |
| Variable | A placeholder value used across queries in a dashboard. |
| Transformation | A post-query operation such as join, filter or calculate. |
| Explore | An ad-hoc query and investigation view. |
| Alert rule | A query plus a condition evaluated on a schedule. |
| Contact point | A destination for notifications. |
| Notification policy | Routing rules that decide which contact point receives which alert. |
| Provisioning | Loading data sources and dashboards from files or code. |
A worked example
This scenario is illustrative. A team runs three large language model endpoints on a shared GPU cluster. Prometheus scrapes the model servers and GPU exporters every 15 seconds, Loki collects container logs, and Tempo stores traces from an OpenTelemetry-instrumented gateway.
They build one dashboard named "LLM serving" with two variables: $cluster and $model. The top row has four stat panels: requests per second, error rate, p95 time to first token and GPU memory used. The second row shows time-series panels for tokens per second and queue length. The bottom row is a logs panel filtered to level="error" for the selected model.
During a busy afternoon the p95 time to first token for one model rises from 400 ms to 3.1 seconds. The error-rate panel stays flat. GPU memory sits at 97%. Clicking a slow data point opens example traces, which show requests waiting in the scheduler before prefill. The logs panel shows repeated warnings about cache eviction. The team lowers the maximum concurrent sequences for that model and adds an alert rule: if p95 time to first token exceeds 1.5 seconds for ten minutes, notify the serving channel. The dashboard JSON is committed to Git so the change is reviewed and reproducible.
Strengths and limitations
Strengths:
- Connects to a very wide range of data sources and mixes them on one dashboard.
- Rich visualisations, variables and transformations.
- Unified alerting across sources.
- Strong links between metrics, logs and traces when instrumentation is consistent.
- Dashboards as JSON suit version control and automation.
- Large community library of ready-made dashboards.
Limitations:
- Grafana is only as good as its data sources; slow queries mean slow dashboards.
- Dashboards multiply and decay without ownership and review.
- Each data source has its own query language to learn.
- AGPLv3 licensing needs review for some redistribution or modification scenarios.
- Not a business intelligence tool; complex ad-hoc analytics fit other products better.
How it compares with alternatives
| Tool | Focus | When it fits better |
|---|---|---|
| Kibana | Front end for Elasticsearch and OpenSearch-style data | Log and search analytics centred on Elasticsearch |
| Datadog and other SaaS observability suites | Hosted collection, storage and dashboards in one product | Teams that want an all-in-one managed service |
| Prometheus built-in UI | Simple query and graph view | Quick checks and debugging PromQL |
| Phoenix, Langfuse | LLM-specific tracing and evaluation views | Prompt-level traces and quality analysis for LLM apps |
| BI tools (Superset, Tableau) | Business analytics over warehouses | Reporting and exploration of business data |
Grafana is usually the operational front end, while LLM tracing tools and model monitoring cover prompt and quality questions.
Practical guidance and best practices
- Start each service dashboard with the key user-facing signals: rate, errors and duration.
- Use variables instead of copying a dashboard per service or environment.
- Set correct units and thresholds on every panel so readers do not have to guess.
- Keep dashboards in Git and provision them; treat manual edits in production as drafts.
- Assign an owner to each dashboard folder and delete stale dashboards regularly.
- Use recording rules or pre-aggregation in the back end for heavy queries.
- Give alert rules runbook links, sensible pending periods and clear severity labels.
- Restrict data source permissions so dashboards cannot expose sensitive logs to everyone.
- Use consistent labels and trace IDs across signals so correlation links work.
Common mistakes
- Building dashboards with dozens of panels that nobody can read during an incident.
- Averaging percentiles or mixing units across panels.
- Running expensive queries over 30-day ranges with 15-second resolution on every page load.
- Creating alerts in Grafana and Prometheus for the same condition, causing duplicate pages.
- Leaving default admin credentials or anonymous access enabled on an internet-facing instance.
- Hard-coding cluster or namespace names into queries instead of using variables.
Frequently asked questions
Does Grafana store data?
Mostly no. Grafana queries external data sources and stores only its own configuration, such as dashboards, users and alert rules. Storage is the job of systems like Prometheus, Mimir, Loki or a database.
Is Grafana free?
Grafana's open-source edition is free under AGPLv3. Grafana Labs also sells Grafana Cloud and Grafana Enterprise with extra features and support.
Can Grafana send alerts?
Yes. Grafana Alerting evaluates rules against many data sources and routes notifications through contact points and notification policies.
What is the LGTM stack?
It refers to Loki for logs, Grafana for visualisation, Tempo for traces and Mimir for metrics, all developed by Grafana Labs as open-source projects.
Can I manage dashboards as code?
Yes. Dashboards are JSON and can be provisioned from files, managed through the API or Terraform, or synced from Git with Git Sync in recent versions.
Is Grafana useful for LLM applications?
Yes, for operational signals such as latency, throughput, errors and GPU use. Prompt-level quality analysis is usually done in dedicated LLM observability tools alongside it.
Glossary
- Dashboard: a collection of panels on one page.
- Panel: a single chart, table or stat.
- Data source: a back end Grafana queries.
- LogQL: Loki's query language.
- Loki: a log aggregation system from Grafana Labs.
- Tempo: a distributed tracing back end from Grafana Labs.
- Mimir: a scalable long-term metrics store compatible with Prometheus.
- Contact point: where alert notifications are sent.
- Provisioning: configuring Grafana from files or code.
- AGPLv3: the copyleft licence Grafana has used since 2021.
Summary
Grafana is a dashboard and alerting layer that queries many data sources and presents metrics, logs and traces together. Released by Torkel Ödegaard in 2014 and developed by Grafana Labs under AGPLv3 since 2021, it reached Grafana 13 in April 2026 with features such as dynamic dashboards and Git Sync. It is most useful when dashboards are focused on user-facing signals, built with variables, kept in version control, owned by a team and linked across signals through consistent labels and trace IDs.
Related
It belongs to Platform in my stack, under MLOps and AI infrastructure. Others in the same group: