FortiGate logging and troubleshooting<\/a> article provides the source-side context; this page focuses on what happens after FortiAnalyzer receives the logs.<\/p>\nDefine the downstream use case before choosing a destination<\/h3>\n A second FortiAnalyzer may support hierarchical logging, delegated operations, or disaster recovery. Syslog and CEF destinations commonly feed SIEM or analytics platforms. Output plugins can connect to supported public cloud services.<\/p>\n
Each destination has different schema, transport, parsing, latency, and retention expectations.<\/p>\n
Document why the destination exists and which team owns the receiving platform so troubleshooting does not stop at \u201cFortiAnalyzer sent the packet.\u201d<\/p>\n
Keep local retention aligned with the forwarding purpose<\/h3>\n FortiAnalyzer keeps a local copy of forwarded logs under its archived-log data policy.<\/p>\n
This means the local retention period and downstream retention can be designed independently.<\/p>\n
For investigations, decide which platform is authoritative for original Fortinet log fidelity, which platform provides long-term search, and how investigators correlate events when retention periods differ.<\/p>\n
Filter aggressively when the destination has a narrower purpose<\/h3>\n Forwarding every event can create unnecessary bandwidth, SIEM ingestion cost, and noise.<\/p>\n
Filters can select relevant devices, event types, severity, or other supported criteria according to the forwarding configuration.<\/p>\n
Security detections, compliance archives, and operational dashboards rarely need exactly the same event set; separate forwarding policies are clearer than one broad stream consumed differently by every downstream team.<\/p>\n
Format should match downstream parsing<\/h3>\n Syslog, CEF, and FortiAnalyzer-to-FortiAnalyzer forwarding have different downstream parsing behavior.<\/p>\n
Choose the format the receiver is designed to ingest and validate field mapping with real events rather than only a connection test.<\/p>\n
A forwarding job can be technically \u201cup\u201d while the SIEM places every message into an unparsed raw field, which is an operational failure even though transport succeeds.<\/p>\n
Use logging topology to understand multi-hop design<\/h3>\n Current FortiAnalyzer provides a Logging Topology view for log-forwarding relationships.<\/p>\n
This is useful when several collectors, analyzers, or destinations exist and one team needs to determine which unit acts as the forwarding client and which service is the receiving server.<\/p>\n
Topology documentation should match reality after migrations so old forwarding paths do not remain silently active.<\/p>\n
Buffering and outage behavior should be tested<\/h3>\n Downstream syslog, CEF, or cloud services can become unavailable because of network, DNS, certificate, quota, or maintenance events.<\/p>\n
Test how the selected forwarding mode buffers, retries, or drops data and how operators see backlog or failure.<\/p>\n
The receiving team should also know what happens after a long outage: burst replay can overwhelm a SIEM even if no logs were lost locally.<\/p>\n
Time synchronization is essential for multi-platform correlation<\/h3>\n Forwarded logs are often correlated with endpoint, cloud, identity, and application data.<\/p>\n
FortiGate, FortiAnalyzer, destination SIEM, and supporting systems should have consistent time synchronization and timezone handling.<\/p>\n
A five-minute clock error can turn one causal incident sequence into a misleading timeline when investigators join data across systems.<\/p>\n
Forwarding security should match log sensitivity<\/h3>\n Security logs can contain usernames, IP addresses, URLs, application names, policy names, file hashes, or other sensitive operational data.<\/p>\n
Use authenticated\/encrypted transport where supported, restrict destination access, and review cross-region data movement.<\/p>\n
A secondary analytics destination should not become a less-protected copy of the organization\u2019s most valuable security evidence.<\/p>\n
Monitor delivery health separately from FortiAnalyzer health<\/h3>\n FortiAnalyzer can remain fully operational while one forwarding destination is unreachable.<\/p>\n
Create alerts for destination failure, queue\/backlog behavior, or unexpected reduction in forwarded volume so silence is not interpreted as \u201cno events.\u201d<\/p>\n
Trend the normal event rate per destination and investigate sudden drops even when the connection itself appears established.<\/p>\n
Schema and parser changes need change control<\/h3>\n FortiOS\/FortiAnalyzer upgrades can add fields, log types, and product features. Downstream SIEM parsers or CEF mappings may need updates.<\/p>\n
Validate key detections after upgrades instead of assuming unchanged transport means unchanged analytics.<\/p>\n
The data contract should include event format and parser compatibility, not only IP address and port of the receiver.<\/p>\n
Forwarding is successful when downstream evidence remains complete and explainable<\/h3>\n The mature design knows which logs leave FortiAnalyzer, where they go, how they are formatted, how failure is buffered or alerted, which copy is authoritative, and who owns parsing and retention.<\/p>\n
That makes log forwarding a controlled security-data pipeline instead of an invisible network socket.<\/p>\n
Forwarding architecture should distinguish operational analytics from evidentiary retention. A SIEM may normalize fields, enrich events, and age data according to a separate storage tier, while FortiAnalyzer retains native Fortinet logs and metadata that can be useful during deep troubleshooting. If both platforms keep copies, document which one investigators should consult first for original event fidelity and which one is authoritative for cross-vendor correlation.<\/p>\n
Destination segmentation can also reduce blast radius. Security analytics, compliance archive, and disaster-recovery forwarding do not necessarily belong on one receiver. Separate destinations can use different filters and retention without forcing one SIEM outage or parser problem to affect every downstream consumer.<\/p>\n
Source-device normalization should be reviewed before forwarding. FortiAnalyzer may receive logs from FortiGate clusters, VDOMs, FortiWeb, FortiMail, FortiSandbox, or other Fortinet products. Downstream analytics should preserve device identity, VDOM\/tenant, policy ID, interface, and product type so events from two systems with similar hostnames are not merged accidentally.<\/p>\n
Network design should account for log bursts. A quiet firewall can become extremely verbose during scanning, DDoS activity, policy change, or incident response. Size links and destinations for peak ingestion rather than average daily volume, and understand whether backpressure causes buffering, dropping, or delayed delivery.<\/p>\n
High availability should be defined for the receiving side as well. Forwarding to one syslog host behind no load balancer or failover mechanism can create an avoidable single point of telemetry loss. If the downstream platform supports multiple collectors, decide whether FortiAnalyzer forwards to several independently or whether an intermediate VIP\/load balancer provides resilience.<\/p>\n
Log filters should be reviewed whenever detection requirements change. If the SOC adds a new use case around DNS, application control, or ZTNA events, verify those log types are actually present in the forwarded stream. A detection rule cannot compensate for telemetry that was filtered out months earlier to reduce ingestion cost.<\/p>\n
Migration between SIEM platforms should use parallel forwarding for a controlled period where capacity allows. Compare event counts, field parsing, timestamps, severity mapping, and detection results before cutting off the old destination. This validates the new pipeline with production evidence rather than discovering after migration that one important log family was lost.<\/p>\n
Forwarding health should be included in incident runbooks. If a SOC dashboard suddenly goes quiet, responders should be able to check FortiAnalyzer local log arrival, forwarding configuration, destination state, queue\/backlog, and network path in sequence. That keeps a telemetry outage from being mistaken for an absence of malicious activity.<\/p>\n
Administrative separation should also be considered. FortiAnalyzer administrators who can change forwarding destinations effectively control where sensitive security telemetry leaves the appliance. Restrict that privilege and review forwarding changes through normal change control, especially when the destination is outside the organization\u2019s primary security boundary.<\/p>\n
Log forwarding should be tested during FortiAnalyzer upgrades and HA events. A destination that receives logs normally before maintenance can become delayed after role changes, certificate updates, or network-path changes. Include downstream event-count validation in the maintenance checklist instead of verifying only FortiAnalyzer system health.<\/p>\n
If several FortiAnalyzer units forward to one central destination, normalize device\/site metadata so the receiver can distinguish which analyzer originally handled the event. This prevents duplicate-log investigations from becoming ambiguous and supports regional failover where another analyzer temporarily forwards the same device population.<\/p>\n
Operational ownership should extend to schema change. When a new FortiOS release introduces a log field used by detections, the FortiAnalyzer\/SIEM teams should decide whether the forwarding format and parser expose it. New security capability creates value only when the downstream analytics path preserves the evidence.<\/p>\n
Change management should preserve the forwarding baseline. Before modifying destination, filter, format, or output plugin, record current event counts and representative messages, then compare the new stream after the change. That makes it possible to detect quiet data loss that a simple connection test would miss.<\/p>\n
Forwarding decommissioning also deserves control. When a SIEM, collector, or regional analyzer is retired, remove its destination cleanly, verify no detections or compliance workflows still depend on it, and document where that telemetry now goes. Stale forwarding jobs waste bandwidth and can leak data to systems that no longer have a business purpose.<\/p>\n
The operating standard should therefore pair FortiAnalyzer health with pipeline health: logs arrive locally, forwarding rules select the intended events, transport is healthy, destination parsing works, and investigators can reconcile the downstream copy with Fortinet-native evidence.<\/p>\n","protected":false},"excerpt":{"rendered":"
FortiAnalyzer log forwarding lets an organization keep FortiAnalyzer as a local log-management and analytics platform while sending selected security telemetry to another FortiAnalyzer, a syslog server, a CEF destination, or supported cloud services through output plugins. In the default forwarding model, FortiAnalyzer retains a local copy, so forwarding creates a second distribution path rather than […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19848","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t