Scrape-Target nicht erreichbar

Alert: TargetDown

Critical Service-spezifisch

🎯

Was genau down ist, steht im Alarm: Scrape target {job}/{instance}. Schwere variiert stark je nach Target — fritz_exporter ist kosmetisch, paperless-metrics ist Funktionseinschränkung.

❓Was bedeutet das?

Ein in prometheus.yml konfiguriertes Scrape-Target antwortet seit über 2 Min nicht. Mögliche Targets:

node-exporter — siehe auch HostDown (gleiche Root-Cause meist)
cadvisor — Container-Metriken
fritz_exporter — FritzBox-Metriken (oft instabil bei Router-Reboots)
blackbox-exporter — Ping-Checks externer Dienste
prometheus oder alertmanager self-scrape
pushgateway — selten down, eigene cgroup

⚠️Wie schlimm ist es?

Hängt vom Job ab:

node-exporter / prometheus / alertmanager → kritisch, Monitoring blind
fritz_exporter → kosmetisch, FritzBox-Grafana-Panels leer
paperless-* / pushgateway → mittel, dahängende Metriken / Cleanup-Alerts kommen nicht

🔧Was tun?

Welches Target? Im Alarm steht job=... und instance=.... Oder live:

curl -s http://localhost:9090/api/v1/targets | python3 -c "
import sys,json
for t in json.load(sys.stdin)['data']['activeTargets']:
    if t['health'] != 'up':
        print(t['labels']['job'], '→', t['scrapeUrl'], t.get('lastError','no error'))"

Container des Targets neu starten:

docker compose ps <name>
docker compose restart <name>

Test direkt: Prometheus-UI öffnen → https://prometheus.home.mattetat.org/targets → siehst farbige Health-Anzeige + letzte Fehlermeldung.
Wenn ganz blockiert (z.B. nach DNS-Änderung — siehe CLAUDE.md): alle Container restarten:
```
cd /srv/eplamat && docker compose restart
```

🆘Wenn das nicht klappt

Kopier den Alert in Claude (inkl. dem genauen {job}/{instance}). Manche Targets brauchen spezifisches Wissen (z.B. fritz_exporter nach Router-Firmware-Update braucht TLS-Cert-Re-Trust).

Alert-Rule: prometheus/conf/rules/service_alerts.yml · Prometheus-Targets: https://prometheus.home.mattetat.org/targets