Il report è vuoto, il report di ieri aveva altri numeri, il report ci mette sei ore: tre guasti diversi con tre catene di cause diverse. Il modo più rapido per chiuderli è chiedersi in che punto della catena log, database, hcache, PDF si sia rotto qualcosa.

Report vuoto: quasi sempre è un problema di log

I report usano gli Analytics log. Gli Archive log non vengono usati per generare report. Quindi la domanda giusta non è perché il report sia vuoto, ma se gli Analytics log di quel periodo esistano ancora.

Tre cose li fanno sparire. La data policy stabilisce per quanti giorni restano indicizzati: scaduto il termine vengono purgati dal database, pur restando compressi in Archive. In System Settings > ADOMs le colonne Analytics e Archive mostrano Actual/Config Days, e il valore Actual è l’età del log indicizzato più vecchio: se è minore del periodo del report, hai la causa in dieci secondi.

La seconda è la quota. Una quota insufficiente su un ADOM spreca CPU fra cancellazioni e trim, e soprattutto può far agire l’enforcement sui dati analitici prima che un report sia completo. Log View > Storage Statistics ha i grafici per dimensionarla. Tieni gli archivi più a lungo degli analytics: servono a rigenerarli in un rebuild.

La terza è il rebuild SQL: mentre è in corso i report non sono disponibili, e nemmeno Log View.

Se i log ci sono, guarda la colonna Config Recommendation in All Reports: la Report Guidance dice se gli Analytics log richiesti sono davvero disponibili. Per i report sugli utenti serve poi che il FortiGate popoli il campo user nei log che invia. E in Collector mode il database SQL è disabilitato di default, quindi nessun report.

Il filtro che non filtra come credi

La regola che spiega metà dei casi: se sullo stesso report ci sono sia un filtro di report (scheda Settings) sia un filtro di chart (scheda Layout), viene usato quello del chart. Il filtro di report che hai appena aggiunto non tocca i grafici già filtrati.

Le altre tre. Non puoi creare più filtri sullo stesso Log Field: per più valori usa la virgola senza spazio, come in port1,port2, e se un valore contiene a sua volta una virgola racchiudi ogni valore fra virgolette doppie. Il campo Value è case sensitive quando lo digiti a mano, cioè quando non c’è tendina. E benché Settings e Layout attingano alla stessa lista di Log Field, alcuni campi non vengono usati nei chart.

Se usi LDAP Query, il nome del gruppo non viene confrontato con il campo group dei log: serve solo alla query che determina l’appartenenza.

Finestra temporale e fuso: il caso più frequente in assoluto

I periodi Previous arrivano al massimo ai dati del giorno precedente e non includono quelli del giorno corrente. È voluto: garantisce che nessun dato si perda durante la generazione e che i report schedulati coprano sempre lo stesso intervallo. Chi lancia a mano un Previous 7 Days per un incidente di stamattina e lo trova vuoto è inciampato qui: gli serve Custom.

Il secondo colpevole è il fuso. Il report ha un proprio Time Zone, il cui Default è quello della FortiAnalyzer, e anche l’ADOM ne ha uno. Sotto, il motore lavora su due timestamp: dtime, l’ora del FortiGate che ha creato il log, e itime, l’ora UTC di arrivo sulla FortiAnalyzer. Con dispositivi su fusi diversi ragiona su itime, che è indipendente dal fuso.

Lento non vuol dire rotto: hcache e auto-cache

L’hcache è il caching proprietario di FortiAnalyzer: esegue in anticipo le query di report e FortiView sulle tabelle di log mature e salva i risultati in tabelle che restano su disco e non scadono a tempo. Una tabella diventa matura quando viene rollata e smette di crescere, il che su gran parte delle piattaforme avviene intorno ai cinque milioni di righe.

Auto-cache dice al sistema di costruire l’hcache da solo. Consuma CPU e spazio, quindi si accende solo sui report che impiegano giorni ad assemblare i dataset. Lo stato di costruzione è nella colonna Cache Status.

Se hai molti report simili, raggruppali: riduci le tabelle hcache e accorci sia l’auto-hcache sia la generazione.

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 è case sensitive. Poi verifichi e ricostruisci, con orari in formato anno-mese-giorno ore:minuti:secondi:

execute sql-report list-schedule <ADOM>
diagnose sql hcache rebuild-report <start-time> <end-time>

Numeri che non tornano: accuratezza contro velocità

In Advanced Settings due opzioni decidono la precisione. Enable Report Filter Caching è attivo di default e applica i filtri interrogando la tabella hcache: veloce. Disattivandolo i filtri finiscono dentro l’hcache, con più accuratezza e meno prestazioni. Enable High Accuracy Caching alza il numero massimo di righe hcache: quel limite esiste perché le tabelle vengono tagliate quando lo superano, e ciò che viene tagliato non compare nel report.

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

Extended Log Filtering mette infine in cache Device ID, Source Endpoint ID, Source IP, Source User ID e Destination IP per filtrare più in fretta. Quando un totale è vicino ma non identico a quello di Log View, sospetta il trimming dell’hcache prima dei log.