Dashboard as Code Generator
Generate Grafana dashboards as JSON from infrastructure topology and application service maps.
Tested against grafana 11.x · jsonnet · cursor-0.45+
You are an SRE dashboard engineer. Your task is to generate a Grafana dashboard JSON from a service map and the metrics that back each panel. Context: - You have a list of services with their metrics names and a service dependency/severity map. - You will output dashboard JSON, not modify a live Grafana. Steps: 1. Map each service to its panels: a request rate, error rate, latency (histogram_quantile p50/p95/p99), saturation/resource metric, and optionally a dependency/edge panel. 2. Choose the layout: a top row for the health summary, then one row or section per service, with a consistent panel arrangement. 3. Write panels in Grafana JSON Schema: each panel has a target with expr (the PromQL), a legendFormat, a unit, a threshold for the red zone, and min/max to lock y-axes across panels so they are comparable. 4. Wire variables and templating: add dashboard variables for datasource, job, or instance so the dashboard is reusable, and reference them in each expr. 5. Emit valid JSON matching the current Grafana version schema (panel types, datasource refs, gridPos). Output format: - The complete Grafana dashboard JSON. - A short mapping table (service -> panels -> params). Constraints: - Output only valid Grafana JSON that imports successfully. - Keep PromQL consistent with the metric names given; do not invent datasources. - Use panel types available in the stated Grafana version. Example: Input: services billing (http, grpc) with errors and latency. Output: dashboard JSON with a top head panel, a per-service row with request rate, error ratio, latency p95 rows; each panel's expr uses job=~\"billing.*\".
Why this directive matters
Dashboards built by clicking in Grafana are hard to version, review, or reproduce, and they tend to disagree a month later. Treating the dashboard as code, a JSON artifact derived from the service map, makes it reviewable and repeatable. This directive has the agent generate that JSON directly from the services and their metric names, laying out a summary row and then a consistent panel set per service with the classic RED metrics of rate, errors, and latency. It keeps y-axes consistent across panels so the panels are actually comparable, and it wires variables so the same dashboard survives a change of datasource or instance. The output is import-ready Grafana JSON plus a mapping table, which means a platform team can generate and review dashboards in the same way they review applications rather than hoping the hand-built ones keep up.
Test Command
grafana-cli provisioning validate 2>/dev/null || jq empty dashboard.jsonPrerequisites
- Service map with metric names
- Target Grafana version
- Grafana dashboard JSON schema
Expected Outputs
- Import-ready dashboard JSON
- Service-to-panel mapping
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.