Allow endpoint warnings during setup acceptance

2026-08-11 10:25:25 +02:00
parent cc1e59916a
commit 951a5e72d1
14 changed files with 234 additions and 37 deletions
@@ -0,0 +1,67 @@
+# Analyse: Runtime-Abnahme mit Endpoint-Reachability `UNKNOWN`
+
+## Beobachtung
+
+Setup 2.2.5 schaltete die neue Version um, startete den Provider erfolgreich
+und validierte danach die Runtime-Artefakte. Die Abnahme endete trotzdem mit:
+
+```text
+Runtime validation failed: Snapshot enthaelt unzuverlaessige UNKNOWN-Zustaende
+in stabilen Services. UNKNOWN=[BizTalk Endpoint Reachability].
+```
+
+Anschließend stellte der Installer die vorherige Version samt Task und frischem
+Snapshot erfolgreich wieder her.
+
+## Einordnung
+
+`LastTaskResult=0` belegt, dass der Providerlauf technisch abgeschlossen und
+ein Snapshot geschrieben wurde. Zusätzlich waren Snapshot-Zeitpunkt,
+SHA-256, Maschine, Collector-Identität, alle neun Servicenamen und der im
+Abnahmelauf synchronisierte Endpoint-Katalog valide. Das verbleibende
+`UNKNOWN` war daher kein Installations- oder Transaktionsfehler, sondern der
+fachliche Zustand der Endpoint-Prüfung.
+
+Der Endpoint-Service verwendet `UNKNOWN`, wenn die Prüfabdeckung nicht
+vollständig verlässlich ist, zum Beispiel bei einer nicht sicher auf
+Host/Port reduzierbaren aktiven Adresse, einem Katalog-/Probehinweis oder
+fehlendem manuellem Override. Diesen Zustand auf `OK` zu ändern würde die
+Monitoringlücke verbergen.
+
+## Korrektur in Version 2.2.6
+
+- Snapshot, Erzeugungszeit, Integrität, Maschine und Collector-Identität
+  werden unverändert strikt geprüft.
+- Alle neun stabilen Services müssen eindeutig vorhanden sein.
+- Bei aktivierter Endpoint-Prüfung muss der Katalog weiterhin im gestarteten
+  Abnahmelauf erfolgreich synchronisiert worden sein.
+- `UNKNOWN` in einem Kernservice bleibt ein Abnahmefehler.
+- Ausschließlich `BizTalk Endpoint Reachability = UNKNOWN` wird als
+  nicht blockierende Betriebswarnung akzeptiert.
+- Die vollständige UNKNOWN-Zeile erscheint in Setup-Ausgabe und Setup-Log und
+  bleibt unverändert im Snapshot für Checkmk erhalten.
+
+Damit wird die Installation abgeschlossen, ohne einen ungeklärten
+Monitoringzustand grünzufärben. Der normale Minutentask läuft weiter und die
+Endpoint-Ursache kann anhand von `unresolved_endpoints`,
+`catalog_or_probe_error`, `biztalk_endpoints_unresolved`, Katalog und
+Provider-Log gezielt bearbeitet werden.
+
+## Weiteres Vorgehen in ACC
+
+1. Setup 2.2.6 als Update ausführen und die ausgegebene
+   `RUNTIME_VALIDATION_WARNING` sichern.
+2. Im Snapshot die vollständige Zeile `BizTalk Endpoint Reachability` prüfen.
+3. Bei `unresolved_endpoints` Adapter, Artefakt und Grund auswerten und nur
+   bei einem tatsächlich externen Ziel einen geheimnisfreien manuellen
+   Override in `endpoints.xml` ergänzen.
+4. Bei `catalog_or_probe_error` zuerst Provider-Log und Katalog-XML prüfen.
+5. Nach der Bereinigung zwei Minutenläufe und den Checkmk-Agent-Dump prüfen.
+
+## Regressionstests
+
+- Ein isoliertes Endpoint-Reachability-`UNKNOWN` wird als Warnung akzeptiert
+  und sein vollständiger Detailtext bleibt erhalten.
+- `BizTalk Platform = UNKNOWN` bleibt blockierend.
+- Fehlender Service, alter Snapshot, falsche Identität und alter Katalog
+  bleiben blockierend.