diff --git a/Dokumentation.md b/Dokumentation.md index ce16327..04dea78 100644 --- a/Dokumentation.md +++ b/Dokumentation.md @@ -2,24 +2,24 @@ ## 1. Ziel und Randbedingungen -Die Anwendung ueberwacht BizTalk Server 2020 auf Windows Server 2019 mit +Die Anwendung überwacht BizTalk Server 2020 auf Windows Server 2019 mit Checkmk 2.4. Pro Umgebung (`ACC`, `DEV`, `TST`, `PRD`) wird lokal auf dem -BizTalk-Server gesammelt. Das Checkmk-MSSQL-Plugin bleibt fuer die allgemeine -SQL-Ueberwachung zustaendig; BizTalk Checkmk Pulse liefert die +BizTalk-Server gesammelt. Das Checkmk-MSSQL-Plugin bleibt für die allgemeine +SQL-Überwachung zuständig; BizTalk Checkmk Pulse liefert die BizTalk-spezifische Laufzeit- und Berechtigungssicht. Verbindliche Randbedingungen: - Der Checkmk Windows Agent bleibt `LocalSystem`. -- `LocalSystem` erhaelt keine BizTalk-/SQL-Gruppenmitgliedschaft. -- Ein normales dediziertes AD-Servicekonto sammelt minuetlich. -- Der Agentpfad fuehrt niemals WMI- oder SQL-Abfragen aus. -- Fehler muessen als gueltige Checkmk-`UNKNOWN`-Services sichtbar werden. -- Schreiben und Lesen duerfen nie einen halben Snapshot exponieren. -- Installation und Laufzeit benoetigen keine PowerShell und keine BizTalk-DLL-Referenz. -- Installation, ACL und Scheduled Task muessen reproduzierbar sein. +- `LocalSystem` erhält keine BizTalk-/SQL-Gruppenmitgliedschaft. +- Ein normales dediziertes AD-Servicekonto sammelt minütlich. +- Der Agentpfad führt niemals WMI- oder SQL-Abfragen aus. +- Fehler müssen als gültige Checkmk-`UNKNOWN`-Services sichtbar werden. +- Schreiben und Lesen dürfen nie einen halben Snapshot exponieren. +- Installation und Laufzeit benötigen keine PowerShell und keine BizTalk-DLL-Referenz. +- Installation, ACL und Scheduled Task müssen reproduzierbar sein. -## 2. Ausloeser der Architekturanderung +## 2. Auslöser der Architekturänderung Der ACC-Agent-Dump vom 29.07.2026 bewies: @@ -31,13 +31,13 @@ Innerer Fehler: Login failed for user 'BEW\AV23AGPWBIO1$' ``` Lokales `root\MicrosoftBizTalkServer` war erreichbar. Die -datenbankgestuetzten BizTalk-WMI-Klassen scheiterten erst beim Zugriff des +datenbankgestützten BizTalk-WMI-Klassen scheiterten erst beim Zugriff des Providers auf den getrennten SQL Server. DCOM-, Firewall- oder pauschale -WMI-ACL-Aenderungen beheben diesen Befund nicht. +WMI-ACL-Änderungen beheben diesen Befund nicht. -Eine Berechtigung des Maschinenkontos haette die Netzwerkrolle allen +Eine Berechtigung des Maschinenkontos hätte die Netzwerkrolle allen `LocalSystem`-Diensten des BizTalk-Servers vermittelt. Die jetzt implementierte -Producer/Consumer-Trennung beschraenkt sie stattdessen auf ein dediziertes +Producer/Consumer-Trennung beschränkt sie stattdessen auf ein dediziertes Konto. ## 3. Architektur @@ -67,12 +67,12 @@ Konto. │ └─ local\biztalk_checkmk_pulse.cmd │ │ └─ BizTalkCheckmkPulse.exe --consume │ │ ├─ Format/Alter/Maschine/SHA-256 validieren │ -│ └─ Payload unveraendert nach STDOUT │ +│ └─ Payload unverändert nach STDOUT │ └──────────────────────────────────────────────────────────────┘ ``` Eine gemeinsame EXE implementiert beide Modi. Das reduziert -Versionsabweichungen. Die zentrale Config unter `%ProgramFiles%` gilt fuer +Versionsabweichungen. Die zentrale Config unter `%ProgramFiles%` gilt für Provider und Consumer. ### 3.1 Provider-Modus @@ -86,13 +86,13 @@ Aufruf: Ablauf: 1. Config laden und absolute Runtimepfade validieren. -2. Tageslogs gemaess `LogRetentionDays` bereinigen. +2. Tageslogs gemäß `LogRetentionDays` bereinigen. 3. exklusives Handle auf `.provider.lock` halten. -4. WMI-, SQL- und Event-Log-Probes ausfuehren. +4. WMI-, SQL- und Event-Log-Probes ausführen. 5. neun stabile und optionale dynamische Checkmk-Zeilen formatieren. -6. Snapshot in einer eindeutigen Temporaerdatei desselben Verzeichnisses +6. Snapshot in einer eindeutigen Temporärdatei desselben Verzeichnisses schreiben. -7. `Flush(true)` ausfuehren und Temporaerdatei atomar publizieren. +7. `Flush(true)` ausführen und Temporärdatei atomar publizieren. 8. Laufzeit, Zeilen- und Diagnosezahl loggen. Exitcodes: @@ -104,7 +104,7 @@ Exitcodes: | `2` | Parallelstart oder Snapshot-I/O-Fehler. | Fachliche WMI-/SQL-Fehler werden strukturiert in den Snapshot geschrieben und -muessen nicht zwingend einen Prozessfehler verursachen. So bleibt die genaue +müssen nicht zwingend einen Prozessfehler verursachen. So bleibt die genaue Fehlerkategorie in Checkmk sichtbar. ### 3.2 Consumer-Modus @@ -120,19 +120,19 @@ setzt es trotzdem explizit. Der Consumer: -- oeffnet nur den Snapshot, -- begrenzt die Dateigroesse vor dem Einlesen, +- öffnet nur den Snapshot, +- begrenzt die Dateigröße vor dem Einlesen, - validiert striktes UTF-8, - validiert Formatversion und Header, - fordert die lokale Maschinenkennung, -- berechnet SHA-256 ueber den exakten Payload, -- prueft Zeilenanzahl und Checkmk-Zeilenform, -- verwirft Zeitstempel mehr als fuenf Minuten in der Zukunft, +- berechnet SHA-256 über den exakten Payload, +- prüft Zeilenanzahl und Checkmk-Zeilenform, +- verwirft Zeitstempel mehr als fünf Minuten in der Zukunft, - verwirft Snapshots nach `SnapshotMaxAgeSeconds`, -- gibt bei Erfolg ausschliesslich den validierten Payload aus. +- gibt bei Erfolg ausschließlich den validierten Payload aus. -Er gibt immer Exitcode `0` zurueck, damit ein Fehler die komplette -Checkmk-Agentsektion nicht zerstoert. Jede Ablehnung erzeugt neun +Er gibt immer Exitcode `0` zurück, damit ein Fehler die komplette +Checkmk-Agentsektion nicht zerstört. Jede Ablehnung erzeugt neun `UNKNOWN`-Zeilen und einen Eintrag im Consumer-Log. ## 4. Snapshot-Vertrag @@ -144,33 +144,33 @@ BIZTALK_CHECKMK_PULSE_SNAPSHOT_V2 generatedUtc=2026-07-30T12:34:56.1234567Z machineBase64=QVYyM0FHUFdCSU8x identityBase64=QkVXXHN2Y19iaXp0YWxrX2NtayQ= -payloadLines=8 +payloadLines=9 payloadSha256=<64 hex characters> 0 "BizTalk Platform" - ... ... ``` -Maschine und Identitaet sind Base64-kodiert, um Zeilenumbrueche und -Trennzeichen im Header auszuschliessen. Base64 ist hier keine Verschluesselung. -Die SHA-256-Pruefung schuetzt vor unbemerkter Teil-/Fehlschreibung, nicht vor +Maschine und Identität sind Base64-kodiert, um Zeilenumbrüche und +Trennzeichen im Header auszuschließen. Base64 ist hier keine Verschlüsselung. +Die SHA-256-Prüfung schützt vor unbemerkter Teil-/Fehlschreibung, nicht vor einem lokalen Administrator. ### 4.1 Atomare Publikation -Die Temporaerdatei liegt zwingend im Snapshotverzeichnis. Dadurch findet der +Die Temporärdatei liegt zwingend im Snapshotverzeichnis. Dadurch findet der Ersatz auf demselben Volume statt. Existiert bereits ein Snapshot, wird `File.Replace` verwendet; beim ersten Lauf `File.Move`. Bis zum erfolgreichen -Ersatz bleibt der letzte vollstaendige Snapshot erhalten. Seine Alterspruefung +Ersatz bleibt der letzte vollständige Snapshot erhalten. Seine Altersprüfung verhindert unbegrenztes Weiterreichen alter Daten. ### 4.2 Keine direkte Checkmk-Spooldatei -Checkmk kann zwar Dateien aus seinem Spoolverzeichnis direkt anhaengen, prueft +Checkmk kann zwar Dateien aus seinem Spoolverzeichnis direkt anhängen, prüft deren Inhalt aber laut eigener Dokumentation nicht. Ein fehlerhafter Spool kann nachfolgende Agentsektionen beeinflussen. Deshalb liegt der Provider-Snapshot in einem eigenen Verzeichnis und wird erst durch den validierenden Consumer in -die Local-Check-Ausgabe uebernommen. +die Local-Check-Ausgabe übernommen. ## 5. Datenquellen @@ -187,11 +187,11 @@ Pflichtklassen: | Klasse | Zweck | | --- | --- | | `MSBTS_GroupSetting` | Gruppe, Read-Only-/Operator-Gruppe, Management- und Master-MessageBox-Ziel. | -| `MSBTS_HostInstance` | lokale Host-Instance-Zustaende. | +| `MSBTS_HostInstance` | lokale Host-Instance-Zustände. | | `MSBTS_ServiceInstance` | suspendierte Instanzen. | -| `MSBTS_ReceiveLocation` | Receive-Location-Zustaende. | -| `MSBTS_SendPort` | Send-Port-Zustaende. | -| `MSBTS_Orchestration` | Orchestration-Zustaende. | +| `MSBTS_ReceiveLocation` | Receive-Location-Zustände. | +| `MSBTS_SendPort` | Send-Port-Zustände. | +| `MSBTS_Orchestration` | Orchestration-Zustände. | `MSBTS_GroupSetting` wird mit den dokumentierten Properties `MgmtDbServerName`, `MgmtDbName`, `SubscriptionDBServerName`, @@ -202,10 +202,10 @@ Pflichtklassen: Hostnamen werden clientseitig verglichen. Sonderzeichen und FQDN-/Kurzname gelangen nicht in dynamisch erzeugte WQL-Filter. -`MSBTS_ServiceInstance` wird fuer `ServiceStatus=4` (resumable), +`MSBTS_ServiceInstance` wird für `ServiceStatus=4` (resumable), `ServiceStatus=32` (non-resumable) und `ServiceClass=64` abgefragt. `ServiceClass=64` kennzeichnet Routing Failure Reports. Sie werden als eigene -Metrik ausgewiesen und zugleich in `suspended_nonresumable` mitgezaehlt. +Metrik ausgewiesen und zugleich in `suspended_nonresumable` mitgezählt. ### 5.2 Kompaktes Checkmk-Servicebild @@ -222,62 +222,62 @@ Services ersetzt. Insgesamt entstehen neun stabile Services: 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 +Receive Locations und Send Ports alarmieren nur für unerwartete +Aus-Zustände. Fachlich bewusst deaktivierte Namen werden exakt, ohne Wildcards, in `ExpectedDisabledReceiveLocations` beziehungsweise `ExpectedInactiveSendPorts` hinterlegt. Ein Eintrag ist entweder nur der Name oder `Anwendung\Name`. Pro Summary werden maximal `MaxSummaryItems` Treffer angezeigt. Weitere Artefakte werden als `(+n more)` zusammengefasst. `MaxDetailCharacters` -begrenzt jede Detailausgabe, damit Checkmk-Ansichten kompakt bleiben, waehrend -alle numerischen Metriken vollstaendig erhalten bleiben. +begrenzt jede Detailausgabe, damit Checkmk-Ansichten kompakt bleiben, während +alle numerischen Metriken vollständig erhalten bleiben. ### 5.3 Endpoint-Discovery und Netzwerkprobe Die Endpoint-Funktion erweitert keine WMI-Klassenmenge. Aus den ohnehin -minuetlich abgefragten Instanzen werden nur dokumentierte Properties gelesen: +minütlich 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. +Nur `Status=Started` beziehungsweise `IsDisabled=false` wird geprüft. Inaktive Artefakte bleiben aus der Probe ausgeschlossen, auch wenn sie noch im -Katalog stehen. Dynamische Send Ports, lokale Dateipfade, SMTP-Empfaengerlisten +Katalog stehen. Dynamische Send Ports, lokale Dateipfade, SMTP-Empfängerlisten 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 +erfolgreichen Lauf erzeugt und danach standardmäßig alle 168 Stunden atomar +abgeglichen. Er enthält keine vollständigen URIs, Querystrings, +Benutzernamen oder Kennwörter, sondern nur Artefaktbezug, Adapter, Host, Port +und `TCP`/`UDP`. Automatisch erzeugte Einträge 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 +`key` muss dem Artefakteintrag entsprechen. Eigenständige 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 +HTTP(S), SFTP, FTP, UNC/SMB, WCF und `net.tcp` werden ausschließlich per +TCP-Connect geprüft. Es findet kein fachlicher Request und keine Anmeldung +statt. Explizite `udp://host:port`-Einträge senden ein einzelnes Datagramm; +das bestätigt 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. +Parallelität getestet. -Der Checkmk-Service nennt im OK-Fall nur die Gesamtzahl. Bei Ausfaellen werden -ausschliesslich die nicht erreichbaren Artefakte in `unavailable=` angezeigt; +Der Checkmk-Service nennt im OK-Fall nur die Gesamtzahl. Bei Ausfällen werden +ausschließlich die nicht erreichbaren Artefakte in `unavailable=` angezeigt; `MaxSummaryItems` und `MaxDetailCharacters` begrenzen die Darstellung. Alle -Einzelfehler bleiben vollstaendig im Provider-Log. +Einzelfehler bleiben vollständig im Provider-Log. ### 5.4 SQL-Zugriffsprobe -Der Provider oeffnet fuer Management- und Master-MessageBox-Datenbank eine +Der Provider öffnet für Management- und Master-MessageBox-Datenbank eine kurze `System.Data.SqlClient`-Verbindung mit integrierter -Windows-Authentifizierung, fuehrt `SELECT 1` aus und schliesst sie. Keine -BizTalk-Tabelle wird direkt gelesen oder veraendert. +Windows-Authentifizierung, führt `SELECT 1` aus und schließt sie. Keine +BizTalk-Tabelle wird direkt gelesen oder verändert. Die Ausgabe `execution_identity=` zeigt deshalb das Provider-Konto, nicht mehr `NT AUTHORITY\SYSTEM`. Der Check beweist, dass genau das Scheduled-Task-Konto @@ -293,10 +293,10 @@ und filtert Quellen wie `BizTalk Server`, `XLANG/s`, `ENTSSO`, ### 6.1 Bevorzugte BizTalk-Rolle -BizTalk Server 2020 fuehrte die `BizTalk Server Read Only Users`-Gruppe ein. +BizTalk Server 2020 führte die `BizTalk Server Read Only Users`-Gruppe ein. Sie darf Artefakte, Servicezustand, Message Flow und Trackinginformationen -lesen, aber keine administrativen Operationen ausfuehren. SQL-seitig wird sie -ueber `BTS_READONLY_USERS` vermittelt. +lesen, aber keine administrativen Operationen ausführen. SQL-seitig wird sie +über `BTS_READONLY_USERS` vermittelt. Soll: @@ -311,16 +311,16 @@ Die genaue Gruppe ist aus `MSBTS_GroupSetting.BizTalkReadOnlyUserGroup` beziehungsweise der BizTalk-Administration zu lesen. Nicht vom Standardnamen ausgehen. -Die Operator-Gruppe (`BTS_OPERATORS`) wird erst geprueft, wenn eine konkret +Die Operator-Gruppe (`BTS_OPERATORS`) wird erst geprüft, wenn eine konkret benannte erforderliche WMI-Klasse trotz nachgewiesener Read-Only-Konfiguration und neuem Anmeldetoken abgewiesen wird. Die Erweiterung muss mit Security, -BizTalk- und SQL-Administration begruendet werden. +BizTalk- und SQL-Administration begründet werden. -Unzulaessig: +Unzulässig: -- Checkmk-Dienstkonto aendern, +- Checkmk-Dienstkonto ändern, - Maschinenkonto pauschal berechtigen, -- individueller SQL-Login fuer das Provider-Konto, +- individueller SQL-Login für das Provider-Konto, - direkte ad-hoc DB-Rollen, - `db_owner` oder `sysadmin`, - WMI-/DCOM-Vollzugriff als Reaktion auf einen SQL-Loginfehler. @@ -328,7 +328,7 @@ Unzulaessig: ### 6.2 Dateisystem-ACL Der Installer entfernt die Vererbung an den Runtimeverzeichnissen und setzt -explizite Eintraege mit sprachneutralen Well-known-SIDs: +explizite Einträge mit sprachneutralen Well-known-SIDs: | Ziel | Collector | SYSTEM | lokale Administratoren | | --- | --- | --- | --- | @@ -337,7 +337,7 @@ explizite Eintraege mit sprachneutralen Well-known-SIDs: | `logs` | Modify | Modify | F | `LocalSystem` kann deshalb den Snapshot lesen, aber im Datenverzeichnis nicht -schreiben. Schreibrecht im Logverzeichnis wird benoetigt, um abgelehnte +schreiben. Schreibrecht im Logverzeichnis wird benötigt, um abgelehnte Snapshots aus dem Consumer-Kontext zu protokollieren. ## 7. Scheduled Task @@ -363,10 +363,10 @@ Sollkonfiguration: | StartWhenAvailable | aktiv | | Restart | zweimal im Minutenabstand | -Der Task wird mit gespeichertem Dienstkontokennwort ausgefuehrt, also -unabhaengig von einer interaktiven Anmeldung. Bei Kennwortwechsel oder +Der Task wird mit gespeichertem Dienstkontokennwort ausgeführt, also +unabhängig von einer interaktiven Anmeldung. Bei Kennwortwechsel oder -ablauf muss das Task-Kennwort aktualisiert werden. Ein gMSA ist weiterhin -optional unterstuetzt, aber nicht die produktive Standardannahme. +optional unterstützt, aber nicht die produktive Standardannahme. ## 8. Installation @@ -380,13 +380,13 @@ scripts\package-release.cmd Der Release-Build der Visual-Studio-2019-Solution baut Anwendung, grafischen Installer und Packaging-Werkzeug. Danach liegen der Paketordner `artifacts\BizTalkCheckmkPulse-Setup` und das direkt transportierbare -`artifacts\BizTalkCheckmkPulse-Setup.zip` bereit. Zusaetzlich entstehen -`BizTalkCheckmkPulse-Setup.zip.b64.txt` fuer `certutil -decode` und eine +`artifacts\BizTalkCheckmkPulse-Setup.zip` bereit. Zusätzlich entstehen +`BizTalkCheckmkPulse-Setup.zip.b64.txt` für `certutil -decode` und eine SHA-256-Textdatei. ### 8.2 Normales Servicekonto -Das ZIP wird auf dem Zielserver vollstaendig entpackt. Danach `Setup.exe` als +Das ZIP wird auf dem Zielserver vollständig entpackt. Danach `Setup.exe` als Administrator starten, Konto im Format `DOMAIN\Benutzer` (zum Beispiel `BEW\t231bizmon`), Kennwort und Umgebung eintragen und die Installation starten. @@ -396,16 +396,16 @@ AD-/BizTalk-/SQL-Rechte; diese bleiben getrennte administrative Freigaben. Beim Update wird zuerst die neue Paketversion im Staging-Verzeichnis mit neun Self-Test-Zeilen validiert. Bestehende AppSettings werden in die neue Config -uebernommen; neue Keys stammen aus der neuen Standardkonfiguration. Die +übernommen; neue Keys stammen aus der neuen Standardkonfiguration. Die Runtime-Daten unter `%ProgramData%` bleiben bestehen. Erst danach wird der Task gestoppt und die Programmversion umgeschaltet. Scheitert ein Folgeschritt, versucht der Installer Programmverzeichnis, Checkmk-Wrapper und Scheduled Task -auf den vorherigen Stand zurueckzusetzen. +auf den vorherigen Stand zurückzusetzen. -Der installierte Task selbst laeuft mit `RunLevel Limited`. Der Installer -uebergibt das Kennwort direkt an die Windows-Task-Scheduler-COM-Schnittstelle; +Der installierte Task selbst läuft mit `RunLevel Limited`. Der Installer +übergibt das Kennwort direkt an die Windows-Task-Scheduler-COM-Schnittstelle; es wird weder in einer Prozesskommandozeile noch in Config oder Log -geschrieben. Das Konto benoetigt `Log on as a batch job`. +geschrieben. Das Konto benötigt `Log on as a batch job`. ### 8.3 Optionales gMSA @@ -420,15 +420,15 @@ Der installierte Wrapper liegt unter: %ProgramData%\checkmk\agent\local\biztalk_checkmk_pulse.cmd ``` -Der Agent darf den Consumer synchron ausfuehren. Er liest nur maximal 1 MiB +Der Agent darf den Consumer synchron ausführen. Er liest nur maximal 1 MiB lokale Daten; ein Checkmk-Async-Cache ist daher nicht notwendig. Falls alte -`check_mk.user.yml`-Regeln fuer den bisherigen 300-Sekunden-Cache existieren, -sollten sie entfernt werden, damit Checkmk den minuetlich aktualisierten -Snapshot nicht zusaetzlich verzoegert. +`check_mk.user.yml`-Regeln für den bisherigen 300-Sekunden-Cache existieren, +sollten sie entfernt werden, damit Checkmk den minütlich aktualisierten +Snapshot nicht zusätzlich verzögert. Nach dem Agent-Dump: -1. Service Discovery fuer den BizTalk-Host ausfuehren. +1. Service Discovery für den BizTalk-Host ausführen. 2. neun stabile Services aufnehmen; den alten Service `BizTalk Runtime Artifacts` nach erfolgreicher Discovery entfernen. 3. Changes aktivieren. @@ -443,24 +443,24 @@ Pfad: biztalk-checkmk-pulse-YYYYMMDD.log ``` -Jede Zeile enthaelt UTC-Zeit, Level, Komponente, PID, Windows-Identitaet und +Jede Zeile enthält UTC-Zeit, Level, Komponente, PID, Windows-Identität und einzeilige Nachricht. Provider-Erfolge werden pro Lauf geloggt; der Consumer loggt nur abgelehnte Snapshots. Exceptions werden mit Typ, Nachricht, HRESULT-/Providerdetails und Stacktrace einzeilig gespeichert. Der erfolgreiche Abschluss nennt Suspensions, Routing Failure Reports, Receive-Location-/Send-Port-Zahlen und Laufzeit. Jede strukturierte -WMI-/SQL-/Event-Log-Diagnose wird zusaetzlich als eigene `WARN`-Zeile -protokolliert und bleibt damit auch ausserhalb der gekuerzten Checkmk-Summary -vollstaendig nachvollziehbar. +WMI-/SQL-/Event-Log-Diagnose wird zusätzlich als eigene `WARN`-Zeile +protokolliert und bleibt damit auch außerhalb der gekürzten Checkmk-Summary +vollständig nachvollziehbar. Logging ist best effort: Ein blockiertes Log darf Checkmk-Ausgabe oder -Snapshot-Publikation nicht zerstoeren. Der Provider entfernt beim Start Dateien -aelter als `LogRetentionDays`. +Snapshot-Publikation nicht zerstören. Der Provider entfernt beim Start Dateien +älter als `LogRetentionDays`. ## 10. Diagnose und Runbook -### 10.1 Grundpruefung +### 10.1 Grundprüfung ```cmd schtasks.exe /query /tn "BizTalk Checkmk Pulse Provider" /v /fo list @@ -472,42 +472,42 @@ type "%ProgramData%\BizTalkCheckmkPulse\logs\biztalk-checkmk-pulse-*.log" ### 10.2 Kein Snapshot -Pruefen: +Prüfen: 1. Task existiert und ist aktiviert. 2. `LastTaskResult` und Provider-Log. 3. Dienstkonto kann sich als Batch anmelden. -4. gespeichertes Task-Kennwort ist nach Rotation/Ablauf noch gueltig. +4. gespeichertes Task-Kennwort ist nach Rotation/Ablauf noch gültig. 5. Provider besitzt Modify auf `data` und `logs`. -6. EXE/Config sind ausfuehrbar. +6. EXE/Config sind ausführbar. ### 10.3 Staler Snapshot Der Consumer nennt Alter und Grenzwert. Ursachen: -- Task deaktiviert oder Konto/Kennwort ungueltig, -- vorheriger Lauf haengt, +- Task deaktiviert oder Konto/Kennwort ungültig, +- vorheriger Lauf hängt, - WMI-/SQL-Timeouts, -- Task Scheduler lief waehrend Wartung nicht, +- Task Scheduler lief während Wartung nicht, - Snapshot-Publikation wird durch AV/EDR oder ACL blockiert. -Nicht einfach `SnapshotMaxAgeSeconds` stark erhoehen. Zuerst den minuetlichen +Nicht einfach `SnapshotMaxAgeSeconds` stark erhöhen. Zuerst den minütlichen Lauf wiederherstellen. Bei geplanten Wartungen darf Checkmk bewusst `UNKNOWN` anzeigen. ### 10.4 SHA-256-/Formatfehler Snapshot nicht reparieren oder direkt an Checkmk kopieren. Task neu starten, -Datentraeger und AV/EDR pruefen. Wiederholt sich der Fehler, Temporaerdateien, +Datenträger und AV/EDR prüfen. Wiederholt sich der Fehler, Temporärdateien, NTFS-Ereignisse und Schreibrechte untersuchen. ### 10.5 BizTalk-/SQL-Permission 1. Log zeigt `execution_identity` des Providers. 2. `BizTalkReadOnlyUserGroup` gegen BizTalk-Konfiguration abgleichen. -3. AD-Gruppenmitgliedschaft des Provider-Kontos pruefen. +3. AD-Gruppenmitgliedschaft des Provider-Kontos prüfen. 4. neuen Logontoken durch neuen Tasklauf sicherstellen. -5. SQL-seitig Gruppenlogin und `BTS_READONLY_USERS` read-only pruefen. +5. SQL-seitig Gruppenlogin und `BTS_READONLY_USERS` read-only prüfen. 6. keine Einzelrechte erteilen. 7. Nur wenn eine spezifische Klasse weiter abgewiesen wird, Read-Only-Umfang mit Microsoft-Dokumentation und BizTalk-Betrieb abgleichen; Operator-Rolle @@ -516,8 +516,8 @@ NTFS-Ereignisse und Schreibrechte untersuchen. ### 10.6 WMI-Schema `InvalidClass` oder `InvalidQuery` wird als `Wmi/Schema` klassifiziert. -Berechtigungserhoehung kann eine nicht vorhandene Klasse nicht erzeugen. -Installierte BizTalk-Version, WQL und Properties pruefen. +Berechtigungserhöhung kann eine nicht vorhandene Klasse nicht erzeugen. +Installierte BizTalk-Version, WQL und Properties prüfen. ## 11. Konfiguration @@ -583,47 +583,47 @@ Automatisiert: - WMI-Queryvertrag nutzt dokumentierte Properties, - eingebetteter SQL-Loginfehler wird `Permission`, - abgewiesener Principal wird extrahiert, -- Routing Failure Reports werden separat und als non-resumable gezaehlt, -- Receive-/Send-Allowlisten trennen bewusste von unerwarteten Aus-Zustaenden, +- Routing Failure Reports werden separat und als non-resumable gezählt, +- Receive-/Send-Allowlisten trennen bewusste von unerwarteten Aus-Zuständen, - ein fehlender `IsDisabled`-Wert wird `UNKNOWN` statt still als enabled, -- betroffene Namen und Gesamtlaenge der Summary bleiben begrenzt, +- betroffene Namen und Gesamtlänge der Summary bleiben begrenzt, - Endpoint-Adressen werden ohne URI-Secrets auf Host/Port reduziert, -- manuelle Endpoint-Overrides ueberleben den automatischen Wochenabgleich, +- manuelle Endpoint-Overrides überleben den automatischen Wochenabgleich, - nur nicht erreichbare Endpoints erscheinen im Checkmk-Detail, -- 70 vollstaendig timeoutende eindeutige Ziele bleiben mit den Defaults in +- 70 vollständig timeoutende eindeutige Ziele bleiben mit den Defaults in einem theoretischen Socket-Budget von etwa 15 Sekunden; das konfigurierte Maximum von 100 Zielen in etwa 21 Sekunden, -- Update-Config-Merge erhaelt bestehende Werte und fuegt neue Defaults hinzu, +- Update-Config-Merge erhält bestehende Werte und fügt neue Defaults hinzu, - Snapshot-Roundtrip und Ersatz, - SHA-256-Manipulation wird verworfen, - Stale-Snapshot wird verworfen, -- Consumer-Fallback enthaelt neun `UNKNOWN`-Services. +- Consumer-Fallback enthält neun `UNKNOWN`-Services. Windows-/ACC-Abnahme: 1. `LastTaskResult=0`. -2. Snapshot wird mindestens dreimal minuetlich aktualisiert. +2. Snapshot wird mindestens dreimal minütlich aktualisiert. 3. Provider-Log nennt das dedizierte Konto. 4. `BizTalk Platform` zeigt `read_only_group=`. 5. `BizTalk SQL Access`: `targets=2`, `available=2`. 6. keine Permission-`UNKNOWN`s. 7. Suspensionsmetriken mit der BizTalk Group Hub Page plausibilisieren, - einschliesslich Routing Failure Reports. + einschließlich Routing Failure Reports. 8. Eine bewusst deaktivierte Receive Location und einen inaktiven Send Port - ueber die exakten Allowlisten als expected bestaetigen. + über die exakten Allowlisten als expected bestätigen. 9. Einen Testnamen aus der Allowlist entfernen und den erwarteten CRIT mit - kurzem `affected=`-Detail pruefen. + kurzem `affected=`-Detail prüfen. 10. ACL-Test: `LocalSystem` kann Snapshot lesen, nicht schreiben. -11. `endpoints.xml` wurde erzeugt; sie enthaelt keine vollstaendigen URIs oder +11. `endpoints.xml` wurde erzeugt; sie enthält keine vollständigen 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 + und nennt ausschließlich das nicht erreichbare Ziel. +13. Ein Artefakt stoppen/deaktivieren: es wird im nächsten Minutenlauf nicht + mehr geprüft. +14. Katalogzeit auf älter 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. +16. Task wieder aktivieren: nächster Snapshot stellt Echtzustand her. 17. Agent-Dump und Checkmk Service Discovery erfolgreich. Erst nach ACC-Abnahme erfolgt der gestufte Rollout nach DEV/TST/PRD. @@ -631,9 +631,9 @@ Erst nach ACC-Abnahme erfolgt der gestufte Rollout nach DEV/TST/PRD. ## 13. Deinstallation und Rollback `Setup.exe` aus dem entpackten Paket erneut starten und **Deinstallieren** -waehlen. Der Installer entfernt Task, Wrapper und Programmdateien, behaelt +wählen. Der Installer entfernt Task, Wrapper und Programmdateien, behält Logs und Snapshot aber absichtlich bei. Die AD-Gruppenmitgliedschaft wird -nicht geaendert und separat nach Change-Verfahren entzogen. +nicht geändert und separat nach Change-Verfahren entzogen. Rollback auf die alte direkte `LocalSystem`-Architektur ist nicht empfohlen. Falls kurzfristig notwendig, muss Security die Maschinenkonto-Berechtigung diff --git a/README.md b/README.md index 380fa4d..5b22d6a 100644 --- a/README.md +++ b/README.md @@ -1,49 +1,49 @@ # BizTalk Checkmk Pulse -`BizTalk Checkmk Pulse` ist ein robuster Checkmk-2.4-Local-Check fuer Microsoft +`BizTalk Checkmk Pulse` ist ein robuster Checkmk-2.4-Local-Check für Microsoft BizTalk Server 2020 auf Windows Server 2019. Die Anwendung trennt den -berechtigten BizTalk-Datenzugriff vollstaendig vom Checkmk-Agenten: +berechtigten BizTalk-Datenzugriff vollständig vom Checkmk-Agenten: ![Architektur von BizTalk Checkmk Pulse mit Provider, Endpoint-Probes, Snapshot und Checkmk-Consumer](docs/architecture.svg) Damit bekommt `LocalSystem` keine BizTalk- oder SQL-Berechtigung. Nur das dedizierte Provider-Konto wird in die konfigurierte BizTalk Server Read Only Users-Gruppe aufgenommen. Der Checkmk-Consumer liest keine BizTalk-Datenbank, -verwendet kein WMI und nimmt keine Identitaetswechsel vor. +verwendet kein WMI und nimmt keine Identitätswechsel vor. -## Endpoint-Erreichbarkeitspruefung +## Endpoint-Erreichbarkeitsprüfung -Der Provider prueft die netzwerktechnische Erreichbarkeit der externen Ziele +Der Provider prüft die netzwerktechnische Erreichbarkeit der externen Ziele aktiver BizTalk Send Ports und Receive Locations. Die Funktion ist im eigenen Checkmk-Service `BizTalk Endpoint Reachability` zusammengefasst: -- Beruecksichtigt werden nur Send Ports mit `Status=Started` und Receive +- Berücksichtigt werden nur Send Ports mit `Status=Started` und Receive Locations mit `IsDisabled=false`. Dynamische Send Ports werden nicht als statisches Ziel interpretiert. - Fehlt der lokale Endpoint-Katalog, wird er aus den bereits gelesenen `MSBTS_SendPort`- und `MSBTS_ReceiveLocation`-Daten aufgebaut. Alle - 168 Stunden erfolgt ein vollstaendiger Abgleich mit der BizTalk-Umgebung. + 168 Stunden erfolgt ein vollständiger Abgleich mit der BizTalk-Umgebung. - HTTP(S), SFTP, FTP, WCF/`net.tcp` und UNC/SMB werden durch einen reinen - TCP-Verbindungsaufbau zu Host und Port geprueft. Explizite + TCP-Verbindungsaufbau zu Host und Port geprüft. Explizite `udp://host:port`-Ziele verwenden ein UDP-Datagramm. - Es werden weder HTTP-Aufrufe noch Anmeldungen, fachliche Requests oder BizTalk-Nachrichten gesendet. Der Check validiert DNS, Netzwerkpfad, Firewall und bei TCP einen annehmenden Zielport, nicht die fachliche Funktion des entfernten Dienstes. - Im OK-Fall meldet Checkmk nur, dass alle aktiven Endpunkte erreichbar sind. - Bei einem Fehler werden ausschliesslich die nicht erreichbaren Endpunkte - ausgegeben; lange Listen sind begrenzt, die Metriken bleiben vollstaendig. + Bei einem Fehler werden ausschließlich die nicht erreichbaren Endpunkte + ausgegeben; lange Listen sind begrenzt, die Metriken bleiben vollständig. - Doppelte Protokoll-/Host-/Port-Ziele werden nur einmal verbunden. Mit den Defaults - benoetigen 70 vollstaendig timeoutende eindeutige Ziele theoretisch etwa + benötigen 70 vollständig timeoutende eindeutige Ziele theoretisch etwa 15 Sekunden; die harte Standardgrenze von 100 Zielen liegt bei etwa 21 Sekunden. -Der Checkmk-Agent fuehrt diese Netzwerkprobes nicht selbst aus. Er liest als -`LocalSystem` weiterhin ausschliesslich den validierten lokalen Snapshot. +Der Checkmk-Agent führt diese Netzwerkprobes nicht selbst aus. Er liest als +`LocalSystem` weiterhin ausschließlich den validierten lokalen Snapshot. Details zum Katalog und zu manuellen Overrides stehen in [docs/EndpointCatalog.md](docs/EndpointCatalog.md). -## Warum die Architektur geaendert wurde +## Warum die Architektur geändert wurde Der ACC-Test vom 29.07.2026 zeigte: @@ -52,44 +52,44 @@ Login failed for user 'BEW\AV23AGPWBIO1$' ``` Der Checkmk-Agent lief korrekt als `NT AUTHORITY\SYSTEM` und erreichte lokales -BizTalk-WMI. Datenbankgestuetzte WMI-Abfragen wurden jedoch am SQL Server als +BizTalk-WMI. Datenbankgestützte WMI-Abfragen wurden jedoch am SQL Server als Maschinenkonto `BEW\AV23AGPWBIO1$` abgewiesen. Eine Mitgliedschaft des -Computerkontos wuerde die BizTalk-Netzwerkberechtigung allen als `LocalSystem` +Computerkontos würde die BizTalk-Netzwerkberechtigung allen als `LocalSystem` laufenden Diensten des Servers geben. -Die neue Trennung reduziert diesen Berechtigungsumfang. Fuer BizTalk Server +Die neue Trennung reduziert diesen Berechtigungsumfang. Für BizTalk Server 2020 ist die konfigurierte `BizTalk Server Read Only Users`-Gruppe mit der SQL-Datenbankrolle `BTS_READONLY_USERS` die bevorzugte Grenze. Die `BizTalk Server Operators`-Gruppe ist nur ein dokumentierter Fallback, wenn -eine konkret benoetigte WMI-Klasse trotz bestaetigter Read-Only-Zuordnung +eine konkret benötigte WMI-Klasse trotz bestätigter Read-Only-Zuordnung abgewiesen wird. Direkte SQL-Logins, manuelle Datenbankrollen und `sysadmin` -sind keine Loesung. +sind keine Lösung. ## Robustheit Der Datenaustausch ist bewusst defensiv: -- Der Provider schreibt zuerst eine eindeutige Temporaerdatei im Zielordner, +- Der Provider schreibt zuerst eine eindeutige Temporärdatei im Zielordner, leert Betriebssystempuffer und ersetzt danach den Snapshot atomar. -- Der Snapshot enthaelt Formatversion, UTC-Zeit, Quellmaschine, - Provider-Identitaet, Zeilenanzahl und SHA-256 des Payloads. -- Der Consumer akzeptiert nur denselben Rechner, gueltiges UTF-8, intakte - Checkmk-Zeilen, korrekte SHA-256-Pruefsumme und ein maximales Alter von - standardmaessig 180 Sekunden. +- Der Snapshot enthält Formatversion, UTC-Zeit, Quellmaschine, + Provider-Identität, Zeilenanzahl und SHA-256 des Payloads. +- Der Consumer akzeptiert nur denselben Rechner, gültiges UTF-8, intakte + Checkmk-Zeilen, korrekte SHA-256-Prüfsumme und ein maximales Alter von + standardmäßig 180 Sekunden. - Fehlende, veraltete, abgeschnittene, manipulierte oder unlesbare Dateien - ergeben neun gueltige `UNKNOWN`-Services statt einer kaputten Agent-Ausgabe. + ergeben neun gültige `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 + überlappende Providerläufe. +- Ein unerwarteter Providerfehler erzeugt nach Möglichkeit einen aktuellen `UNKNOWN`-Snapshot und einen ungleich null lautenden Task-Exitcode. -- Provider und Consumer protokollieren in taegliche Dateien; die Aufbewahrung - ist standardmaessig 30 Tage. -- Snapshotgroesse, WMI-/SQL-Timeouts, Log-Retention und Stale-Grenze sind +- Provider und Consumer protokollieren in tägliche Dateien; die Aufbewahrung + ist standardmäßig 30 Tage. +- Snapshotgröße, WMI-/SQL-Timeouts, Log-Retention und Stale-Grenze sind begrenzt und konfigurierbar. ## Erzeugte Services -Standardmaessig entstehen: +Standardmäßig entstehen: - `BizTalk Platform` - `BizTalk SQL Access` @@ -108,27 +108,27 @@ Zustand und Graphen direkt erkennbar, ohne eine lange Sammelzeile zu lesen: - 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 + eine Gesamtaussage, im Fehlerfall ausschließlich nicht erreichbare Ziele - Orchestrations: total, started, stopped, bound, unbound und unbekannt -Der Provider nutzt fuer die Endpoint-Discovery keine neue WMI-Klasse. Er liest +Der Provider nutzt für 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 +geprüft; 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 +nächsten erfolgreichen Providerlauf erstellt. Alle 168 Stunden wird er gegen +die Umgebung abgeglichen. Automatisch verwaltete Einträge für inzwischen inaktive Artefakte verschwinden beim Abgleich; bei jedem Minutenlauf werden -sie zusaetzlich gegen den aktuellen Started-/Enabled-Zustand gefiltert. +sie zusätzlich 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. +Pro Service werden standardmäßig maximal fünf betroffene Namen gezeigt. +Weitere Treffer erscheinen nur als `(+n more)`; Details sind zusätzlich auf +1600 Zeichen begrenzt. Metriken bleiben trotzdem vollständig. Mit `EnvironmentName=ACC`, `DEV`, `TST` oder `PRD` wird die Umgebung in den Servicenamen aufgenommen, zum Beispiel `BizTalk ACC Platform`. @@ -155,21 +155,21 @@ BizTalk-Server: `root\MicrosoftBizTalkServer` - .NET Framework 4.7.2 - Checkmk Windows Agent -- administrativer Zugriff fuer die einmalige Installation -- normales dediziertes AD-Servicekonto fuer den Provider +- administrativer Zugriff für die einmalige Installation +- normales dediziertes AD-Servicekonto für den Provider -Das Provider-Konto benoetigt: +Das Provider-Konto benötigt: -- lokales Recht zur Ausfuehrung als Scheduled Task -- lokalen Lese-/Ausfuehrungszugriff auf die installierte EXE +- lokales Recht zur Ausführung als Scheduled Task +- lokalen Lese-/Ausführungszugriff auf die installierte EXE - Schreibzugriff nur auf Snapshot- und Logverzeichnis - Mitgliedschaft in der exakt konfigurierten BizTalk Server Read Only Users-Gruppe Es soll weder lokaler Administrator noch SQL-`sysadmin` sein. Der Scheduled -Task laeuft mit `RunLevel Limited`. Das Servicekonto braucht ein gespeichertes +Task läuft mit `RunLevel Limited`. Das Servicekonto braucht ein gespeichertes Task-Kennwort und das Recht `Log on as a batch job`. Ein gMSA bleibt optional, -ist aber fuer diese Installation nicht vorausgesetzt. +ist aber für diese Installation nicht vorausgesetzt. ## Build und Tests @@ -197,8 +197,8 @@ artifacts\ ``` Das Packaging-Projekt ist Teil von `BizTalkCheckmkPulse.sln`. Ein normaler -`Release`-Build in Visual Studio 2019 genuegt daher; ein separates -PowerShell-/WiX-/MSI-Tooling wird nicht benoetigt. +`Release`-Build in Visual Studio 2019 genügt daher; ein separates +PowerShell-/WiX-/MSI-Tooling wird nicht benötigt. Die Base64-TXT kann auf dem Windows-Zielsystem ohne Zusatzwerkzeug dekodiert werden: @@ -214,10 +214,10 @@ Format-Self-Test ohne WMI, SQL oder Event Log: artifacts\BizTalkCheckmkPulse-Setup\application\BizTalkCheckmkPulse.exe --self-test ``` -Erwartet werden exakt neun `OK`-Zeilen. Die Regressionstests pruefen -zusaetzlich Snapshot-Roundtrip, atomaren Ersatz, SHA-256-Manipulation, +Erwartet werden exakt neun `OK`-Zeilen. Die Regressionstests prüfen +zusätzlich 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 +Ein Mono-Build ist eine hilfreiche Quellcodeprüfung, ersetzt aber nicht die Windows-/BizTalk-Laufzeitvalidierung. ## Berechtigung vorbereiten @@ -233,48 +233,48 @@ Die BizTalk-Konfiguration muss die Domain-Gruppe bereits als Windows-Login und in `BizTalkMgmtDb`, `BizTalkMsgBoxDb`, `BizTalkDTADb`, `BizTalkRuleEngineDb` sowie gegebenenfalls `BAMPrimaryImport` mit `BTS_READONLY_USERS` abbilden. Eine fehlende Abbildung wird durch BizTalk- und -SQL-Administration fuer die Gruppe repariert, nicht als Einzelberechtigung -fuer das Provider-Konto. +SQL-Administration für die Gruppe repariert, nicht als Einzelberechtigung +für das Provider-Konto. ## Installation mit normalem Servicekonto -1. `BizTalkCheckmkPulse-Setup.zip` auf dem Zielserver vollstaendig entpacken. -2. `Setup.exe` starten und die UAC-Abfrage bestaetigen. +1. `BizTalkCheckmkPulse-Setup.zip` auf dem Zielserver vollständig entpacken. +2. `Setup.exe` starten und die UAC-Abfrage bestätigen. 3. Collector-Konto, zum Beispiel `BEW\t231bizmon`, Kennwort und Umgebung eingeben. -4. **Installieren / aktualisieren** waehlen. +4. **Installieren / aktualisieren** wählen. -Der Installer uebergibt das Kennwort direkt ueber die Windows-Task-Scheduler- +Der Installer übergibt das Kennwort direkt über die Windows-Task-Scheduler- COM-Schnittstelle. Es steht weder in einer Prozesskommandozeile noch in der Konfigurationsdatei oder in Logs. Der Backslash in `DOMAIN\Benutzer` wird als normaler Bestandteil des Kontonamens verarbeitet. -Wenn das Kennwort rotiert oder ablaeuft, muss es im Scheduled Task aktualisiert -werden. Dazu `Setup.exe` mit dem neuen Kennwort erneut ausfuehren. Bis dahin +Wenn das Kennwort rotiert oder abläuft, muss es im Scheduled Task aktualisiert +werden. Dazu `Setup.exe` mit dem neuen Kennwort erneut ausführen. Bis dahin wird der Snapshot nach 180 Sekunden stale und Checkmk zeigt alle neun Services als `UNKNOWN`. -Ein gMSA kann ueber die Checkbox ohne Kennworteingabe installiert werden; die +Ein gMSA kann über die Checkbox ohne Kennworteingabe installiert werden; die produktive Standardbeschreibung geht vom normalen Servicekonto aus. Der Installer: -1. prueft Paket und neun Self-Test-Zeilen, bevor der bestehende Task angehalten +1. prüft Paket und neun Self-Test-Zeilen, bevor der bestehende Task angehalten wird, -2. baut die neue Version in einem Staging-Verzeichnis auf und uebernimmt +2. baut die neue Version in einem Staging-Verzeichnis auf und übernimmt vorhandene AppSettings; neue Keys erhalten ihre neuen Defaults. Die alten - unveraenderten Endpoint-Defaults `12`/`500` werden auf `16`/`100` migriert, + unveränderten Endpoint-Defaults `12`/`500` werden auf `16`/`100` migriert, 3. schaltet die Programmdateien per Verzeichniswechsel um; bei einem Fehler werden vorherige Version, Wrapper und Task best effort wiederhergestellt, -4. behaelt `%ProgramData%\BizTalkCheckmkPulse` mit Endpoint-Katalog, Snapshot +4. behält `%ProgramData%\BizTalkCheckmkPulse` mit Endpoint-Katalog, Snapshot und Logs bei, 5. installiert EXE und Config nach `%ProgramFiles%\BizTalkCheckmkPulse`, -6. setzt explizite ACLs fuer Administratoren, Provider und `LocalSystem`, +6. setzt explizite ACLs für Administratoren, Provider und `LocalSystem`, 7. installiert nur den kleinen `.cmd`-Consumer unter `%ProgramData%\checkmk\agent\local`, -8. registriert `BizTalk Checkmk Pulse Provider` minuetlich mit - `IgnoreNew`, fuenf Minuten Laufzeitlimit und zwei Wiederholungen, -9. fuehrt den installierten Self-Test erneut aus und startet den Provider. +8. registriert `BizTalk Checkmk Pulse Provider` minütlich mit + `IgnoreNew`, fünf Minuten Laufzeitlimit und zwei Wiederholungen, +9. führt den installierten Self-Test erneut aus und startet den Provider. Installation, Update, Deinstallation und Laufzeit verwenden keine PowerShell. @@ -306,8 +306,8 @@ Verbindlicher Test im echten `LocalSystem`-Kontext: "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" dump ``` -Danach in Checkmk eine Service Discovery ausfuehren, die neun Services -aufnehmen und Changes aktivieren. Ein zusaetzlicher Checkmk-Async-Cache ist +Danach in Checkmk eine Service Discovery ausführen, die neun Services +aufnehmen und Changes aktivieren. Ein zusätzlicher Checkmk-Async-Cache ist nicht erforderlich: Der Consumer liest nur eine kleine lokale Datei und der Provider besitzt bereits seinen eigenen Minutentakt. @@ -334,13 +334,13 @@ ACL-Soll: | Pfad | Provider | LocalSystem | Administratoren | | --- | --- | --- | --- | -| Programm | Lesen/Ausfuehren | Lesen/Ausfuehren | Vollzugriff | -| `data` | Aendern | Lesen/Ausfuehren | Vollzugriff | -| `logs` | Aendern | Aendern | Vollzugriff | +| Programm | Lesen/Ausführen | Lesen/Ausführen | Vollzugriff | +| `data` | Ändern | Lesen/Ausführen | Vollzugriff | +| `logs` | Ändern | Ändern | Vollzugriff | -Der Snapshot enthaelt Monitoringzustand und kompakte Fehlerdetails, aber keine -Passwoerter oder Nachrichteninhalte. Der Consumer validiert die Datei trotzdem -vollstaendig, bevor er sie an Checkmk weitergibt. +Der Snapshot enthält Monitoringzustand und kompakte Fehlerdetails, aber keine +Passwörter oder Nachrichteninhalte. Der Consumer validiert die Datei trotzdem +vollständig, bevor er sie an Checkmk weitergibt. ## Konfiguration @@ -357,12 +357,12 @@ Wichtige Werte: | `EnvironmentName` | leer | Optional `ACC`, `DEV`, `TST`, `PRD`. | | `SnapshotPath` | `%ProgramData%\BizTalkCheckmkPulse\data\...` | Gemeinsame Provider-/Consumer-Datei. | | `SnapshotMaxAgeSeconds` | `180` | Ab diesem Alter liefert der Consumer `UNKNOWN`. | -| `SnapshotMaxBytes` | `1048576` | Harte Eingabegroesse fuer den Consumer. | +| `SnapshotMaxBytes` | `1048576` | Harte Eingabegröße für den Consumer. | | `LogDirectory` | `%ProgramData%\BizTalkCheckmkPulse\logs` | Tageslogs. | -| `LogRetentionDays` | `30` | Provider bereinigt aeltere Logs. | +| `LogRetentionDays` | `30` | Provider bereinigt ältere 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. | +| `EndpointCatalogPath` | `%ProgramData%\BizTalkCheckmkPulse\data\endpoints.xml` | Lokal gepflegte Endpoint-Konfiguration ohne vollständige URIs/Secrets. | +| `EndpointDiscoveryIntervalHours` | `168` | Intervall für den vollständigen Umgebungsabgleich. | | `EndpointProbeTimeoutMilliseconds` | `3000` | Timeout je dedupliziertem Host/Port-Ziel. | | `EndpointProbeMaxConcurrency` | `16` | Begrenzte parallele Socket-Probes. | | `EndpointMaxCount` | `100` | Harte Obergrenze und Laufzeitbudget; bei 3 s Timeout theoretisch maximal etwa 21 s. | @@ -374,40 +374,40 @@ Wichtige Werte: | `AlertOnArtifactRuntimeIssues` | `true` | Unerwartet deaktivierte Receive Locations bzw. inaktive Send Ports werden CRIT. | | `ExpectedDisabledReceiveLocations` | leer | Pipe-getrennte exakte Allowlist: `Name` oder `Anwendung\Name`. | | `ExpectedInactiveSendPorts` | leer | Pipe-getrennte exakte Allowlist: `Name` oder `Anwendung\Name`. | -| `AlertOnInactiveOrchestrations` | `false` | Optional WARN fuer stopped/bound/unbound Orchestrations. | +| `AlertOnInactiveOrchestrations` | `false` | Optional WARN für stopped/bound/unbound Orchestrations. | | `MaxSummaryItems` | `5` | Maximal angezeigte betroffene Artefakte je Service. | -| `MaxDetailCharacters` | `1600` | Harte Obergrenze fuer Checkmk-Summary. | -| `EmitPerApplicationSuspensionServices` | `false` | Zusaetzliche Anwendungsservices. | +| `MaxDetailCharacters` | `1600` | Harte Obergrenze für Checkmk-Summary. | +| `EmitPerApplicationSuspensionServices` | `false` | Zusätzliche Anwendungsservices. | | `EventLogLookbackMinutes` | `60` | Event-Log-Zeitfenster des Providers. | -Nach einer Config-Aenderung den Scheduled Task manuell starten. Der Consumer -liest den naechsten atomar publizierten Snapshot. +Nach einer Config-Änderung den Scheduled Task manuell starten. Der Consumer +liest den nächsten atomar publizierten Snapshot. ## Fehlerbilder -| Beobachtung | Ursache / Massnahme | +| Beobachtung | Ursache / Maßnahme | | --- | --- | -| 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. | +| Alle neun Services melden fehlenden Snapshot | Task, Provider-Log, Task-Konto/Kennwort und ACL prüfen. | +| Snapshot ist `stale` | `LastTaskResult`, Laufzeit, WMI-/SQL-Timeout und Log prüfen. | +| SHA-256 oder Format ungültig | Datei nicht manuell bearbeiten; Datenträger/AV und Schreibpfad prüfen, Task neu starten. | +| Provider meldet `Login failed` | Provider-Konto und exakt konfigurierte Read-Only-Gruppe sowie `BTS_READONLY_USERS` prüfen. | +| Receive Locations / Send Ports sind CRIT | `affected=` prüfen; nur fachlich bewusst inaktive Namen exakt in die jeweilige Allowlist aufnehmen. | +| Endpoint Reachability ist CRIT | Nur `unavailable=` prüfen; DNS, Zielport, Firewall und externen Dienst kontrollieren. | +| Endpoint Reachability ist UNKNOWN | WMI-Vollständigkeit, `endpoints.xml`, wöchentlichen Refresh und nicht automatisch auflösbare externe Adapteradresse prüfen. | +| `Wmi/Schema` | Klasse/Properties gegen BizTalk-2020-Schema prüfen; keine Rechte ausweiten. | +| Nur Event Log `UNKNOWN` | lokalen Application-Log-Zugriff des Provider-Kontos prüfen. | +| Task-Result `2` | Parallelstart oder Snapshot-I/O; Log und Lock/ACL prüfen. | -Ausfuehrliche Betriebs- und Architekturdetails stehen in +Ausführliche Betriebs- und Architekturdetails stehen in [Dokumentation.md](Dokumentation.md). ## Deinstallation -`Setup.exe` erneut starten und **Deinstallieren** waehlen. Snapshot und Logs +`Setup.exe` erneut starten und **Deinstallieren** wählen. Snapshot und Logs bleiben dabei unter `%ProgramData%\BizTalkCheckmkPulse` erhalten. Die AD-Gruppenmitgliedschaft des Provider-Kontos wird bewusst nicht automatisch -geaendert und muss separat durch AD-/BizTalk-Administration entfernt werden. +geändert und muss separat durch AD-/BizTalk-Administration entfernt werden. ## Quellen diff --git a/deployment/INSTALLATION.md b/deployment/INSTALLATION.md index fedb536..1196a72 100644 --- a/deployment/INSTALLATION.md +++ b/deployment/INSTALLATION.md @@ -1,47 +1,47 @@ # Installation auf dem BizTalk-Server -Falls nur die TXT-Datei uebertragen wurde: +Falls nur die TXT-Datei übertragen wurde: ```cmd certutil -decode BizTalkCheckmkPulse-Setup.zip.b64.txt BizTalkCheckmkPulse-Setup.zip certutil -hashfile BizTalkCheckmkPulse-Setup.zip SHA256 ``` -1. `BizTalkCheckmkPulse-Setup.zip` vollstaendig in ein lokales Verzeichnis entpacken. -2. `Setup.exe` als lokaler Administrator starten und die UAC-Abfrage bestaetigen. +1. `BizTalkCheckmkPulse-Setup.zip` vollständig in ein lokales Verzeichnis entpacken. +2. `Setup.exe` als lokaler Administrator starten und die UAC-Abfrage bestätigen. 3. Das Collector-Konto im Format `DOMAIN\Benutzer` eingeben, zum Beispiel `BEW\t231bizmon`. -4. Kennwort und Umgebung eingeben und **Installieren / aktualisieren** waehlen. +4. Kennwort und Umgebung eingeben und **Installieren / aktualisieren** wählen. 5. Im Aufgabenplaner den Task `BizTalk Checkmk Pulse Provider` und danach den Checkmk-Agent-Dump kontrollieren. Bei einer bereits vorhandenen ACC-Installation ist dies ein Update. Der -Installer erkennt die bestehende Umgebung, behaelt Endpoint-Katalog, Snapshot -und Logs sowie vorhandene AppSettings bei und ergaenzt neue Config-Keys aus dem -Paket. Das BEW-Konto und sein aktuelles Kennwort muessen erneut eingegeben -werden, weil der Scheduled Task mit den bestaetigten Zugangsdaten neu +Installer erkennt die bestehende Umgebung, behält Endpoint-Katalog, Snapshot +und Logs sowie vorhandene AppSettings bei und ergänzt neue Config-Keys aus dem +Paket. Das BEW-Konto und sein aktuelles Kennwort müssen erneut eingegeben +werden, weil der Scheduled Task mit den bestätigten Zugangsdaten neu registriert wird. -Die frueheren unveraenderten Endpoint-Defaults `12` parallele Probes und +Die früheren unveränderten Endpoint-Defaults `12` parallele Probes und `EndpointMaxCount=500` werden beim Update auf `16` beziehungsweise `100` migriert. Abweichende, bewusst konfigurierte Werte bleiben erhalten. Vor dem Stoppen des vorhandenen Tasks wird die neue Version separat getestet. -Bei normalen Servicekonten prueft der Installer ausserdem Kennwort und +Bei normalen Servicekonten prüft der Installer außerdem Kennwort und Batch-Anmelderecht vor der Umschaltung. Der Task wird vor dem Dateitausch deaktiviert und sein Prozessende maximal zehn -Sekunden abgewartet, damit keine laufende Provider-EXE ueberschrieben wird. +Sekunden abgewartet, damit keine laufende Provider-EXE überschrieben wird. Bei einem Fehler nach der Umschaltung versucht der Installer, vorherige Programmdateien, Wrapper und Task wiederherzustellen. -PowerShell wird fuer Installation, Update, Deinstallation und Laufzeit nicht -benoetigt. Das Kennwort wird direkt an die Windows-Aufgabenplanung uebergeben +PowerShell wird für Installation, Update, Deinstallation und Laufzeit nicht +benötigt. Das Kennwort wird direkt an die Windows-Aufgabenplanung übergeben und weder in einer Datei noch in einer Prozesskommandozeile abgelegt. Der Installer vergibt keine AD-, BizTalk- oder SQL-Berechtigungen. Das Konto -muss separat Mitglied der fuer die BizTalk-Gruppe konfigurierten Read-Only- +muss separat Mitglied der für die BizTalk-Gruppe konfigurierten Read-Only- Gruppe sein und lokal das Recht `Log on as a batch job` besitzen. Bei einer Deinstallation bleiben Snapshot und Logs absichtlich unter -`%ProgramData%\BizTalkCheckmkPulse` erhalten. Sie koennen nach der +`%ProgramData%\BizTalkCheckmkPulse` erhalten. Sie können nach der Betriebsfreigabe manuell entfernt werden. diff --git a/docs/ACC-WMI-SQL-Berechtigung.txt b/docs/ACC-WMI-SQL-Berechtigung.txt index f6de1e5..a8e2031 100644 --- a/docs/ACC-WMI-SQL-Berechtigung.txt +++ b/docs/ACC-WMI-SQL-Berechtigung.txt @@ -5,34 +5,34 @@ BEFUND ====== Host: AV23AGPWBIO1 -Checkmk-Identitaet: NT AUTHORITY\SYSTEM -Alte Netzwerkidentitaet: BEW\AV23AGPWBIO1$ +Checkmk-Identität: NT AUTHORITY\SYSTEM +Alte Netzwerkidentität: BEW\AV23AGPWBIO1$ Fehler: COMException HRESULT=0x80131904 Innerer Fehler: Login failed for user 'BEW\AV23AGPWBIO1$' -Der lokale BizTalk-WMI-Namespace war erreichbar. Datenbankgestuetzte +Der lokale BizTalk-WMI-Namespace war erreichbar. Datenbankgestützte BizTalk-WMI-Abfragen scheiterten am SQL-Login des Maschinenkontos. NEUE VERBINDLICHE ARCHITEKTUR ============================= -Das Maschinenkonto erhaelt keine BizTalk-Berechtigung. +Das Maschinenkonto erhält keine BizTalk-Berechtigung. -1. Ein normales dediziertes Servicekonto laeuft minuetlich als +1. Ein normales dediziertes Servicekonto läuft minütlich als Scheduled Task "BizTalk Checkmk Pulse Provider". -2. Dieses Konto fuehrt BizTalkCheckmkPulse.exe --collect aus. -3. Es schreibt atomar einen SHA-256-geschuetzten Snapshot nach: +2. Dieses Konto führt BizTalkCheckmkPulse.exe --collect aus. +3. Es schreibt atomar einen SHA-256-geschützten Snapshot nach: %ProgramData%\BizTalkCheckmkPulse\data\biztalk-checkmk-pulse.snapshot 4. Der Checkmk-Agent bleibt LocalSystem und startet nur den Consumer. -5. Der Consumer liest und validiert den Snapshot. Er fuehrt kein WMI und +5. Der Consumer liest und validiert den Snapshot. Er führt kein WMI und keinen SQL-Zugriff aus. BERECHTIGUNG DES PROVIDER-KONTOS ================================ -Bevorzugte Rolle fuer BizTalk Server 2020: +Bevorzugte Rolle für BizTalk Server 2020: BizTalk Server Read Only Users SQL-Datenbankrolle: BTS_READONLY_USERS @@ -42,27 +42,27 @@ BizTalk Administration Console ablesen. Das Provider-Konto durch AD-Administration in BizTalkReadOnlyUserGroup aufnehmen. Nicht vom Standardnamen ausgehen. -Die Operator-Gruppe ist nur eine begruendungspflichtige Eskalation, falls eine -konkret benoetigte WMI-Klasse trotz bestaetigter Read-Only-Zuordnung und neuem +Die Operator-Gruppe ist nur eine begründungspflichtige Eskalation, falls eine +konkret benötigte WMI-Klasse trotz bestätigter Read-Only-Zuordnung und neuem Anmeldetoken verweigert wird. -NICHT DURCHFUEHREN +NICHT DURCHFÜHREN ================== -- keinen SQL-Einzellogin fuer Provider- oder Maschinenkonto +- keinen SQL-Einzellogin für Provider- oder Maschinenkonto - keine ad-hoc BizTalk-Datenbankrollen - kein db_owner oder sysadmin - keine pauschalen DCOM-/WMI-ACL-Erweiterungen - Checkmk-Agentdienst nicht auf das Provider-Konto umstellen -- Maschinenkonto BEW\AV23AGPWBIO1$ nicht fuer diese Loesung berechtigen +- Maschinenkonto BEW\AV23AGPWBIO1$ nicht für diese Lösung berechtigen INSTALLATION ============ -BizTalkCheckmkPulse-Setup.zip vollstaendig entpacken und Setup.exe als +BizTalkCheckmkPulse-Setup.zip vollständig entpacken und Setup.exe als Administrator starten. Konto im Format DOMAIN\Benutzer (zum Beispiel BEW\t231bizmon), Kennwort und Umgebung eingeben. PowerShell wird nicht -benoetigt. +benötigt. VERIFIKATION ============ @@ -77,7 +77,7 @@ ERWARTET ======== - LastTaskResult = 0 -- Snapshot wird minuetlich aktualisiert +- Snapshot wird minütlich aktualisiert - Provider-Log nennt das dedizierte Konto - BizTalk Platform zeigt read_only_group= - BizTalk SQL Access zeigt targets=2 und available=2 diff --git a/docs/CheckmkServices.md b/docs/CheckmkServices.md index e387ea1..d9a87d0 100644 --- a/docs/CheckmkServices.md +++ b/docs/CheckmkServices.md @@ -8,23 +8,23 @@ Alle Services werden als Checkmk Local Checks ausgegeben. Das Format ist: Die Ausgabe ist so gebaut, dass sie auch mit Checkmk 2.4.0p4 kompatibel bleibt: zwischen den vier Feldern steht genau ein normales Leerzeichen. -Die fachlichen Daten werden minuetlich vom privilegierten Scheduled-Task- +Die fachlichen Daten werden minütlich vom privilegierten Scheduled-Task- Provider erzeugt. Der Checkmk-Agent liest als `LocalSystem` nur den -integritaets- und altersgeprueften Snapshot. Ist dieser Transport nicht -verfuegbar, liefern alle neun stabilen Services `UNKNOWN`. +integritäts- und altersgeprüften Snapshot. Ist dieser Transport nicht +verfügbar, liefern alle neun stabilen Services `UNKNOWN`. ## BizTalk Platform Zweck: -- Prueft, ob der BizTalk-WMI-Namespace erreichbar ist. +- Prüft, ob der BizTalk-WMI-Namespace erreichbar ist. - Zeigt Server, Gruppe, konfigurierte BizTalk-Read-Only-/Operator-Gruppe, Management-DB und Master-MessageBox-DB aus `MSBTS_GroupSetting`. Status: | Status | Bedingung | | --- | --- | -| `OK` | WMI-Verbindung erfolgreich und `MSBTS_GroupSetting` liefert beide vollstaendigen Datenbankziele. | +| `OK` | WMI-Verbindung erfolgreich und `MSBTS_GroupSetting` liefert beide vollständigen Datenbankziele. | | `UNKNOWN` | Namespace, `MSBTS_GroupSetting`, ein erforderliches Datenbankziel oder der Programmstart fehlgeschlagen. | Metriken: @@ -35,33 +35,33 @@ Metriken: Zweck: -- Ermittelt Management- und Master-MessageBox-Datenbank ueber `MSBTS_GroupSetting`. -- Oeffnet mit der Windows-Identitaet des privilegierten Provider-Tasks eine integrierte SQL-Verbindung. -- Fuehrt die harmlose Abfrage `SELECT 1` aus und schliesst die Verbindung sofort wieder. -- Zeigt lokale Ausfuehrungsidentitaet und erwartete Netzwerkidentitaet an. +- Ermittelt Management- und Master-MessageBox-Datenbank über `MSBTS_GroupSetting`. +- Öffnet mit der Windows-Identität des privilegierten Provider-Tasks eine integrierte SQL-Verbindung. +- Führt die harmlose Abfrage `SELECT 1` aus und schließt die Verbindung sofort wieder. +- Zeigt lokale Ausführungsidentität und erwartete Netzwerkidentität an. -Der Service ersetzt nicht das Checkmk-MSSQL-Plugin. Er prueft den fuer das +Der Service ersetzt nicht das Checkmk-MSSQL-Plugin. Er prüft den für das BizTalk-Monitoring relevanten Zugriff des dedizierten Provider-Kontos. Status: | Status | Bedingung | | --- | --- | -| `OK` | WMI-Zielermittlung vollstaendig und alle ermittelten Datenbanken erreichbar. | -| `UNKNOWN` | Zielermittlung unvollstaendig, Anmeldung verweigert, SQL nicht erreichbar, Timeout oder Providerfehler. | +| `OK` | WMI-Zielermittlung vollständig und alle ermittelten Datenbanken erreichbar. | +| `UNKNOWN` | Zielermittlung unvollständig, Anmeldung verweigert, SQL nicht erreichbar, Timeout oder Providerfehler. | | `OK` mit Hinweis | Nur wenn `ProbeSqlConnectivity=false`; der Test ist dann bewusst deaktiviert. | Fehlerkategorien: | Kategorie | Typische Bedeutung | | --- | --- | -| `Sql/Permission` | Login abgelehnt, Datenbank nicht oeffenbar oder fehlende Berechtigung. | +| `Sql/Permission` | Login abgelehnt, Datenbank nicht öffnbar oder fehlende Berechtigung. | | `Sql/Connectivity` | DNS, SQL-Dienst, Instanz, TCP-Port oder Firewall nicht erreichbar. | -| `Sql/Timeout` | Verbindungsaufbau oder Testabfrage ueberschreitet das konfigurierte Zeitlimit. | +| `Sql/Timeout` | Verbindungsaufbau oder Testabfrage überschreitet das konfigurierte Zeitlimit. | | `Sql/Provider` | Sonstiger von SQL Server oder SqlClient gemeldeter Providerfehler. | -| `Sql/Configuration` | WMI-Ziele aus einem Nicht-Berechtigungsgrund unvollstaendig oder TLS-, Zertifikats-, SPN-/SSPI-Konfiguration fehlerhaft. | +| `Sql/Configuration` | WMI-Ziele aus einem Nicht-Berechtigungsgrund unvollständig oder TLS-, Zertifikats-, SPN-/SSPI-Konfiguration fehlerhaft. | -Ist die Zielermittlung wegen eines eingebetteten SQL-Loginfehlers des BizTalk-WMI-Providers unvollstaendig, wird die Folgediagnose als `Sql/Permission` statt als `Sql/Configuration` ausgegeben. +Ist die Zielermittlung wegen eines eingebetteten SQL-Loginfehlers des BizTalk-WMI-Providers unvollständig, wird die Folgediagnose als `Sql/Permission` statt als `Sql/Configuration` ausgegeben. Metriken: @@ -77,7 +77,7 @@ Zweck: - Ermittelt suspendierte BizTalk-Service-Instanzen. - Unterscheidet resumable und non-resumable. -- Zaehlt Routing Failure Reports (`ServiceClass=64`) separat. +- Zählt Routing Failure Reports (`ServiceClass=64`) separat. - Zeigt betroffene Anwendungen und Beispiele in der Summary. Status: @@ -88,7 +88,7 @@ Status: | `WARN` | `biztalk_suspended_resumable >= WarnResumableThreshold`. | | `CRIT` | `biztalk_suspended_nonresumable >= CritNonResumableThreshold`. | | `CRIT` | `biztalk_routing_failure_reports >= CritRoutingFailureThreshold`. | -| `UNKNOWN` | `MSBTS_ServiceInstance` nicht verlaesslich lesbar oder Programmfehler. | +| `UNKNOWN` | `MSBTS_ServiceInstance` nicht verlässlich lesbar oder Programmfehler. | Metriken: @@ -103,7 +103,7 @@ Metriken: Zweck: -- Ueberwacht BizTalk Host Instances auf dem BizTalk-Server. +- Überwacht BizTalk Host Instances auf dem BizTalk-Server. - Filtert die gruppenweite WMI-Auflistung clientseitig auf den konfigurierten BizTalk-Server; Namen mit Sonderzeichen gelangen nicht in WQL. - Nicht gestartete Host Instances sind normalerweise betriebsrelevant. @@ -130,7 +130,7 @@ Metriken: Zweck: -- Zaehlt alle konfigurierten Receive Locations und ihren `IsDisabled`-Zustand. +- Zählt alle konfigurierten Receive Locations und ihren `IsDisabled`-Zustand. - Trennt bewusst deaktivierte von unerwartet deaktivierten Namen. Status: @@ -139,7 +139,7 @@ Status: | --- | --- | | `OK` | Daten lesbar und keine unerwartet deaktivierte Receive Location. | | `CRIT` | Mindestens eine unerwartet deaktivierte Receive Location bei `AlertOnArtifactRuntimeIssues=true`. | -| `UNKNOWN` | `MSBTS_ReceiveLocation` nicht verlaesslich lesbar oder `IsDisabled` eines Objekts nicht interpretierbar. | +| `UNKNOWN` | `MSBTS_ReceiveLocation` nicht verlässlich lesbar oder `IsDisabled` eines Objekts nicht interpretierbar. | Metriken: @@ -160,7 +160,7 @@ Status: | --- | --- | | `OK` | Alle nicht allowlisted Send Ports sind started. | | `CRIT` | Mindestens ein unerwartet stopped/bound Port oder unbekannter Status. | -| `UNKNOWN` | `MSBTS_SendPort` nicht verlaesslich lesbar. | +| `UNKNOWN` | `MSBTS_SendPort` nicht verlässlich lesbar. | Metriken: @@ -178,12 +178,12 @@ Metriken: Zweck: -- Prueft nur Receive Locations mit `IsDisabled=false` und Send Ports mit +- Prüft nur Receive Locations mit `IsDisabled=false` und Send Ports mit `Status=Started`. -- Reduziert die Adresse auf Host/Port und fuehrt keinen fachlichen +- Reduziert die Adresse auf Host/Port und führt keinen fachlichen HTTP-, FTP-, SFTP-, WCF- oder BizTalk-Aufruf aus. -- Dedupliziert gemeinsame Host/Port-Ziele und prueft sie mit begrenzter - Parallelitaet; das Ergebnis wird danach wieder den Artefakten zugeordnet. +- Dedupliziert gemeinsame Host/Port-Ziele und prüft sie mit begrenzter + Parallelität; das Ergebnis wird danach wieder den Artefakten zugeordnet. - Zeigt im gesunden Zustand nur `Alle n ... erreichbar`. Nur bei Fehlern erscheint die begrenzte Liste `unavailable=`. @@ -191,29 +191,29 @@ Status: | Status | Bedingung | | --- | --- | -| `OK` | Katalog und Runtimezustand vollstaendig; alle aktiven pruefbaren Ziele erreichbar. | +| `OK` | Katalog und Runtimezustand vollständig; alle aktiven prüfbaren Ziele erreichbar. | | `CRIT` | Mindestens ein getestetes TCP-/UDP-Ziel nicht erreichbar. | -| `UNKNOWN` | Katalog fehlt/ist ungueltig, Wochenabgleich scheitert, Runtimezustand ist unvollstaendig oder ein aktiver externer Endpoint kann nicht sicher auf Host/Port reduziert werden. | +| `UNKNOWN` | Katalog fehlt/ist ungültig, Wochenabgleich scheitert, Runtimezustand ist unvollständig oder ein aktiver externer Endpoint kann nicht sicher auf Host/Port reduziert werden. | | `OK` mit Hinweis | Nur wenn `ProbeEndpointConnectivity=false`; der Test ist bewusst deaktiviert. | Metriken: | Metrik | Bedeutung | | --- | --- | -| `biztalk_endpoints_configured` | Eintraege in `endpoints.xml`, einschliesslich derzeit inaktiver. | -| `biztalk_endpoints_active` | Im aktuellen Lauf Started/Enabled und fuer die Probe ausgewaehlt. | -| `biztalk_endpoints_unique_targets` | Nach Host/Port/Protokoll-Deduplizierung tatsaechlich verbundene Ziele. | -| `biztalk_endpoints_tested` | Vollstaendig abgeschlossene Artefaktprobes. | +| `biztalk_endpoints_configured` | Einträge in `endpoints.xml`, einschließlich derzeit inaktiver. | +| `biztalk_endpoints_active` | Im aktuellen Lauf Started/Enabled und für die Probe ausgewählt. | +| `biztalk_endpoints_unique_targets` | Nach Host/Port/Protokoll-Deduplizierung tatsächlich verbundene Ziele. | +| `biztalk_endpoints_tested` | Vollständig abgeschlossene Artefaktprobes. | | `biztalk_endpoints_available` | Erreichbare aktive Artefaktziele. | | `biztalk_endpoints_failed` | Nicht erreichbare aktive Artefaktziele; CRIT ab 1. | | `biztalk_endpoints_unsupported` | Aktive externe Adressen ohne sicher bestimmbaren Host/Port. | -| `biztalk_endpoints_inactive_skipped` | Konfigurierte Eintraege, deren BizTalk-Artefakt aktuell nicht aktiv ist. | +| `biztalk_endpoints_inactive_skipped` | Konfigurierte Einträge, deren BizTalk-Artefakt aktuell nicht aktiv ist. | | `biztalk_endpoint_probe_duration_ms` | Gesamtlaufzeit der parallelisierten Socket-Probes in Millisekunden. | -Bei expliziten `udp://host:port`-Eintraegen kann ein generischer Check ohne +Bei expliziten `udp://host:port`-Einträgen kann ein generischer Check ohne applikationsspezifisches Protokoll nur DNS, Route und erfolgreichen lokalen -Datagrammversand bestaetigen. Er beweist keine Antwort des entfernten -UDP-Dienstes. Fuer alle ueblichen streambasierten Adapter wird deshalb TCP +Datagrammversand bestätigen. Er beweist keine Antwort des entfernten +UDP-Dienstes. Für alle üblichen streambasierten Adapter wird deshalb TCP verwendet. ## BizTalk Orchestrations @@ -222,10 +222,10 @@ Status: | Status | Bedingung | | --- | --- | -| `OK` | Daten lesbar und kein unbekannter Status; inaktive Orchestrations sind standardmaessig nur Information. | +| `OK` | Daten lesbar und kein unbekannter Status; inaktive Orchestrations sind standardmäßig nur Information. | | `WARN` | stopped/bound/unbound bei `AlertOnInactiveOrchestrations=true`. | | `CRIT` | Mindestens ein unbekannter Statuswert. | -| `UNKNOWN` | `MSBTS_Orchestration` nicht verlaesslich lesbar. | +| `UNKNOWN` | `MSBTS_Orchestration` nicht verlässlich lesbar. | Metriken: @@ -238,21 +238,21 @@ Metriken: | `biztalk_orchestrations_unbound` | Unbound Orchestrations. | | `biztalk_orchestrations_unknown` | Nicht interpretierbarer Orchestration-Status. | -Allowlist-Syntax fuer Receive Locations und Send Ports: +Allowlist-Syntax für Receive Locations und Send Ports: ```text Name|Anwendung\Name|Weiterer Name ``` Die Auswertung ist case-insensitive und exakt. Wildcards werden bewusst nicht -unterstuetzt, damit eine breite Regel keine neuen Artefaktfehler verdeckt. +unterstützt, damit eine breite Regel keine neuen Artefaktfehler verdeckt. ## BizTalk Event Log Zweck: - Erfasst BizTalk-bezogene Errors und Warnings aus dem Windows Application Log. -- Ergaenzt WMI-Zustandsdaten um aktuelle Laufzeitereignisse. +- Ergänzt WMI-Zustandsdaten um aktuelle Laufzeitereignisse. Status: @@ -272,10 +272,10 @@ Metriken: ## Optionale per-Application-Services -Wenn `EmitPerApplicationSuspensionServices=true` gesetzt ist, werden zusaetzliche Services fuer Anwendungen erzeugt, die suspendierte Instanzen haben und deren Anwendung per WMI tatsaechlich zugeordnet werden konnte: +Wenn `EmitPerApplicationSuspensionServices=true` gesetzt ist, werden zusätzliche Services für Anwendungen erzeugt, die suspendierte Instanzen haben und deren Anwendung per WMI tatsächlich zugeordnet werden konnte: ```text BizTalk Suspended ``` -Nicht zuordenbare Instanzen bleiben im stabilen Aggregat-Service enthalten; ein irrefuehrender per-Application-Service namens `(unknown)` wird nicht erzeugt. Die Option kann die Service-Anzahl erhoehen und bleibt fuer den Basisausbau deaktiviert. +Nicht zuordenbare Instanzen bleiben im stabilen Aggregat-Service enthalten; ein irreführender per-Application-Service namens `(unknown)` wird nicht erzeugt. Die Option kann die Service-Anzahl erhöhen und bleibt für den Basisausbau deaktiviert. diff --git a/docs/EndpointCatalog.md b/docs/EndpointCatalog.md index 8630fa1..68eb987 100644 --- a/docs/EndpointCatalog.md +++ b/docs/EndpointCatalog.md @@ -10,12 +10,12 @@ Transportadressen. Fehlt die Datei %ProgramData%\BizTalkCheckmkPulse\data\endpoints.xml ``` -wird sie im ersten erfolgreichen Lauf erzeugt. Danach erfolgt der vollstaendige +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 gueltigen Katalog. Checkmk meldet -den ueberfaelligen/fehlgeschlagenen Abgleich trotzdem als `UNKNOWN`. +Fehler beim Abgleich ersetzt keinen letzten gültigen Katalog. Checkmk meldet +den überfälligen/fehlgeschlagenen Abgleich trotzdem als `UNKNOWN`. -Unabhaengig vom Wochenabgleich wird bei jedem Minutenlauf gegen den aktuellen +Unabhängig vom Wochenabgleich wird bei jedem Minutenlauf gegen den aktuellen BizTalk-Runtimezustand gefiltert: - Receive Location nur bei `IsDisabled=false` @@ -23,28 +23,28 @@ BizTalk-Runtimezustand gefiltert: - dynamischer Send Port nie als statisches Ziel Damit wird ein inzwischen gestopptes/deaktiviertes Artefakt sofort nicht mehr -geprueft. Neue Artefakte werden spaetestens beim naechsten Wochenabgleich +geprüft. Neue Artefakte werden spätestens beim nächsten Wochenabgleich aufgenommen. ## Laufzeitbudget Die Socket-Probes werden nach Protokoll, Host und Port dedupliziert und mit -maximal `EndpointProbeMaxConcurrency=16` parallelen Verbindungen ausgefuehrt. -Bei `EndpointProbeTimeoutMilliseconds=3000` benoetigen 70 vollstaendig +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. Nicht pruefbare aktive BizTalk-Artefakte zaehlen nicht gegen diese +21 Sekunden. Nicht prüfbare aktive BizTalk-Artefakte zählen nicht gegen diese Grenze; sie werden separat als `unsupported` 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` ueberlappende Providerlaeufe. +mit `IgnoreNew` überlappende Providerläufe. ## Sicherheitsmodell -Der Katalog speichert nicht die vollstaendige BizTalk-Adresse. Persistiert +Der Katalog speichert nicht die vollständige BizTalk-Adresse. Persistiert werden nur: - Artefakttyp, Anwendung, Name und Transportrolle @@ -53,16 +53,16 @@ werden nur: - Host und Port - `enabled` und `autoDiscovered` -URI-Benutzerinformationen, Kennwoerter, Pfade und Querystrings werden nicht -geschrieben. Der Katalog liegt im bereits ACL-geschuetzten `data`-Verzeichnis; -nur Provider und Administratoren duerfen ihn aendern. `LocalSystem` liest nur +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. -## Manuelle Korrektur eines automatisch nicht aufloesbaren Endpoints +## Manuelle Korrektur eines automatisch nicht auflösbaren Endpoints -Vor einer manuellen Aenderung den Scheduled Task kurz stoppen und die Datei -sichern. Einen vorhandenen Eintrag auf den gewuenschten Host/Port korrigieren -und `autoDiscovered="false"` setzen. Der vorhandene `key` bleibt unveraendert: +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 ``` -Manuelle Eintraege werden beim Wochenabgleich erhalten. Stimmen Artefakttyp -und `key` mit einem Send-/Receive-Artefakt ueberein, gilt weiterhin dessen -Started-/Enabled-Filter. Ein zusaetzliches, nicht an BizTalk gebundenes Ziel +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 -geprueft. +geprüft. -Nach dem Speichern Task wieder starten und pruefen: +Nach dem Speichern Task wieder starten und prüfen: ```powershell Start-ScheduledTask -TaskName 'BizTalk Checkmk Pulse Provider' @@ -93,22 +93,22 @@ Get-Content "$env:ProgramData\BizTalkCheckmkPulse\logs\*.log" -Tail 100 & "$env:ProgramFiles\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe" --consume ``` -Ungueltiges XML, doppelte Keys, falsche Maschine/Umgebung, unbekannte -Protokolle, ungueltige Ports und uebergrosse Dateien werden verworfen. Der -Provider kann bei vollstaendig verfuegbarem BizTalk-Runtimezustand einen -ungueltigen rein automatisch erzeugten Katalog neu aufbauen. Deshalb muss ein +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 fuer HTTP(S), SFTP, FTP, SMB/UNC, WCF und `net.tcp` der -passende nebenwirkungsfreie Netzwerktest. Er bestaetigt DNS, Routing, +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` bestaetigt der Check nur DNS, -Route und erfolgreichen lokalen Datagrammversand. Fuer einen belastbaren -UDP-Dienstcheck waere ein adapter-/protokollspezifisches Request/Response- +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. diff --git a/docs/ExampleOutput.md b/docs/ExampleOutput.md index 78699c3..41afa38 100644 --- a/docs/ExampleOutput.md +++ b/docs/ExampleOutput.md @@ -53,7 +53,7 @@ werden nicht doppelt zum Total addiert. 2 "BizTalk Receive Locations" ... affected=App\RL1, App\RL2, App\RL3, App\RL4, App\RL5 (+17 more) ``` -Die Zaehler und Performance-Daten enthalten weiterhin alle 22 betroffenen +Die Zähler und Performance-Daten enthalten weiterhin alle 22 betroffenen Artefakte. Nur die Textliste ist begrenzt. ## Endpoint-Erreichbarkeit diff --git a/docs/Integration.md b/docs/Integration.md index 4d852c6..4ef61fa 100644 --- a/docs/Integration.md +++ b/docs/Integration.md @@ -1,24 +1,24 @@ -# Checkmk-Integration und Betriebsuebergabe +# Checkmk-Integration und Betriebsübergabe ## Verantwortungsgrenzen | Team | Aufgabe | | --- | --- | | AD/Security | normales dediziertes Servicekonto; Aufnahme in exakt konfigurierte BizTalk-Read-Only-Gruppe | -| BizTalk/SQL | Gruppenabbildung und `BTS_READONLY_USERS` bestaetigen; keine Einzelrechte | -| Windows | Paket installieren, ACL und Scheduled Task pruefen | +| BizTalk/SQL | Gruppenabbildung und `BTS_READONLY_USERS` bestätigen; keine Einzelrechte | +| Windows | Paket installieren, ACL und Scheduled Task prüfen | | Checkmk | Wrapper verteilen beziehungsweise Installation koordinieren, Discovery und Alarmierung | Der Checkmk-Agent bleibt `LocalSystem`. Er greift weder auf BizTalk-WMI noch -auf SQL zu. Der minuetliche Scheduled Task sammelt unter dem privilegierten +auf SQL zu. Der minütliche Scheduled Task sammelt unter dem privilegierten Provider-Konto und publiziert einen validierbaren Snapshot. ## Installation -`BizTalkCheckmkPulse-Setup.zip` vollstaendig entpacken, `Setup.exe` als +`BizTalkCheckmkPulse-Setup.zip` vollständig entpacken, `Setup.exe` als Administrator starten und Konto, Kennwort sowie Umgebung eingeben. Konten wie `BEW\t231bizmon` werden direkt im Windows-Format `DOMAIN\Benutzer` verarbeitet. -Der Installer benoetigt keine PowerShell. +Der Installer benötigt keine PowerShell. Der Installer legt den Local Check hier ab: @@ -36,10 +36,10 @@ Die EXE liegt zentral hier: Der Wrapper darf synchron laufen, da er nur einen kleinen lokalen Snapshot liest. Eine alte Async-Regel mit `cache_age: 300` aus der direkten -WMI-Architektur soll entfernt werden; andernfalls addiert sie eine unnoetige -Verzoegerung zum minuetlichen Provider. +WMI-Architektur soll entfernt werden; andernfalls addiert sie eine unnötige +Verzögerung zum minütlichen Provider. -Aktive Agentkonfiguration pruefen: +Aktive Agentkonfiguration prüfen: ```cmd "C:\Program Files (x86)\checkmk\service\check_mk_agent.exe" showconfig local @@ -54,9 +54,9 @@ Verbindlicher Agent-Dump: ## Service Discovery 1. Provider dreimal erfolgreich laufen lassen. -2. `LastTaskResult=0`, frischen Snapshot und Log pruefen. -3. Agent-Dump im `LocalSystem`-Kontext pruefen. -4. Service Discovery fuer den BizTalk-Host ausfuehren. +2. `LastTaskResult=0`, frischen Snapshot und Log prüfen. +3. Agent-Dump im `LocalSystem`-Kontext prüfen. +4. Service Discovery für den BizTalk-Host ausführen. 5. neun stabile Services aufnehmen und den alten `BizTalk Runtime Artifacts`-Service entfernen. 6. Changes aktivieren. @@ -85,7 +85,7 @@ Die komplette Installation umfasst mehr als eine Dateiablage: - Local-Check-Wrapper. Der Wrapper allein kann per Agent Bakery verteilt werden, ersetzt aber nicht -die lokale Providerinstallation und die Kontofreigabe. Fuer den ersten Rollout +die lokale Providerinstallation und die Kontofreigabe. Für den ersten Rollout ist das signierte/abgenommene Deployment-Paket mit administrativer Installationsautomation die klarere Variante. @@ -100,27 +100,27 @@ type "%ProgramData%\BizTalkCheckmkPulse\logs\biztalk-checkmk-pulse-*.log" Soll: -- Task laeuft jede Minute und endet mit `0`. -- Snapshot ist kleiner als `SnapshotMaxBytes` und juenger als 180 Sekunden. +- Task läuft jede Minute und endet mit `0`. +- Snapshot ist kleiner als `SnapshotMaxBytes` und jünger als 180 Sekunden. - Log nennt das dedizierte Providerkonto. - Platform zeigt `read_only_group=...`. - SQL Access zeigt `targets=2`, `available=2`. - Suspended Instances zeigt total/resumable/non-resumable/routing failures. - Receive Locations und Send Ports zeigen getrennte expected/unexpected Werte. - Endpoint Reachability zeigt bei Erfolg nur die Gesamtzahl und bei Fehlern - ausschliesslich nicht erreichbare Ziele. + ausschließlich nicht erreichbare Ziele. - keine berechtigungsbedingten `UNKNOWN`-Services. ## Alarmierung der Transportkette -Ein Ausfall des Providers wird ueber alle neun Services als `UNKNOWN` -sichtbar. Die Summary nennt fehlenden, unlesbaren, ungueltigen oder stale +Ein Ausfall des Providers wird über alle neun Services als `UNKNOWN` +sichtbar. Die Summary nennt fehlenden, unlesbaren, ungültigen oder stale Snapshot. Als Betriebsregel sollte `UNKNOWN` dieser Services genauso eskaliert werden wie ein technischer Monitoringausfall. -Optional kann Windows Task Scheduler zusaetzlich durch vorhandene Checkmk -Task-/Event-Log-Regeln ueberwacht werden. Das ist eine Ergaenzung, kein Ersatz -fuer die eingebaute Stale-Pruefung. +Optional kann Windows Task Scheduler zusätzlich durch vorhandene Checkmk +Task-/Event-Log-Regeln überwacht werden. Das ist eine Ergänzung, kein Ersatz +für die eingebaute Stale-Prüfung. ## Rollout @@ -128,7 +128,7 @@ Empfohlene Reihenfolge: 1. ACC: Berechtigung, Task, Snapshot, Stale-Test und Discovery abnehmen. 2. DEV/TST: gleiche Automatisierung und umgebungsspezifische Config. -3. PRD: Change, Wartungsfenster, Healthcheck und fachliche Plausibilitaet. +3. PRD: Change, Wartungsfenster, Healthcheck und fachliche Plausibilität. -Ausfuehrliche Architektur, ACL, Fehlerbilder und Abnahmekriterien: +Ausführliche Architektur, ACL, Fehlerbilder und Abnahmekriterien: [Dokumentation.md](../Dokumentation.md). diff --git a/docs/architecture.svg b/docs/architecture.svg index 351ab44..67ed84f 100644 --- a/docs/architecture.svg +++ b/docs/architecture.svg @@ -1,6 +1,6 @@ BizTalk Checkmk Pulse Architektur - Ein privilegierter Scheduled Task liest BizTalk-Daten und prueft aktive Endpunkte. Er schreibt einen validierten Snapshot, den der Checkmk-Agent als LocalSystem nur konsumiert. + Ein privilegierter Scheduled Task liest BizTalk-Daten und prüft aktive Endpunkte. Er schreibt einen validierten Snapshot, den der Checkmk-Agent als LocalSystem nur konsumiert. @@ -38,7 +38,7 @@ Scheduled Task jede Minute, RunLevel Limited - IgnoreNew verhindert Ueberlappung + IgnoreNew verhindert Überlappung