Expand BizTalk operational metrics
This commit is contained in:
@@ -5,7 +5,7 @@ BizTalk Server 2020 auf Windows Server 2019. Die Anwendung trennt den
|
||||
berechtigten BizTalk-Datenzugriff vollstaendig vom Checkmk-Agenten:
|
||||
|
||||
```text
|
||||
Scheduled Task (dediziertes Dienstkonto oder gMSA)
|
||||
Scheduled Task (normales dediziertes Servicekonto)
|
||||
|
|
||||
| jede Minute: BizTalkCheckmkPulse.exe --collect
|
||||
v
|
||||
@@ -20,7 +20,7 @@ lokales BizTalk-WMI + BizTalk-SQL + Application Event Log
|
||||
Checkmk Windows Agent (LocalSystem)
|
||||
|
|
||||
v
|
||||
sechs stabile Checkmk Local Checks
|
||||
acht kompakte Checkmk Local Checks
|
||||
```
|
||||
|
||||
Damit bekommt `LocalSystem` keine BizTalk- oder SQL-Berechtigung. Nur das
|
||||
@@ -62,7 +62,7 @@ Der Datenaustausch ist bewusst defensiv:
|
||||
Checkmk-Zeilen, korrekte SHA-256-Pruefsumme und ein maximales Alter von
|
||||
standardmaessig 180 Sekunden.
|
||||
- Fehlende, veraltete, abgeschnittene, manipulierte oder unlesbare Dateien
|
||||
ergeben sechs gueltige `UNKNOWN`-Services statt einer kaputten Agent-Ausgabe.
|
||||
ergeben acht gueltige `UNKNOWN`-Services statt einer kaputten Agent-Ausgabe.
|
||||
- Ein exklusives Lock und die Task-Einstellung `IgnoreNew` verhindern
|
||||
ueberlappende Providerlaeufe.
|
||||
- Ein unerwarteter Providerfehler erzeugt nach Moeglichkeit einen aktuellen
|
||||
@@ -80,9 +80,23 @@ Standardmaessig entstehen:
|
||||
- `BizTalk SQL Access`
|
||||
- `BizTalk Suspended Instances`
|
||||
- `BizTalk Host Instances`
|
||||
- `BizTalk Runtime Artifacts`
|
||||
- `BizTalk Receive Locations`
|
||||
- `BizTalk Send Ports`
|
||||
- `BizTalk Orchestrations`
|
||||
- `BizTalk Event Log`
|
||||
|
||||
Die drei Artefaktbereiche sind absichtlich getrennte Services. Dadurch sind
|
||||
Zustand und Graphen direkt erkennbar, ohne eine lange Sammelzeile zu lesen:
|
||||
|
||||
- Suspensions: total, resumable, non-resumable und Routing Failure Reports
|
||||
- Receive Locations: total, enabled, unerwartet/bewusst disabled und unbekannt
|
||||
- Send Ports: total, started, stopped, bound, unbekannt sowie bewusst inactive
|
||||
- Orchestrations: total, started, stopped, bound, unbound und unbekannt
|
||||
|
||||
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.
|
||||
|
||||
Mit `EnvironmentName=ACC`, `DEV`, `TST` oder `PRD` wird die Umgebung in den
|
||||
Servicenamen aufgenommen, zum Beispiel `BizTalk ACC Platform`.
|
||||
|
||||
@@ -106,7 +120,7 @@ BizTalk-Server:
|
||||
- .NET Framework 4.7.2
|
||||
- Checkmk Windows Agent
|
||||
- administrativer Zugriff fuer die einmalige Installation
|
||||
- dediziertes AD-Dienstkonto oder bevorzugt gMSA fuer den Provider
|
||||
- normales dediziertes AD-Servicekonto fuer den Provider
|
||||
|
||||
Das Provider-Konto benoetigt:
|
||||
|
||||
@@ -116,9 +130,10 @@ Das Provider-Konto benoetigt:
|
||||
- Mitgliedschaft in der exakt konfigurierten BizTalk Server Read Only
|
||||
Users-Gruppe
|
||||
|
||||
Es soll weder lokaler Administrator noch SQL-`sysadmin` sein. Fuer ein gMSA
|
||||
muss der BizTalk-Server das verwaltete Kennwort abrufen duerfen und das Konto
|
||||
lokal installiert sein.
|
||||
Es soll weder lokaler Administrator noch SQL-`sysadmin` sein. Der Scheduled
|
||||
Task laeuft 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.
|
||||
|
||||
## Build und Tests
|
||||
|
||||
@@ -146,7 +161,7 @@ Format-Self-Test ohne WMI, SQL oder Event Log:
|
||||
artifacts\BizTalkCheckmkPulse-deploy\application\BizTalkCheckmkPulse.exe --self-test
|
||||
```
|
||||
|
||||
Erwartet werden exakt sechs `OK`-Zeilen. Die Regressionstests pruefen
|
||||
Erwartet werden exakt acht `OK`-Zeilen. Die Regressionstests pruefen
|
||||
zusaetzlich Snapshot-Roundtrip, atomaren Ersatz, SHA-256-Manipulation,
|
||||
Stale-Erkennung, stabile Fallbacks und die bestehenden BizTalk-WMI-Diagnosen.
|
||||
Ein Mono-Build ist eine hilfreiche Quellcodepruefung, ersetzt aber nicht die
|
||||
@@ -167,9 +182,8 @@ Get-CimInstance `
|
||||
```
|
||||
|
||||
Ein AD-Administrator nimmt das neue Provider-Konto in
|
||||
`BizTalkReadOnlyUserGroup` auf. Bei einem gMSA endet der Kontoname mit `$`.
|
||||
Nach AD-Replikation muss ein regulaeres Dienstkonto einen neuen Anmeldetoken
|
||||
erhalten; bei gMSA wird der Task nach der Gruppenfreigabe neu gestartet.
|
||||
`BizTalkReadOnlyUserGroup` auf. Nach AD-Replikation muss das Servicekonto durch
|
||||
einen neuen Tasklauf einen neuen Anmeldetoken erhalten.
|
||||
|
||||
Die BizTalk-Konfiguration muss die Domain-Gruppe bereits als Windows-Login und
|
||||
in `BizTalkMgmtDb`, `BizTalkMsgBoxDb`, `BizTalkDTADb`,
|
||||
@@ -178,25 +192,7 @@ in `BizTalkMgmtDb`, `BizTalkMsgBoxDb`, `BizTalkDTADb`,
|
||||
SQL-Administration fuer die Gruppe repariert, nicht als Einzelberechtigung
|
||||
fuer das Provider-Konto.
|
||||
|
||||
## Installation mit gMSA
|
||||
|
||||
Deployment-Paket auf den BizTalk-Server kopieren. In administrativer Windows
|
||||
PowerShell:
|
||||
|
||||
```powershell
|
||||
Set-Location C:\Temp\BizTalkCheckmkPulse-deploy
|
||||
|
||||
# Optional, falls das gMSA noch nicht lokal installiert wurde:
|
||||
Install-ADServiceAccount -Identity svc_biztalk_cmk
|
||||
Test-ADServiceAccount -Identity svc_biztalk_cmk
|
||||
|
||||
.\Install-BizTalkCheckmkPulse.ps1 `
|
||||
-CollectorAccount 'BEW\svc_biztalk_cmk$' `
|
||||
-Gmsa `
|
||||
-EnvironmentName ACC
|
||||
```
|
||||
|
||||
## Installation mit regulaerem Dienstkonto
|
||||
## Installation mit normalem Servicekonto
|
||||
|
||||
```powershell
|
||||
Set-Location C:\Temp\BizTalkCheckmkPulse-deploy
|
||||
@@ -209,6 +205,13 @@ Der Installer fragt das Kennwort ueber `Get-Credential` ab und speichert es
|
||||
durch die Windows-Aufgabenplanung. Das Kennwort steht weder in der
|
||||
Konfigurationsdatei noch in den Logs.
|
||||
|
||||
Wenn das Kennwort rotiert oder ablaeuft, muss es im Scheduled Task aktualisiert
|
||||
werden. Bis dahin wird der Snapshot nach 180 Sekunden stale und Checkmk zeigt
|
||||
alle acht Services als `UNKNOWN`.
|
||||
|
||||
Ein gMSA kann weiterhin optional mit `-Gmsa` installiert werden; die
|
||||
produktive Standardbeschreibung geht vom normalen Servicekonto aus.
|
||||
|
||||
Der Installer:
|
||||
|
||||
1. kopiert EXE und Config nach
|
||||
@@ -265,7 +268,7 @@ Verbindlicher Test im echten `LocalSystem`-Kontext:
|
||||
Select-String -Pattern "BizTalk|UNKNOWN|Snapshot|Permission" -Context 0,1
|
||||
```
|
||||
|
||||
Danach in Checkmk eine Service Discovery ausfuehren, die sechs Services
|
||||
Danach in Checkmk eine Service Discovery ausfuehren, die acht Services
|
||||
aufnehmen und Changes aktivieren. Ein zusaetzlicher Checkmk-Async-Cache ist
|
||||
nicht erforderlich: Der Consumer liest nur eine kleine lokale Datei und der
|
||||
Provider besitzt bereits seinen eigenen Minutentakt.
|
||||
@@ -322,7 +325,13 @@ Wichtige Werte:
|
||||
| `SqlConnectionTimeoutSeconds` | `5` | SQL-Timeout je Ziel. |
|
||||
| `WarnResumableThreshold` | `1` | WARN ab n resumable Suspensions. |
|
||||
| `CritNonResumableThreshold` | `1` | CRIT ab n non-resumable Suspensions. |
|
||||
| `AlertOnArtifactRuntimeIssues` | `false` | WARN fuer bewusst inaktive Artefakte aktivieren. |
|
||||
| `CritRoutingFailureThreshold` | `1` | CRIT ab n Routing Failure Reports. |
|
||||
| `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. |
|
||||
| `MaxSummaryItems` | `5` | Maximal angezeigte betroffene Artefakte je Service. |
|
||||
| `MaxDetailCharacters` | `1600` | Harte Obergrenze fuer Checkmk-Summary. |
|
||||
| `EmitPerApplicationSuspensionServices` | `false` | Zusaetzliche Anwendungsservices. |
|
||||
| `EventLogLookbackMinutes` | `60` | Event-Log-Zeitfenster des Providers. |
|
||||
|
||||
@@ -333,10 +342,11 @@ liest den naechsten atomar publizierten Snapshot.
|
||||
|
||||
| Beobachtung | Ursache / Massnahme |
|
||||
| --- | --- |
|
||||
| Alle sechs Services melden fehlenden Snapshot | Task, Provider-Log, Task-Konto und ACL pruefen. |
|
||||
| Alle acht 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. |
|
||||
| `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. |
|
||||
|
||||
Reference in New Issue
Block a user