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

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

Die EXE liegt zentral hier:

```text
%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:

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

Verbindlicher Agent-Dump:

```cmd
"C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" dump
```

## Service Discovery

Das Setup 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.

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:

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

Servicefilter:

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

```cmd
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](../Dokumentation.md).