Ogni log che entra in FortiAnalyzer viene scritto due volte, in due posti e con due scopi diversi. Capita quella differenza, quasi tutte le domande su spazio, retention e report trovano risposta da sole.

Due copie, due mestieri

Quando FortiAnalyzer riceve un log lo scrive in un file. Il file cresce fino al limite, poi viene «rollato»: compresso e sostituito da uno nuovo per i log successivi di quel tipo. Questi file, rollati o meno, sono gli Archive log, detti anche offline. Restano inalterati, e per questo si possono caricare su un file server come backup — mentre il RAID di un FortiAnalyzer fisico, va ricordato, non è un backup.

Subito dopo lo stesso log viene inserito nel database SQL: è l’indicizzazione, e il risultato sono gli Analytics log, o online. Sono gli unici usati per l’analisi: Log View — con l’eccezione di Log Browse, che legge i file — Incidents & Events e Reports lavorano solo su questi. Un log che sta solo in Archive non si cerca e non entra in un report.

Da qui la regola di progetto più importante della materia: l’archivio deve durare più degli analytics. È l’archivio a ricostruire il database in caso di corruzione e a ricaricare gli analytics in un rebuild, che può scattare anche da solo durante un aggiornamento firmware. Serve analizzare un periodo fuori dalla finestra Analytics? Un rebuild svuota gli Analytics e ricarica dall’archivio i giorni utili, e un secondo rebuild riporta ai dati correnti.

Il rolling decide più cose di quante sembri

Il rolling si governa con due impostazioni che possono coesistere: la dimensione del file, attiva di default a 200 MB, e un orario schedulato, giornaliero o settimanale. Scatta quando si verifica la prima delle due condizioni.

La raccomandazione ufficiale è rollare ogni giorno, e la ragione è sottile: un file che copre più di 24 ore maschera il numero reale di giorni che stai conservando. Il motivo è che FortiAnalyzer cancella file, non singoli log dentro un file.

Da lì nasce il paradosso che vedrai prima o poi in un pannello: Archive che dichiara 100 giorni su 90 configurati. Non è un bug. Un file non è eleggibile alla cancellazione finché contiene anche una sola riga ancora dentro la retention, quindi quel numero è la data del log più vecchio, non la garanzia di avere log per ogni giorno fino a lì. Quando invece a forzare la cancellazione è lo spazio, viene eliminato il file con il log ricevuto più vecchio: il risultato è lo stesso, qualcosa di 90 giorni fa e un buco nel mezzo.

Data policy e le tre cancellazioni che corrono insieme

La data policy si configura per ADOM da System Settings > ADOMs e dice due cose: per quanto tenere indicizzati gli Analytics e per quanto tenere gli Archive su disco. Attenzione allo zero, che non è simmetrico. Keep Logs for Analytics a 0 significa illimitato. Keep Logs for Archive a 0 significa invece cancellare gli Archive dopo il rolling, con i file rollati che restano comunque fino al successivo controllo della retention, che gira ogni dodici ore.

Cambiare questi valori agisce anche sul passato: Analytics purgati, Archive rimessi nel database, Archive fuori intervallo cancellati.

Sopra alla data policy ci sono altre due politiche, e tutte e tre sono sempre attive insieme: la cancellazione automatica globale dei file, che agisce su tutto il sistema a prescindere dalle impostazioni per device, e la disk utilization, che cancella al superamento della soglia in Alert and Delete When Usage Reaches. Vince chi arriva prima alla propria soglia, quindi vanno configurate tutte e tre con la stessa cura.

Un dettaglio che sorprende: quando è la quota a forzare il trimming, le tabelle SQL e quelle SIEM contano insieme e viene tagliata la più vecchia in assoluto, finché la quota non rientra.

Dimensionare senza indovinare

Il sistema si tiene da parte fra il 5% e il 20% del disco per uso interno e sfondamenti di quota, quindi allochi solo l’80-95%. La percentuale dipende dalla taglia: fino a 500 GB si riserva il 20% o 50 GB, il minore dei due; fino a 1 TB il 15% o 100 GB; fino a 3 TB il 10% o 200 GB; da 5 TB in su il 5% o 300 GB. Il livello RAID scelto determina la dimensione utile e quindi la fascia; nello spazio riservato finiscono anche i report.

Per il resto bastano tre numeri. Un log in Archive pesa in media 80 byte, lo stesso log indicizzato 600, e gli Analytics oltre i sette giorni vengono compressi di default a 150 byte: più efficienti, più lenti da leggere. La soglia si sposta da CLI:

config system sql
    set compress-table-min-age <giorni>
end

Il calcolo è meccanico: log al secondo per dimensione media per 86400 per i giorni desiderati, sommando archivio, analytics compressi e non compressi. Con 1500 log/s, un anno di archivio e novanta giorni di analytics si arriva a circa 5,4 TiB.

Come finestra Analytics la maggior parte delle installazioni sta fra 30 e 60 giorni: tienila lunga quanto serve a completare i report schedulati, perché una quota insufficiente non ti fa solo perdere dati — brucia CPU in cancellazioni e trim continui e può tagliare i dati analitici mentre un report è in corso. Per controllare, System Settings > ADOMs mostra Analytics e Archive come Actual/Config Days e Used/Max.