68 lines
3.0 KiB
Markdown
68 lines
3.0 KiB
Markdown
# 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.
|