Anforderungsprofil: Monitoring/Observability
Herstellerneutrales technisches Anforderungs- und Beschaffungspaket zum Entscheidungspaket „Monitoring/Observability“.
Am Ende stehen wenige Ende-zu-Ende überwachte Services, getestete Fehlerbilder, definierte Alarm-Owner und Eskalationen sowie ein belastbares Datenvolumen-, Retention- und Betriebsmodell.
Thema: monitoring · Stand 2026-09-21Welle 3 · Compute, Recovery & Observability
Server, Virtualisierung, Backup/Restore und Monitoring als gemeinsame Betriebsplattform dimensionieren und abnehmen.
Vor jeder Punktebewertung nachweisen
Diese Kriterien sind als technische Mindestnachweise formuliert. Nicht erfüllte Muss-Kriterien sollten nicht durch Komfort- oder Preisvorteile kompensiert werden.
| ID | Kriterium | Geforderter Nachweis |
|---|---|---|
| M01 | Monitoring-Scope aus kritischen Services, Hosts, Netzkomponenten und Abhängigkeiten ableiten und gegen das Asset-Inventar abgleichen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M02 | Metriken, Logs und gegebenenfalls Traces mit realen Fehlerfällen testen; Datenlücken, Zeitstempel und Collector-Ausfälle sichtbar machen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M03 | Alarme mit Eigentümern, Prioritäten, Wartungsfenstern, Deduplizierung und Eskalation pilotieren und False Positives messen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M04 | Verteilte Standorte, Proxies/Collector, Firewall-Pfade und Verhalten bei WAN-Ausfall in einem realen Pilot prüfen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M05 | Retention, Datenvolumen, Lizenzmetrik, Export/Exit sowie Monitoring der Monitoring-Plattform vor Produktivsetzung dokumentieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
Mehrwert nur mit realem Betriebsnutzen bewerten
| ID | Kriterium | Bewertungshinweis |
|---|---|---|
| K01 | OpenTelemetry oder vergleichbare offene Telemetriepfade reduzieren proprietäre Agent-/Collector-Bindungen. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K02 | Service Maps oder Topologiebezüge unterstützen die Einordnung technischer Signale in fachliche Services. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K03 | SLO-/Anomalie-Funktionen können gezielt für priorisierte Services genutzt und nachvollziehbar bewertet werden. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K04 | Offene APIs und Exporte ermöglichen Weitergabe an ITSM, SIEM und Datenplattformen ohne geschlossene Einbahnstraße. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
Fragen für Angebot, Workshop und technische Klärung
Kann die Plattform technische Signale sinnvoll auf kritische Services und Abhängigkeiten abbilden?
Werden Datenlücken, Zeitprobleme, Collector-/Proxy-Ausfälle und fehlende Signale sichtbar?
Besitzen Alarme Owner, Priorität, Wartungslogik, Deduplizierung und einen getesteten Eskalationsweg?
Sind Metriken, Logs und – wo benötigt – Traces ausreichend korrelierbar und exportierbar?
Funktionieren Standorte, Proxies/Collector und WAN-Ausfälle ohne falschen grünen Zustand?
Sind Retention, Kosten, Self-Monitoring, Pflege und Exit dauerhaft beherrschbar?
Gates als objektive Abnahmekriterien verwenden
Jeder Pilotservice besitzt bekannte Abhängigkeiten, relevante Fehlerbilder und einen verantwortlichen Owner.
Für jedes Signal ist klar, wo es entsteht, wie es transportiert wird und wie ein Erfassungsausfall erkannt wird.
Die Shortlist deckt die benötigten Systeme, Signale, Standorte und das geforderte Betriebsmodell ab.
Priorisierte Fehler werden reproduzierbar erkannt und erreichen innerhalb der Zielzeit die richtige Person ohne unkontrollierten Alarmlärm.
Datenvolumen und Kosten sind mit Pilotdaten belegt; Betrieb, Self-Monitoring und Exit sind praktisch nachvollziehbar.
Vor Produktivsetzung klären
- Collector, Proxy, Agenten und zentrale Plattform auf Datenlücken und Eigenfehler überwachen.
- Alarmregeln, Owner, Wartungsfenster und Eskalationen mit definierter Review-Cadence pflegen.
- Kapazität, Telemetrievolumen und Retention laufend gegen technische und wirtschaftliche Zielwerte prüfen.
- Dashboards, Service-Modelle und Integrationen nach Änderungen mit reproduzierbaren Fehlerbildern testen.
Vor Vertragsbindung nachweisen
- Checks, Regeln, Dashboards, Service-Modelle und relevante Konfigurationen exportierbar bzw. reproduzierbar dokumentieren.
- Telemetriedaten gemäß Nachweisbedarf exportieren und Collector-/Agent-Pfade auf eine Folgelösung umstellen können.
- Repräsentative Services inklusive Alarmierung auf einer Folgelösung neu aufbauen, bevor die Altplattform abgeschaltet wird.
Gewichtete Bewertung erst nach den Muss-Kriterien
Die Gewichte ergeben zusammen 100 %. Die Skala bewertet nachgewiesene Eignung – nicht Herstellergröße oder Markenpräferenz.
| Kategorie | Gewicht | Skala | Dokumentation |
|---|---|---|---|
| Abdeckung & Datenqualität | 25 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Alerting & Service-Sicht | 25 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Distributed & Integration | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Betrieb & Retention | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Commercial & Exit | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
Für Pilot, Entscheidung und Vertrag dokumentieren
- Service-/Abhängigkeitsmodell
- Fehlerbild-Katalog
- Signal-/Datenquellenmatrix
- Collector-/Proxy-Design
- Retention-Entwurf
- Finder-Profil
- Vergleichsmatrix
- Pilotarchitektur
- Fehlertest-Protokoll
- False-Positive-Liste
- Volumen-/Kostenmodell
- Betriebs-Runbook