# ACC-Analyse: Checkmk-Datenalter und Endpoint Reachability

## Befund

Die am 10.08.2026 bereitgestellten ACC-Artefakte zeigen zwei getrennte
Fehlerbilder.

### 1. Checkmk findet die neun Services nicht mehr

Die Checkmk-Ansicht erwartet die bisherigen Namen ohne Umgebung, zum Beispiel:

```text
BizTalk Endpoint Reachability
BizTalk Platform
BizTalk SQL Access
```

Der aktuelle Snapshot enthält dagegen ausschließlich umbenannte Services:

```text
BizTalk ACC Endpoint Reachability
BizTalk ACC Platform
BizTalk ACC SQL Access
```

Damit ist `Item not found in monitoring data` kein Beleg für einen veralteten
oder fehlenden Snapshot. Checkmk sucht nach einem anderen Servicenamen als der
Agent aktuell liefert. Die unterschiedlichen Alterswerte sind die Zeitpunkte,
zu denen Checkmk die jeweiligen alten Namen zuletzt gesehen hat.

Ursache in Version 2.2.1: `EnvironmentName=ACC` wurde zugleich als
Servicenamensbestandteil verwendet. Das Installerfeld „Umgebung“ konnte damit
bei einem Update den stabilen Checkmk-Vertrag unbeabsichtigt ändern.

### 2. Endpoint-Probe ist schnell und erfolgreich, wird aber als UNKNOWN formatiert

Der Snapshot belegt:

| Wert | ACC-Befund |
| --- | ---: |
| aktive Transportkandidaten laut Katalog | 135 |
| automatisch konfigurierte/prüfbare Artefakte | 64 |
| vollständig getestete Artefakte | 64 |
| erreichbare Artefakte | 64 |
| fehlgeschlagene Artefakte | 0 |
| eindeutige Host-/Port-/Protokoll-Ziele | 17 |
| nicht automatisch auflösbare externe Kandidaten | 61 |
| Probe-Laufzeit | 266 ms |

Die Netzwerkprobe selbst ist damit weder veraltet noch langsam. Sie
dedupliziert 64 Artefakte auf 17 Netzwerkverbindungen und schließt alle Probes
in deutlich unter einer Sekunde ab.

Version 2.2.1 behandelt jedoch jeden Wert
`biztalk_endpoints_unsupported > 0` als unvollständiges Ergebnis. Deshalb wird
der Service trotz `available=64` und `failed=0` als `UNKNOWN` ausgegeben. Die
61 Kandidaten fehlen erwartungsgemäß in `endpoints.xml`, weil für sie kein
sicherer und geheimnisfreier Host/Port ermittelt werden konnte. Das ist eine
Abdeckungsinformation, kein Fehler der 64 ausgeführten Probes.

Aus `135 - 64 - 61` ergeben sich zusätzlich 10 lokale, dynamische oder bewusst
nicht netzwerkprüfbare Kandidaten. Version 2.2.2 weist sie explizit als
`excluded` aus.

## Korrektur in Version 2.2.2

### Stabile Servicenamen

- `EnvironmentName` bleibt Umgebungsmetadatum für Snapshot und Katalog.
- Standard `IncludeEnvironmentInServiceName=false`: Die neun Namen bleiben
  `BizTalk ...` und passen wieder zu den bereits entdeckten ACC-Services.
- Nur ein bewusstes Opt-in mit `true` erzeugt Namen wie `BizTalk ACC ...` und
  verlangt anschließend eine Checkmk Service Discovery.
- Version 2.2.3 ergänzt einen versionsübergreifenden Installer-Schutz: Der
  tatsächliche Servicevertrag der vorhandenen und der neuen EXE wird vor dem
  Task-Stopp verglichen. Unbestätigte Renames, neue oder entfernte Services
  blockieren das Update; die Differenz wird vollständig angezeigt.
- Version 2.2.4 erzwingt nach der Umschaltung einen frischen vollständigen
  Endpoint-Katalogabgleich und akzeptiert die Installation erst nach einem
  erfolgreichen Providerlauf mit neuem, identitäts- und integritätsgeprüftem
  Snapshot sowie neun verlässlichen stabilen Services.

### Korrekte Abdeckungssemantik

- Erfolgreich geprüfte Ziele bestimmen den Zustand der Endpoint-Probe.
- Ein fehlgeschlagenes getestetes Ziel bleibt `CRIT`.
- `unsupported` und `excluded` werden als vollständige Metriken ausgegeben,
  führen neben erfolgreicher Prüfabdeckung aber nicht mehr zu `UNKNOWN`.
- Wenn externe `unsupported`-Kandidaten existieren und überhaupt kein Ziel
  automatisch geprüft werden kann, bleibt der Service bewusst `UNKNOWN`.

### Sofortige Katalogkonsistenz

Der Provider vergleicht in jedem Minutenlauf die bereits aus WMI gelesenen
aktiven Kandidaten mit dem Katalog. Folgende Änderungen lösen sofort einen
atomaren Neuabgleich aus:

- neuer, deaktivierter oder entfernter prüfbarer Artefaktschlüssel,
- geänderter Host, Port oder Protokoll eines vorhandenen Artefakts,
- geänderte Zahl aktiver oder nicht automatisch auflösbarer Kandidaten.

Manuelle Overrides gelten weiterhin als beabsichtigte Abdeckung und lösen
keine Refresh-Schleife aus. Der 168-Stunden-Abgleich bleibt als zusätzliche
Frischegrenze bestehen.

### Laufzeitgrenzen

Die performante Implementierung bleibt unverändert:

- Deduplizierung nach Protokoll, Host und Port,
- maximal 16 parallele Probes,
- 3 Sekunden Timeout je eindeutiges Ziel,
- maximal 100 automatisch konfigurierte Endpoint-Einträge.

Der beobachtete ACC-Wert von 266 ms für 17 eindeutige Ziele liegt deutlich im
Minutenbudget.

## Erwartung nach dem Update

Der Endpoint-Service sollte bei unverändertem ACC-Zustand sinngemäß liefern:

```text
0 "BizTalk Endpoint Reachability" ... candidates=135 ... active=64 ...
available=64 ... failed=0 ... unsupported=61 ... excluded=10 ...
unique_targets=17 ... probe_ms=<Laufzeit>
```

Die übrigen fachlichen Zustände aus dem gelieferten Snapshot werden danach in
Checkmk wieder sichtbar und sind getrennt zu bewerten:

- 3 resumable Suspensions: `WARN`,
- 2 Host Instances mit unbekanntem Status: `CRIT`,
- 22 nicht allowlistete deaktivierte Receive Locations: `CRIT`,
- 17 nicht allowlistete inaktive Send Ports: `CRIT`,
- 2 Errors und 6 Warnings im Event-Log-Zeitfenster: `WARN`.

Diese Zustände sind nicht die Ursache des Datenalters und werden durch den
Endpoint-/Namensfix bewusst nicht grüngefärbt.

## ACC-Abnahme nach Installation

1. Setup 2.2.4 als Update ausführen; Umgebung `ACC` kann bestehen bleiben.
   Beim Wechsel von der fehlerhaften 2.2.1-Ausgabe `BizTalk ACC ...` auf die
   stabilen Namen die Rename-/Discovery-Checkbox bewusst aktivieren.
2. In der installierten Config bestätigen:

   ```text
   EnvironmentName=ACC
   IncludeEnvironmentInServiceName=false
   ```

3. Scheduled Task manuell starten und `LastTaskResult=0` prüfen.
4. Snapshot zweimal im Abstand von ungefähr einer Minute prüfen; `generatedUtc`
   muss fortschreiten und die Namen müssen `BizTalk ...` ohne `ACC` lauten.
5. `BizTalk Endpoint Reachability` muss bei `failed=0` und vorhandener
   automatischer Prüfabdeckung `OK` liefern. `unsupported`/`excluded` bleiben
   als Metriken sichtbar.
6. Agent-Dump prüfen:

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

7. Checkmk-Prüfung neu planen. Die bestehenden neun Namen sollten ohne
   Umbenennung wieder Daten erhalten. Nur falls Checkmk noch alte
   `BizTalk ACC ...`-Services enthält, einmal Service Discovery durchführen
   und die bewusst falschen Namen entfernen.
8. `biztalk_endpoint_probe_duration_ms` und `elapsed_ms` über mehrere Läufe
   beobachten; der Task darf nicht in das nächste Minutenintervall laufen.