fix(monitoring): restore DMARC dashboard under Grafana 13

Grafana 13 externalised its core data sources; nixpkgs no longer bundles
the Elasticsearch datasource, so every DMARC panel failed with "Plugin not
registered". Load the official Grafana-signed elasticsearch plugin via
declarativePlugins, pin the dmarc-ag/dmarc-fo datasource UIDs (Grafana 11+
resolves datasource template variables by UID, not name), and clear stale
uid-less records left by an earlier deploy.
This commit is contained in:
Berwn
2026-06-26 11:34:08 +07:00
parent 48fcc3058b
commit 4bafc64b84
2 changed files with 82 additions and 3 deletions
+18 -1
View File
@@ -62,7 +62,24 @@ The `cnx.email` DMARC record (`rua`/`ruf`) points at the `dmarc@cnx.email`
mailbox on `mx1`. **parsedmarc** on `control` (`modules/monitoring/parsedmarc.nix`)
polls that mailbox over IMAPS, parses the XML reports, and stores them in a local
**Elasticsearch** (`127.0.0.1:9200`, loopback-only); Grafana renders them via the
auto-provisioned parsedmarc dashboard + Elasticsearch datasource.
parsedmarc dashboard + two Elasticsearch datasources (`dmarc-ag`/`dmarc-fo`).
> Two Grafana-13 gotchas, both handled in `modules/monitoring/parsedmarc.nix`:
>
> 1. **The Elasticsearch data source plugin is no longer bundled.** Grafana 13
> externalised its core data sources and nixpkgs ships no `grafanaPlugins`
> entry for Elasticsearch, so a bare ES datasource fails with "Plugin not
> registered" and every panel errors (and Explore silently falls back to the
> default datasource). We pull the official, Grafana-signed `elasticsearch`
> plugin from the catalog via `services.grafana.declarativePlugins`.
> 2. **Datasource variables now resolve by UID, not name.** The bundled dashboard
> binds its datasource through template variables whose stored value is the
> datasource _name_ (`dmarc-ag`/`dmarc-fo`); Grafana 11+ matches that against
> the datasource **UID**. So we provision the two datasources ourselves with
> their **UID pinned to their name** (and leave the module's own
> `provision.grafana.datasource` off to avoid a duplicate, uid-less pair).
> `deleteDatasources` clears any stale uid-less records left by an earlier
> deploy so the pinned-UID versions can be re-created.
The IMAP fetch rides the **mesh**, not the public net: `control` pins
`mx1.cnx.email` to mx1's mesh address in `/etc/hosts`, so TLS still validates