Use proper German umlauts in documentation
This commit is contained in:
+131
-131
@@ -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 `<SnapshotPath>.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
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
||||
|
||||
+15
-15
@@ -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.
|
||||
|
||||
@@ -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=<exakte Gruppe>
|
||||
- BizTalk SQL Access zeigt targets=2 und available=2
|
||||
|
||||
+43
-43
@@ -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 <ApplicationName>
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
+31
-31
@@ -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
|
||||
<Endpoint
|
||||
@@ -79,13 +79,13 @@ und `autoDiscovered="false"` setzen. Der vorhandene `key` bleibt unveraendert:
|
||||
autoDiscovered="false" />
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
@@ -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
|
||||
|
||||
+23
-23
@@ -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).
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="1200" height="720" viewBox="0 0 1200 720" role="img" aria-labelledby="title description">
|
||||
<title id="title">BizTalk Checkmk Pulse Architektur</title>
|
||||
<desc id="description">Ein privilegierter Scheduled Task liest BizTalk-Daten und prueft aktive Endpunkte. Er schreibt einen validierten Snapshot, den der Checkmk-Agent als LocalSystem nur konsumiert.</desc>
|
||||
<desc id="description">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.</desc>
|
||||
<defs>
|
||||
<marker id="arrow-blue" markerWidth="10" markerHeight="10" refX="9" refY="3" orient="auto" markerUnits="strokeWidth">
|
||||
<path d="M0,0 L0,6 L9,3 z" fill="#2563eb"/>
|
||||
@@ -38,7 +38,7 @@
|
||||
<rect x="70" y="175" width="245" height="105" rx="14" class="provider-box"/>
|
||||
<text x="192" y="207" text-anchor="middle" class="box-title">Scheduled Task</text>
|
||||
<text x="192" y="232" text-anchor="middle" class="box-text">jede Minute, RunLevel Limited</text>
|
||||
<text x="192" y="254" text-anchor="middle" class="box-text">IgnoreNew verhindert Ueberlappung</text>
|
||||
<text x="192" y="254" text-anchor="middle" class="box-text">IgnoreNew verhindert Überlappung</text>
|
||||
</g>
|
||||
|
||||
<g filter="url(#shadow)">
|
||||
|
||||
|
Before Width: | Height: | Size: 6.1 KiB After Width: | Height: | Size: 6.1 KiB |
Reference in New Issue
Block a user