Die Host-Seite ist deployt und verifiziert; der Betreiber hat drei Abweichungen
zu ba59518 gemeldet, alle uebernommen:
1. pterodactyl_exporter zeigt auf 9810 statt 9531. Der alte Exporter (loens2)
hat NIE funktioniert - er rief die Client-API mit einem Application-Key ueber
http auf und lieferte null pterodactyl_*-Metriken. Ersetzt durch einen, der
die Panel-MariaDB read-only liest und keinen API-Key braucht.
2. metric_relabel_configs sind hinzugekommen. Sie lebten bisher im lokalen
Prometheus des Game-Hosts und gehoeren immer dem SCRAPENDEN Prometheus - mit
dessen Rueckbau also hierher. Ohne sie waeren Gameserver nur unter ihrer UUID
sichtbar und je Serie rund 20 container_label_* uebrig geblieben; erwartete
Serienzahl faellt von 3615 auf ~1700.
3. instance = gameserver statt pterodactyl, damit Metrik und Log denselben
Schluessel tragen (promtail setzt host=gameserver). Kostet keine Historie -
die Targets sind am 2026-08-20 zum ersten Mal ueberhaupt up gegangen.
Neu: gameserver-rules.yml nimmt den Join Container-UUID -> Klarname vorweg.
cAdvisor kennt Gameserver nur unter ihrer UUID, und Relabeling kann keine
zweite Metrik nachschlagen.
Mit promtool gegen die hier tatsaechlich laufende Version 3.3.1 geprueft (die
Uebergabe nutzte 3.0.0): Konfiguration gueltig, 2 Regeldateien, 5 Regeln.
⚠️ Die Uebergabe nennt --force-recreate wegen der Inode-Falle (#0083). Fuer
Prometheus gilt das hier NICHT mehr: Das Verzeichnis wird gemountet
(./prometheus:/etc/prometheus), genau um diese Falle zu beseitigen. Ein
restart bzw. SIGHUP genuegt.
Die Targets standen seit dem ersten Scrape auf der oeffentlichen IP und waren
nie up. Ursache jetzt belegt: Die Exporter-Container auf dem Game-Host
veroeffentlichen ihre Ports gar nicht - docker ps zeigt "9100/tcp" ohne
0.0.0.0-Mapping, sie sind nur im Docker-Netz erreichbar. Weder Firewall noch
Bind-Adresse, wie bisher vermutet.
Targets auf 10.0.0.4 umgestellt (Host liegt im vSwitch, 22/80/443 antworten
dort). cadvisor bewusst auf Host-Port 8081: 8080 ist von coolify-proxy belegt.
Neu angebunden: pterodactyl_exporter auf 9531 - laeuft dort seit drei Monaten
und war nie im Monitoring.
README nachgezogen; sie nannte weiterhin die oeffentliche IP und beschrieb die
Targets als "antworten aktuell nicht", ohne den Grund.
⚠️ Wirksam erst, wenn die Ports auf dem Game-Host auf 10.0.0.4 veroeffentlicht
sind. Bis dahin bleiben die Targets down - unveraendert zum Zustand davor, nur
mit richtiger Adresse und dokumentierter Ursache.
Alertmanager was configured as an alerting target but never scraped, so its own
metrics were absent: a silently breaking alert chain could not report itself —
the same blind spot as a missing series, now at the end of the chain. Adds the
operating_alertmanager scrape job and AlertDeliveryFailing on
alertmanager_notifications_failed_total.
The README still claimed alert delivery was deliberately muted via a
room=security null receiver. That route is gone; alertmanager.yml routes
everything to the matrix receiver, so the backup alerts added yesterday do get
delivered. Documentation asserting the opposite is dangerous in both directions,
so it now states the current wiring and keeps the alert-storm history as
background.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- cve-scan: Trivy-Loop ueber die 29 real deployten Images (Cluster-Inventur
2026-08-01 + Prod-Web-Image); 24h-Intervall, Fehler einzelner Images
blockieren nicht
- cve-exporter: Stdlib-Exporter mit first_seen-State (Zeitstrahl), Schema
trivy_vuln_info/_count/_first_seen/_last_scan gemaess Pflichtfeldern
- 3 Alertregeln (CRITICAL sofort, HIGH mit 24h-Daempfung, Scan-Frische) -
promtool SUCCESS 9 rules; alle mit room=security
- matrix-alerts: Label-basiertes Raum-Routing (MATRIX_ROOM_<NAME>), Edits
landen im richtigen Raum via State
- Grafana-Dashboard cve-overview: Severity-Stats, CVE-Tabelle mit
NVD-Link/Fix-Version/first-seen, Zeitstrahl, Verlauf
UNGETESTET bis zum Deploy auf CFGMON (compose up -d).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Regeln decken die real erlebten Fehlerklassen ab: TargetDown (coturn-Klasse),
KubePodRestartLoop (36k-Restarts-Klasse), OOM-Kills, RAM-/Swap-/Disk-Druck.
Zustellung in den wartung-Raum ueber einen minimalen Stdlib-Webhook-Receiver
(gleiche Machart wie maintenance-notify, gitops Issue #24); Bot-Token kommt
beim Deploy per .env (Vorlage in .env.example).
UNGETESTET/DEPLOY-PENDING: promtool/amtool-Lint auf dem Mac an haengendem
Docker-Hub-Pull gescheitert - vor dem Deploy auf CFGMON ausfuehren (Images
liegen dort bereits):
docker run --rm -v $PWD/monitoring/prometheus:/cfg:ro --entrypoint promtool prom/prometheus:v3.3.1 check rules /cfg/alerts.yml
docker run --rm -v $PWD/monitoring/alertmanager:/cfg:ro --entrypoint amtool prom/alertmanager:v0.28.1 check-config /cfg/alertmanager.yml
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Grafana-Provisioning ergaenzt: Datasources (prometheus/loki) mit den
bestehenden UIDs, damit alle Dashboards weiter funktionieren, sowie vier
Dashboard-Provider passend zu den vorhandenen Ordnern.
- 9 Dashboards aus der laufenden Instanz exportiert und bereinigt: id/version
entfernt, hart kodierte und verwaiste Datasource-UIDs auf die
provisionierten UIDs umgeschrieben.
- Images von :latest auf feste Versionen gepinnt (Prometheus v3.3.1,
Loki 3.7.1, Alloy v1.16.0, Grafana 12.0.0, node-exporter v1.9.1).
- Alloy: Docker-Metadaten (container, compose_service, compose_project) als
Loki-Labels via discovery.relabel.
- .env-Variablen auf GRAFANA_ADMIN_USER/GRAFANA_ADMIN_PASSWORD vereinheitlicht,
.env.example ergaenzt, .env bleibt ungetrackt.
- prometheus.yml kommentiert (Remote-Write-Quellen, Fremd-Stack-Targets),
toten auskommentierten Matrix-Job entfernt.
- README mit Deployment, Struktur, externen Abhaengigkeiten und offenen
Sicherheitspunkten (offene Ports 9090/3100/9100).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Import des bisherigen Stands aus /opt/monitoring auf dem Operating-Host,
unveraendert. Images auf :latest, Grafana ohne Provisioning (Datasources und
Dashboards nur in der grafana.db), keine Dokumentation.
Dient als Ausgangspunkt fuer den Umbau auf einen vollstaendig
provisionierbaren Stack.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Thore Cimbal
sorbandClaude Opus 4.8
sorbandClaude Opus 5