143 lines
6.2 KiB
Markdown
143 lines
6.2 KiB
Markdown
# 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 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
|
|
|
|
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:
|
|
|
|
```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 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:
|
|
|
|
```powershell
|
|
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.
|