PRTG Database

Diese Seite beschreibt nicht, wie Sie die PRTG-Datenbank "hacken" oder direkt auslesen o.ä. sondern nur wie diese auf dem, Speichersystem organisiert ist.

PRTG nutzt keine RRD Datenbank

Die Mutter und Ideengeber vieler Monitoring-Programme war MRTG und die dahinterliegende RRD-Datenbank (RRDTool), bei der Werte immer wieder zusammengefasst wurden und damit ein stetiges Wachstum der Datenbank verhindert wurde. MRTG hat einfach die Daten von 2 Stunden, 24h, 1 Woche und 1 Monat und 365 Tage zusammengefasst. So konnte ein Admin die letzten Stunden und Tage relativ genau betrachten aber die Auflösung älterer Abschnitte wurde immer ungenauer. Die Bilder von Netzwerkports sind wohl bekannt:

Aber PRTG arbeitet hier doch etwas anders.

Disk-Bedarf von PRTG

Aufgefallen ist mir das, als ich eine Warnung bekommen habe, dass meine Festplatte langsam voll läuft und der passende PRTG-Sensor hat die Schwindsucht auch schön dokumentiert:

Also war es an der Zeit mal zu schauen, wo der Platz belegt wurde.

Speicherplatz der Monitoring Daten

Mein präferiertes Tool hierfür ist WinDirStat/ Sequioa, welches sehr schnell einen Überblick über viele Verzeichnisse gibt. Hier sind über 42.000 Dateien in 366 Verzeichnissen abgelegt.

So war es leicht zu sehen, dass in dem Verzeichnis der Datenbank anscheinend für jeden Tag ein neues Verzeichnis angelegt wurde, in dem viele kleine Dateien sind.

Es ist möglich, diesen Bereich per NTS-Kompression zu verkleinern, was aber laut Paessler auf die Datenbank-Performance geht. Heute sollte das GB-Platz wirklich kein Problem mehr darstellen, auch wenn eine Komprimierung von 20GB bei mir den Platz auf 5 GB reduziert hat.

In einer früheren Version konnten Sie sogar PRTG anweisen, die Datenbanken per NTFS-Komprimierung zu speichern.

Genauere Analyse eines Sensors

Ich habe mir dann eine der Dateien raus gefischt und per Powershell mit alle Dateien dieses Namens ausgeben lassen:

$a=Get-ChildItem "Device 2306.prd" -Recurse
$a.count = 363
$a | ft fullname,length -AutoSize
 
FullName                                                        Length
--------                                                        ------
D:\prtg-database\Monitoring Database\20160201\Device 2306.prd  4872048
D:\prtg-database\Monitoring Database\20160202\Device 2306.prd  4872048
D:\prtg-database\Monitoring Database\20160203\Device 2306.prd  4872048
D:\prtg-database\Monitoring Database\20160204\Device 2306.prd  4872048
...
D:\prtg-database\Monitoring Database\20160522\Device 2306.prd  4536048
D:\prtg-database\Monitoring Database\20160523\Device 2306.prd  4536048
D:\prtg-database\Monitoring Database\20160524\Device 2306.prd  4536048
D:\prtg-database\Monitoring Database\20160525\Device 2306.prd 26152048
D:\prtg-database\Monitoring Database\20160526\Device 2306.prd 27720048
D:\prtg-database\Monitoring Database\20160527\Device 2306.prd 27720048
...
D:\prtg-database\Monitoring Database\20161223\Device 2306.prd 31920048
D:\prtg-database\Monitoring Database\20161224\Device 2306.prd 31920048
D:\prtg-database\Monitoring Database\20161225\Device 2306.prd  3192048
D:\prtg-database\Monitoring Database\20161229\Device 2306.prd 19152048
...
D:\prtg-database\Monitoring Database\20170128\Device 2306.prd 30800048
D:\prtg-database\Monitoring Database\20170129\Device 2306.prd 30800048
D:\prtg-database\Monitoring Database\20170130\Device 2306.prd 30800048
D:\prtg-database\Monitoring Database\20170131\Device 2306.prd 18480048

Es sind schon ca. 363 Dateien die aber am 25.5.2016 einen deutlichen Zuwachs pro Datei zeigen. Allerdings gibt es auch danach immer mal wieder "kleine Dateien", was ich aber auf Betriebsunterbrechungen im Monitoring zurückführe. Es sind auch eher die Ausnahmen wie eine Analyse mit Measure-Object zeigt:

$a | Measure-Object length -Sum -Average -Maximum -Minimum

Count    : 363
Average  : 20863364,8044077
Sum      : 7573401424
Maximum  : 35112048
Minimum  : 3192048
Property : Length

Allein dieser eine Sensor generiert also ca. 7 GB Daten insgesamt. DAS ist schön, weil Sie damit natürlich über die Reports auch ältere Daten mit der gleichen Genauigkeit auswerten können. Sie müssen dies aber auch beim Platzbedarf berücksichtigen. In meinem Beispiel konnte ich den Sensor finden, indem ich einfach ein beliebiges Device angewählt und dann in der die URL die ID ersetzt habe. Es handelte sich um einen Hyper-V-Sensor der mit vielen Sensoren sehr viele Messdaten ermittelt.

Ein Sensor mit einem PING alle 60 Sekunden generiert gerade mal 100 Kilobyte/Tag und damit 36,3 Megabyte/Jahr, damit sie über 365 Tage die Antwortzeit mit einer Auflösung von 1 Minute analysieren können.

Purge von Daten

Über die Einstellungen "Setup - System Administration - Cores & Probes" kann eingestellt werden, wie PRTG "aufräumt".

Das ändert aber nichts daran, dass die "Historic Sensor Data" bei einer Einstellung von 365 Tagen eben für jeden Sensor ein Verzeichnis anlegt.

Analyse mit PowerBI

Nun wollte ich natürlich etwas mehr wissen und habe mir daher per PowerShell alle 42580 Dateien in eine CSV-Datei exportiert und mit PowerBI (Desktop) angeschaut.

Get-ChildItem "D:\prtg-database\Monitoring Database\*.prd" -Recurse | select directory,name,length | Export-Csv prtgdata.csv -NoTypeInformation

Die CSV-Datei habe ich in PowerBI beim Import durch eine Transformation so angepasst, dass die erste Zeile der Header ist und in der Spalte" directory" der vordere Teil des Pfads entfernt wird

So bleibt dann nur noch der Zeitstempel übrig, den ich über eine Typkonvertierung auf "Ganze Zahl" geändert habe. Wenn ich dann die Verzeichnisnamen auf die X-Achse lege und die "Length" (=Größe) nach Device auf der Y-Achse anzeigen lasse, dann sehe ich, wie sich der Platzbedarf der einzelnen Devices entwickelt.

Mit einigen Aussetzern sind die Datendateien der Sensoren also immer gleich groß. Diese Zahlen erlauben mir dann aber auch eine Abschätzung, wie groß insgesamt der Speicherbedarf meiner PRTG-Installation werden wird. Ich muss nur die "Length" der Dateien eines Tages addieren und anzeigen. So sehe ich zum einen wie viel Platz die Dateien pro Tag benötigen:

Ich sehe zum einen, dass der Bedarf/Tag nach der Einrichtungszeit, bei der neue Sensoren addiert wurden, nun statisch auf ca. 410Mio/Bytes pro Tag sich stabilisiert hat. Für ein Jahr mit 365 Tagen komme ich als auf 150GB Platzbedarf. Ich kann genauso natürlich davon ableiten, dass zumindest neue Tage immer 410MB Platz belegen und wenn die Dateien vor 366 Tagen kleiner war, dann nimmt der Platz entsprechend ab. Bezogen auf mein obiges Bild mit dem abnehmenden Platz ist es also nur eine Frage der Zeit, ab wann die Linien wieder waagrecht weiterlaufen wird.

Mit den Daten können Sie natürlich auch noch andere Daten ermitteln, z.B. die Anzahl der Devices über die Zeit, indem Sie die Anzahl der Dateien pro Tag ausgeben:

Auch hier sehen Sie, dass diese PRTG-Installation am Anfang ca. 80 Devices überwacht hat aber mittlerweile ca. 130 überwacht und die Menge sich nicht sichtbar verändert. Dies ist aber keine Aussage zur Größe, da ein Device ja sowohl eine unterschiedliche Anzahl an Sensoren und Kanäle beinhaltet und auch die Abtastrate abweichen kann.

PRTG-System-Sensor

Ich habe hier aus der Not heraus analysiert, wie PRTG die Daten abspeichert und wie sich das Datenvolumen über die Zeit hinweg entwickelt. Aber das hat mich natürlich auf den Gedanken gebracht, dass man solche Kennzahlen selbst per PRTG erfassen könnte. PRTG enthält für jede Probe ja schon einen Core/Prtobe-Sensor, der viele Daten bezüglich der Probe erfasst

Aber ich habe noch keinen Sensor gefunden, der die Betriebsdaten der PRTG-Serverinstanz, an den alle Probes berichten, erfasst. Quasi die Kennzahlen über die Tage hinweg protokolliert, die im PRTG System Status bei den "Database Object" sichtbar sind.

Auch Daten bei einer PRTG-Cluster-Installation und die Kennzahlen des PRTG WebServers könnte PRTG leicht selbst als eingebauten Sensor mitbringen. Die Probe, die zugleich auch auf dem PRTG-Server läuft könnten ja einmal am Tag erfassen:

  • Anzahl der Probes
    So könnten Sie nachvollziehen, wann eine Probes addiert und entfernt werden
  • Anzahl der Devices
    Auch hilfreich, wenn mehrere Administratoren etwas einrichten oder Sensoren "automatisch generiert werden"
  • Größe der "Datenbank" vom Vortag
    Die Daten von heute werde ja noch geschrieben und wachsen daher noch. Aber die Größe des Verzeichnisses von Gestern ist durchaus hilfreich bei der Abschätzung des weiteren Bedarfs

Wer es natürlich noch perfektionieren möchte, könne die aktuelle Größe der gesamten Datenbank ermitteln und schauen, wie schnell der Datenbestand wächst und wie lange die Disks noch ausreichen. Aber das ist eher Theorie, wenn was hilft ihnen PRTG, wenn Sie nicht ab und an drauf schauen oder Alarme zugestellt bekommt. So sollten Sie auch über den Core/Probe-Sensor schon die Information erhalten.

Weitere Links