161 lines
6.0 KiB
Markdown
161 lines
6.0 KiB
Markdown
# 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).
|