Add BizTalk endpoint reachability monitoring

Dokumentation.md

@@ -89,7 +89,7 @@ Ablauf:
 2. Tageslogs gemaess `LogRetentionDays` bereinigen.
 3. exklusives Handle auf `<SnapshotPath>.provider.lock` halten.
 4. WMI-, SQL- und Event-Log-Probes ausfuehren.
-5. acht stabile und optionale dynamische Checkmk-Zeilen formatieren.
+5. neun stabile und optionale dynamische Checkmk-Zeilen formatieren.
 6. Snapshot in einer eindeutigen Temporaerdatei desselben Verzeichnisses
    schreiben.
 7. `Flush(true)` ausfuehren und Temporaerdatei atomar publizieren.
@@ -132,7 +132,7 @@ Der Consumer:
 - gibt bei Erfolg ausschliesslich den validierten Payload aus.
 
 Er gibt immer Exitcode `0` zurueck, damit ein Fehler die komplette
-Checkmk-Agentsektion nicht zerstoert. Jede Ablehnung erzeugt acht
+Checkmk-Agentsektion nicht zerstoert. Jede Ablehnung erzeugt neun
 `UNKNOWN`-Zeilen und einen Eintrag im Consumer-Log.
 
 ## 4. Snapshot-Vertrag
@@ -210,7 +210,7 @@ Metrik ausgewiesen und zugleich in `suspended_nonresumable` mitgezaehlt.
 ### 5.2 Kompaktes Checkmk-Servicebild
 
 Die alte Sammelzeile `BizTalk Runtime Artifacts` wurde durch drei kurze
-Services ersetzt. Insgesamt entstehen acht stabile Services:
+Services ersetzt. Insgesamt entstehen neun stabile Services:
 
 1. `BizTalk Platform`
 2. `BizTalk SQL Access`
@@ -218,8 +218,9 @@ Services ersetzt. Insgesamt entstehen acht stabile Services:
 4. `BizTalk Host Instances`
 5. `BizTalk Receive Locations`
 6. `BizTalk Send Ports`
-7. `BizTalk Orchestrations`
-8. `BizTalk Event Log`
+7. `BizTalk Endpoint Reachability`
+8. `BizTalk Orchestrations`
+9. `BizTalk Event Log`
 
 Receive Locations und Send Ports alarmieren nur fuer unerwartete
 Aus-Zustaende. Fachlich bewusst deaktivierte Namen werden exakt, ohne
@@ -232,7 +233,46 @@ Artefakte werden als `(+n more)` zusammengefasst. `MaxDetailCharacters`
 begrenzt jede Detailausgabe, damit Checkmk-Ansichten kompakt bleiben, waehrend
 alle numerischen Metriken vollstaendig erhalten bleiben.
 
-### 5.3 SQL-Zugriffsprobe
+### 5.3 Endpoint-Discovery und Netzwerkprobe
+
+Die Endpoint-Funktion erweitert keine WMI-Klassenmenge. Aus den ohnehin
+minuetlich abgefragten Instanzen werden nur dokumentierte Properties gelesen:
+
+| WMI-Klasse | Properties |
+| --- | --- |
+| `MSBTS_SendPort` | `Status`, `IsDynamic`, `PTAddress`, `STAddress`, `PTTransportType`, `STTransportType` |
+| `MSBTS_ReceiveLocation` | `IsDisabled`, `InboundTransportURL`, `AdapterName` |
+
+Nur `Status=Started` beziehungsweise `IsDisabled=false` wird geprueft.
+Inaktive Artefakte bleiben aus der Probe ausgeschlossen, auch wenn sie noch im
+Katalog stehen. Dynamische Send Ports, lokale Dateipfade, SMTP-Empfaengerlisten
+und Named Pipes werden nicht als externe Host/Port-Ziele behandelt.
+
+Der lokale Katalog
+`%ProgramData%\BizTalkCheckmkPulse\data\endpoints.xml` wird beim ersten
+erfolgreichen Lauf erzeugt und danach standardmaessig alle 168 Stunden atomar
+abgeglichen. Er enthaelt keine vollstaendigen URIs, Querystrings,
+Benutzernamen oder Kennwoerter, sondern nur Artefaktbezug, Adapter, Host, Port
+und `TCP`/`UDP`. Automatisch erzeugte Eintraege tragen
+`autoDiscovered="true"`. Ein bewusst manueller Override wird mit
+`autoDiscovered="false"` markiert und beim Wochenabgleich erhalten; sein
+`key` muss dem Artefakteintrag entsprechen. Eigenstaendige manuelle Ziele
+verwenden `artifactType="Manual"`.
+
+HTTP(S), SFTP, FTP, UNC/SMB, WCF und `net.tcp` werden ausschliesslich per
+TCP-Connect geprueft. Es findet kein fachlicher Request und keine Anmeldung
+statt. Explizite `udp://host:port`-Eintraege senden ein einzelnes Datagramm;
+das bestaetigt DNS, Route und lokalen Versand, kann ohne
+applikationsspezifisches Antwortprotokoll aber keinen entfernten Dienstzustand
+beweisen. Gemeinsame Host/Port-Ziele werden dedupliziert und mit begrenzter
+Parallelitaet getestet.
+
+Der Checkmk-Service nennt im OK-Fall nur die Gesamtzahl. Bei Ausfaellen werden
+ausschliesslich die nicht erreichbaren Artefakte in `unavailable=` angezeigt;
+`MaxSummaryItems` und `MaxDetailCharacters` begrenzen die Darstellung. Alle
+Einzelfehler bleiben vollstaendig im Provider-Log.
+
+### 5.4 SQL-Zugriffsprobe
 
 Der Provider oeffnet fuer Management- und Master-MessageBox-Datenbank eine
 kurze `System.Data.SqlClient`-Verbindung mit integrierter
@@ -243,7 +283,7 @@ Die Ausgabe `execution_identity=` zeigt deshalb das Provider-Konto, nicht mehr
 `NT AUTHORITY\SYSTEM`. Der Check beweist, dass genau das Scheduled-Task-Konto
 die Ziele erreichen kann.
 
-### 5.4 Event Log
+### 5.5 Event Log
 
 Der Provider liest das lokale Application Log im konfigurierten Zeitfenster
 und filtert Quellen wie `BizTalk Server`, `XLANG/s`, `ENTSSO`,
@@ -378,7 +418,7 @@ Snapshot nicht zusaetzlich verzoegert.
 Nach dem Agent-Dump:
 
 1. Service Discovery fuer den BizTalk-Host ausfuehren.
-2. acht stabile Services aufnehmen; den alten Service
+2. neun stabile Services aufnehmen; den alten Service
    `BizTalk Runtime Artifacts` nach erfolgreicher Discovery entfernen.
 3. Changes aktivieren.
 4. Views/Benachrichtigungen nach Umgebung konfigurieren.
@@ -485,6 +525,8 @@ Runtime:
 | `SnapshotMaxBytes` | `1048576` | 4096 bis 16777216 |
 | `LogDirectory` | `%ProgramData%\BizTalkCheckmkPulse\logs` | absolut |
 | `LogRetentionDays` | `30` | 1 bis 365 |
+| `EndpointCatalogPath` | `%ProgramData%\BizTalkCheckmkPulse\data\endpoints.xml` | absolut |
+| `EndpointCatalogMaxBytes` | `1048576` | 4096 bis 16777216 |
 
 BizTalk-Probes:
 
@@ -496,6 +538,11 @@ BizTalk-Probes:
 | `SqlConnectionTimeoutSeconds` | `5` |
 | `ProbeEventLog` | `true` |
 | `EventLogLookbackMinutes` | `60` |
+| `ProbeEndpointConnectivity` | `true` |
+| `EndpointDiscoveryIntervalHours` | `168` |
+| `EndpointProbeTimeoutMilliseconds` | `3000` |
+| `EndpointProbeMaxConcurrency` | `12` |
+| `EndpointMaxCount` | `500` |
 
 Alarmierung:
 
@@ -519,7 +566,7 @@ Alarmierung:
 Automatisiert:
 
 - Release-Build .NET Framework 4.7.2,
-- exakt acht Self-Test-Services,
+- exakt neun Self-Test-Services,
 - unbekannte Quellen werden `UNKNOWN`,
 - dynamische Anwendungsservices nur bei bekannter Anwendung,
 - WMI-Queryvertrag nutzt dokumentierte Properties,
@@ -529,10 +576,13 @@ Automatisiert:
 - Receive-/Send-Allowlisten trennen bewusste von unerwarteten Aus-Zustaenden,
 - ein fehlender `IsDisabled`-Wert wird `UNKNOWN` statt still als enabled,
 - betroffene Namen und Gesamtlaenge der Summary bleiben begrenzt,
+- Endpoint-Adressen werden ohne URI-Secrets auf Host/Port reduziert,
+- manuelle Endpoint-Overrides ueberleben den automatischen Wochenabgleich,
+- nur nicht erreichbare Endpoints erscheinen im Checkmk-Detail,
 - Snapshot-Roundtrip und Ersatz,
 - SHA-256-Manipulation wird verworfen,
 - Stale-Snapshot wird verworfen,
-- Consumer-Fallback enthaelt acht `UNKNOWN`-Services.
+- Consumer-Fallback enthaelt neun `UNKNOWN`-Services.
 
 Windows-/ACC-Abnahme:
 
@@ -549,9 +599,17 @@ Windows-/ACC-Abnahme:
 9. Einen Testnamen aus der Allowlist entfernen und den erwarteten CRIT mit
    kurzem `affected=`-Detail pruefen.
 10. ACL-Test: `LocalSystem` kann Snapshot lesen, nicht schreiben.
-11. Task deaktivieren: nach 180 Sekunden acht stale-`UNKNOWN`s.
-12. Task wieder aktivieren: naechster Snapshot stellt Echtzustand her.
-13. Agent-Dump und Checkmk Service Discovery erfolgreich.
+11. `endpoints.xml` wurde erzeugt; sie enthaelt keine vollstaendigen URIs oder
+    Zugangsdaten und nur Started-/Enabled-Artefakte.
+12. Einen erreichbaren Testport sperren: nur `Endpoint Reachability` wird CRIT
+    und nennt ausschliesslich das nicht erreichbare Ziel.
+13. Ein Artefakt stoppen/deaktivieren: es wird im naechsten Minutenlauf nicht
+    mehr geprueft.
+14. Katalogzeit auf aelter als 168 Stunden setzen beziehungsweise Intervall
+    testweise reduzieren: erfolgreicher atomarer Umgebungsabgleich.
+15. Task deaktivieren: nach 180 Sekunden neun stale-`UNKNOWN`s.
+16. Task wieder aktivieren: naechster Snapshot stellt Echtzustand her.
+17. Agent-Dump und Checkmk Service Discovery erfolgreich.
 
 Erst nach ACC-Abnahme erfolgt der gestufte Rollout nach DEV/TST/PRD.