FortiAnalyzer turns device logs into searchable evidence, normalized security data, dashboards, events, incidents, and reports. Those capabilities depend on a pipeline: logs must arrive, be identified correctly, be parsed into fields, be normalized where SIEM functionality is used, and be retained in a database that the requested analysis feature can query.

The NSE 5 FortiAnalyzer 7.6 Analyst explicitly covers Fabric integration and log collection, log data flow, normalization, parsing, analytics, incidents, automation, and reporting. Understanding the pipeline makes troubleshooting much faster because “the dashboard is empty” can be traced to the specific stage where data stopped being useful.

Collection begins with trusted log sources and ADOM context

FortiAnalyzer can receive logs from Fortinet devices and, with its SIEM capabilities, from supported third-party sources. Device registration, authorization, connectivity, certificates where applicable, time synchronization, and ADOM placement all influence whether the incoming data arrives in the right administrative context.

A log that never reaches FortiAnalyzer cannot become an event or report. Start collection troubleshooting with network reachability, device logging configuration, registration state, and the correct destination address. Then verify that FortiAnalyzer is actually receiving new records from the expected source.

Time matters at this first stage. Incorrect device clocks can make recent events appear outside the analyst’s search window, distort correlation, and complicate incident timelines. Centralized logging is only as trustworthy as the timestamps and source identities attached to the records.

Parsing turns raw messages into structured fields

Security analytics needs more than raw text. Parsers identify the format of incoming logs and extract fields that can be searched, filtered, correlated, and summarized. FortiAnalyzer includes predefined parsers for Fortinet and supported third-party data sources.

Fortinet documents that enabled parsers are automatically assigned to devices by matching incoming log patterns. If the correct parser is unavailable or disabled, the log may still be visible by device and native log type, but it will not be inserted into the SIEM database as a normalized Fabric log.

This distinction explains a common symptom: an analyst can see raw logs in one view while a SIEM event handler or normalized-field query returns nothing. The collection stage succeeded, but the parsing/normalization stage did not produce the data structure required by the downstream feature.

Normalization creates a common field model

Different products describe similar security concepts with different field names and message formats. FortiAnalyzer’s SIEM normalization maps supported source data into a common set of fields so event handlers, reports, and searches can work across heterogeneous logs.

Normalization is what makes a cross-source question practical. Instead of writing a separate correlation rule for every vendor’s username or source-address syntax, an analyst can use normalized fields where supported. This is a core idea in SIEM: collection becomes more valuable when the platform can compare events using a consistent schema.

Normalization does not mean all source detail disappears. Native logs and device-specific fields still matter during investigation. The normalized model provides a common analytical layer, while raw or product-specific context helps explain what actually happened on the source device.

Native log storage and the SIEM database serve different use cases

FortiAnalyzer stores log data for search and analysis, and its 7.6 SIEM capabilities use a dedicated normalized database for Fabric logs. Fortinet documentation refers to the siemdb for normalized log processing and reporting use cases, while local log tables can also be queried for reporting.

This is why analysts should identify which database a feature expects. A report or event handler designed around normalized Fabric fields cannot use an unparsed source exactly the same way a native device log view can. Data presence in one storage path does not guarantee suitability for every feature.

Storage architecture also affects troubleshooting. If old logs have aged out according to data policy, no amount of dashboard filtering will restore them. Retention, quotas, and storage capacity are part of the analytical pipeline, not merely infrastructure housekeeping.

Analytics logs matter for reporting

Fortinet states that FortiAnalyzer reports use Analytics logs rather than Archive logs. Reports can also use normalized SIEM data where supported. The chart, dataset, and macro in a report definition determine which logs and fields are queried.

This produces another common failure pattern: logs exist, but not in the form the report expects. A custom report may query the wrong log type, a required field may not be populated, or the relevant data may not be available as Analytics logs for the selected period.

When a report is empty, trace the query backward. Confirm the dataset, log type, fields, time range, device selection, and underlying log availability before rewriting the report layout.

From logs to events and incidents

Once logs are parsed and searchable, FortiAnalyzer can evaluate them with event handlers. Basic handlers can generate events when configured rules match; correlation handlers can combine conditions and sequence relationships. Events can then become part of a broader incident investigation.

The pipeline is therefore cumulative. Missing source logs prevent parsing. Missing parsing prevents normalized-field analytics. Missing fields or badly tuned handlers prevent useful events. Poor event quality creates noisy incidents and unreliable automation.

Analysts should resist debugging at the final dashboard first. Start at the earliest stage that could explain the symptom and move forward until the expected data disappears.

Troubleshoot the pipeline with a known test event

A controlled test is one of the fastest diagnostic tools. Generate a known event on a test FortiGate or supported source, note the timestamp and source, and follow it through FortiAnalyzer: reception, Log View, parsing, normalized fields, event handler, incident, and any downstream playbook or report.

If the log is absent, troubleshoot collection. If it appears only as native data, inspect the parser. If normalized fields exist but no event is generated, inspect the handler filters. If the event exists but the dashboard is empty, inspect dashboard time range, filters, and widget data source.

This method is much stronger than waiting for production traffic to reproduce the problem because the expected input is known. It also provides a repeatable validation test after upgrades or parser changes.

Log quality determines SOC quality

Central analytics cannot recover detail that sources never send. Configure managed devices to log the fields needed for security operations, including identity information where appropriate. Fortinet notes, for example, that user-focused reporting depends on FortiGate populating the user field in logs.

Use consistent time synchronization, source naming, ADOM design, and retention policy. Monitor storage and parser health so a quiet dashboard is not mistaken for a quiet network. Across Fortinet certification roles, device administration and analytics are connected by the same dependency: telemetry quality begins at the enforcement devices.

A mature FortiAnalyzer deployment treats the log pipeline as production infrastructure. Collection, parsing, normalization, storage, and retention are monitored just like network links or application services. Reliable detection and reporting start with reliable data.

Think in stages, not screens

FortiAnalyzer exposes several operational views—Device Manager, Log View, FortiView, Incidents & Events, reports, and dashboards—but they represent distinct stages of the log and response workflow. Learning only the menus can make troubleshooting feel arbitrary.

Instead, remember the stages: source generates data, FortiAnalyzer receives it, parser structures it, normalization creates common fields, databases retain it, analytics query it, handlers generate events, incidents organize investigation, and reports or dashboards present the result.

When each stage has an expected input and output, analysts can explain why a result is missing and restore the pipeline without guessing. That systems view is more valuable than memorizing where a particular widget appears in the GUI.

Collector and analyzer roles can also affect where logs are stored and where analytics are performed in larger FortiAnalyzer designs. Analysts should know whether they are querying the system that owns the relevant data or a node that primarily forwards or aggregates it. Architecture can explain why a log exists in one location but not another.

Log integrity includes source identity as well as message content. Duplicate device identifiers, misassigned ADOMs, or reused hostnames can make searches misleading even when every packet reaches FortiAnalyzer. Standardize device naming and registration so analysts can trust that a field refers to the intended asset.

Parser health should be reviewed after adding new third-party sources or upgrading products that change log format. A source that parsed correctly yesterday may start producing unnormalized records after a format change. Monitoring the ratio of parsed to unparsed data can reveal this degradation before a detection silently loses coverage.

Retention design should distinguish operational search from regulatory retention. Keeping raw or archive data for a long period does not automatically mean the same data remains available for fast analytics or scheduled reporting. Map each retention requirement to the database and feature that must satisfy it rather than treating storage capacity as one undifferentiated pool.

Searchability should be tested from an analyst account, not only from a super-admin session. ADOM scope and administrator permissions can make data appear missing when the real issue is visibility. A pipeline health check should therefore include both backend data presence and the access path used by the SOC.

High-volume sources should be reviewed for logging quality as well as capacity. Excessive low-value logs can consume storage and obscure important signals, while overly aggressive filtering can remove evidence needed later. Tune at the source and in FortiAnalyzer with a clear statement of which security questions the retained data must support.

Periodic end-to-end tests can prove that the logging pipeline still supports the detections the SOC depends on. Generate a harmless test event, verify that it is collected, parsed, normalized, searchable, and available to the expected handler or report. This turns logging health from an assumption into a measurable control.