175 lines
7.0 KiB
Markdown
175 lines
7.0 KiB
Markdown
# ACC-Analyse: Checkmk-Datenalter und Endpoint Reachability
|
|
|
|
> Nachtrag 11.08.2026: Version 2.2.7 behebt die aus der RTM-Ausgabe
|
|
> identifizierten Schedule-, Oracle-DATABASE- und WCF-SAP-Sonderfälle. Die
|
|
> verbindliche Nachfolgeregel steht in
|
|
> [RTM-Endpoint-Adapterregeln-2026-08-11.md](RTM-Endpoint-Adapterregeln-2026-08-11.md).
|
|
|
|
## 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.
|
|
- Version 2.2.3 ergänzt einen versionsübergreifenden Installer-Schutz: Der
|
|
tatsächliche Servicevertrag der vorhandenen und der neuen EXE wird vor dem
|
|
Task-Stopp verglichen. Unbestätigte Renames, neue oder entfernte Services
|
|
blockieren das Update; die Differenz wird vollständig angezeigt.
|
|
- Version 2.2.4 erzwingt nach der Umschaltung einen frischen vollständigen
|
|
Endpoint-Katalogabgleich und akzeptiert die Installation erst nach einem
|
|
erfolgreichen Providerlauf mit neuem, identitäts- und integritätsgeprüftem
|
|
Snapshot sowie neun verlässlichen stabilen Services.
|
|
|
|
### 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.6 als Update ausführen; Umgebung `ACC` kann bestehen bleiben.
|
|
Beim Wechsel von der fehlerhaften 2.2.1-Ausgabe `BizTalk ACC ...` auf die
|
|
stabilen Namen die Rename-/Discovery-Checkbox bewusst aktivieren.
|
|
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.
|