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.
- NTFS Compression for PRTG Data Storage
https://kb.paessler.com/en/topic/39253-how-can-i-disable-enable-ntfs-compression-for-prtg-s-local-data-storage - reduce the size of Monitoring database
https://kb.paessler.com/en/topic/71626-reduce-the-size-of-monitoring-database - How to Define a Different Drive or Data
Directory for PRTG Installations
https://kb.paessler.com/en/topic/543-how-can-i-change-the-data-directory-of-my-prtg-installation
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
- VoIP mit MRTG/Nagios
- MRTG
- RRDTool
- How and where does PRTG store its data?
https://kb.paessler.com/en/topic/463-how-and-where-does-prtg-store-its-data - Introducing a New Database Format with
PRTG 8.2
https://kb.paessler.com/en/topic/14353-how-does-prtg-store-data-for-log-files-toplists-and-todos - HowTo: Automatically Exporting PRTG's
Raw Monitoring Data Into Daily CSV or XML
Files
https://kb.paessler.com/en/topic/343-how-can-i-export-raw-sensor-data-automatically-from-prtg - How can I change the data directory of
my PRTG installation?
https://kb.paessler.com/en/topic/543-how-can-i-change-the-data-directory-of-my-prtg-installation - Delete or move Historic Sensor Data
https://kb.paessler.com/en/topic/61135-delete-or-move-historic-sensor-data - PRTG DATA EXTRACTOR (DISCONTINUED)
https://www.de.paessler.com/tools/dataextractor