---
# source: src/content/services/de/monitoring.md
# route:  /de/services/monitoring/
title: Monitoring
group: support
order: 3
tags: [monitoring, managed-services]
summary: Jedes System kann Alarme senden. Die Kunst ist, sie zueinander in Beziehung zu setzen, statt fünfzig Meldungen für einen Ausfall zu bekommen.
photo: monitoring-wall
photoNeed: "A monitoring dashboard at 2am tone: dark room, one screen, one person"
stub: false
draft: false
---

## Das eigentliche Problem

Jedes Produkt, Hardware wie Software, kann heute Alarme und Meldungen verschicken. Genau
das ist die Schwierigkeit: Bei einem einzigen Ausfall melden sich der Host, der Storage,
die Datenbank und die Anwendung gleichzeitig, und in dieser Menge geht die eine Meldung
unter, die die Ursache benennt.

## Was eine Monitoring-Infrastruktur leisten muss

Sie besteht aus Sendern und Empfängern, und ihre Aufgabe ist die Korrelation: Meldungen
zueinander in Beziehung setzen, damit aus fünfzig Ereignissen ein Vorfall wird. Erst dann
ist eine Analyse überhaupt möglich.

## Zwei Arten, und beide werden gebraucht

**Verfügbarkeitsmonitoring** beantwortet, ob etwas läuft. Es meldet den Ausfall.

**Leistungsmonitoring** beantwortet, wie gut es läuft. Es meldet den Trend, der zum Ausfall
führt, und ist damit das, was einen Ausfall überhaupt verhindert.

Wer nur das erste betreibt, erfährt zuverlässig, dass etwas kaputt ist. Wer beides
betreibt, erfährt es vorher.

## Worauf zu achten ist

Ein Alarm, auf den niemand reagiert, ist schlimmer als keiner: Er gewöhnt das Team daran,
Meldungen zu ignorieren. Vor der Einführung gehört geklärt, welche Meldung wen erreicht
und was daraufhin passiert.
