FCP FortiAnalyzer 7.4 cheat sheet

FortiAnalyzer runs as a physical appliance, VM, or hosted instance; the management interface is HTTPS on port 443 and admin SSH is TCP 22 - both are configurable per interface.

Administrative domains (ADOMs) partition logs, devices, and policies; a device can belong to exactly one ADOM at a time, and the default ADOM is 'root'.

HA supports two modes: standalone (primary/secondary, formerly master/slave) and distributed (collector and analyzer roles); log replication requires matching firmware and configured log forwarding between peers.

The 'get system status' CLI command shows firmware version, serial number, HA role, and uptime; 'diagnose ha status' reports synchronization state.

Firmware upgrade order in HA is secondary first, then primary, with failover performed so the secondary becomes primary before upgrading the other unit.

Storage capacity is checked under System Settings > Dashboard or with 'diagnose system print partitions'; log retention can be set by age or by disk usage thresholds.

NTP must be synchronized across FortiAnalyzer and all managed devices; skewed time breaks log correlation and report scheduling.

Administrators authenticate locally or via LDAP, RADIUS, TACACS+, or SAML; admin profiles control read/write access per ADOM and per feature area.

A FortiGate is added to FortiAnalyzer by authorizing the device serial number after the FortiGate is configured with 'config log fortianalyzer setting' pointing to the analyzer IP.

Log transmission from FortiGate to FortiAnalyzer uses OFTP over TCP 514 by default; reliable mode buffers logs on the device and acknowledges receipt.

FortiGate log types include traffic, event, security (UTM), anomaly, and VoIP; each type can be enabled or disabled independently in the FortiGate logging settings.

Raw logs are stored in compressed form on disk; indexed fields are written to the SQL database, which is what Log View and reports query.

Log parsing maps received fields to the FortiAnalyzer log schema; unrecognized or non-standard fields may be stored as raw text and are not searchable in structured views.

'diagnose log test' on FortiAnalyzer generates a test log entry to verify ingestion and indexing; 'diagnose fortilogd stats' shows received log counts per device.

Log forwarding from FortiAnalyzer to another analyzer or syslog server is configured per ADOM and per log type, and can filter by severity or free-text match.

Disk quotas per ADOM can be set so one ADOM cannot consume the entire log volume; when the quota is reached the oldest logs in that ADOM are rolled over.

Archiving to a remote server (FTP, SFTP, SCP) moves aged logs off-box; archived logs are not searchable until restored.

Log retention policies define how long logs are kept before automatic deletion; deletion is by age or by maximum disk usage, whichever triggers first.

Report types include predefined (layouts shipped with the product), custom (built in the layout editor), and scheduled (a custom or predefined report bound to a time and delivery method).

A report layout is composed of datasets; a dataset is a SQL query against the log database, and its output columns determine the charts and tables available.

Scheduled reports can be delivered by email, uploaded to a remote server, or stored locally; the schedule defines frequency (daily, weekly, monthly) and the report period.

Time period selection in a report defines the log window queried; a common error is scheduling a daily report with a period that does not cover the prior day's logs.

Report templates can be exported and imported as files, which is the supported way to move a layout between FortiAnalyzer instances.

The 'Reports' > 'Report Configurations' view shows last-run status; a failed report usually indicates a dataset SQL error, missing logs, or an unreachable mail server.

Charts in a layout support bar, pie, line, and table formats; the chart type must match the dataset output (for example, pie needs a label and a value column).

Report generation runs as a background task; large reports over long periods consume CPU and disk I/O and should be scheduled outside peak log ingestion.

ADOM-level report access is controlled by admin profile; a report created in one ADOM is not visible when the administrator is scoped to another ADOM.

Event handlers evaluate incoming logs against conditions (log type, field match, severity, frequency threshold) and trigger actions such as email, SNMP trap, syslog forward, or a playbook.

A frequency-based event handler counts matching logs within a time window; a single-log handler fires on each match and can flood notifications if not scoped tightly.

Incidents group related events and alerts for investigation; an incident can be created manually or by an event handler, and has a status (new, in progress, resolved).

Playbooks are automated response sequences bound to triggers; steps can run CLI commands, quarantine a device, or send notifications, and each run is recorded in the playbook history.

The Log View search syntax supports field:value pairs, wildcards, and logical operators; free-text search is slower than indexed field search.

FortiView dashboards aggregate traffic, threats, and top sources; they are driven by indexed logs and therefore reflect only logs already parsed and stored.

Threat detection uses indicators of compromise and anomaly rules to flag suspicious behavior; results appear as events and can feed incident creation.

Automation stitches (connectors) define the external system a playbook step talks to; credentials are stored in the stitch and referenced by the playbook step.

Audit logs record administrator actions (logins, configuration changes, report runs) and are separate from device logs; they are the reference for change tracking.