Add BizTalk endpoint reachability monitoring

README.md

@@ -20,7 +20,7 @@ lokales BizTalk-WMI + BizTalk-SQL + Application Event Log
 Checkmk Windows Agent (LocalSystem)
   |
   v
-acht kompakte Checkmk Local Checks
+neun kompakte Checkmk Local Checks
 ```
 
 Damit bekommt `LocalSystem` keine BizTalk- oder SQL-Berechtigung. Nur das
@@ -62,7 +62,7 @@ Der Datenaustausch ist bewusst defensiv:
   Checkmk-Zeilen, korrekte SHA-256-Pruefsumme und ein maximales Alter von
   standardmaessig 180 Sekunden.
 - Fehlende, veraltete, abgeschnittene, manipulierte oder unlesbare Dateien
-  ergeben acht gueltige `UNKNOWN`-Services statt einer kaputten Agent-Ausgabe.
+  ergeben neun gueltige `UNKNOWN`-Services statt einer kaputten Agent-Ausgabe.
 - Ein exklusives Lock und die Task-Einstellung `IgnoreNew` verhindern
   ueberlappende Providerlaeufe.
 - Ein unerwarteter Providerfehler erzeugt nach Moeglichkeit einen aktuellen
@@ -82,6 +82,7 @@ Standardmaessig entstehen:
 - `BizTalk Host Instances`
 - `BizTalk Receive Locations`
 - `BizTalk Send Ports`
+- `BizTalk Endpoint Reachability`
 - `BizTalk Orchestrations`
 - `BizTalk Event Log`
 
@@ -91,8 +92,25 @@ Zustand und Graphen direkt erkennbar, ohne eine lange Sammelzeile zu lesen:
 - Suspensions: total, resumable, non-resumable und Routing Failure Reports
 - Receive Locations: total, enabled, unerwartet/bewusst disabled und unbekannt
 - Send Ports: total, started, stopped, bound, unbekannt sowie bewusst inactive
+- Endpoint Reachability: nur aktive Send-/Receive-Artefakte; im OK-Fall nur
+  eine Gesamtaussage, im Fehlerfall ausschliesslich nicht erreichbare Ziele
 - Orchestrations: total, started, stopped, bound, unbound und unbekannt
 
+Der Provider nutzt fuer die Endpoint-Discovery keine neue WMI-Klasse. Er liest
+`PTAddress`, `STAddress`, `PTTransportType`, `STTransportType`,
+`InboundTransportURL` und `AdapterName` aus den bereits vorhandenen
+`MSBTS_SendPort`-/`MSBTS_ReceiveLocation`-Abfragen. Der Check selbst ist ein
+reiner Host/Port-Test: HTTP(S), SFTP, FTP, WCF/net.tcp und UNC werden per TCP
+geprueft; explizite `udp://`-Ziele per UDP-Datagramm. Es werden keine
+HTTP-Requests, Anmeldungen oder fachlichen Nachrichten gesendet.
+
+Der geheimnisfreie Katalog liegt unter
+`%ProgramData%\BizTalkCheckmkPulse\data\endpoints.xml`. Fehlt er, wird er beim
+naechsten erfolgreichen Providerlauf erstellt. Alle 168 Stunden wird er gegen
+die Umgebung abgeglichen. Automatisch verwaltete Eintraege fuer inzwischen
+inaktive Artefakte verschwinden beim Abgleich; bei jedem Minutenlauf werden
+sie zusaetzlich gegen den aktuellen Started-/Enabled-Zustand gefiltert.
+
 Pro Service werden standardmaessig maximal fuenf betroffene Namen gezeigt.
 Weitere Treffer erscheinen nur als `(+n more)`; Details sind zusaetzlich auf
 1600 Zeichen begrenzt. Metriken bleiben trotzdem vollstaendig.
@@ -104,6 +122,9 @@ Statuslogik und Metriken: [docs/CheckmkServices.md](docs/CheckmkServices.md)
 
 Beispielausgaben: [docs/ExampleOutput.md](docs/ExampleOutput.md)
 
+Endpoint-Katalog, manuelle Overrides und Protokollgrenzen:
+[docs/EndpointCatalog.md](docs/EndpointCatalog.md)
+
 ## Voraussetzungen
 
 Build-Host:
@@ -161,7 +182,7 @@ Format-Self-Test ohne WMI, SQL oder Event Log:
 artifacts\BizTalkCheckmkPulse-deploy\application\BizTalkCheckmkPulse.exe --self-test
 ```
 
-Erwartet werden exakt acht `OK`-Zeilen. Die Regressionstests pruefen
+Erwartet werden exakt neun `OK`-Zeilen. Die Regressionstests pruefen
 zusaetzlich Snapshot-Roundtrip, atomaren Ersatz, SHA-256-Manipulation,
 Stale-Erkennung, stabile Fallbacks und die bestehenden BizTalk-WMI-Diagnosen.
 Ein Mono-Build ist eine hilfreiche Quellcodepruefung, ersetzt aber nicht die
@@ -207,7 +228,7 @@ Konfigurationsdatei noch in den Logs.
 
 Wenn das Kennwort rotiert oder ablaeuft, muss es im Scheduled Task aktualisiert
 werden. Bis dahin wird der Snapshot nach 180 Sekunden stale und Checkmk zeigt
-alle acht Services als `UNKNOWN`.
+alle neun Services als `UNKNOWN`.
 
 Ein gMSA kann weiterhin optional mit `-Gmsa` installiert werden; die
 produktive Standardbeschreibung geht vom normalen Servicekonto aus.
@@ -268,7 +289,7 @@ Verbindlicher Test im echten `LocalSystem`-Kontext:
     Select-String -Pattern "BizTalk|UNKNOWN|Snapshot|Permission" -Context 0,1
 ```
 
-Danach in Checkmk eine Service Discovery ausfuehren, die acht Services
+Danach in Checkmk eine Service Discovery ausfuehren, die neun Services
 aufnehmen und Changes aktivieren. Ein zusaetzlicher Checkmk-Async-Cache ist
 nicht erforderlich: Der Consumer liest nur eine kleine lokale Datei und der
 Provider besitzt bereits seinen eigenen Minutentakt.
@@ -284,6 +305,7 @@ Provider besitzt bereits seinen eigenen Minutentakt.
   data\
     biztalk-checkmk-pulse.snapshot
     biztalk-checkmk-pulse.snapshot.provider.lock
+    endpoints.xml
   logs\
     biztalk-checkmk-pulse-YYYYMMDD.log
 
@@ -321,6 +343,12 @@ Wichtige Werte:
 | `SnapshotMaxBytes` | `1048576` | Harte Eingabegroesse fuer den Consumer. |
 | `LogDirectory` | `%ProgramData%\BizTalkCheckmkPulse\logs` | Tageslogs. |
 | `LogRetentionDays` | `30` | Provider bereinigt aeltere Logs. |
+| `ProbeEndpointConnectivity` | `true` | Aktiviert den aggregierten TCP-/UDP-Netzwerkcheck. |
+| `EndpointCatalogPath` | `%ProgramData%\BizTalkCheckmkPulse\data\endpoints.xml` | Lokal gepflegte Endpoint-Konfiguration ohne vollstaendige URIs/Secrets. |
+| `EndpointDiscoveryIntervalHours` | `168` | Intervall fuer den vollstaendigen Umgebungsabgleich. |
+| `EndpointProbeTimeoutMilliseconds` | `3000` | Timeout je dedupliziertem Host/Port-Ziel. |
+| `EndpointProbeMaxConcurrency` | `12` | Begrenzte parallele Socket-Probes. |
+| `EndpointMaxCount` | `500` | Harte Obergrenze gegen fehlerhafte/uebergrosse Konfiguration. |
 | `QueryTimeoutSeconds` | `25` | WMI-Timeout je Query. |
 | `SqlConnectionTimeoutSeconds` | `5` | SQL-Timeout je Ziel. |
 | `WarnResumableThreshold` | `1` | WARN ab n resumable Suspensions. |
@@ -342,11 +370,13 @@ liest den naechsten atomar publizierten Snapshot.
 
 | Beobachtung | Ursache / Massnahme |
 | --- | --- |
-| Alle acht Services melden fehlenden Snapshot | Task, Provider-Log, Task-Konto/Kennwort und ACL pruefen. |
+| Alle neun Services melden fehlenden Snapshot | Task, Provider-Log, Task-Konto/Kennwort und ACL pruefen. |
 | Snapshot ist `stale` | `LastTaskResult`, Laufzeit, WMI-/SQL-Timeout und Log pruefen. |
 | SHA-256 oder Format ungueltig | Datei nicht manuell bearbeiten; Datentraeger/AV und Schreibpfad pruefen, Task neu starten. |
 | Provider meldet `Login failed` | Provider-Konto und exakt konfigurierte Read-Only-Gruppe sowie `BTS_READONLY_USERS` pruefen. |
 | Receive Locations / Send Ports sind CRIT | `affected=` pruefen; nur fachlich bewusst inaktive Namen exakt in die jeweilige Allowlist aufnehmen. |
+| Endpoint Reachability ist CRIT | Nur `unavailable=` pruefen; DNS, Zielport, Firewall und externen Dienst kontrollieren. |
+| Endpoint Reachability ist UNKNOWN | WMI-Vollstaendigkeit, `endpoints.xml`, woechentlichen Refresh und nicht automatisch aufloesbare externe Adapteradresse pruefen. |
 | `Wmi/Schema` | Klasse/Properties gegen BizTalk-2020-Schema pruefen; keine Rechte ausweiten. |
 | Nur Event Log `UNKNOWN` | lokalen Application-Log-Zugriff des Provider-Kontos pruefen. |
 | Task-Result `2` | Parallelstart oder Snapshot-I/O; Log und Lock/ACL pruefen. |
@@ -388,6 +418,8 @@ Die konkrete Datei und SHA-256-Summe werden bei der Uebergabe genannt.
 - Microsoft: BizTalk `MSBTS_GroupSetting.BizTalkReadOnlyUserGroup`
 - Microsoft: Windows Groups and User Accounts in BizTalk Server
 - Microsoft: Managing BizTalk Server Security
+- Microsoft: [`MSBTS_SendPort` (WMI)](https://learn.microsoft.com/en-us/biztalk/core/technical-reference/msbts-sendport-wmi)
+- Microsoft: [`MSBTS_ReceiveLocation` (WMI)](https://learn.microsoft.com/en-us/biztalk/core/technical-reference/msbts-receivelocation-wmi)
 - Checkmk: Windows Agent und Local Checks
 
 Die genauen Links stehen in [Dokumentation.md](Dokumentation.md).