Grafana Interview Questions

You can use Grafana to collect metrics, make sense of enormous volumes of data, and monitor your applications via interactive, configurable dashboards. Grafana connects to Graphite, Prometheus, InfluxDB, Elasticsearch, MySQL, PostgreSQL, Loki, Tempo, Mimir, OpenTelemetry, Azure Monitor, BigQuery, ClickHouse, and more.

Grafana's open-source nature allows us to create custom plugins for a range of data sources. Time-series analytics is a technique for analysing, tracking, and reviewing data over time.

You can use Grafana dashboards to create smart visualisations and alerts to help users better understand their data metrics.

Grafana dashboards not only add meaning to data from a variety of sources but also let you share them with other team members, enabling collaboration on data analysis.

Grafana can visualise data, but it depends on Prometheus, Alloy, and OpenTelemetry collectors.

Grafana Tempo strongly integrates with Grafana, Prometheus, and Loki. Tempo supports open-source tracing protocols such as Jaeger, Zipkin, and OpenTelemetry.

A panel editor includes a query builder as well as a variety of options for data transformation and data addition to your panels.

This tool helps organisations transfer resources from a self-managed Grafana OSS or Grafana Enterprise instance to Grafana Cloud. 

It provides a guided, UI-based workflow. It also automates much of the migration process, so there’s no need to use Grafana APIs or custom scripts.

Adaptive Telemetry filters, samples, aggregates, or drops unimportant metrics, logs, and traces before storage. This lets teams manage data volume without losing key insights.

You dont need to create dashboards manually in the Grafana UI; instead, you can write JSONnet code, generate the dashboard JSON, and then deploy it to Grafana.

Grafana supports more than 100 data sources through built-in integrations and official or community plugins. These data sources include metrics, logs, traces, SQL and NoSQL databases, cloud monitoring platforms, ClickHouse, Pyroscope (profiling), OpenTelemetry-native sources and third-party SaaS services.

Grafana is the most widely used open-source tool for querying, visualising, and alerting on metrics and logs from everywhere. It also supports traces, profiles, continuous profiling (Pyroscope), synthetic monitoring, frontend observability, Kubernetes monitoring, and incident response.

Time-series databases like Graphite, Prometheus, Elasticsearch, OpenTSDB, and InfluxDB are used for querying.

Labels are key-value pairs. For example, you use the term "metadata" To describe a log stream. Labels are crucial in Loki since they define a stream. More precisely, the stream is defined by the combination of each label key and value.

Grafana Cloud lets you view all your observability data in one place, whether it's stored in Grafana Cloud Metrics or on your own bare-metal and cloud systems.

With built-in support for Prometheus, Elasticsearch, and Amazon CloudWatch, all you have to do is configure data sources in Grafana Cloud to start developing dashboards and querying metric data.

Grafana Enterprise provides access to enterprise plugins that let you use your existing data sources in Grafana. You can get the most out of complex, costly monitoring solutions and databases by viewing data more efficiently and effectively.

This version also supports RBAC, reporting, enterprise authentication, audit logs, premium plugins, governance, caching, and more.

Grafana visualises data, and Prometheus stores the time-series metrics Grafana visualises. Prometheus has data visualisation options. Grafana, on the other hand, remains the most widely used data visualisation tool.

Prometheus data is retrieved via queries initiated from the dashboard. It is the most suitable open-source data model for storing time-series data.

The table below shows the differences between Grafana and Prometheus.

Grafana receives OpenTelemetry (OTel) data through the OpenTelemetry Collector. This collector gets telemetry from applications and sends it to Grafana's observability backends. 

The data is transferred to different Grafana components based on the type of telemetry:

• Metrics move to Grafana Mimir or Prometheus.  
• Logs move to Grafana Loki.  
• Traces move to Grafana Tempo.

You can create, explore, and share observability dashboards with your team, so you can spend less time managing your Grafana infrastructure and more time improving the health, performance, and availability of your apps.

You can connect Amazon Managed Grafana to a variety of observability data sources, including AWS data sources such as Amazon Managed Service for Prometheus, Amazon CloudWatch, and Amazon OpenSearch Service; third-party ISVs such as Datadog and Splunk; and self-managed data sources such as InfluxDB.

Amazon Managed Grafana integrates seamlessly with AWS services, letting you securely add, query, visualise, and analyse your AWS data.

The process of using AWS Grafana is demonstrated in the image below:

1. Create Grafana Workspaces: Automatically build, deploy, and manage workspaces.
2. Manage User Access: Use AWS IAM Identity Centre to grant users access to the workspace.
3. Connect to Multiple Data Sources: Add multiple data sources.
4. Set up Dashboards: Visualise and analyse logs and metrics, and track data across data sources, all in one console.
5. Centralise third-party ISV Data: Add more data sources by upgrading to Grafana Enterprise (optional).

Grafana Loki is a log aggregation tool that collects and organises logs from all of your apps and infrastructure. It takes a unique approach by indexing only log-line metadata rather than full text.

The procedure for how Grafana Loki works is explained below:

Here are the reasons why we use Grafana Loki.

• As you can distribute logs in any format, from any source, and through multiple clients, getting started is simple.
• With 100% persistence to object storage, you get petabyte-scale, high-throughput, cost-effective & durable storage.
• You can use your log lines to create metrics and alarms.
• Ingestion logs have no formatting requirements, providing you with more flexibility and the ability to format at query time.
• Follow your logs in real time as they arrive in the system, update them at set intervals, view logs for a given day, and more.
• Prometheus, Grafana, and K8S all have native integrations, allowing you to move seamlessly between metrics, logs, and traces.

Grafana Loki v3 is the latest release of Grafana's open-source log aggregation system. It brings key improvements in OpenTelemetry integration, query performance, and storage architecture.

SQL Expressions in Grafana 12 allow you to query and combine results from multiple data sources. They use a SQL-like syntax. 

We can use SQL expressions to join, filter, aggregate, and transform data from various sources without altering the underlying databases.

Consider a scenario where your company's website sees more visitors. While more than 80% of users can access the website in less than two seconds, some users experience longer-than-typical response times, resulting in a negative user experience.

Compare a rapid-response trace with a slow-response trace to determine which elements contribute to the latency. Given the enormous volume of data in a typical production setting, this will be very time-consuming.

You can use exemplars to help identify faults in your data distribution by filtering query traces with excessive latency within a given time interval.

A line, dot path, or bar group can represent a Grafana time series. Because of its flexibility, it can display virtually any time-series data.

Common time series options available in Grafana are listed below:

In a Time-Series Database (TSDB) such as Prometheus, these metrics are recorded with a timestamp. Although each TSDB has its unique data schema, they all share these two characteristics, and Grafana Cloud can visualise their varied metric formats.

A visualisation is a graph that shows how resource utilisation has changed over time. Using visualisations to compare these time-stamped measurements over time makes it quick and straightforward to spot changes in a computer system, particularly as events occur. 

The Grafana Scenes API is a framework for building interactive, dashboard-like experiences in Grafana plugins using reusable React components and scene objects. It allows you to define panels, layouts, variables, data queries, time ranges, and user interactions programmatically. It helps you avoid building every dashboard feature from scratch.

Let’s see how the Grafana Scenes API changes plugin development:

• Creating dashboard experiences from code using reusable scene components.
• Managing common features such as time ranges, variables, data queries, and navigation with the Scenes framework.
• Using plugins to provide richer, application-like experiences instead of being limited to conventional panels.
• Integrating Scenes with Grafana's React ecosystem.
• Changing layouts and scene objects based on user actions or application state.
• Using complex plugin UIs as reusable scene objects rather than relying on large amounts of custom UI logic.

Grafana Unified Alerting provides a centralised alerting framework. Alert rules can query multiple data sources and use a common evaluation, notification, and routing model.

Let’s see the differences between Grafana Unified Alerting v2 and legacy alerting:

LogQL is the query language Grafana Loki uses to select, filter, parse, and aggregate log data. PromQL is the query language used by Prometheus-compatible metrics systems to query and calculate time-series metrics.

Grafana Mimir is a horizontally scalable, highly available, long-term storage system for Prometheus metrics. It is designed to handle large volumes of metrics from many Prometheus-compatible agents. It also supports PromQL for querying.

Prometheus is primarily a monitoring and metrics collection system.

We can choose Mimir over Prometheus when we need:

• Long-term metric retention beyond Prometheus's typical local storage model
• To work with large-scale or multi-cluster environments generating high metric volumes
• Horizontal scalability for ingestion and querying
• High availability and replicated metric storage
• Multi-tenancy with isolated metric data and access controls
• Centralised metrics storage for many Prometheus instances.

Grafana Alloy is an open-source telemetry collector that is based on the OpenTelemetry Collector. It provides unified pipelines for metrics, logs, traces, and profiles, with native support for Prometheus and Grafana ecosystem backends such as Loki, Mimir, Tempo, and Pyroscope.

Grafana Agent reached End-of-Life on November 1, 2025 and no longer receives vendor support, bug fixes, or security fixes.

Grafana Alloy replaces Grafana Agent in the following ways:

• Supports the major telemetry collection use cases previously handled by Grafana Agent
• Grafana Agent's Flow mode configuration provides the foundation for Alloy, which can simplify migration easily.
• Alloy extends the Agent model by combining Prometheus and OpenTelemetry pipelines in one collector.
• Collect and route metrics, logs, traces, and profiles to one or more compatible backends.

k6 can be used to assess the reliability and performance of your systems, allowing you to detect performance regressions and problems sooner. k6 will help you create applications that are scalable, robust, and fast.

Some of the most common k6 use cases are listed as follows:

• k6 is designed to run high-load tests (spike, stress, and soak tests) while using minimal resources.
• By running low-load tests, you can use k6 to assess your production system's performance and availability frequently.
• k6's architecture is extensible. You can use k6 to generate traffic as part of your chaotic experiments, or you can use it to trigger traffic from your k6 tests.

The LGTM stack is a modern open-source observability stack built on Grafana. It combines tools to collect, store, query, and visualise logs, metrics, traces, and profiling data from applications.

LGTM = Loki + Grafana + Tempo + Mimir

Grafana Assistant is an AI assistant built into Grafana that helps users interact with the platform using natural language. You can ask questions in plain English to handle common monitoring and observability tasks, eliminating the need to navigate dashboards or write complex queries.

Git Sync is a Grafana feature that lets you store dashboards and related settings in a Git repository. It keeps them in sync with your Grafana instance. This feature helps teams manage dashboards using Git workflows. It also supports version control, teamwork, and automation for dashboard management.

We can use PromQL (Prometheus Query Language) to select, aggregate, and analyse time-series metrics stored in Prometheus. We can also use PromQL to track CPU, memory, traffic, errors, latency, and availability.

• CPU Utilisation

To calculate CPU utilisation in different scenarios.

Example:

# Dashboarding CPU utilisation when the query is scoped to a single VM resource

100 * (1-avg ({"system.cpu.utilization", state="idle"}))

# Alerting on high CPU utilisation scoped to a single VM

avg_over_time({"system.cpu.utilization",}[5m]) > 0.8

• Memory Utilisation

To show the available memory and trigger alerts when memory usage is high.

Example:

# Dashboarding available MB, scoped to a single VM

(sum ({"system.memory.limit"}) - sum ({"system.memory.usage, state="used"})) / (1024 * 1024)

# Alerting on high memory utilisation

{"system.memory.utilization", state="used"} > 0.9

• Disk utilisation 

To show the total disk throughput and total disk operations per second.

Example:

# Dashboarding total disk throughput (bytes/sec), scoped to a single VM.

sum by (device, direction) rate({"system.disk.io"} [5m])

# Dashboarding disk total operations per second, scoped to a single VM.

sum by (device, direction) rate({"system.disk.operations"} [5m])

To design an observability platform for 500+ microservices, we should build a centralised, scalable, multi-signal platform covering metrics, logs, traces, and alerts.

The design should include the following:

• Use Prometheus for collection and Grafana Mimir for horizontally scalable, long-term metrics storage.
• Use Grafana Loki with controlled labels, and avoid high-cardinality labels such as request_id or user_id.
• Use Grafana Tempo or any other OpenTelemetry-compatible tracing backend.
• Apply tail sampling to control trace volume and cost.
• Deploy Grafana Alloy or OpenTelemetry Collector as agents or gateways to collect, enrich, filter, and route telemetry.
• Define common labels or attributes such as service.name, service.namespace, environment, cluster, and version.
• Build reusable Grafana dashboards with variables and service-level dashboard templates, rather than maintaining hundreds of separate dashboards. 

Grafana multi-tenancy separates users, teams, dashboards, data sources, and alerting configurations between different organisations or tenants.

To set up multi-tenancy in Grafana, we need to:

• First, choose a tenancy model
• Create separate organisations or tenants
• Configure authentication and teams
• Apply RBAC and permissions
• Isolate data sources, dashboards, and folders
• Configure alerting separately.

Grafana integrates with OpenTelemetry (OTel) as an observability frontend and as part of the telemetry pipeline. OpenTelemetry standardises how applications generate and export metrics, logs, and traces. Grafana and its backends visualise and analyse this telemetry.

We can implement dashboards as code in Grafana as follows:

• Define dashboards as JSON or code using Grafana dashboard schemas or tools such as provisioning, Terraform, or Grafana as Code.
• Store the definitions in Git to review, version, and roll back changes.
• Parameterise dashboards with variables for environments, services, clusters, and data sources.
• Automate deployment through CI/CD to provision or update dashboards across development, staging, and production.
• Validate changes before deployment to detect invalid dashboard definitions or broken references.

High cardinality occurs when a metric has labels with many unique combinations, such as user_id, request_id, or dynamically generated URLs. It can increase memory usage, storage costs, and query latency.

We can handle high-cardinality metrics in the following ways:

• Avoiding the use of user_id, session_id, request_id, or other highly variable values as Prometheus labels unless necessary.
• Using bounded categories such as status_code, method, or region.
• Recording or querying metrics at an appropriate level rather than storing every unique dimension
• Using Prometheus relabel_configs or metric_relabel_configs to prevent storing unwanted metrics or labels.
• Using Prometheus and Grafana cardinality analysis to identify metrics and labels that generate excessive series.

We can deploy Grafana HA by running multiple Grafana instances behind a load balancer and using shared external dependencies.

We can use the following approaches when deploying Grafana:

• Run at least two Grafana servers/pods so one can fail without interrupting access
• Distribute requests across healthy Grafana instances
• Using a highly available external database such as PostgreSQL or MySQL for dashboards, users, alerting configuration, and other Grafana state
• Keep crucial Grafana configuration and secrets consistent across instances
• Configure a suitable session strategy to allow us to switch between instances without authentication problems
• Configure Grafana Alerting correctly to prevent multiple instances from unnecessarily generating duplicate notifications.

We can use Grafana variables to let dashboards change dynamically based on user-selected values. This helps avoid creating separate dashboards for each environment, service, or cluster.

We can implement this approach as follows:

• Create dashboard variables such as $environment, $cluster, $namespace, or $service
• Populate the variables from a data-source query
• Use variables in panel queries, titles, transformations, and dashboard links.
• Enable multi-value or All selections when users need to compare multiple values.
• Use chained variables where one variable depends on another
• Reuse the same dashboard across development, staging, and production by changing variable selections rather than duplicating dashboards.