FCP FortiAnalyzer 7.4 common mistakes
FCP FortiAnalyzer 7.4 · Understand the traps and how to avoid them.
Treating FortiAnalyzer as a log-only appliance and forgetting it also runs the FortiView, event, and report engines on the same hardware, so candidates size deployments by log volume alone and pick a VM/disk layout that cannot sustain reporting or indexing load.
FortiAnalyzer 7.4 deployment sizing questions mix ADOM count, device count, log rate (GB/day), and retention together; candidates who have only run it as a syslog sink misjudge the resource impact of the analytics and report processes and answer sizing questions from log throughput only.
What to do instead
Memorize the relationship between log rate, retention days, ADOM/device count, and disk sizing on the FortiAnalyzer 7.4 deployment guidance, and remember that report generation and indexing consume CPU/disk beyond raw ingestion. When a scenario gives GB/day plus retention, compute total storage and add headroom for indexes, reports, and the SQL database rather than answering from ingestion rate alone.
Confusing FortiAnalyzer operating modes (standalone, collector, analyzer, and the collector/analyzer split) and assigning the wrong role to a device in a multi-tier or HA design.
FortiAnalyzer supports forwarding and split collector/analyzer topologies, and the mode names overlap with FortiGate log-forwarding settings. Candidates conflate 'collector' with 'forwarding' and misassign which appliance stores logs versus which one analyzes them.
What to do instead
Learn each mode by what it stores and what it serves: collector mode ingests and forwards, analyzer mode stores and analyzes, and standalone does both. Map each exam scenario to the mode that matches where logs are retained and where FortiView/reports are run, and remember that a collector in front of an analyzer changes where retention and indexing happen.
Misconfiguring ADOMs by assuming one ADOM per device or leaving devices in the root ADOM, then answering questions about log visibility and report scope as if all devices share one view.
ADOMs are the isolation boundary for logs, reports, and administrators, but the default root ADOM accepts all devices, so candidates who never split ADOMs assume cross-device FortiView and reports are always global.
What to do instead
Treat the ADOM as the unit of isolation: devices, logs, reports, and admin permissions are scoped per ADOM. When a question asks why an administrator cannot see another team's logs or why a report is missing data, check ADOM assignment first, and when asked to isolate, create the ADOM and move devices rather than filtering in FortiView.
Assuming a FortiGate will send all log types to FortiAnalyzer by default, then failing questions about missing traffic, event, or security logs in FortiView and reports.
Log forwarding requires both the FortiGate-side feature (fortianalyzer logging enabled and per-category log settings) and a matching FortiAnalyzer device entry. Candidates who only check the FortiAnalyzer side miss that the FortiGate decides which categories are sent, and defaults vary by category.
What to do instead
Verify the full path: FortiGate has FortiAnalyzer logging enabled, the correct device is registered/authorized on FortiAnalyzer, and the relevant log categories (traffic, event, security, anomaly) are enabled on the FortiGate. When logs are missing, check the FortiGate log settings and connectivity before assuming a FortiAnalyzer parsing or disk problem.
Ignoring log rate limits and disk-full behavior, so candidates answer retention and overflow questions as if FortiAnalyzer silently drops logs with no operational signal.
FortiAnalyzer has configurable log handling under disk pressure and per-device log rate limits; candidates who have not seen these settings assume logs are always kept until the disk is full and then everything stops.
What to do instead
Know the log rate-limit and disk-full/rollover options and what each does (drop oldest, stop logging, or alert). For a question about logs disappearing or a device being throttled, check the device's log rate setting and the global disk-full policy rather than assuming a network or parsing fault.
Treating log parsing as automatic and never checking whether a device's logs are recognized, so candidates cannot explain 'unknown' log entries or fields that fail to populate in FortiView.
FortiAnalyzer matches incoming logs to a device type and parser; unregistered or misidentified devices produce unparsed or generically parsed logs, which still appear in raw log view but do not populate structured fields, indexes, or report datasets.
What to do instead
When structured fields are empty but raw logs exist, check device registration and the assigned device type/parser. Remember that parsing feeds indexing and reports, so a parsing mismatch shows up as missing report data, not missing raw logs, and correct it by fixing the device entry rather than rebuilding the report.
Building a report and assuming the default dataset covers the metric asked for, instead of selecting or editing the dataset and confirming its time range and filters.
FortiAnalyzer reports are layouts plus datasets, and many built-in datasets have fixed SQL logic and time windows. Candidates who only use the report wizard answer dataset questions as if the chart definition alone determines the numbers.
What to do instead
Trace a report from layout to chart to dataset to SQL. When a report shows unexpected values, check the dataset's time period, filters, and ADOM scope before changing the chart. Know that custom reports require selecting or cloning a dataset, and that dataset time ranges can differ from the report schedule.
Confusing scheduled report delivery with on-demand generation, and misconfiguring output format, recipients, or the schedule so reports never arrive or arrive with the wrong scope.
Report scheduling involves the schedule object, output profile, email/export settings, and the ADOM the report runs against; missing any one of these produces silent failures. Candidates often test by generating on demand, which bypasses the schedule and hides the misconfiguration.
What to do instead
When a scheduled report fails, verify the schedule is enabled, the output profile and mail server are configured, recipients are valid, and the report is bound to the correct ADOM and time period. Test the schedule path itself (not just on-demand generation) and check the report/task status for errors.
Jumping straight to FortiView charts for an incident instead of using log search with precise filters, so candidates cannot answer questions about isolating a specific host, user, or threat over a time window.
FortiView is aggregated and pre-indexed, which is fast for trends but hides individual log entries and exact field values. Candidates used to dashboards try to answer forensic questions from aggregated views and miss the raw evidence.
What to do instead
For investigation questions, start from Log View/search with explicit filters (source IP, destination, user, log type, time range) to find the exact events, then use FortiView to see the broader pattern. Know that search operates on indexed fields, so a field that is not parsed will not filter correctly.
Treating event handlers as passive alerts and not understanding that handler actions (email, syslog, SNMP, and automation stitches) determine whether a detected event triggers a response.
Event handlers detect conditions in logs, but the response comes from the configured actions and any linked automation stitch. Candidates who stop at 'the handler fired' cannot answer why no notification or automated action occurred.
What to do instead
Separate detection from response: the event handler defines the condition and severity, the handler's actions define notification, and automation stitches define remediation. When an event is detected but nothing happens, check the handler's enabled actions and the stitch trigger/action configuration, and verify the handler is scoped to the right ADOM and log type.