When a user reports that a connection disappeared, a firewall administrator needs more than a dashboard full of green indicators. The correct evidence may be a forward-traffic accept or deny, an IPS detection, a failed administrator login, an HA transition or an IPsec negotiation event. Fortinet includes log settings, searches and FortiAnalyzer registration in the FortiOS 7.6.0 NSE 4 deployment domain. This article develops a reproducible investigation rather than promising that one log field answers every fault.
Start by identifying the kind of event
Traffic logs record the session-related decision and context; security event logs can explain an antivirus, application-control, IPS or web-filter action; system and event logs show control-plane behavior such as configuration edits, administrative authentication, resource alarms and HA membership changes. If an HTTP request was accepted by the firewall rule but blocked by a web category, a security event may be the decisive record. A firewall policy accept log alone cannot guarantee the application finished successfully.
Decide which device or VDOM handled the reported traffic and the approximate time range. Gather a reliable source/destination tuple, protocol, destination port and user identity when permitted. Record any NAT-translated address shown in the session so you don’t search for only the original client IP. The existing NAT and Central SNAT guide explains why the pre-translation and post-translation endpoints may differ, and the firewall policy guide clarifies what counts as a policy match.
Choose storage and retention deliberately
FortiOS can send or store logs through different supported destinations, depending on appliance capability and configuration. Local retention can be limited on models without persistent disks; a central platform may be needed for historical searches and correlation. A retention policy must account for incident response, privacy, regulatory requirements and write capacity. Increasing logs on every session without checking collection throughput may create blind spots or storage pressure rather than useful visibility.
Fortinet’s Log and Report documentation describes FortiView and log targets. Distinguish device-local views from central analytic views: FortiView can combine real-time and historical traffic perspectives, but a dashboard whose underlying log source is incomplete does not retroactively create missing events. Logging is most valuable when policy intent, timestamp precision and storage destination are clear.
Understand FortiAnalyzer registration and ingest
FortiAnalyzer is not just another syslog file. A FortiGate sending to FortiAnalyzer must be configured to reach the collector, and the device must be registered or authorized as required by the FortiAnalyzer environment. Fortinet’s FortiAnalyzer log lifecycle documentation distinguishes newly received real-time logs, archive files and SQL-indexed analytics logs. A delay between ingest and analytic search does not necessarily mean the device never sent an event.
When a device is missing from the expected central search, verify the management-plane route and collector address, registration/authorization state, encryption compatibility, VDOM scope and the time range. Look for transport-level evidence of delivery before changing every firewall policy. If one branch sends logs but another with the same configuration does not, compare licensing, reachability, time settings and device authorization to narrow the cause.
Use FortiView as a question-driven instrument
FortiView helps answer who is consuming bandwidth, which destinations or applications are common and what threat actions correlate with a user or interface. It is not a replacement for the route table or a packet capture. For example, a spike in sessions to a newly deployed cloud service may be expected business behavior or data exfiltration; the view provides a starting signal, while identity, policy, timing and content alerts establish meaning. Avoid ranking incidents solely by bytes transferred.
A practical monitoring layout exposes denied-versus-accepted flows, blocked-content categories, top destinations, WAN or VPN anomalies, and capacity trends. Tie each visualization to an operational question with an owner. When investigating high latency, contrast throughput charts with the resource and packet-flow workflow; an SD-WAN member can fail a health SLA before any given application becomes fully unreachable.
A four-record investigation exercise
In a safe lab, generate four known events: an allowed HTTPS session, a denied service by policy, a web-filter violation after policy acceptance, and an unsuccessful administrator login. Write down which page or log category should show each event and what the record proves. Search using the five-tuple, policy ID, username or attack signature as appropriate. Then deliberately disable the relevant log setting for one controlled test, and observe why a valid policy action might still leave no expected traffic record.
Next forward events to a registered FortiAnalyzer test instance if available. Compare source event time to central availability and confirm the device belongs to the right administrative domain. Keep screenshots or exported records free of production credentials and personal data. End the exercise by drawing a boundary around unsupported claims: neither an absent record nor a sparse FortiView graph proves that no traffic or compromise occurred.
Prepare operationally credible answers
If the question asks why traffic was denied, start with the traffic decision, then drill into related security profiles. If the question asks why logs are absent, confirm the source device, logging configuration, destination reachability and collector acceptance. If the question asks how to investigate changing traffic trends, FortiView and central historical analytics may help, provided the data source and retention support the query.
Treat the monitoring system as a chain: event generated → feature logging enabled → stored or transported → collector authorized → indexed or displayed → analyst interprets. A failure at any stage changes what you can conclude. The official NSE 4 exam task list tests that reasoning rather than simply naming a menu.