Datenmenge und Aufbewahrungszeit

Die Aufbewahrungszeit von historischen Daten wird über die Systemoptionen in der WebGUI gesteuert. Darunter zählen die Daten von Metriken, Ereignissen, Benachrichtigungen und Web-Transaktionen. Einige Tabellen sind in Partitionen aufgeteilt. Partitionen, die älter als die Aufbewahrungszeit sind, werden automatisch vom DB-Manager des Bloonix-Servers entfernt.

Metriken

Die Messwerte aller Checks (mit Ausnahme von Web-Transaktionen) werden hochauflösend in der Tabelle stat mit täglichen Partitionen im Datastore gespeichert. Der Archive-Manager des Bloonix-Servers fasst die Messwerte jeder Stunde zu den Werten MIN, MAX und AVG zusammen und speichert diese in der Tabelle stat_hourly, die in monatliche Partitionen unterteilt ist.

Eine Besonderheit gilt für Checks, deren Prüfungen über Satelliten erfolgen. Bei der Aggregation werden die Messwerte aller Satelliten eines Service zusammengefasst. Die Zuordnung zu einzelnen Satelliten wird dabei nicht in den aggregierten Daten gespeichert. Daher ist eine Auswertung nach einzelnen Satelliten nur für den Zeitraum möglich, der über die Aufbewahrungszeit für Metriken festgelegt ist.

Speicherbedarf für Metriken

Der Speicherbedarf eines Checks hängt von verschiedenen Faktoren ab, insbesondere von der Anzahl der Metriken, dem Check-Intervall, der Anzahl der Statuswechsel mit Debug-Informationen sowie weiteren Einflüssen. Als grober Richtwert kann jedoch angenommen werden, dass eine einzelne Metrik in der Tabelle stat etwa 82 Byte Speicherplatz benötigt. Bei einem Intervall von 60 Sekunden beträgt der Speicherbedarf pro Jahr etwa 41 MB. Aggregierte Daten benötigen in der Tabelle stat_hourly aufgrund der stündlichen Zusammenfassung nur einen Bruchteil dieses Speicherplatzes.

Der Check check-linux-cpu erfasst beispielsweise 11 Metriken. Daraus ergibt sich bei einem Check-Intervall von 60 Sekunden und einer Aufbewahrungszeit von einem Jahr ein Speicherbedarf von rund 451 MB (11 × 41 MB) in der Tabelle stat und etwa 9 MB in der Tabelle stat_hourly.

Standardmäßig beträgt die Aufbewahrungszeit für Metriken 365 Tage und für aggregierte Metriken 10 Jahre. Sollte der verfügbare Speicherplatz nicht ausreichen, empfiehlt es sich, die Aufbewahrungszeit für Metriken zu reduzieren oder den Datastore auf einen Server auszulagern mit ausreichend Speicherplatz.

Um den aktuellen Speicherbedarf der einzelnen Partitionen zu ermitteln, führe den folgenden Befehl auf dem Datastore aus:

SELECT
    c.relname AS partition,
    pg_size_pretty(pg_total_relation_size(c.oid)) AS total,
    pg_size_pretty(pg_relation_size(c.oid)) AS heap,
    pg_size_pretty(pg_total_relation_size(c.reltoastrelid)) AS toast_total
FROM pg_class c
JOIN pg_inherits i ON i.inhrelid = c.oid
JOIN pg_class p ON p.oid = i.inhparent
WHERE p.relname = 'stat'
ORDER BY pg_total_relation_size(c.oid) DESC;

Um den ungefähren Speicherbedarf eines Checks in der Tabelle stat zu ermitteln, kann der Check mit der Option —plugin-dstat ausgeführt werden. Das folgende Beispiel zeigt den Check check-linux-cpu:

check-linux-cpu --plugin-dstat --pretty
{
    "bytes_per_interval": 902,
    "num_metrics": 11
}

Ereignisse

In den Ereignissen wird historisch der Statusverlauf eines Service-Check gespeichert. Besonders wichtig sind die Ereignisse für die Verfügbarkeitsberichte. Gespeichert werden Ereignisse in der Tabelle event mit täglichen Partitionen.

Web-Transaktionen

Die Ergebnisse von Web-Transaktionen werden in der Tabelle result mit täglichen Partitionen im Datastore gespeichert.

Benachrichtigungen

Benachrichtigungen, die per Mail, SMS oder sonstigen Nachrichtendiensten versendet werden, werden in der Tabelle notification gespeichert.