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

%ProgramData%\BizTalkCheckmkPulse\data\endpoints.xml

wird sie im ersten erfolgreichen Lauf erzeugt. Danach erfolgt der vollständige Abgleich alle EndpointDiscoveryIntervalHours (Default: 168 Stunden). Ein Fehler beim Abgleich ersetzt keinen letzten gültigen Katalog. Checkmk meldet den überfälligen/fehlgeschlagenen Abgleich trotzdem als UNKNOWN.

Bei Installation oder Update ab Version 2.2.4 erzwingt ein einmaliger Provider-Abnahmelauf unabhängig vom Alter einen vollständigen Abgleich. Der Installer akzeptiert den Release erst, wenn der neue Synchronisationszeitpunkt nach dem Start dieses Laufs liegt. Gültige manuelle Overrides werden dabei erhalten; der Katalog wird nicht blind gelöscht.

Ab Setup 2.2.6 blockiert ein technisch gültiger Abnahmelauf nicht mehr allein deshalb, weil BizTalk Endpoint Reachability fachlich UNKNOWN meldet. Die Installation wird mit einer sichtbaren Warnung abgeschlossen; Status, Metriken und Detailtext bleiben im Snapshot erhalten. Ein fehlender, ungültiger oder nicht in diesem Abnahmelauf synchronisierter Katalog bleibt dagegen ein harter Installationsfehler.

Unabhängig 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
Scheduling-Komponente nie als Netzwerkziel

Damit wird ein inzwischen gestopptes/deaktiviertes Artefakt sofort nicht mehr geprüft. Prüffähige aktuelle WMI-Adressen werden bei jedem Minutenlauf direkt verwendet; der Wochenabgleich pflegt nur den persistenten, geheimnisfreien Katalog. Dadurch wird weder ein neues Ziel verzögert noch eine bis zu sieben Tage alte Auto-Discovery-Adresse weiter geprüft. Manuelle Overrides gewinnen weiterhin anhand ihres stabilen Artefaktschlüssels.

Laufzeitbudget

Die Socket-Probes werden nach Protokoll, Host und Port dedupliziert und mit maximal EndpointProbeMaxConcurrency=16 parallelen Verbindungen ausgeführt. Bei EndpointProbeTimeoutMilliseconds=3000 benötigen 70 vollständig timeoutende eindeutige Ziele theoretisch etwa 15 Sekunden. Die Standardgrenze EndpointMaxCount=100 begrenzt diesen Anteil eines Providerlaufs auf etwa 21 Sekunden. Die Grenze gilt für deduplizierte Host/Port/Protokoll-Ziele, nicht für die Anzahl der darauf abgebildeten BizTalk-Artefakte. Der Katalog ist separat über EndpointCatalogMaxEntries=1000 begrenzt. Erwartbar nicht als Socket prüfbare Artefakte zählen nicht gegen das Laufzeitbudget; echte Auflösungslücken werden als unresolved mit einem geheimnisfreien Grund gemeldet.

Checkmk selbst wartet nicht auf diese Verbindungen, sondern liest nur den zuletzt atomar geschriebenen Snapshot. Die reale ACC-Laufzeit ist nach dem Update an biztalk_endpoint_probe_duration_ms sowie an endpoint_probe_ms und elapsed_ms im Provider-Log zu kontrollieren. Der Scheduled Task verhindert mit IgnoreNew überlappende Providerläufe.

Sicherheitsmodell

Der Katalog speichert nicht die vollständige BizTalk-Adresse. Persistiert werden nur:

Artefakttyp, Anwendung, Name und Transportrolle
Adaptername
TCP oder UDP
Host und Port
enabled, autoDiscovered und die Best-Effort-Kennzeichnung

URI-Benutzerinformationen, Kennwörter, Pfade und Querystrings werden nicht geschrieben. Der Katalog liegt im bereits ACL-geschützten data-Verzeichnis; nur Provider und Administratoren dürfen ihn ändern. LocalSystem liest nur den separaten, validierten Checkmk-Snapshot.

Die automatische Auflösung akzeptiert neben absoluten URIs auch host:port und bei FTP/SFTP die schemafreie Form [benutzer@]host[:port]/pfad. Die Reihenfolge ist absichtlich eindeutig: host:port wird vor der allgemeinen .NET-URI-Auswertung erkannt, damit der Host nicht fälschlich als URI-Schema gedeutet wird. Benutzerinformationen und Pfad bleiben ausschließlich im flüchtigen WMI-Kandidaten und werden nicht persistiert. Eckige URI-Klammern um IPv6-Adressen werden vor der Socket-Probe entfernt.

Manuelle Korrektur eines automatisch nicht auflösbaren Endpoints

Vor einer manuellen Änderung den Scheduled Task kurz stoppen und die Datei sichern. Einen vorhandenen Eintrag auf den gewünschten Host/Port korrigieren und autoDiscovered="false" setzen. Der vorhandene key bleibt unverändert:

<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 Einträge werden beim Wochenabgleich erhalten. Stimmen Artefakttyp und key mit einem Send-/Receive-Artefakt überein, gilt weiterhin dessen Started-/Enabled-Filter. Ein zusätzliches, nicht an BizTalk gebundenes Ziel kann artifactType="Manual" verwenden; es wird bei enabled="true" immer geprüft.

Nach dem Speichern Task wieder starten und prüfen:

Start-ScheduledTask -TaskName 'BizTalk Checkmk Pulse Provider'
Get-Content "$env:ProgramData\BizTalkCheckmkPulse\logs\*.log" -Tail 100
& "$env:ProgramFiles\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe" --consume

Ungültiges XML, doppelte Keys, falsche Maschine/Umgebung, unbekannte Protokolle, ungültige Ports und übergroße Dateien werden verworfen. Der Provider kann bei vollständig verfügbarem BizTalk-Runtimezustand einen ungültigen 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 für HTTP(S), SFTP, FTP, SMB/UNC, WCF und net.tcp der passende nebenwirkungsfreie Netzwerktest. Er bestätigt DNS, Routing, Firewall und einen annehmenden TCP-Port, aber nicht die fachliche Antwort der Zielanwendung.

Oracle-DATABASE-Adressen mit explizitem Anbietersegment /Oracle verwenden den angegebenen Port oder den Oracle-Standard TCP 1521. WCF-SAP-Adressen verwenden vorrangig den ersten SAPROUTER=/H/host[/S/port]-Hop, andernfalls ListenerGwHost/ListenerGwServ beziehungsweise GwHost/GwServ. sapgwNN wird als TCP 33NN abgeleitet; der SAProuter-Standard ist TCP 3299. Diese automatisch erkannten Adapterziele sind bestEffort="true": Die Probe wird ausgeführt und gemessen, ein Fehlschlag aber nur in biztalk_endpoints_best_effort_ignored gezählt. Nicht sicher ableitbare DATABASE-/WCF-SAP-Adressen werden erwartbar ausgenommen. Ein manueller Katalogeintrag bleibt standardmäßig streng alarmierend und ist die bewusste Option für verbindliche Überwachung.

UDP ist verbindungslos. Bei udp://host:port bestätigt der Check nur DNS, Route und erfolgreichen lokalen Datagrammversand. Für einen belastbaren UDP-Dienstcheck wäre ein adapter-/protokollspezifisches Request/Response- Payload erforderlich; ein solches fachliches Paket wird bewusst nicht erfunden.

7.1 KiB Raw Blame History