biztalk-checkmk-pulse/docs/ACC-Endpoint-Reachability-Analyse-2026-08-10.md

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:

BizTalk Endpoint Reachability
BizTalk Platform
BizTalk SQL Access

Der aktuelle Snapshot enthält dagegen ausschließlich umbenannte Services:

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:

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:

   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:

   "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.