biztalk-checkmk-pulse/docs/Integration.md

Checkmk-Integration und Betriebsuebergabe

Verantwortungsgrenzen

Team	Aufgabe
AD/Security	dediziertes Dienstkonto oder gMSA; 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
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 Provider-Konto und publiziert einen validierbaren Snapshot.

Installation

gMSA:

.\Install-BizTalkCheckmkPulse.ps1 `
    -CollectorAccount 'BEW\svc_biztalk_cmk$' `
    -Gmsa `
    -EnvironmentName ACC

Regulaeres Dienstkonto:

.\Install-BizTalkCheckmkPulse.ps1 `
    -CollectorAccount 'BEW\svc_biztalk_cmk' `
    -EnvironmentName ACC

Der Installer legt den Local Check hier ab:

%ProgramData%\checkmk\agent\local\biztalk_checkmk_pulse.cmd

Die EXE liegt zentral hier:

%ProgramFiles%\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe

Checkmk-Agent-Konfiguration

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.

Aktive Agentkonfiguration pruefen:

& "C:\Program Files (x86)\checkmk\service\check_mk_agent.exe" showconfig local

Verbindlicher Agent-Dump:

& "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" dump |
    Select-String -Pattern "BizTalk|UNKNOWN|snapshot|Permission" -Context 0,1

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.
5. sechs stabile Services aufnehmen.
6. Changes aktivieren.
7. Views, Servicegruppen und Benachrichtigungen einrichten.

Host-Tags:

env:ACC|DEV|TST|PRD
app:biztalk

Servicefilter:

Service starts with: BizTalk

Bakery-/Softwareverteilung

Die komplette Installation umfasst mehr als eine Dateiablage:

• Programmdateien unter %ProgramFiles%,
• Runtimeverzeichnisse und ACLs,
• Scheduled Task mit Providerkonto,
• 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 ist das signierte/abgenommene Deployment-Paket mit administrativer Installationsautomation die klarere Variante.

Healthchecks

Get-ScheduledTaskInfo -TaskName 'BizTalk Checkmk Pulse Provider'
Get-Item "$env:ProgramData\BizTalkCheckmkPulse\data\biztalk-checkmk-pulse.snapshot"
Get-Content "$env:ProgramData\BizTalkCheckmkPulse\logs\*.log" -Tail 50
& "$env:ProgramFiles\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe" --consume

Soll:

• Task laeuft jede Minute und endet mit 0.
• Snapshot ist kleiner als SnapshotMaxBytes und juenger als 180 Sekunden.
• Log nennt das dedizierte Providerkonto.
• Platform zeigt read_only_group=....
• SQL Access zeigt targets=2, available=2.
• keine berechtigungsbedingten UNKNOWN-Services.

Alarmierung der Transportkette

Ein Ausfall des Providers wird ueber alle sechs Services als UNKNOWN sichtbar. Die Summary nennt fehlenden, unlesbaren, ungueltigen 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.

Rollout

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.

Ausfuehrliche Architektur, ACL, Fehlerbilder und Abnahmekriterien: Dokumentation.md.