game: GAME-01 eingegrenzt -- Firewall bestaetigt, Alerting bis 2026-08-04 silenced

Neue Befunde von CFGMON aus:
- Host lebt: Port 80/443 offen, antworten sofort -> Ursache 3 (Host weg) raus
- 8080/9100/22 laufen ins Timeout statt connection refused -> Signatur eines
  Paketfilters, nicht eines toten Exporters -> Ursache 1 wahrscheinlich
- 10.0.0.0/24 abgeklopft: nur k3s (.2) und CFGMON (.3) -- der Host ist nicht
  im vSwitch, damit ist die Zeile "Privat: unbekannt" beantwortet
- beide Targets waren im gesamten 45-Tage-Retentionfenster nie up

Seit dem Alerting-Rollout (gitops#32) erzeugen die Targets alle 4h echte
Alarme im Matrix-Raum. Zwei Alertmanager-Silences bis 2026-08-04 01:30 UTC
gesetzt, IDs im Eintrag vermerkt -- laufen bewusst ab, damit der Punkt nicht
still liegen bleibt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

hosts/game.md

@@ -7,8 +7,8 @@ Pterodactyl- / Gameserver-Host.
 | **IPv4** | `157.90.155.206` |
 | **IPv6** | kein AAAA-Record |
 | **DNS** | `game.axion1337.de` |
-| **Privat** | unbekannt — siehe GAME-01 |
-| **Stand** | 2026-07-30 |
+| **Privat** | **nicht** im vSwitch `10.0.0.0/24` (geprüft 2026-08-01) |
+| **Stand** | 2026-08-01 |
 
 > **Nicht inventarisiert.** Alle Angaben hier stammen aus Beobachtungen von CFGMON
 > aus. Auf dem Host selbst wurde nichts geprüft. Beim ersten direkten Zugriff
@@ -38,8 +38,29 @@ sondern die Erreichbarkeit. Mögliche Ursachen, von wahrscheinlich nach unwahrsc
 3. Der Host ist abgeschaltet oder umgezogen und die IP ist veraltet. Dagegen spricht,
    dass `game.axion1337.de` weiter auf sie zeigt.
 
-**Nächster Schritt:** auf dem Host prüfen, ob die beiden Exporter laufen und worauf
-sie binden, dann die Firewall entsprechend öffnen.
+### Nachtrag 2026-08-01 — Ursache eingegrenzt
+
+Erneut von CFGMON aus geprüft. Die Befunde streichen die Liste oben zusammen:
+
+| Prüfung | Ergebnis |
+|---|---|
+| Port 80 / 443 | **offen, antworten sofort** |
+| Port 22 / 8080 / 9100 | keine Antwort, Timeout |
+| ICMP | 100 % Verlust |
+| `10.0.0.0/24`, Ports 9100+8080 | nur `10.0.0.2` (k3s) und `10.0.0.3` (CFGMON) — dieser Host ist **nicht** im vSwitch |
+| `up == 1` in den letzten 45 Tagen | **nie** — beide Targets waren im gesamten Retention-Fenster nie erreichbar |
+
+Damit ist **Ursache 3 ausgeschlossen**: der Host lebt und bedient 80/443. Und
+**Ursache 1 ist die wahrscheinliche**: die Ports laufen ins *Timeout* statt
+`connection refused` zu liefern. Ein nicht laufender oder auf `127.0.0.1` gebundener
+Exporter würde die Verbindung aktiv ablehnen — stilles Verwerfen ist die Signatur
+eines Paketfilters davor. Ursache 2 bleibt als Zusatzbedingung möglich: selbst bei
+offener Firewall muss cAdvisor drüben seinen Port auch veröffentlichen (auf CFGMON
+läuft er bewusst ohne `-p`, nur containerintern).
+
+**Nächster Schritt:** in der Hetzner-Cloud-Firewall dieses Hosts inbound TCP 8080 und
+9100 für `188.245.193.243/32` freigeben — oder besser den Weg unten gehen. Danach auf
+dem Host prüfen, ob beide Exporter laufen und worauf sie binden.
 
 **Empfehlung: nicht über die öffentliche IP.** CFGMON scrapt den k3s-Host bereits
 über das private Netz (`10.0.0.2:9100`) und der ist up — das ist das Modell, das
@@ -53,8 +74,21 @@ Danach in `threadnet-operating` die Targets in `monitoring/prometheus/prometheus
 von der rohen IP auf die private Adresse bzw. den DNS-Namen umstellen — aktuell
 stehen dort öffentliche IPs, obwohl mit `game.axion1337.de` ein Name existiert.
 
-**Solange offen:** die beiden Targets in Grafana als *known down* behandeln, damit
-sie kein Dauer-Alerting erzeugen.
+**Solange offen — Alerting stummgeschaltet.** Seit dem Alerting-Rollout (gitops#32,
+2026-08-01) erzeugen beide Targets echte `TargetDown`-Alarme im Matrix-Alerts-Raum,
+mit `repeat_interval: 4h` also alle vier Stunden erneut. Dafür sind auf CFGMON zwei
+Alertmanager-Silences gesetzt:
+
+| Silence-ID | Matcher |
+|---|---|
+| `abedb8a2-6969-41d0-aa94-20c1f575fe61` | `alertname="TargetDown" instance="pterodactyl"` |
+| `0f64aa3c-67a0-45c5-a9d9-a30ce64e8113` | `alertname="TargetDown" instance="157.90.155.206:8080"` |
+
+**Sie laufen am 2026-08-04 01:30 UTC ab.** Ist der Host bis dahin nicht gefixt, meldet
+sich das Alerting von selbst zurück — bewusst so gewählt, damit der Punkt nicht still
+liegen bleibt. Verlängern oder aufheben mit `docker compose exec alertmanager amtool
+silence expire <id> --alertmanager.url=http://localhost:9093` aus
+`/opt/threadnet-operating/monitoring`.
 
 ---