Grafana Monitoring-Mixin Jsonnet Dashboard Prompt

You are a senior platform engineer who builds Grafana dashboards as code using monitoring-mixins, grafonnet, and jsonnet-bundler, and renders them to JSON in CI.

I will provide:
- The mixin or dashboards I want (an existing upstream mixin to customize, or a new one)
- The metrics/labels available and the datasource variable convention
- How the JSON is consumed (provisioned files, Grafana API, or Terraform)

Your job:

1. **Project layout**: lay out `jsonnetfile.json`, the `vendor/` from `jb install`, and a `dashboards.jsonnet` entry point; pin grafonnet (`github.com/grafana/grafonnet`) and any upstream mixin versions.
2. **Mixin customization**: show how to import an upstream mixin, override its `_config` (selectors, thresholds, datasource) without forking, and add extra panels via `+::` deep merges rather than editing vendored files.
3. **grafonnet dashboards**: build a dashboard with grafonnet — panels, template variables (`datasource` + `query`), rows, and links — using functions, not hand-written JSON, so it stays DRY.
4. **Datasource variable**: make every panel reference a `$datasource` template variable so the same dashboard works across environments.
5. **Render & validate**: give the `jsonnet -J vendor` render command and a check that the output is valid dashboard JSON before it's provisioned.
6. **Delivery**: output the rendered JSON to the provisioning path (or wrap it for the Terraform/HTTP-API loader), and note idempotency.

Mark DESTRUCTIVE: none — but editing vendored files directly is lost on the next `jb update`; always override via `_config`/mixins.

---

Mixin/dashboard goal: [DESCRIBE]
Metrics/labels + datasource var: [DESCRIBE]
How JSON is consumed: [DESCRIBE]

Why this prompt works

Dashboards-as-code with Jsonnet fails in predictable ways: people edit vendored mixin files (lost on update), hardcode datasource UIDs, or forget -J vendor at render time. This prompt enforces _config overrides instead of forks, a $datasource variable for portability, pinned versions for reproducibility, and a validate-before-provision step.

How to use it

1. Say whether you’re customizing an upstream mixin or writing new so the merge strategy is right.
2. Give the datasource variable convention so panels stay portable.
3. State how JSON is consumed so the render output lands in the right place.
4. Pin versions so CI renders are reproducible.

Useful commands

# Vendor dependencies and render dashboards to JSON
jb install
jsonnet -J vendor -m dist/ dashboards.jsonnet

# Validate each rendered dashboard is well-formed JSON
for f in dist/*.json; do jq -e . "$f" > /dev/null && echo "ok: $f"; done

Example config

jsonnetfile.json (pinned deps):

{
  "version": 1,
  "dependencies": [
    { "source": { "git": { "remote": "https://github.com/grafana/grafonnet.git" } }, "version": "v11.1.0" }
  ]
}

Customizing a mixin without forking:

local kubernetesMixin = import 'kubernetes-mixin/mixin.libsonnet';

kubernetesMixin {
  _config+:: {
    datasource: '$datasource',
    cadvisorSelector: 'job="cadvisor", cluster="$cluster"',
  },
}

Common findings this catches

• Customizations vanish after update → edited vendored files.
• Dashboard broken outside prod → hardcoded datasource UID.
• couldn't open import errors → missing -J vendor.
• Non-reproducible CI → unpinned grafonnet/mixin versions.
• Broken grid → duplicate panel IDs from bad merges.

When to escalate

• Upstream mixin bugs — file/track against the mixin repo.
• Terraform vs file provisioning strategy — the platform lead.
• Jsonnet library standards across teams — the dashboards-as-code owner.