# 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 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 vorliegen. `UNKNOWN` in einem Kernservice
bleibt blockierend. Ab Version 2.2.6 wird ein isoliertes
`BizTalk Endpoint Reachability = UNKNOWN` als fachliche Betriebswarnung
akzeptiert, sofern Snapshot, Identität und frisch synchronisierter Katalog
valide sind. Die UNKNOWN-Zeile bleibt in Checkmk sichtbar. 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:

```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.
- Schedule ist vollständig ausgenommen; Oracle-DATABASE und WCF-SAP laufen
  als TCP-Best-Effort und können keinen Alarm auslösen. Die zugehörigen
  Erfolgs-/Ignoriert-Zähler bleiben für die Betriebsanalyse sichtbar.
- 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).