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.

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

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 und autoDiscovered

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.

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.

5.8 KiB Raw Blame History