Wer sich schon mit dem FortiAnalyzer auseinander gesetzt hat, dem ist sicherlich aufgefallen, dass sich die Verteilung der vorhandenen LogDisk Ressourcen als schwieriger herausstellt als zunächst erwartet.
Zwar lassen sich Quotas pro Log Device setzen, jedoch ist es damit noch nicht getan. Es gibt noch die sogenannten „Log Arrays“, welche in diesem Artikel näher beschrieben sind.
Im folgenden Beispiel gibt es zwei FortiGates, welche Logs zum Analyzer senden (FGT1 und FGT2). Beiden Devices werden 10GB Disk Quota zugewiesen.
UPDATE: Seit dem Release des FAZ 5.0.7 sind die Log Array Quotas wieder komplett verschwunden! Wir werden den Artikel mit neuen Infos versorgen, sobald uns der Support weitere Details bestätigt. Link dazu hier Klicken!
Ohne Log Array
Wenn kein Log Array definiert ist, dann werden für FGT1 sowie FGT2 die RAW Logs in jeweils eigene Logfiles gespeichert. Der Analyzer nimmt die Logeinträge aus den Files und erstellt für jedes Device je eine SQL Datenbank. Die Logs vom File werden in die jeweilige Datenbank geladen.
Somit belegen natürlich einerseits die Logfiles Platz, andererseits auch die Datenbank, welche die Logeinträge noch einmal enthält. Die Grösse der SQL Datenbank ist etwa 1.5 der Grösse der Log Files.
Beispiel
Als Beispiel hat FGT1 Logfiles von 1GB und FGT2 4GB, dann wird die Grösse der SQL Datenbank entsprechend etwa 1.5GB (FGT1) und 6GB (FGT2) betragen.
Es ist also wichtig zu wissen, dass der Import in die Datenbank die effektive Grösse auf der Festplatte nochmals erheblich erhöht.
Resultat
Alles in allem wird in unserem Beispiel für FGT1 entsprechend 1GB+1.5GB=2.5GB auf der Festplatte belegt. Dasselbe gilt bei FGT2, wo mit 4GB+6GB also bereits 10GB! Diskplatz belegt wird.
Quota
Wird nun weitergeloggt, so läuft FGT2 in die Quota und es werden daher alte Logfiles und alte Einträge in der Datenbank auf der Disk gelöscht. FGT1 hat die Quota jedoch noch nicht erreicht, es wird daher weiter geschrieben.
Mit Log Array
Anders sieht es aus, wenn FGT1 und FGT2 in dasselbe Logarray gepackt werden. Erstellt man also ein solches Log Array für die beiden Geräte und definiert wiederum 10GB in den entsprechenden Log Array Settings als Quota, so werden wieder pro Device die Raw Logs auf die Disk gespeichert. Im gleichen Zug wird jedoch eine gemeinsame SQL DB für beide FortiGates angelegt.
Beispiel
Hat hier nun FGT1 1GB an Raw Logs und FGT2 erneut 4GB Logs, so berechnet sich die Grösse der SQL Datenbank wie folgt: (1GB+4GB)*1.5=7.5GB
Das ergibt 1GB+4GB+7.5GB = 12.5 GB, welche auf der Logdisk liegen.
Resultat
In diesem Fall werden die drei Werte aber unabhängig voneinander gerechnet. Der Unterschied ist also, dass die Quota der SQL Datenbank von 10GB noch nicht erreicht ist. Somit werden bis jetzt also auch noch keinerlei Logdaten gelöscht.
Quota
Wachsen die Logs weiter an auf beispielsweise 2GB und 5GB, so ergibt dies eine SQL DB von 10.5GB ((2GB+5GB)*1.5=10.5GB).
Hiermit würde nun die Quota des LogArray überschritten, was bewirkt, dass der Analyzer nun Log Einträge aus der SQL DB im LogArray zu löschen beginnt.
Dabei wird soweit gelöscht, bis wieder max. 85% der Quota benutzt wird. Was hier bedeutet, dass nach dem Löschen das Log Array wieder auf 8.5GB heruntergelöscht wurde. Sobald dieser Wert erreicht wird, hört der Analyzer mit dem Löschen von Log Einträgen auf.
Wie erwähnt, passiert dies jedoch ausschliesslich im LogArray, da hier der definierte Wert erreicht wurde. Die RAW Logs mit 2GB und 5GB werden bis zum erreichen der Device Quota nicht angerührt!
Device vs. LogArray Quota
Soweit die Theorie. Es kam dann jedoch auch die Frage auf, was denn genau passiert, wenn man pro Device nur die minimalen 100MB als Quota zuweist und somit nur dem LogArray die benötigten GB’s zuweist?
Der Support lieferte uns dann die interessante Info, dass dies eigentlich funktionieren würde, falls die Log Quota von 100MB nicht innert Minutenfrist erreicht würde.
D.h. die Daten aus den RAW Logs werden jeweils regelmässig in die SQL DB exportiert. Würde nun natürlich während dieser Zeit die Device Quota erreicht, so könnte es passieren das Log Einträge weggelöscht werden, bevor Sie in die Datenbank importiert wurden.
Generell sollte dem jedoch nichts im Wege stehen, sofern man die RAW Logs nicht für den Deasaster Fall noch beiseite halten will.
Es kann denn auch in Ausnahmefällen vorkommen, dass die SQL DB durch Stromunterbrüche oder Diskausfälle inkonsistent wird und somit unbrauchbar wird.
Hat man in diesem Fall noch die RAW Logs auf der Disk beiseite, so kann man die Datenbank immerhin aus diesen Files wiederherstellen.
Der Analyzer CLI Guide enhält hierfür entsprechende Infos zum Befehl: „execute sql-local <rebuild-db>“ oder „execute sql-local <rebuild-device> <device id>“
Wir hoffen, euch damit ein paar Fragen zu diesem Thema beantwortet zu haben. Wir freuen uns auch über euer Feedback hier im Blog.
Das Thema ist bei uns zufälligerweise gerade aktuell. In diesem Sinne merci, Markus, für diesen sehr interessanten Beitrag!