Add BizTalk endpoint reachability monitoring

This commit is contained in:
2026-08-04 09:48:00 +02:00
parent 826d87fef7
commit 91e0db5619
20 changed files with 1714 additions and 38 deletions
+41 -1
View File
@@ -11,7 +11,7 @@ Die Ausgabe ist so gebaut, dass sie auch mit Checkmk 2.4.0p4 kompatibel bleibt:
Die fachlichen Daten werden minuetlich vom privilegierten Scheduled-Task-
Provider erzeugt. Der Checkmk-Agent liest als `LocalSystem` nur den
integritaets- und altersgeprueften Snapshot. Ist dieser Transport nicht
verfuegbar, liefern alle acht stabilen Services `UNKNOWN`.
verfuegbar, liefern alle neun stabilen Services `UNKNOWN`.
## BizTalk Platform
@@ -174,6 +174,46 @@ Metriken:
| `biztalk_send_ports_expected_inactive` | Bewusst inactive und exakt allowlisted. |
| `biztalk_send_ports_unknown` | Nicht interpretierbarer Send-Port-Status. |
## BizTalk Endpoint Reachability
Zweck:
- Prueft nur Receive Locations mit `IsDisabled=false` und Send Ports mit
`Status=Started`.
- Reduziert die Adresse auf Host/Port und fuehrt keinen fachlichen
HTTP-, FTP-, SFTP-, WCF- oder BizTalk-Aufruf aus.
- Dedupliziert gemeinsame Host/Port-Ziele und prueft sie mit begrenzter
Parallelitaet; das Ergebnis wird danach wieder den Artefakten zugeordnet.
- Zeigt im gesunden Zustand nur `Alle n ... erreichbar`. Nur bei Fehlern
erscheint die begrenzte Liste `unavailable=`.
Status:
| Status | Bedingung |
| --- | --- |
| `OK` | Katalog und Runtimezustand vollstaendig; alle aktiven pruefbaren Ziele erreichbar. |
| `CRIT` | Mindestens ein getestetes TCP-/UDP-Ziel nicht erreichbar. |
| `UNKNOWN` | Katalog fehlt/ist ungueltig, Wochenabgleich scheitert, Runtimezustand ist unvollstaendig oder ein aktiver externer Endpoint kann nicht sicher auf Host/Port reduziert werden. |
| `OK` mit Hinweis | Nur wenn `ProbeEndpointConnectivity=false`; der Test ist bewusst deaktiviert. |
Metriken:
| Metrik | Bedeutung |
| --- | --- |
| `biztalk_endpoints_configured` | Eintraege in `endpoints.xml`, einschliesslich derzeit inaktiver. |
| `biztalk_endpoints_active` | Im aktuellen Lauf Started/Enabled und fuer die Probe ausgewaehlt. |
| `biztalk_endpoints_tested` | Vollstaendig abgeschlossene Artefaktprobes. |
| `biztalk_endpoints_available` | Erreichbare aktive Artefaktziele. |
| `biztalk_endpoints_failed` | Nicht erreichbare aktive Artefaktziele; CRIT ab 1. |
| `biztalk_endpoints_unsupported` | Aktive externe Adressen ohne sicher bestimmbaren Host/Port. |
| `biztalk_endpoints_inactive_skipped` | Konfigurierte Eintraege, deren BizTalk-Artefakt aktuell nicht aktiv ist. |
Bei expliziten `udp://host:port`-Eintraegen kann ein generischer Check ohne
applikationsspezifisches Protokoll nur DNS, Route und erfolgreichen lokalen
Datagrammversand bestaetigen. Er beweist keine Antwort des entfernten
UDP-Dienstes. Fuer alle ueblichen streambasierten Adapter wird deshalb TCP
verwendet.
## BizTalk Orchestrations
Status:
+98
View File
@@ -0,0 +1,98 @@
# Endpoint-Katalog und Netzwerkprobe
## Automatischer Betrieb
Der privilegierte Provider liest bei seiner bereits vorhandenen
`MSBTS_SendPort`-/`MSBTS_ReceiveLocation`-Abfrage auch die dokumentierten
Transportadressen. Fehlt die Datei
```text
%ProgramData%\BizTalkCheckmkPulse\data\endpoints.xml
```
wird sie im ersten erfolgreichen Lauf erzeugt. Danach erfolgt der vollstaendige
Abgleich alle `EndpointDiscoveryIntervalHours` (Default: 168 Stunden). Ein
Fehler beim Abgleich ersetzt keinen letzten gueltigen Katalog. Checkmk meldet
den ueberfaelligen/fehlgeschlagenen Abgleich trotzdem als `UNKNOWN`.
Unabhaengig vom Wochenabgleich wird bei jedem Minutenlauf gegen den aktuellen
BizTalk-Runtimezustand gefiltert:
- Receive Location nur bei `IsDisabled=false`
- Send Port nur bei `Status=Started`
- dynamischer Send Port nie als statisches Ziel
Damit wird ein inzwischen gestopptes/deaktiviertes Artefakt sofort nicht mehr
geprueft. Neue Artefakte werden spaetestens beim naechsten Wochenabgleich
aufgenommen.
## Sicherheitsmodell
Der Katalog speichert nicht die vollstaendige BizTalk-Adresse. Persistiert
werden nur:
- Artefakttyp, Anwendung, Name und Transportrolle
- Adaptername
- `TCP` oder `UDP`
- Host und Port
- `enabled` und `autoDiscovered`
URI-Benutzerinformationen, Kennwoerter, Pfade und Querystrings werden nicht
geschrieben. Der Katalog liegt im bereits ACL-geschuetzten `data`-Verzeichnis;
nur Provider und Administratoren duerfen ihn aendern. `LocalSystem` liest nur
den separaten, validierten Checkmk-Snapshot.
## Manuelle Korrektur eines automatisch nicht aufloesbaren Endpoints
Vor einer manuellen Aenderung den Scheduled Task kurz stoppen und die Datei
sichern. Einen vorhandenen Eintrag auf den gewuenschten Host/Port korrigieren
und `autoDiscovered="false"` setzen. Der vorhandene `key` bleibt unveraendert:
```xml
<Endpoint
key="SENDPORT|ORDERS|SP ORDER OUT|PRIMARY"
artifactType="SendPort"
application="Orders"
artifact="SP Order Out"
transportRole="Primary"
adapter="Custom Adapter"
protocol="TCP"
host="gateway.example.internal"
port="7443"
enabled="true"
autoDiscovered="false" />
```
Manuelle Eintraege werden beim Wochenabgleich erhalten. Stimmen Artefakttyp
und `key` mit einem Send-/Receive-Artefakt ueberein, gilt weiterhin dessen
Started-/Enabled-Filter. Ein zusaetzliches, nicht an BizTalk gebundenes Ziel
kann `artifactType="Manual"` verwenden; es wird bei `enabled="true"` immer
geprueft.
Nach dem Speichern Task wieder starten und pruefen:
```powershell
Start-ScheduledTask -TaskName 'BizTalk Checkmk Pulse Provider'
Get-Content "$env:ProgramData\BizTalkCheckmkPulse\logs\*.log" -Tail 100
& "$env:ProgramFiles\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe" --consume
```
Ungueltiges XML, doppelte Keys, falsche Maschine/Umgebung, unbekannte
Protokolle, ungueltige Ports und uebergrosse Dateien werden verworfen. Der
Provider kann bei vollstaendig verfuegbarem BizTalk-Runtimezustand einen
ungueltigen rein automatisch erzeugten Katalog neu aufbauen. Deshalb muss ein
manueller Eintrag vor dem produktiven Einsatz gesichert und im Provider-Log
verifiziert werden.
## Protokollgrenzen
TCP-Connect ist fuer HTTP(S), SFTP, FTP, SMB/UNC, WCF und `net.tcp` der
passende nebenwirkungsfreie Netzwerktest. Er bestaetigt DNS, Routing,
Firewall und einen annehmenden TCP-Port, aber nicht die fachliche Antwort der
Zielanwendung.
UDP ist verbindungslos. Bei `udp://host:port` bestaetigt der Check nur DNS,
Route und erfolgreichen lokalen Datagrammversand. Fuer einen belastbaren
UDP-Dienstcheck waere ein adapter-/protokollspezifisches Request/Response-
Payload erforderlich; ein solches fachliches Paket wird bewusst nicht
erfunden.
+16 -1
View File
@@ -9,6 +9,7 @@
0 "BizTalk Host Instances" biztalk_host_instances_total=0;;;0 Self test OK. No WMI query was executed.
0 "BizTalk Receive Locations" biztalk_receive_locations_total=0;;;0 Self test OK. No WMI query was executed.
0 "BizTalk Send Ports" biztalk_send_ports_total=0;;;0 Self test OK. No WMI query was executed.
0 "BizTalk Endpoint Reachability" biztalk_endpoints_active=0;;;0 Self test OK. No network connection was opened.
0 "BizTalk Orchestrations" biztalk_orchestrations_total=0;;;0 Self test OK. No WMI query was executed.
0 "BizTalk Event Log" biztalk_eventlog_errors=0;;;0 Self test OK. No event log was read.
```
@@ -55,9 +56,23 @@ werden nicht doppelt zum Total addiert.
Die Zaehler und Performance-Daten enthalten weiterhin alle 22 betroffenen
Artefakte. Nur die Textliste ist begrenzt.
## Endpoint-Erreichbarkeit
Gesund, ohne Auflistung aller Ziele:
```text
0 "BizTalk ACC Endpoint Reachability" biztalk_endpoints_configured=63;;;0|biztalk_endpoints_active=61;;;0|biztalk_endpoints_tested=61;;;0|biztalk_endpoints_available=61;;;0|biztalk_endpoints_failed=0;;1;0|biztalk_endpoints_unsupported=0;;1;0|biztalk_endpoints_inactive_skipped=2;;;0 Alle 61 aktiven, pruefbaren Send-/Receive-Endpunkte sind erreichbar; catalog_utc=2026-08-04T10:00:00.0000000Z
```
Fehlerhaft, nur mit nicht erreichbaren Zielen:
```text
2 "BizTalk ACC Endpoint Reachability" ... Endpoint reachability active=61, tested=61, available=59, failed=2, unsupported_external=0; unavailable=SendPort:Orders\SP_Order_API[Primary]->orders.example:443/TCP(TCP timeout), ReceiveLocation:Invoices\RL_SFTP[Inbound]->sftp.example:22/TCP(SocketError=ConnectionRefused)
```
## Fehlender oder veralteter Provider-Snapshot
Alle acht Services werden `UNKNOWN`, zum Beispiel:
Alle neun Services werden `UNKNOWN`, zum Beispiel:
```text
3 "BizTalk Platform" - Privilegierter BizTalk-Datensnapshot nicht verfuegbar: Snapshot is stale: age=241s, maximum=180s. Massnahme: Scheduled Task 'BizTalk Checkmk Pulse Provider', Provider-Log, Snapshot-Alter und ACL pruefen.
+4 -2
View File
@@ -61,7 +61,7 @@ Verbindlicher Agent-Dump:
2. `LastTaskResult=0`, frischen Snapshot und Log pruefen.
3. Agent-Dump im `LocalSystem`-Kontext pruefen.
4. Service Discovery fuer den BizTalk-Host ausfuehren.
5. acht stabile Services aufnehmen und den alten
5. neun stabile Services aufnehmen und den alten
`BizTalk Runtime Artifacts`-Service entfernen.
6. Changes aktivieren.
7. Views, Servicegruppen und Benachrichtigungen einrichten.
@@ -111,11 +111,13 @@ Soll:
- SQL Access zeigt `targets=2`, `available=2`.
- Suspended Instances zeigt total/resumable/non-resumable/routing failures.
- Receive Locations und Send Ports zeigen getrennte expected/unexpected Werte.
- Endpoint Reachability zeigt bei Erfolg nur die Gesamtzahl und bei Fehlern
ausschliesslich nicht erreichbare Ziele.
- keine berechtigungsbedingten `UNKNOWN`-Services.
## Alarmierung der Transportkette
Ein Ausfall des Providers wird ueber alle acht Services als `UNKNOWN`
Ein Ausfall des Providers wird ueber alle neun Services als `UNKNOWN`
sichtbar. Die Summary nennt fehlenden, unlesbaren, ungueltigen oder stale
Snapshot. Als Betriebsregel sollte `UNKNOWN` dieser Services genauso
eskaliert werden wie ein technischer Monitoringausfall.