Logging and Monitoring
This chapter is about evidence: what FortiGate logs, where it sends logs, and how to prove why traffic was allowed, denied, dropped, or never seen.
Mental model
Logging is not only for after-the-fact reporting. In NSE-style troubleshooting, logs are evidence that a packet, session, event, or security profile match happened. If logs are absent, that absence is also evidence: traffic may not be matching the policy, logging may be disabled, severity may filter it out, or the FortiGate may not be delivering logs to the selected destination.
Log categories
| Category | What it proves | Common use |
|---|---|---|
| Traffic | A session was accepted, denied, dropped, reset, or otherwise handled by policy. | Policy validation, NAT validation, user impact, forensic reconstruction. |
| Event | Something happened on the system or control plane. | HA events, admin login, VPN state, routing events, system health. |
| Security / UTM | A security profile detected or blocked something. | IPS, AV, web filter, app control, DLP, anomaly detection. |
| Local traffic | Traffic to or from the FortiGate itself. | FortiGuard, DNS, NTP, FortiManager, FortiAnalyzer, admin access. |
Log destinations
FortiGate can log to memory, disk, FortiAnalyzer, FortiCloud, syslog, or SIEM tooling. For serious troubleshooting, FortiAnalyzer is the expected Fortinet-native destination because it keeps logs centralized and searchable.
- Memory logging: useful for quick checks, but volatile.
- Disk logging: useful where hardware supports it, but not ideal as the only enterprise log store.
- FortiAnalyzer: best fit for reporting, event correlation, and practical exam visibility.
- Syslog: useful for third-party SIEM integration and independent validation.
FortiAnalyzer delivery checklist
- Confirm FortiAnalyzer server IP and source IP.
- Confirm route from FortiGate to FortiAnalyzer.
- Confirm reliable/OFTP settings and encryption settings.
- Confirm the FortiGate is authorized on FortiAnalyzer.
- Generate test logs and confirm arrival.
CLI anchors
diagnose log testGenerate test logs to verify local and remote delivery.
execute log filter resetClear CLI log display filters.
execute log displayShow logs from the selected source.
diagnose test application oftp 1Check FortiAnalyzer/OFTP state.
diagnose sniffer packet any 'host 8.8.8.8' 4 20 lPacket path visibility with interface names.
diagnose debug flow trace start 100Policy, route, NAT, and inspection path tracing.
diagnose debug duration 300Limit debug runtime to avoid leaving noisy debug enabled.
diagnose hardware sysinfo conserveConfirm or rule out conserve mode.
Reading traffic logs
For practical troubleshooting, the high-value fields are usually srcip, dstip, srcintf, dstintf, policyid, action, service, sentbyte, and rcvdbyte. Those fields tell you which policy matched, what FortiGate did, and whether traffic was one-way or bidirectional.
NSE 8 WATCHPOINTS
- Policy ID 0, the implicit deny, does not log by default.
- Severity is a filter. If the threshold is too high, lower-severity logs are intentionally omitted.
- Flow debug without filters can flood the console; filter first, then trace, then enable debug.
action=denyandaction=dropcreate different client symptoms.- FortiView depends on logs. Empty FortiView does not always mean empty traffic.
- Conserve mode can make security features appear to stop working because the unit is protecting itself.
Lab exam checkpoint
Goal: build proof habits. Enable logging on a test policy, generate allowed traffic, generate denied traffic, enable implicit deny logging in a lab context, verify logs locally and on FortiAnalyzer, then prove the same path with sniffer and flow debug.