biztalk-checkmk-pulse/docs/Integration.md

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 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 minütliche Scheduled Task sammelt unter dem privilegierten Provider-Konto und publiziert einen validierbaren Snapshot.

Installation

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 benötigt 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 unnötige Verzögerung zum minütlichen Provider.

Aktive Agentkonfiguration prüfen:

"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

Das Setup ab 2.2.4 schließt erst erfolgreich ab, nachdem der erste Providerlauf unter dem echten Collector-Konto einen frischen Snapshot und – bei aktivierter Endpoint-Prüfung – einen frisch synchronisierten Katalog erzeugt hat. Die neun stabilen Services müssen vollständig und ohne UNKNOWN vorliegen. Diese lokale Runtime-Abnahme ersetzt nicht die zentrale Checkmk Service Discovery.

EnvironmentName kennzeichnet Snapshot und Katalog, ändert die neun Servicenamen aber standardmäßig nicht. Nur das bewusste Opt-in IncludeEnvironmentInServiceName=true erzeugt umgebungsabhängige Namen und verlangt den anschließenden Discovery-Abgleich.

Ab Setup 2.2.5 darf der gültige Servicevertrag der installierten Ausgangsversion weniger als neun Services enthalten. So ist das Update einer Legacy-Version mit acht Services möglich; nur Paket, Staging und Zielversion müssen exakt neun Services liefern. Additive Services werden gemeldet, aber nicht blockiert. Entfernte oder umbenannte Services erfordern weiterhin die bewusste Bestätigung im Setup. Laufbezogene Details stehen in %ProgramData%\BizTalkCheckmkPulse\logs\setup-*.log.

1. Provider dreimal erfolgreich laufen lassen.
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.
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. Für 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 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 ausschließlich nicht erreichbare oder wirklich unaufgelöste Ziele.
• keine berechtigungsbedingten UNKNOWN-Services.

Alarmierung der Transportkette

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

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 Plausibilität.

Ausführliche Architektur, ACL, Fehlerbilder und Abnahmekriterien: Dokumentation.md.