biztalk-checkmk-pulse/docs/Installer-Runtime-Unknown-Analyse-2026-08-11.md

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:

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.