# 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

Normales Servicekonto:

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

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 unnoetige
Verzoegerung zum minuetlichen Provider.

Aktive Agentkonfiguration pruefen:

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

Verbindlicher Agent-Dump:

```powershell
& "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. acht 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. Fuer den ersten Rollout
ist das signierte/abgenommene Deployment-Paket mit administrativer
Installationsautomation die klarere Variante.

## Healthchecks

```powershell
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`.
- Suspended Instances zeigt total/resumable/non-resumable/routing failures.
- Receive Locations und Send Ports zeigen getrennte expected/unexpected Werte.
- keine berechtigungsbedingten `UNKNOWN`-Services.

## Alarmierung der Transportkette

Ein Ausfall des Providers wird ueber alle acht 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](../Dokumentation.md).