FortiAnalyzer reporting is built from layers. Logs provide the raw evidence. Datasets define which data is extracted from the database. Charts turn dataset results into visual components. Macros can insert calculated values into report text. Report definitions assemble those pieces into scheduled or on-demand outputs for security, operations, and compliance audiences.
The NSE 5 FortiAnalyzer 7.6 Analyst explicitly includes reports, charts, datasets, report configuration, and report-generation troubleshooting. The practical skill is tracing a report result back to the query and log source that produced it.
Datasets are the data logic behind reports
Fortinet defines a dataset as a collection of data extracted from logs for monitored devices. FortiAnalyzer ships with predefined datasets and allows custom datasets to be created. Custom datasets use SQL queries against the relevant local database.
Predefined datasets are valuable starting points because they already reflect FortiAnalyzer’s log tables and common reporting patterns. When a custom report needs a variation, copying a known dataset and modifying it is often safer than building a complex query from nothing.
A dataset should answer one clear question. If a single query tries to calculate unrelated metrics across many log types, troubleshooting and performance become harder. Split complex reporting into focused datasets and combine their outputs at the report layer.
Charts visualize dataset results
Charts reference datasets and define how the returned fields are presented. A chart can make top sources, bandwidth, security events, users, applications, or other metrics understandable to a human reader. The visualization is only as trustworthy as the query beneath it.
When a chart is empty, first test the dataset. When a chart labels data incorrectly, inspect the fields returned by the query and the chart mapping. Changing colors or layout does not fix a dataset that selects the wrong log type or groups on the wrong field.
Choose chart types according to the question. Ranking categories, showing change over time, and displaying a single KPI are different analytical tasks. A report should optimize comprehension rather than maximize visual variety.
Macros place calculated values into narrative text
FortiAnalyzer macros are also based on datasets but are designed to return a single value that can be inserted into report text. Examples include a top user, maximum bandwidth value, or other summary metric.
Macros can make a report easier to read because narrative paragraphs can include current values without manual editing. The same caution applies: if the underlying dataset or field is wrong, the report will confidently display the wrong summary.
Use macros for values that genuinely help the reader interpret the report. Do not fill pages with dynamic numbers simply because the feature exists.
Reports use Analytics logs, not Archive logs
Fortinet states that report generation uses Analytics logs rather than Archive logs. Reports can also use the SIEM database for normalized data in supported designs. This distinction is central to report troubleshooting.
An administrator may confirm that a historical log exists in storage and still get an empty report if the needed data is not available in the Analytics form used by the report. Retention and data-policy choices therefore affect reporting capability.
For user-focused reports, source devices must populate the necessary identity fields. Fortinet specifically notes that FortiGate should populate the user field for reports about users. Reporting cannot infer identity that the original telemetry never included.
Custom SQL should be tested before report generation
FortiAnalyzer provides dataset validation and query-analysis tools. Use them while building custom datasets rather than waiting for a full scheduled report to fail. A test query can reveal syntax errors, missing fields, unexpected grouping, or a filter that removes all rows.
Start with a narrow time range and a known device that has relevant logs. Once the query returns correct rows, expand scope gradually. This reduces the chance that a broad, inefficient query consumes unnecessary resources while still producing a result that is hard to validate.
The SQL model is product-specific. Understand FortiAnalyzer log tables, fields, macros, and supported query behavior rather than assuming a query from a generic database can be copied unchanged.
Troubleshoot empty or failed reports in layers
Confirm the report scope, ADOM, devices, time range, and schedule. Then test the dataset independently. If the dataset returns no data, inspect log availability and field names. If the dataset works but the chart fails, inspect chart mapping. If all components work interactively but scheduled generation fails, inspect task status and resource conditions.
Report problems often reveal upstream telemetry issues. A missing user field, incorrect time, or unparsed source is not fundamentally a reporting problem even though the symptom appears in a report. Trace the missing result back to the earliest layer that lacks the expected data.
The SIEM perspective is helpful: collection, normalization, storage, query, and presentation are connected. Reporting sits near the end of that chain.
Design reports for decisions, not for log volume
A useful report has an audience and a decision. An executive may need trend, risk, and exception summaries. A SOC lead may need event volume, incident categories, and response metrics. A network team may need bandwidth, application, or device-health views.
Do not include every available chart. Too much information makes the important signal harder to find. Start with the questions the reader must answer, then select datasets that support those questions.
For recurring reports, keep definitions stable enough that readers can compare periods. If chart logic changes, document the change so a sudden trend is not mistaken for a real environmental shift.
Performance and retention are reporting design constraints
Large time ranges, high-cardinality grouping, and complex queries can increase report-generation cost. Efficient datasets filter early, return only required fields, and avoid unnecessary transformations. If a report is slow, optimize the query before simply allocating more resources.
Retention must also match the reporting requirement. A quarterly compliance report cannot be reconstructed if the necessary Analytics logs have already aged out. Coordinate storage policy with the longest reporting and investigation window the organization needs.
Scheduled reports should be monitored like other automation. A schedule that silently fails for weeks can create a compliance gap even though the FortiAnalyzer appliance itself is healthy.
Validate the report against raw evidence
Before trusting a new report, choose a small sample and reconcile it with Log View. If the report says ten critical events occurred, identify those events in the underlying data. If it shows a top source or user, verify that the aggregation matches the raw records.
This validation catches query mistakes that produce plausible-looking charts. Security reports often look authoritative because they are formatted well; visual polish is not evidence of data correctness.
Once validated, the report becomes a repeatable analytical product. Keep the dataset, chart, schedule, and source-data assumptions documented so future administrators can maintain it without reverse-engineering the intent.
Time zones are a subtle reporting dependency. Source logs, FortiAnalyzer system time, report schedules, and the reader’s business calendar may not use the same zone. Define which time basis the report represents so daily or monthly totals are not disputed simply because the boundaries were interpreted differently.
Dataset field selection also affects long-term maintainability. Returning every available column can make queries heavier and obscure which fields the chart actually uses. Select the minimum fields needed for grouping, filtering, and presentation, and name custom datasets so their purpose is clear to the next administrator.
When cloning a predefined dataset, preserve a reference to the original logic and document the reason for each modification. This makes later upgrades easier because administrators can compare the custom query with the updated built-in version and decide whether the customization is still necessary.
Report schedules should match data availability. A report generated before all remote devices have uploaded their expected logs may appear incomplete even though the query is correct. Choose generation windows that allow normal collection delays, especially for intermittently connected branches or collector architectures.
For compliance or executive reporting, archive the report definition and validation method as well as the output. A PDF or exported result proves what was presented, while the dataset and chart definitions explain how the numbers were produced. Both are useful when someone later asks whether a metric was calculated consistently.
Report guidance and built-in references can help identify whether the required logs are available for a report. Use those tools before inventing a custom query for a problem that is actually caused by missing source telemetry. The cheapest query to optimize is the one you do not need to write.
Charts should use units and labels that remain meaningful outside the FortiAnalyzer interface. “Top 10” without a time period, device scope, or measurement unit is ambiguous when the report is forwarded. Make the report self-explanatory enough that a reader can interpret it without reconstructing the GUI filters.
When a report drives a control or compliance decision, define the expected data-quality checks. For example, confirm that all required devices reported during the period and that no collector outage created a gap. A perfectly generated report can still be incomplete if the input pipeline was unhealthy.
Keep report ownership explicit. Every important recurring report should have someone responsible for validating its data sources, schedule, and audience after upgrades or organizational changes. Orphaned reports often continue running long after their assumptions are obsolete, which can make stale metrics look official simply because they arrive automatically.
When a report definition changes, compare at least one overlapping period using both the old and new logic. Differences should be explainable by the intentional query change. This side-by-side check prevents an unnoticed field or grouping change from rewriting historical interpretation without anyone realizing the metric definition moved.