← Back to Interview Prep
📈

Grafana Interview Q&A

50 Grafana scenario-based interview questions covering dashboards, PromQL, LogQL, alerting, Loki, Tempo, Mimir, and production administration.

10 Fundamentals10 PromQL & Querying10 Dashboards & Panels10 Alerting & Notifications10 Administration
1

Grafana Fundamentals

Q1.What is Grafana and what problem does it solve?

  • ▸Grafana is an open-source analytics and interactive visualization platform that allows you to query, visualize, alert on, and understand your metrics, logs, and traces — no matter where they are stored.
  • ▸It solves the problem of fragmented observability by providing a single unified UI to visualize data from multiple data sources (Prometheus, InfluxDB, Elasticsearch, MySQL, CloudWatch, etc.) side by side.
  • ▸Key strengths: Beautiful dashboards, powerful query editors, flexible alerting, extensive plugin ecosystem, and multi-data-source correlation.

Q2.What are the key components of the Grafana ecosystem (LGTM stack)?

  • ▸Grafana: The visualization and dashboarding frontend — the core product.
  • ▸Loki: A log aggregation system designed to work seamlessly with Grafana. Inspired by Prometheus but for logs. Uses labels for indexing, not full-text indexing.
  • ▸Tempo: A distributed tracing backend that integrates with Grafana for trace visualization. Stores traces cost-effectively by only indexing trace IDs.
  • ▸Mimir: A horizontally scalable, long-term metrics storage for Prometheus, providing high availability and multi-tenancy.
  • ▸Together they form the LGTM (Loki, Grafana, Tempo, Mimir) observability stack.

Q3.What is a Data Source in Grafana?

  • ▸A Data Source is a connection to a backend system that stores your data — Prometheus, InfluxDB, Elasticsearch, MySQL, PostgreSQL, CloudWatch, Loki, Tempo, and many more.
  • ▸Configuration: Administration → Data Sources → Add data source → Enter the URL, authentication, and connection details.
  • ▸Grafana supports 150+ data sources via built-in integrations and community plugins. Each panel in a dashboard can query a different data source.

Q4.What is the difference between Grafana OSS, Grafana Enterprise, and Grafana Cloud?

  • ▸Grafana OSS: The free, open-source version with core dashboarding, alerting, and data source support. Self-hosted.
  • ▸Grafana Enterprise: Adds enterprise features — RBAC, SAML/LDAP auth, enhanced data sources (Oracle, SAP HANA, Splunk), reporting (PDF), audit logging, and premium support. Self-hosted.
  • ▸Grafana Cloud: A fully managed SaaS offering that includes Grafana, Mimir (metrics), Loki (logs), Tempo (traces), and synthetic monitoring. No infrastructure to manage.

Q5.Explain the Grafana dashboard hierarchy: Organizations, Folders, and Dashboards.

  • ▸Organization: The top-level tenant. Each org has its own data sources, dashboards, users, and settings. Users can belong to multiple orgs.
  • ▸Folders: Group related dashboards together within an organization. Permissions can be set at the folder level — e.g., "Team A can edit dashboards in the Production folder."
  • ▸Dashboards: Collections of panels (charts, tables, stats) arranged in a grid layout. Each dashboard can query multiple data sources.

Q6.What are Panels in Grafana and what types are available?

  • ▸A Panel is the fundamental visualization building block in a Grafana dashboard. Each panel has a query, a visualization type, and optional transformations.
  • ▸Built-in panel types: Time Series (line/area charts), Bar Chart, Stat (single value), Gauge, Table, Heatmap, Histogram, Pie Chart, Geomap, Logs, Traces, Node Graph, Canvas, and more.
  • ▸Each panel can have its own data source, query, thresholds, and overrides — allowing mixed data source dashboards.

Q7.What are Dashboard Variables (Template Variables) in Grafana?

  • ▸Variables are dynamic placeholders that appear as dropdown selectors at the top of a dashboard, allowing users to filter data without editing queries.
  • ▸Types: Query (populated from a data source query, e.g., list of servers), Custom (hardcoded comma-separated values), Constant, Data source (switch between data sources), Interval (time intervals like 1m, 5m, 1h).
  • ▸Usage in queries: Reference variables with `$variable_name` or `${variable_name}` syntax. Example PromQL: `cpu_usage{instance="$instance"}`
  • ▸Variables can be chained — selecting a value in one variable can filter the options in another (cascading variables).

Q8.How does Grafana handle authentication and authorization?

  • ▸Authentication methods: Built-in (username/password), LDAP, OAuth 2.0 (Google, GitHub, Azure AD, Okta), SAML (Enterprise), and anonymous access.
  • ▸Authorization (Roles): Viewer (can only view dashboards), Editor (can create/edit dashboards), Admin (full control including data sources and users).
  • ▸Grafana Enterprise adds fine-grained RBAC — custom roles with specific permissions (e.g., "can edit dashboards in folder X but not data sources").
  • ▸Permissions can be set at the organization, folder, and dashboard levels.

Q9.What is Grafana Provisioning and why is it important?

  • ▸Provisioning allows you to configure Grafana (data sources, dashboards, alerting, plugins) using YAML configuration files rather than the UI.
  • ▸Files are placed in the provisioning directory (e.g., /etc/grafana/provisioning/datasources/, /etc/grafana/provisioning/dashboards/).
  • ▸Importance: Enables GitOps/Infrastructure as Code — dashboard and data source configurations can be version-controlled, peer-reviewed, and automatically deployed across environments.
  • ▸Dashboards can also be provisioned as JSON model files, making them reproducible and consistent.

Q10.What is the Grafana Plugin system?

  • ▸Grafana has a rich plugin ecosystem with three plugin types: Panel plugins (new visualization types), Data Source plugins (connect to new backends), and App plugins (bundled experiences with pages, data sources, and panels).
  • ▸Installation: Via CLI (`grafana-cli plugins install <plugin-id>`), or in Grafana Cloud via the UI.
  • ▸Marketplace: grafana.com/grafana/plugins has 200+ community and official plugins.
  • ▸You can also develop custom plugins using the Grafana Plugin SDK (React + TypeScript).
2

PromQL, LogQL & Querying

Q11.What is PromQL and how is it used in Grafana?

  • ▸PromQL (Prometheus Query Language) is the query language used to select and aggregate time series data stored in Prometheus.
  • ▸In Grafana, you use PromQL in the query editor when your data source is Prometheus. It powers metric dashboards, alerting rules, and recording rules.
  • ▸Basic syntax: `metric_name{label="value"}` — selects time series by metric name and label filters.

Q12.Explain the difference between Instant Vectors and Range Vectors in PromQL.

  • ▸Instant Vector: Returns a single sample per time series at a given point in time. Example: `http_requests_total{method="GET"}` — returns the current value for each matching series.
  • ▸Range Vector: Returns a range of samples over a time window for each time series. Example: `http_requests_total{method="GET"}[5m]` — returns all samples from the last 5 minutes.
  • ▸Range vectors are typically used as input to functions like `rate()` and `increase()`, not displayed directly.

Q13.What is the difference between rate() and irate() in PromQL?

  • ▸rate(): Calculates the per-second average rate of increase over a time range. It uses the first and last data points in the range. Ideal for alerting and slow-moving counters. Example: `rate(http_requests_total[5m])`
  • ▸irate(): Calculates the instant rate using only the last two data points in the range. More responsive to spikes but also noisier. Better for volatile, fast-moving counters in ad-hoc dashboards.
  • ▸Best practice: Use `rate()` for alerting (smooths out spikes) and `irate()` for dashboards where you want to see real-time spikes.

Q14.How do you calculate the error rate of an HTTP service using PromQL?

  • ▸Error rate (percentage): `sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100`
  • ▸This divides the rate of 5xx responses by the total request rate.
  • ▸For per-endpoint breakdown, add `by (handler)`: `sum by (handler) (rate(http_requests_total{status=~"5.."}[5m])) / sum by (handler) (rate(http_requests_total[5m])) * 100`
  • ▸Use this in SLO dashboards and alerting rules.

Q15.What are Recording Rules in Prometheus and how do they help Grafana?

  • ▸Recording Rules precompute frequently used or computationally expensive PromQL expressions and store the result as a new time series.
  • ▸Example: `record: job:http_requests:rate5m` with `expr: sum by (job) (rate(http_requests_total[5m]))` — precomputes the 5m request rate per job.
  • ▸Benefits for Grafana: Dashboards load faster because they query the precomputed metric instead of running complex PromQL on the fly. Essential for large-scale deployments.

Q16.How do you use the histogram_quantile() function?

  • ▸`histogram_quantile()` calculates quantiles (like p50, p95, p99) from histogram metrics.
  • ▸Syntax: `histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))` — calculates the 95th percentile request duration.
  • ▸The `le` (less than or equal) label is required — it defines the histogram bucket boundaries.
  • ▸Common pitfall: Always use `rate()` on the `_bucket` metric inside `histogram_quantile()` to get accurate per-second rates, not cumulative counts.

Q17.What are PromQL aggregation operators and when do you use them?

  • ▸sum: Total across series. `sum(rate(http_requests_total[5m]))` — total request rate.
  • ▸avg: Average across series. `avg by (instance) (cpu_usage)` — average CPU per instance.
  • ▸max / min: Highest/lowest value. `max(memory_usage_bytes)` — peak memory usage.
  • ▸count: Number of series matching. `count(up == 1)` — number of healthy targets.
  • ▸topk / bottomk: Top/bottom N series. `topk(5, rate(http_requests_total[5m]))` — top 5 busiest endpoints.
  • ▸Use `by (label)` to group results and `without (label)` to exclude labels from grouping.

Q18.How do you query logs in Grafana using LogQL (Loki)?

  • ▸LogQL is Loki's query language, inspired by PromQL. It has two types of queries:
  • ▸Log queries (return log lines): `{job="nginx"} |= "error" | json | status >= 500` — finds nginx logs containing "error" with status ≥ 500.
  • ▸Metric queries (return numbers from logs): `rate({job="nginx"} |= "error" [5m])` — calculates the rate of error log lines per second over 5 minutes.
  • ▸Pipeline stages: `|=` (contains), `!=` (doesn't contain), `|~` (regex match), `| json` (parse JSON), `| line_format` (format output).

Q19.How do you correlate metrics, logs, and traces in Grafana?

  • ▸Grafana enables correlation through data links and the Explore view:
  • ▸Metrics → Logs: Add an "Exemplar" data link on a Prometheus metric to jump to the corresponding Loki log lines filtered by the same labels.
  • ▸Logs → Traces: If log lines contain a trace ID, Grafana can auto-detect it and create a link to view the full trace in Tempo.
  • ▸Traces → Logs/Metrics: From a Tempo trace, jump to related logs in Loki or metrics in Prometheus filtered by the same service/span.
  • ▸This metrics ↔ logs ↔ traces correlation is a key advantage of the Grafana LGTM stack.

Q20.What is the Grafana Explore view and how does it differ from Dashboards?

  • ▸Explore is an ad-hoc query and investigation interface — designed for troubleshooting, not for permanent display.
  • ▸Key differences: Explore supports split view (compare two queries/data sources side by side), has no panel layout, and is optimized for rapid iteration with query history.
  • ▸Use Explore for: Investigating incidents (querying logs, tracing requests), testing new PromQL/LogQL queries before adding them to dashboards, and correlating metrics with logs and traces.
  • ▸Once you've built a useful query in Explore, you can add it directly to a dashboard panel.
3

Dashboards, Panels & Visualization

Q21.How do you design an effective Grafana dashboard?

  • ▸Follow the USE method (Utilization, Saturation, Errors) or RED method (Rate, Errors, Duration) as a framework for what to monitor.
  • ▸Layout: Put the most critical information (golden signals) at the top. Use stat panels for key metrics, time series for trends, and tables for detailed data.
  • ▸Use variables for filtering (environment, service, instance) to make dashboards reusable.
  • ▸Keep dashboards focused: One dashboard per service or team. Avoid "wall of charts" syndrome — every panel should answer a specific question.
  • ▸Use consistent color coding: Green = healthy, Yellow = warning, Red = critical across all dashboards.

Q22.What are Dashboard Annotations in Grafana?

  • ▸Annotations are event markers displayed as vertical lines on time series panels — showing when specific events occurred (deployments, incidents, config changes).
  • ▸Sources: Manual annotations (added via the UI), query-based annotations (from a data source, e.g., deployment events from Prometheus or Elasticsearch), and API-based annotations.
  • ▸Use case: Overlay deployment markers on your latency chart to visually correlate "latency spiked right after deploy v2.3.1."

Q23.How do you share and export Grafana dashboards?

  • ▸JSON Export/Import: Every dashboard can be exported as a JSON model file and imported into another Grafana instance.
  • ▸Dashboard Links: Generate a direct URL to a dashboard with specific time ranges and variable values.
  • ▸Snapshots: Create a static snapshot of a dashboard at a point in time — can be shared publicly without requiring Grafana access.
  • ▸Grafana Enterprise: Export dashboards as scheduled PDF reports via email.
  • ▸grafana.com: Publish community dashboards to the public dashboards repository.

Q24.What are Transformations in Grafana and how do you use them?

  • ▸Transformations process query results before they are passed to the visualization — allowing you to reshape, combine, and calculate data without changing the query.
  • ▸Key transformations: Merge (combine results from multiple queries), Filter by name/value, Reduce (aggregate series to a single value), Group by, Sort by, Join by field, and Calculate field (add computed columns).
  • ▸Use case: You have CPU metrics from two different data sources — use the "Merge" transformation to display them in a single table, then "Sort by" to find the top consumers.

Q25.What are Overrides in Grafana panels?

  • ▸Overrides let you customize the visualization settings for specific fields/series without affecting others in the same panel.
  • ▸Example: In a time series panel with multiple metrics, you can override one series to display as a bar, use a different Y-axis, change its color, or set different thresholds.
  • ▸Override matching: By field name, by regex, by type, or by query. Example: "Fields with name matching /error/" → set color to red.
  • ▸Overrides are essential for complex multi-metric panels where each series needs different visual treatment.

Q26.How do you set up Thresholds and Value Mappings in Grafana?

  • ▸Thresholds: Define color-coded ranges for your data. Example: Green (0-80%), Yellow (80-90%), Red (90-100%) for CPU usage. Applied via Panel Options → Thresholds.
  • ▸Value Mappings: Map specific values or ranges to custom text and colors. Example: Map value `1` to "Healthy 🟢" and value `0` to "Down 🔴" for an up/down metric.
  • ▸Both are especially useful for Stat panels, Gauges, and Table panels to make data immediately interpretable without reading numbers.

Q27.What is a Mixed Data Source in Grafana?

  • ▸The "Mixed" data source allows you to query multiple different data sources within a single panel.
  • ▸Each query in the panel can target a different data source — for example, Query A from Prometheus (metrics), Query B from MySQL (business data), Query C from CloudWatch (AWS metrics).
  • ▸Use case: Compare application latency (Prometheus) with business KPIs (MySQL) and infrastructure metrics (CloudWatch) in a single chart.
  • ▸Combined with transformations (Merge, Join), this enables powerful cross-system correlation dashboards.

Q28.How do you make Grafana dashboards responsive for different screen sizes?

  • ▸Grafana dashboards use a responsive grid system — panels automatically resize based on browser width.
  • ▸Use the Row feature to group related panels and make sections collapsible.
  • ▸Best practices: Set panel minimum widths, use Stat/Gauge panels for mobile-friendly KPIs at the top, and avoid very wide tables that don't work on narrow screens.
  • ▸For TV/wall displays (NOC screens): Use Grafana's Kiosk mode (`?kiosk` URL parameter) and Playlist feature to rotate between dashboards automatically.

Q29.What is Grafana as Code (Dashboard as Code)?

  • ▸The practice of defining Grafana dashboards, data sources, and alert rules as code — stored in version control and deployed via CI/CD.
  • ▸Tools: Grafonnet (Jsonnet library for generating dashboard JSON), Terraform Grafana Provider (manage Grafana resources via Terraform), Grafana Provisioning (YAML-based configuration).
  • ▸Benefits: Peer-reviewed dashboard changes, consistent dashboards across environments, rollback capability, and automated deployment.
  • ▸Modern approach: Use the Grafana Kubernetes Operator to manage dashboards as Kubernetes custom resources (CRDs).

Q30.How do you optimize Grafana dashboard performance?

  • ▸Reduce time range: Default to shorter time ranges (last 1h instead of last 7d) to reduce query load.
  • ▸Use recording rules in Prometheus to precompute expensive queries.
  • ▸Limit the number of panels per dashboard — each panel fires a separate query.
  • ▸Use `$__interval` variable for dynamic step sizing — prevents over-fetching data points.
  • ▸Enable query caching (Grafana Enterprise or frontend caching with a reverse proxy).
  • ▸For high-cardinality metrics, use `topk()` or `limit` to restrict the number of returned series.
4

Alerting & Notification Policies

Q31.How does Grafana Alerting work?

  • ▸Grafana Alerting evaluates alert rules at regular intervals, checking if query results breach defined thresholds.
  • ▸Architecture: Alert Rules (define conditions) → Evaluation → Notification Policies (routing) → Contact Points (delivery channels like email, Slack, PagerDuty).
  • ▸Alert states: Normal (OK), Pending (condition met but waiting for duration), Firing (condition met and duration exceeded), No Data, Error.
  • ▸Grafana 9+ uses a unified alerting system that works across all data sources (not just Prometheus).

Q32.What is the difference between Grafana-managed and Data source-managed alert rules?

  • ▸Grafana-managed rules: Evaluated by the Grafana server itself. Can alert on any data source Grafana supports. Rules are stored in Grafana's database.
  • ▸Data source-managed rules (Mimir/Cortex/Loki rules): Alert rules are pushed to and evaluated by the backend data source (e.g., Mimir Ruler). Rules are stored in the data source, not Grafana.
  • ▸When to use which: Use Grafana-managed for multi-data-source alerts or simpler setups. Use data source-managed for high-availability alerting at scale (rules survive Grafana restarts/failures).

Q33.What are Contact Points in Grafana Alerting?

  • ▸Contact Points define where alert notifications are delivered — the integration with external systems.
  • ▸Built-in integrations: Email, Slack, PagerDuty, OpsGenie, Microsoft Teams, Webhook, Telegram, Discord, and many more.
  • ▸Each Contact Point can have multiple integrations — for example, a single Contact Point "Production-Critical" can send to both PagerDuty AND Slack simultaneously.
  • ▸Message templates: Customize notification content using Go templating — include metric values, labels, dashboard links, and runbook URLs.

Q34.What are Notification Policies in Grafana?

  • ▸Notification Policies define the routing tree — which alerts go to which Contact Points based on alert labels.
  • ▸Structure: A default policy (catches everything) with child policies that match specific labels. Example: labels `severity=critical` → PagerDuty, labels `team=backend` → Slack #backend-alerts.
  • ▸Features: Grouping (batch related alerts into a single notification), Group wait/interval (control notification frequency), and Repeat interval (how often to re-send ongoing alerts).
  • ▸Muting/Silences: Temporarily suppress notifications for specific alerts (e.g., during maintenance) without disabling the alert rule.

Q35.How do you write an effective alert rule in Grafana?

  • ▸Choose the right metric: Alert on symptoms (error rate, latency) not causes (CPU usage) — unless you have specific infrastructure SLAs.
  • ▸Set a meaningful threshold: Based on SLOs or historical baselines, not arbitrary values. Example: "Error rate > 1% for 5 minutes" based on a 99% availability SLO.
  • ▸Use a "for" duration (Pending period): Prevents flapping alerts. "Fire only if condition is true for 5 minutes" avoids alerting on brief spikes.
  • ▸Add labels and annotations: Labels for routing (team, severity), annotations for context (dashboard link, runbook URL, summary of what the alert means).

Q36.What are Silences in Grafana Alerting?

  • ▸Silences temporarily mute notifications for alerts matching specific label matchers — without disabling the alert rule itself.
  • ▸Use cases: Planned maintenance (silence all alerts for `environment=staging` for 2 hours), known issues (silence a specific alert while the fix is being deployed).
  • ▸Silences match on labels: You can silence by exact match (`severity=warning`), regex match, or combination of multiple labels.
  • ▸Important: The alert rule continues to evaluate and fire — only the notifications are suppressed. The alert state is still visible in the UI.

Q37.How do you test alert rules before deploying them?

  • ▸Use Grafana's built-in "Preview" button in the alert rule editor — it runs the query and shows what the result would be right now.
  • ▸Set the alert to "Paused" state initially — it evaluates but doesn't fire notifications. Monitor it for a day to check for false positives.
  • ▸Create a test Contact Point (e.g., a personal Slack channel or webhook endpoint like webhook.site) to verify notification delivery without alerting the team.
  • ▸Review historical data in Explore: Run the alert query over the past week and check if it would have fired at expected times.

Q38.What is High Availability (HA) for Grafana Alerting?

  • ▸In HA mode, multiple Grafana instances evaluate the same alert rules simultaneously — but only one instance sends the notification to avoid duplicate alerts.
  • ▸This is achieved through a peer-to-peer gossip protocol (using HashiCorp Memberlist) that coordinates between Grafana instances.
  • ▸Configuration: Set `[unified_alerting]` section in grafana.ini with `ha_peers` listing all Grafana instances.
  • ▸Benefit: If one Grafana instance goes down, another picks up alert evaluation seamlessly — no missed alerts.

Q39.How do you handle alert fatigue in Grafana?

  • ▸Use Notification Policies with grouping: Group related alerts (e.g., by service) into a single notification instead of one per alert.
  • ▸Set appropriate severity levels: Not everything is critical. Use labels like `severity=info|warning|critical` and route only critical alerts to pagers.
  • ▸Increase "for" duration: Require conditions to persist for 5-10 minutes before firing — eliminates transient spikes.
  • ▸Regular alert review: Periodically review firing frequency — alerts that fire too often are either too sensitive or indicate an unresolved systemic issue.
  • ▸Use mute timings: Define recurring time windows (e.g., weekends, non-business hours) where certain non-critical alerts are muted.

Q40.How do you set up alert notifications to Slack in Grafana?

  • ▸1. Create a Slack Incoming Webhook URL in your Slack workspace (Apps → Incoming Webhooks → Add to Slack → Choose channel).
  • ▸2. In Grafana: Alerting → Contact Points → Add Contact Point → Select "Slack" → Paste the Webhook URL.
  • ▸3. Configure message settings: Channel, title, text body (supports Go templates to include metric values, labels, and dashboard links).
  • ▸4. Set up a Notification Policy to route specific alerts to this Contact Point based on labels.
  • ▸5. Test: Click "Test" in the Contact Point editor to send a test notification to Slack.
5

Administration & Best Practices

Q41.How do you upgrade Grafana safely?

  • ▸1. Read the release notes and "What's New" page for breaking changes and deprecations.
  • ▸2. Backup: Database (SQLite/MySQL/PostgreSQL), configuration files (grafana.ini, provisioning/), and plugin directory.
  • ▸3. Test the upgrade in a staging environment first — especially if you have custom plugins or provisioned dashboards.
  • ▸4. Perform the upgrade: Package manager (`apt-get upgrade grafana` / `yum update grafana`), Docker (update image tag), or Helm chart (update values).
  • ▸5. Verify: Check Grafana startup logs, confirm all dashboards load, verify alerting is functional, and test data source connections.

Q42.What database backends does Grafana support and when should you use each?

  • ▸SQLite (default): Embedded database, zero configuration. Good for single-instance deployments and small teams. Not suitable for HA setups.
  • ▸MySQL: Production-ready relational database. Supports HA Grafana setups with multiple instances sharing the same database.
  • ▸PostgreSQL: Production-ready, supports HA. Generally preferred for larger deployments and better concurrent read performance.
  • ▸Best practice: Use SQLite for development/evaluation. Use PostgreSQL or MySQL for production, especially when running multiple Grafana instances behind a load balancer.

Q43.How do you configure Grafana behind a reverse proxy (Nginx)?

  • ▸Set `root_url` in grafana.ini to the public-facing URL: `root_url = https://grafana.example.com/`
  • ▸Nginx configuration: proxy_pass to Grafana's HTTP port (default 3000), set proper headers (`Host`, `X-Real-IP`, `X-Forwarded-For`, `X-Forwarded-Proto`).
  • ▸For WebSocket support (live features, alerting): Add `proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";` for the `/api/live/` path.
  • ▸If Grafana runs on a subpath (e.g., /grafana/), set `serve_from_sub_path = true` and `root_url = https://example.com/grafana/`.

Q44.How do you back up and restore Grafana?

  • ▸What to backup: (1) Grafana database (contains dashboards, users, alert rules, annotations). (2) Configuration files (grafana.ini, provisioning directory). (3) Plugins directory.
  • ▸SQLite: Simply copy the `grafana.db` file. MySQL/PostgreSQL: Use standard database dump tools (mysqldump, pg_dump).
  • ▸Dashboard backup alternative: Export all dashboards as JSON via the API: `GET /api/dashboards/uid/{uid}` — useful for GitOps workflows.
  • ▸Restore: Import the database dump, copy config files, reinstall plugins, and restart Grafana.

Q45.What is Grafana's Service Account and when should you use it?

  • ▸Service Accounts are non-human accounts for API access — replacing the older API key system.
  • ▸Each Service Account can have multiple tokens, assigned roles (Viewer/Editor/Admin), and can be disabled/deleted independently.
  • ▸Use cases: CI/CD pipelines that deploy dashboards via API, external applications that query Grafana for data, and automated scripts that manage alert rules.
  • ▸Best practice: Create dedicated service accounts per application/use-case with the minimum required role (principle of least privilege).

Q46.How do you monitor Grafana itself?

  • ▸Grafana exposes Prometheus metrics at the `/metrics` endpoint — covering request latency, active users, alert rule evaluation times, data source errors, and more.
  • ▸Key metrics to watch: `grafana_http_request_duration_seconds` (API performance), `grafana_alerting_rule_evaluation_duration_seconds` (alert rule performance), `grafana_datasource_request_total` (data source health).
  • ▸Use a dedicated "Grafana Health" dashboard that queries Grafana's own metrics endpoint — yes, Grafana monitoring itself!
  • ▸Also monitor: Database performance (if using MySQL/PostgreSQL), disk space, memory usage, and plugin errors in logs.

Q47.How do you implement LDAP authentication in Grafana?

  • ▸Enable LDAP in grafana.ini: `[auth.ldap]` → `enabled = true` → `config_file = /etc/grafana/ldap.toml`
  • ▸Configure ldap.toml: Set server host, port, bind DN/password, search base DN, and user search filter.
  • ▸Map LDAP groups to Grafana roles: `[[servers.group_mappings]]` → map LDAP group DNs to Grafana roles (Viewer, Editor, Admin) and organizations.
  • ▸Test: Restart Grafana and try logging in with LDAP credentials. Check Grafana logs for LDAP connection errors if login fails.

Q48.What is Grafana OnCall and how does it integrate with alerting?

  • ▸Grafana OnCall is an incident response and on-call management tool that integrates natively with Grafana Alerting.
  • ▸Features: On-call schedules, escalation policies, alert grouping, mobile push notifications, phone calls, SMS, and ChatOps integration (Slack, Teams).
  • ▸Integration: Configure a Grafana OnCall Contact Point in Grafana Alerting — alerts are routed to the on-call engineer based on the schedule.
  • ▸It replaces the need for external tools like PagerDuty or OpsGenie for teams already in the Grafana ecosystem.

Q49.How do you troubleshoot "No Data" issues in Grafana panels?

  • ▸1. Check the data source connection: Go to Data Sources → Test. If it fails, verify URL, credentials, and network connectivity.
  • ▸2. Test the query in Explore: Run the panel's query in Explore view to see if data is returned. Check for typos in metric names or label filters.
  • ▸3. Check time range: Ensure the dashboard time range overlaps with when the data exists. Use absolute time ranges for debugging.
  • ▸4. Check data source-specific issues: For Prometheus — is the target up? (`up{job="your-job"}`). For Loki — is the label selector correct?
  • ▸5. Check Grafana server logs for query errors or data source timeout messages.

Q50.What are the best practices for Grafana in production?

  • ▸Use a production-grade database (PostgreSQL/MySQL) — not SQLite.
  • ▸Run multiple Grafana instances behind a load balancer for high availability.
  • ▸Enable HTTPS: Configure TLS or terminate SSL at the reverse proxy.
  • ▸Use provisioning/GitOps for dashboards and data sources — avoid manual UI changes in production.
  • ▸Set up proper RBAC: Viewers for stakeholders, Editors for teams, Admins restricted to platform team.
  • ▸Monitor Grafana itself using its /metrics endpoint.
  • ▸Keep Grafana updated — security patches and bug fixes are released regularly.

🔥 Abu's Real-World Incident Case Study: Debugging a High Latency Outage in Grafana

When asked in an interview: “Can you walk me through how you troubleshoot a sudden latency spike using Grafana?” use this exact 4-step Observability correlation framework:

1. Metrics Phase (Prometheus / Stat Panels)

Check the RED metrics (Rate, Errors, Duration) panel. Identify that the p99 latency spiked from 120ms to 4.5s on the checkout service using: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)).

2. Tracing Phase (Grafana Tempo / Jaeger)

Click an Exemplar trace dot on the Grafana Time Series chart to instantly jump into Grafana Tempo. The trace waterfall reveals that 90% of duration was spent blocked on a database query call in the payment gateway span.

3. Logs Phase (Grafana Loki)

Use LogQL to filter logs matching the Trace ID: {app="payment-service"} |= "trace_id=xyz123" | json. The logs indicate DB connection pool exhaustion: ConnectionPoolTimeoutException: Timeout waiting for connection from pool.

4. Resolution & Prevention (Alerting & Dashboards)

Increase the connection pool limit, deploy a hotfix, add a new Grafana Stat Panel for connection pool usage, and configure a Grafana Alert rule firing when active connections exceed 85% capacity.

Abu Thahir - Author

Written by Abu Thahir

Founder & Career Mentor

IT career advisor, technical interview coach, and observability specialist with years of hands-on experience in the tech industry.

📅 Last updated: Learn more →

📈 Pro Tip for Grafana Interviews

Be prepared to demo — interviewers love candidates who can walk through building a dashboard from scratch, write PromQL queries on the spot, and explain their alerting strategy with real-world examples.

← Back to All Interview Guides