Si tende a trattare i report di FortiAnalyzer come una scatola nera: scegli un predefinito, premi Run Report, esce un PDF. Ma il giorno che esce vuoto, o ci mette ore, o mostra indirizzi IP dove ti aspettavi nomi utente, senza sapere com’è fatta la catena non hai dove guardare. E la catena è corta.
La catena che porta dal log al PDF
Quattro pezzi, in quest’ordine.
Il dataset è una query SQL che estrae dati dai log. Chart e macro sono due modi di rappresentare il risultato di un dataset: entrambi ne referenziano uno, e ogni chart richiede uno specifico tipo di log. Il template definisce quali chart e macro entrano nel report e come sono disposti, insieme a testo, immagini e tabelle. Il report è il template più le impostazioni: periodo, dispositivi, filtri, pianificazione, output.
Quando generi il report, i dataset associati a ogni chart e a ogni macro estraggono i dati dai log e li popolano. Da qui il fatto più importante dell’obiettivo: i report usano solo i log Analytics, mai gli Archive. Se i log che ti servono sono già finiti in archivio secondo la data policy, il report non li vedrà.
Il dataset è una query SQL su ClickHouse
FortiAnalyzer usa un database SQL ClickHouse, ed è un dettaglio da fissare: il motore delle versioni precedenti non è più quello. Le tabelle di log vengono ruotate, la maggior parte intorno ai cinque milioni di righe, e una tabella ruotata diventa «matura»: non cresce più.
I dataset stanno in Reports > Report Definitions > Datasets; prima di crearne uno assicurati di essere nell’ADOM giusto. Scegli il tipo di log, scrivi la query e usa i pulsanti in fondo: Validate controlla la sintassi, Format riordina, Test esegue davvero su periodo e dispositivi scelti da te, e Analyze Query mostra query originale, query trasformata e la query hcache usata se il report abilita l’auto-cache.
Non partire da zero: clona un predefinito. Dentro trovi due cose da riconoscere: gli alias t1, t2 e simili, nomi temporanei validi solo in quel dataset, e le tabelle di metadati che arrivano da FortiGuard e si uniscono ai log con una JOIN — ips_mdata, app_mdata, fct_mdata, pci_dss_mdata, td_threat_name_mdata. La prima aggiunge nome della vulnerabilità, tipo e CVE ai log di intrusion prevention.
Chart e macro: due modi di consumare lo stesso dataset
Un chart si crea in Chart Library scegliendo dataset e tipo: Table, Bar, Pie, Line, Area, Donut o Radar. Le tabelle hanno tre varianti con vincoli precisi: Regular fino a 15 colonne, Ranked due, Drilldown tre. Quasi ovunque c’è Show Top, che limita agli X elementi più significativi e può raggruppare il resto in «Others».
Attenzione ai formati di colonna: sono tutti selezionabili a prescindere dal data binding, ma non tutti funzionano insieme. Icon-IP Country/Region mostra la bandiera giusta solo con data binding dstcountry; altrimenti non dà errore, dà una colonna sbagliata.
La macro è il fratello minore del chart: dataset, data binding e display, per piazzare un singolo valore dentro il testo. Il Chart Builder di Log View costruisce invece un chart dalla vista che stai guardando. E in un ADOM Security Fabric puoi mettere in un solo report chart di tutti i tipi di dispositivo.
Perché esce vuoto, lento o senza nomi utente
Tre sintomi, tre spiegazioni.
Vuoto. Oltre alla questione Analytics contro Archive, guarda il periodo: i filtri «Previous» arrivano al massimo ai dati del giorno precedente e non includono il giorno corrente, così che i report pianificati coprano un intervallo coerente. Un report «di oggi» generato oggi è vuoto per progetto. Poi usa l’icona nella colonna Config Recommendation per verificare che i log Analytics necessari ci siano davvero. E durante un rebuild del database SQL i report restano indisponibili.
Senza nomi utente. Due cause, entrambe fuori dal report. A monte: perché un report sugli utenti funzioni, deve essere il FortiGate a popolare il campo user nei log che invia. A valle, ed è quella che fa perdere più tempo, nelle Advanced Settings c’è Obfuscate User, che nasconde le informazioni utente. Se qualcuno l’ha attivata, i log sono a posto e il report no.
Lento. Qui entra l’auto-cache. L’hcache è la cache proprietaria di FortiAnalyzer: esegue in anticipo le query sulle tabelle ormai mature e conserva i risultati intermedi in tabelle su disco, persistenti e senza scadenza, così alla generazione resta solo da fondere i risultati. Ha però un costo in CPU e spazio: abilitalo solo sui report lenti davvero. Lo stato è nella colonna Cache Status.
Due impostazioni collegate sono un compromesso esplicito fra velocità e precisione. Enable Report Filter Caching, attiva di default, applica i filtri interrogando la tabella hcache: più veloce, meno accurata. Disattivandola i filtri finiscono dentro l’hcache: più accurata, più lenta. Enable High Accuracy Caching alza il numero massimo di righe hcache; i limiti si gestiscono da CLI:
diagnose sql config hcache-max-rpt-row [reset | set <integer>]
diagnose sql config hcache-max-high-accu-row [reset | set <integer>]Filtri: quale vince
Ultimo dettaglio, piccolo e molto sfruttabile in sede d’esame. Puoi filtrare a livello di report, nella scheda Settings, oppure di singolo chart. Se sono impostati entrambi, vince il filtro del chart.
Altre due regole: non puoi creare più filtri sullo stesso Log Field — se ti servono più valori li elenchi separati da virgola senza spazio — e il campo Value distingue maiuscole e minuscole.