Fix ACC endpoint reachability and stable service names
This commit is contained in:
@@ -0,0 +1,159 @@
|
||||
# ACC-Analyse: Checkmk-Datenalter und Endpoint Reachability
|
||||
|
||||
## Befund
|
||||
|
||||
Die am 10.08.2026 bereitgestellten ACC-Artefakte zeigen zwei getrennte
|
||||
Fehlerbilder.
|
||||
|
||||
### 1. Checkmk findet die neun Services nicht mehr
|
||||
|
||||
Die Checkmk-Ansicht erwartet die bisherigen Namen ohne Umgebung, zum Beispiel:
|
||||
|
||||
```text
|
||||
BizTalk Endpoint Reachability
|
||||
BizTalk Platform
|
||||
BizTalk SQL Access
|
||||
```
|
||||
|
||||
Der aktuelle Snapshot enthält dagegen ausschließlich umbenannte Services:
|
||||
|
||||
```text
|
||||
BizTalk ACC Endpoint Reachability
|
||||
BizTalk ACC Platform
|
||||
BizTalk ACC SQL Access
|
||||
```
|
||||
|
||||
Damit ist `Item not found in monitoring data` kein Beleg für einen veralteten
|
||||
oder fehlenden Snapshot. Checkmk sucht nach einem anderen Servicenamen als der
|
||||
Agent aktuell liefert. Die unterschiedlichen Alterswerte sind die Zeitpunkte,
|
||||
zu denen Checkmk die jeweiligen alten Namen zuletzt gesehen hat.
|
||||
|
||||
Ursache in Version 2.2.1: `EnvironmentName=ACC` wurde zugleich als
|
||||
Servicenamensbestandteil verwendet. Das Installerfeld „Umgebung“ konnte damit
|
||||
bei einem Update den stabilen Checkmk-Vertrag unbeabsichtigt ändern.
|
||||
|
||||
### 2. Endpoint-Probe ist schnell und erfolgreich, wird aber als UNKNOWN formatiert
|
||||
|
||||
Der Snapshot belegt:
|
||||
|
||||
| Wert | ACC-Befund |
|
||||
| --- | ---: |
|
||||
| aktive Transportkandidaten laut Katalog | 135 |
|
||||
| automatisch konfigurierte/prüfbare Artefakte | 64 |
|
||||
| vollständig getestete Artefakte | 64 |
|
||||
| erreichbare Artefakte | 64 |
|
||||
| fehlgeschlagene Artefakte | 0 |
|
||||
| eindeutige Host-/Port-/Protokoll-Ziele | 17 |
|
||||
| nicht automatisch auflösbare externe Kandidaten | 61 |
|
||||
| Probe-Laufzeit | 266 ms |
|
||||
|
||||
Die Netzwerkprobe selbst ist damit weder veraltet noch langsam. Sie
|
||||
dedupliziert 64 Artefakte auf 17 Netzwerkverbindungen und schließt alle Probes
|
||||
in deutlich unter einer Sekunde ab.
|
||||
|
||||
Version 2.2.1 behandelt jedoch jeden Wert
|
||||
`biztalk_endpoints_unsupported > 0` als unvollständiges Ergebnis. Deshalb wird
|
||||
der Service trotz `available=64` und `failed=0` als `UNKNOWN` ausgegeben. Die
|
||||
61 Kandidaten fehlen erwartungsgemäß in `endpoints.xml`, weil für sie kein
|
||||
sicherer und geheimnisfreier Host/Port ermittelt werden konnte. Das ist eine
|
||||
Abdeckungsinformation, kein Fehler der 64 ausgeführten Probes.
|
||||
|
||||
Aus `135 - 64 - 61` ergeben sich zusätzlich 10 lokale, dynamische oder bewusst
|
||||
nicht netzwerkprüfbare Kandidaten. Version 2.2.2 weist sie explizit als
|
||||
`excluded` aus.
|
||||
|
||||
## Korrektur in Version 2.2.2
|
||||
|
||||
### Stabile Servicenamen
|
||||
|
||||
- `EnvironmentName` bleibt Umgebungsmetadatum für Snapshot und Katalog.
|
||||
- Standard `IncludeEnvironmentInServiceName=false`: Die neun Namen bleiben
|
||||
`BizTalk ...` und passen wieder zu den bereits entdeckten ACC-Services.
|
||||
- Nur ein bewusstes Opt-in mit `true` erzeugt Namen wie `BizTalk ACC ...` und
|
||||
verlangt anschließend eine Checkmk Service Discovery.
|
||||
|
||||
### Korrekte Abdeckungssemantik
|
||||
|
||||
- Erfolgreich geprüfte Ziele bestimmen den Zustand der Endpoint-Probe.
|
||||
- Ein fehlgeschlagenes getestetes Ziel bleibt `CRIT`.
|
||||
- `unsupported` und `excluded` werden als vollständige Metriken ausgegeben,
|
||||
führen neben erfolgreicher Prüfabdeckung aber nicht mehr zu `UNKNOWN`.
|
||||
- Wenn externe `unsupported`-Kandidaten existieren und überhaupt kein Ziel
|
||||
automatisch geprüft werden kann, bleibt der Service bewusst `UNKNOWN`.
|
||||
|
||||
### Sofortige Katalogkonsistenz
|
||||
|
||||
Der Provider vergleicht in jedem Minutenlauf die bereits aus WMI gelesenen
|
||||
aktiven Kandidaten mit dem Katalog. Folgende Änderungen lösen sofort einen
|
||||
atomaren Neuabgleich aus:
|
||||
|
||||
- neuer, deaktivierter oder entfernter prüfbarer Artefaktschlüssel,
|
||||
- geänderter Host, Port oder Protokoll eines vorhandenen Artefakts,
|
||||
- geänderte Zahl aktiver oder nicht automatisch auflösbarer Kandidaten.
|
||||
|
||||
Manuelle Overrides gelten weiterhin als beabsichtigte Abdeckung und lösen
|
||||
keine Refresh-Schleife aus. Der 168-Stunden-Abgleich bleibt als zusätzliche
|
||||
Frischegrenze bestehen.
|
||||
|
||||
### Laufzeitgrenzen
|
||||
|
||||
Die performante Implementierung bleibt unverändert:
|
||||
|
||||
- Deduplizierung nach Protokoll, Host und Port,
|
||||
- maximal 16 parallele Probes,
|
||||
- 3 Sekunden Timeout je eindeutiges Ziel,
|
||||
- maximal 100 automatisch konfigurierte Endpoint-Einträge.
|
||||
|
||||
Der beobachtete ACC-Wert von 266 ms für 17 eindeutige Ziele liegt deutlich im
|
||||
Minutenbudget.
|
||||
|
||||
## Erwartung nach dem Update
|
||||
|
||||
Der Endpoint-Service sollte bei unverändertem ACC-Zustand sinngemäß liefern:
|
||||
|
||||
```text
|
||||
0 "BizTalk Endpoint Reachability" ... candidates=135 ... active=64 ...
|
||||
available=64 ... failed=0 ... unsupported=61 ... excluded=10 ...
|
||||
unique_targets=17 ... probe_ms=<Laufzeit>
|
||||
```
|
||||
|
||||
Die übrigen fachlichen Zustände aus dem gelieferten Snapshot werden danach in
|
||||
Checkmk wieder sichtbar und sind getrennt zu bewerten:
|
||||
|
||||
- 3 resumable Suspensions: `WARN`,
|
||||
- 2 Host Instances mit unbekanntem Status: `CRIT`,
|
||||
- 22 nicht allowlistete deaktivierte Receive Locations: `CRIT`,
|
||||
- 17 nicht allowlistete inaktive Send Ports: `CRIT`,
|
||||
- 2 Errors und 6 Warnings im Event-Log-Zeitfenster: `WARN`.
|
||||
|
||||
Diese Zustände sind nicht die Ursache des Datenalters und werden durch den
|
||||
Endpoint-/Namensfix bewusst nicht grüngefärbt.
|
||||
|
||||
## ACC-Abnahme nach Installation
|
||||
|
||||
1. Setup 2.2.2 als Update ausführen; Umgebung `ACC` kann bestehen bleiben.
|
||||
2. In der installierten Config bestätigen:
|
||||
|
||||
```text
|
||||
EnvironmentName=ACC
|
||||
IncludeEnvironmentInServiceName=false
|
||||
```
|
||||
|
||||
3. Scheduled Task manuell starten und `LastTaskResult=0` prüfen.
|
||||
4. Snapshot zweimal im Abstand von ungefähr einer Minute prüfen; `generatedUtc`
|
||||
muss fortschreiten und die Namen müssen `BizTalk ...` ohne `ACC` lauten.
|
||||
5. `BizTalk Endpoint Reachability` muss bei `failed=0` und vorhandener
|
||||
automatischer Prüfabdeckung `OK` liefern. `unsupported`/`excluded` bleiben
|
||||
als Metriken sichtbar.
|
||||
6. Agent-Dump prüfen:
|
||||
|
||||
```cmd
|
||||
"C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" dump | findstr /C:"BizTalk "
|
||||
```
|
||||
|
||||
7. Checkmk-Prüfung neu planen. Die bestehenden neun Namen sollten ohne
|
||||
Umbenennung wieder Daten erhalten. Nur falls Checkmk noch alte
|
||||
`BizTalk ACC ...`-Services enthält, einmal Service Discovery durchführen
|
||||
und die bewusst falschen Namen entfernen.
|
||||
8. `biztalk_endpoint_probe_duration_ms` und `elapsed_ms` über mehrere Läufe
|
||||
beobachten; der Task darf nicht in das nächste Minutenintervall laufen.
|
||||
Reference in New Issue
Block a user