2.5 Logging, Monitoring & Diagnostics

Why Logging and Diagnostics Are on the Exam

The FortiOS 7.6 blueprint explicitly lists configuring log settings and diagnosing problems using logs and diagnosing resource and connectivity problems in the Deployment and System Configuration domain. These are practical, hands-on skills, and the exam tests them as scenarios: a tunnel that will not pass traffic, a policy that drops the wrong sessions, or a FortiGate running slowly. Knowing which tool answers which question is the goal.

FortiGate Log Types

FortiOS organizes logs into three top-level categories:

• Traffic logs — record sessions that pass through the firewall (forward traffic, local-in/local-out traffic). Generated only when logging is enabled on the firewall policy that handled the session.
• Security (UTM) logs — record events from security profiles: a virus blocked by AntiVirus, a URL blocked by Web Filter, an attack matched by IPS, an application matched by Application Control.
• Event logs — record system activity: administrator logins, configuration changes, HA events, VPN negotiation, routing changes, and FortiGuard updates.

Every log entry carries a severity level on a scale of 0 (most severe) to 7 (least): Emergency (0), Alert (1), Critical (2), Error (3), Warning (4), Notification (5), Information (6), Debug (7). The configured logging level sets the minimum severity recorded — set it to Warning and you capture Warning(4) through Emergency(0), but not Information or Debug.

Log Severity Levels Reference

Exam trap: Logs only appear if logging is turned on at the source. If a firewall policy has Log Allowed Traffic disabled, its sessions never reach any log destination, no matter how the log settings are configured globally.

Where Logs Are Stored

FortiGate can send logs to several destinations at once, and the exam expects you to know the trade-offs:

The Log Allowed Traffic setting on each ACCEPT policy controls volume:

• Security Events — log a session only when a security profile records an event (a blocked virus, URL, or attack). Low volume.
• All Sessions — log every session the policy accepts. High volume; used selectively where full visibility is needed.

Deny policies offer Log Violation Traffic, and enabling it on the implicit deny is the only way to see what that rule is dropping. A practical design logs security events broadly and full sessions only on a few critical policies to control storage and FortiAnalyzer load.

Diagnosing Connectivity Problems

When traffic will not flow, FortiOS provides a layered set of CLI tools, from simple reachability to packet-level tracing:

• execute ping <host> and execute ping-options — basic reachability and the ability to set source interface, size, and count.
• execute traceroute <host> — shows the hop-by-hop path and where it breaks.
• Packet sniffer — diagnose sniffer packet <interface> '<filter>' <verbosity> — captures packets matching a Berkeley-style filter on an interface. Verbosity 4 shows interface names; higher verbosities add headers/payload. This proves whether packets are arriving and leaving the FortiGate.
• Debug flow — diagnose debug flow — the single most powerful FortiGate troubleshooting tool. It traces a packet's journey through the FortiGate's internals and prints, step by step, the route lookup, which firewall policy matched (or that it hit the implicit deny), and how NAT was applied. If a session is being dropped, the flow trace usually names the exact reason.

A typical debug-flow sequence is: diagnose debug flow filter addr <ip>, diagnose debug flow show function-name enable, diagnose debug flow trace start <count>, then diagnose debug enable. The output line that says a packet "matched policy X" or "denied by forward policy check" is what pinpoints a misordered or missing policy.

Exam linkage: The classic "IPsec tunnel is up but no traffic" and "SSL VPN user reaches nothing" scenarios are confirmed with debug flow — it reveals the missing route or missing policy that the VPN sections describe.

Diagnosing Resource Problems and Conserve Mode

When a FortiGate is slow or dropping sessions, the cause is often CPU or memory exhaustion. Key tools:

• get system performance status — a snapshot of CPU usage, memory usage, session counts, and average network throughput.
• diagnose sys top — a live, top-style view of per-process CPU and memory, so you can see which daemon (for example the IPS engine or a proxy worker) is consuming resources.
• get system status — firmware version, serial number, and uptime, useful when confirming you are on FortiOS 7.6.
• diagnose hardware sysinfo family — lower-level hardware and memory detail.

Conserve Mode

Conserve mode is a self-protection state the FortiGate enters automatically when available memory falls below a threshold (the red threshold). In conserve mode the FortiGate stops accepting new sessions that require proxy-based inspection (and may pass them without full inspection, depending on the av-failopen setting) to relieve memory pressure and stay stable; it leaves conserve mode when memory recovers below the green threshold. Frequent conserve mode signals an undersized device, too many proxy-based profiles, or a memory-hungry feature — a known exam symptom.

Matching the Tool to the Problem

Memorizing this mapping is the fastest way to answer the Deployment-domain troubleshooting questions, which describe a symptom and ask which command or condition explains it.