biztalk-checkmk-pulse/docs/Integration.md

Checkmk-Integration und Betriebsuebergabe

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
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

BizTalkCheckmkPulse-Setup.zip vollstaendig 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 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

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. neun stabile Services aufnehmen und den alten BizTalk Runtime Artifacts-Service entfernen.
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

schtasks.exe /query /tn "BizTalk Checkmk Pulse Provider" /v /fo list
dir "%ProgramData%\BizTalkCheckmkPulse\data\biztalk-checkmk-pulse.snapshot"
type "%ProgramData%\BizTalkCheckmkPulse\logs\biztalk-checkmk-pulse-*.log"
"%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.
• 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.
• 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 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.