“Il report non funziona” sono due guasti diversi e vanno separati subito: vuoto o parziale è un problema di dati disponibili, lento è un problema di quanto lavoro il motore deve fare alla generazione. Si curano in punti opposti della macchina.

Vuoto: quasi sempre è la retention Analytics

I report leggono i log Analytics, quelli indicizzati nel database SQL ClickHouse. I log Archive non alimentano i report. La data policy stabilisce per quanto tempo i log restano indicizzati: alla scadenza vengono rimossi dal database ma restano compressi sul disco come Archive. Ecco perché un report su novanta giorni con una retention Analytics di trenta produce righe solo per gli ultimi trenta, senza alcun errore a schermo.

Il controllo si fa in System Settings > ADOMs, dove per ogni ADOM trovi Analytics (Actual/Config Days) e Archive (Actual/Config Days). Actual è l’età dei log più vecchi realmente presenti, Config è quanti giorni la policy dice di tenerne. Se Actual è sensibilmente sotto Config non è la policy a tagliare: è la quota, che ha già cancellato. Nella stessa pagina vedi anche lo spazio usato rispetto al massimo.

Per un periodo fuori dalla finestra Analytics la strada c’è, ma è invasiva: un rebuild del database che ricarica dall’Archive l’intervallo che ti serve, e a lavoro finito un secondo rebuild per tornare ai giorni correnti. Durante il rebuild i report non sono disponibili. Da qui la raccomandazione di tenere l’Archive più a lungo dell’Analytics: è l’unica sorgente da cui i dati analitici si rigenerano, anche negli aggiornamenti di firmware che fanno un rebuild da soli.

Un caso limite da tenere a mente: in modalità Collector il database SQL è disabilitato per impostazione predefinita, quindi non ci sono report finché non lo si abilita.

Lento: cosa precalcola l’auto-cache

Senza cache il dataset viene assemblato quando lanci il report, e su volumi importanti questo può richiedere giorni. Abilitando Enable Auto-Cache nella scheda Settings dici al sistema di costruire in anticipo l’hcache.

L’hcache è il sistema di caching proprietario di FortiAnalyzer: tabelle che vivono sul disco dentro il database e che, a differenza di altre cache, sono persistenti e non scadono a tempo. Il meccanismo dipende dalla maturazione delle tabelle di log: quando una tabella viene ruotata diventa matura, cioè non crescerà più — la maggior parte delle tabelle ruota intorno ai cinque milioni di righe. Su quelle mature il sistema esegue le query in anticipo e conserva i risultati intermedi, così al momento della generazione resta solo da fondere i pezzi.

Il prezzo sono CPU e spazio su disco. La regola operativa è quella indicata da Fortinet: abilitalo sui report che impiegano molto ad assemblare i dataset, e disabilitalo su quelli inutilizzati o già veloci. Lo stato di costruzione si legge nella colonna Cache Status dell’elenco dei report. Nella stessa scheda, Extended Log Filtering mette in cache alcuni campi (Device ID, Source Endpoint ID, Source IP, Source User ID, Destination IP) per rendere più rapido il filtraggio.

Le due manopole fra velocità e accuratezza

Nelle Advanced Settings del report ci sono due opzioni che decidono un compromesso, e conviene saperle spiegare.

Enable Report Filter Caching è attiva per impostazione predefinita: i filtri vengono applicati interrogando la tabella hcache, il che accelera la generazione soprattutto quando produci molti report. Disattivandola i filtri finiscono dentro l’hcache: il dato diventa più accurato ma le prestazioni peggiorano. È la manopola da toccare quando il numero in un report filtrato non torna con quello che vedi in Log View.

Enable High Accuracy Caching alza invece il numero massimo di righe delle tabelle hcache. Serve perché quelle tabelle sono limitate e vengono tagliate quando superano il limite: su una classifica con coda lunga il taglio è esattamente ciò che fa sparire i valori minori. I limiti si ispezionano e si modificano da CLI:

diagnose sql config hcache-max-rpt-row [reset | set <integer>]
diagnose sql config hcache-max-high-accu-row [reset | set <integer>]

Quando il problema è il numero di report

Se il carico viene da molti report simili — il caso tipico è Multiple Reports per-device su un parco numeroso — la leva non è la cache del singolo report ma il raggruppamento: riduce il numero di tabelle hcache e accorcia il completamento dell’auto-hcache. Si configura da CLI indicando una stringa contenuta nei titoli e i criteri di raggruppamento:

config system report group
    edit 0
        set adom root
        config group-by
            edit devid
            next
            edit vd
            next
        end
        set report-like Security_Report
    next
end

La stringa di report-like distingue maiuscole e minuscole. Per verificare il risultato guarda la colonna Report Group nell’output di questo comando:

execute sql-report list-schedule <ADOM>

Dopo aver cambiato il raggruppamento va rifatta la cache, indicando l’intervallo nel formato anno-mese-giorno e ora:

diagnose sql hcache rebuild-report <start-time> <end-time>

La quota che sabota i report

Una quota di ADOM insufficiente non dà un errore: dà dati che mancano. Impedisce di rispettare la retention, spreca CPU in cancellazioni e trim del database e fa agire l’enforcement sui dati analitici mentre un report è ancora in corso. Quando il taglio scatta per quota, le tabelle SQL e quelle SIEM sono considerate insieme e viene rimossa la più vecchia, finché la quota rientra. Per dimensionare, i grafici di Log View > Storage Statistics mostrano i trend: verifica che ogni ADOM abbia spazio e giorni sufficienti a completare i report schedulati.