Generate Production-Ready Grafana Dashboards
Designs production Grafana dashboards using RED/USE methods, panel JSON, variables, alerts, and dashboard-as-code provisioning.
Why it matters
Create and manage production-ready Grafana dashboards for comprehensive system observability. This skill helps visualize metrics, monitor infrastructure, and track KPIs.
Outcomes
What it gets done
Design and implement Grafana dashboards for API, infrastructure, and application monitoring.
Generate dashboard configurations using JSON and best practices.
Integrate dashboards with Prometheus and other data sources.
Automate dashboard provisioning using Terraform or Ansible.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-grafana-dashboards | bash Overview
Grafana Dashboards
Guides production Grafana dashboard design using the RED and USE methods, JSON panel structures (stat, time series, table, heatmap), templating variables, inline alerting, and dashboard-as-code provisioning via Terraform and Ansible. Use when building Grafana dashboards for services, infrastructure, databases, or SLOs; use prometheus-configuration or slo-implementation for adjacent metric-collection or SLO-specific work.
What it does
Designs and manages production-ready Grafana dashboards for observability across applications, infrastructure, and business metrics. It applies an information hierarchy (critical big-number metrics on top, key trends as time series in the middle, detailed tables/heatmaps below) plus the RED method for services (Rate, Errors, Duration) and the USE method for resources (Utilization, Saturation, Errors).
When to use - and when NOT to
Use this skill to visualize Prometheus metrics, create custom dashboards, implement SLO dashboards, monitor infrastructure, or track business KPIs. Do not use it for tasks unrelated to Grafana dashboards - related skills exist for metric collection (prometheus-configuration) and SLO dashboards specifically (slo-implementation).
Inputs and outputs
Dashboard JSON structure example (API monitoring): a dashboard with refresh: "30s", a request-rate graph panel using sum(rate(http_requests_total[5m])) by (service), an error-rate panel with a built-in alert condition, and a P95 latency panel using histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)).
Panel types covered: stat panels (single value with threshold-based coloring), time series graphs (e.g. CPU usage via node_cpu_seconds_total), table panels (with field transformations like renaming/excluding columns), and heatmaps (latency distribution via bucketed histograms).
Templating variables let dashboards be parameterized - a namespace query variable sourced from label_values(kube_pod_info, namespace) and a dependent service variable filtered by $namespace, referenced in queries like sum(rate(http_requests_total{namespace="$namespace", service=~"$service"}[5m])).
Alerting is defined inline on panels (evaluator threshold, for duration, frequency, notification channel UID) and dashboards can be provisioned automatically via a dashboards.yml file pointing at a directory of JSON dashboards.
Common dashboard patterns with their key panels: infrastructure (CPU/memory per node, disk I/O, network traffic, pod count, node status), database (QPS, connection pool usage, P50/P95/P99 query latency, replication lag, slow queries), and application (request rate, error rate, response time percentiles, active sessions, cache hit rate, queue length).
Ten best practices: start from Grafana community templates, use consistent panel/variable naming, group related metrics in rows, default to a 6-hour time range, use variables for flexibility, add panel descriptions, configure units correctly, set meaningful threshold colors, keep colors consistent across dashboards, and test across different time ranges.
Dashboard-as-code provisioning is shown for both Terraform (grafana_dashboard resource loading a JSON config file into a grafana_folder) and Ansible (copying dashboard JSON files into /etc/grafana/dashboards/ and notifying a Grafana restart).
Reference files: assets/api-dashboard.json, assets/infrastructure-dashboard.json, assets/database-dashboard.json, and references/dashboard-design.md.
Integrations
Built around Grafana's dashboard JSON model and Prometheus as the metrics datasource, with provisioning support via Terraform's grafana_dashboard/grafana_folder resources and Ansible file-copy tasks.
Who it's for
SRE, platform, and DevOps teams building production Grafana dashboards for services, infrastructure, or databases who want proven panel structures, RED/USE-method organization, and dashboard-as-code provisioning instead of building dashboards ad hoc in the UI.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.