Courseiva
NSE4Chapter 12 of 14Objective 7.1

Logging, Monitoring, and Alerts

Exam objective 7.1 — Configure logging to local and remote destinations, enable alerts, and use the FortiGate dashboard for monitoring — is about giving your network a memory and a pair of watchful eyes. Without logging and monitoring, you are flying blind: you have no way to know what happened during a security incident, who attacked, or whether your defences actually stopped them. For the NSE4 exam, you need to understand how to turn on logging, where logs can be stored, what alerts mean, and how to read the dashboard to spot problems before they become disasters.

12 min read
Intermediate
Updated Jul 24, 2026
Editorial oversight: Johnson Ajibi· Security Systems Architect · MSc IT Security · IEEE Senior Member

A simple way to picture Logging, Monitoring, and Alerts

The Building Security Desk Analogy

A building's security desk is the central nervous system of safety for the entire structure.

Every person who enters or leaves the building signs a logbook, recording their name, purpose, time of entry, and time of departure. A security guard monitors the live camera feeds on a bank of screens, watching for anything unusual — someone propping a fire door open, an unauthorised person tailgating behind an employee, or a package left unattended in the lobby. The guard also keeps a separate clipboard for incidents: when a fire alarm triggers a false alarm, when a visitor loses their badge, or when a delivery truck blocks the loading bay. Each incident gets a timestamp, a description, and a resolution note.

If someone tries to force the main door after hours, an alert sounds on the guard's console, and a red light flashes on the master panel. The guard can then look at the logbook to see who was in the building at that time, check the camera feeds for visual evidence, and review recent incident records to see if there have been other break-in attempts. This system of logs, live monitoring, and alerts lets the guard protect the building, investigate problems, and prove what happened to building management or law enforcement. A FortiGate does exactly this for a computer network — it keeps detailed logs of network traffic, monitors activity in real time on a dashboard, and sends alerts when it detects something suspicious or dangerous.

How It Actually Works

Logging, monitoring, and alerts are the three pillars of network visibility. Think of them as the record-keeping, live surveillance, and emergency notification systems for your FortiGate firewall.

Logging is the process of recording events that happen on the FortiGate. Every time a packet passes, a user logs in, or an attack is blocked, the FortiGate can create a log entry. That entry contains details like the source IP address, destination IP address, port numbers, the action taken (allowed or denied), and a timestamp. These logs are like a detailed diary of all network activity. By default, some logging is enabled, but for the exam you must know how to configure it properly.

A log entry is a single record in that diary. A log file is a collection of those entries, usually organised by date or type. Logs can be stored locally on the FortiGate's hard drive or solid-state drive, or they can be sent to a remote destination — something called a syslog server, a FortiAnalyzer appliance, or a cloud-based logging service. Sending logs off the FortiGate is important because if the FortiGate itself is compromised or crashes, local logs may be lost. Remote storage keeps them safe for later analysis or compliance audits.

Monitoring is what happens in real time. The FortiGate dashboard is a graphical interface that shows you live data about your network traffic, security events, system resources, and user activity. You can see how many sessions are active, which applications are consuming bandwidth, whether there is a spike in blocked attacks, and how much memory the FortiGate is using. Monitoring helps you detect problems the moment they start — before they escalate. You can also create custom dashboard widgets, save dashboard layouts, and toggle views to focus on what matters most.

Alerts are automatic notifications triggered when the FortiGate detects a specific event or condition. For example, you can configure an alert to send an email when a new malware signature is detected, when a user logs in from a suspicious country, or when the CPU usage exceeds 90%. Alerts are not logs — they are warnings designed to get your attention immediately. You define the conditions, the severity level, and where the alert should go (email, SNMP trap, or syslog). On the exam, you must know the difference between log messages and alert messages, and how to configure alert email settings under Log & Report > Alert Email Settings.

Severity levels are used to classify how serious an event is. FortiGate uses standard syslog severity levels: Emergency (0), Alert (1), Critical (2), Error (3), Warning (4), Notification (5), Informational (6), and Debug (7). You can filter logs by severity so you only see critical events, or analyse all informational logs for forensic investigations. You can also set alerts to trigger only for events above a certain severity threshold.

FortiGate supports multiple log types:

Traffic logs: record every session that passes through the firewall — who connected, where they went, what protocol (HTTP, HTTPS, DNS, etc.), and whether the FortiGate allowed or blocked it.

Event logs: record administrative actions, system events, user authentications, VPN connections, and configuration changes.

Security logs: record threats detected by security features like antivirus, intrusion prevention system (IPS), web filtering, and application control.

Flat logs: older style logs that are not parsed into structured fields — mostly legacy, but still tested in NSE4.

Log formats include Comma-Separated Values (CSV), Key-Value (KV), and Syslog formats. You can export logs for offline analysis in tools like Excel or a Security Information and Event Management (SIEM) system.

Why logging, monitoring, and alerts exist: before firewalls had these capabilities, network administrators had no visibility. If a breach happened, they might not even know for days or weeks, and they had no records to trace what went wrong. Compliance regulations like GDPR, PCI DSS, and HIPAA now require organisations to keep detailed logs, monitor network activity, and respond to security events in a timely manner. Without proper logging and alerts, you cannot prove you are compliant, and you cannot effectively defend your network.

What it replaces: In the early days of networking, administrators relied on simple counters and manual inspection of each device. Logging and monitoring replaced guesswork with data. Instead of wondering if an attack succeeded, you have concrete evidence. Instead of waiting for a user to complain about slow internet, you can see on the dashboard that a bandwidth-heavy application is saturating the link. Alerts replace the need to constantly watch the dashboard — they notify you only when something requires action, freeing you to do other work.

Flowchart showing how the FortiGate generates logs and alerts, stores them locally or remotely, and enables real-time monitoring through the dashboard.

Walk-Through

1

Enable Global Log Settings

Navigate to Log & Report > Log Settings. Here you choose where logs are stored: local disk, remote syslog server, FortiAnalyzer, or both. You also set log formats (CSV, syslog, or key-value) and define log roll (how long to keep old logs before deletion). This is the foundation — without enabling global storage, no logs will be saved even if policies log traffic.

2

Enable Logging on Firewall Policies

Go to Policy & Objects > Firewall Policy and edit each policy. Under Logging, check the box 'Log All Sessions' or 'Log Security Events' (depending on whether you want every session logged or only those that trigger security profiles). This step is the one beginners most frequently miss. If a policy does not have logging enabled, the FortiGate will not record that traffic even if the global settings are configured.

3

Configure Alert Email Settings

Go to Log & Report > Alert Email Settings. Click Create New. Define the event type (e.g., IPS signature, antivirus detection), the severity threshold (e.g., Critical and above), and the email recipients. Configure the SMTP server details (address, port, authentication). Click Send Test Email to verify the configuration works. Without this step, you will not receive alerts when security incidents occur.

4

Set Up Dashboard for Real-Time Monitoring

Log into the FortiGate GUI and go to the Dashboard tab. Click the '+ Widget' button to add widgets that show System Resources, Top Applications, Security Events, VPN Status, and Active Sessions. Rearrange widgets by dragging them. Save the dashboard layout to your administrator profile. This gives you a single-pane view of network health and lets you spot anomalies immediately.

5

Check and Export Logs for Analysis

When an incident occurs or you need to investigate, go to Log & Report > Forward Traffic (or Security Events, or Event Log). Use the filter fields at the top to search by source IP, destination IP, date range, or action. Click Export to save the filtered log as a CSV file for offline analysis or compliance evidence. This step turns raw data into actionable intelligence.

6

Review Alerts and Take Action

When you receive an alert email, log into the FortiGate and navigate to the relevant log type (e.g., Security Events) to view the details. Confirm whether the action taken (blocked, allowed, quarantined) was appropriate. If needed, update firewall policies, add IP addresses to blocklists, or adjust security profiles. Document the incident for your organisation's incident response records.

What This Looks Like on the Job

Imagine you work as the IT administrator for a medium-sized company with 200 employees. The company uses a FortiGate firewall to secure its internet connection and separate internal departments. One Tuesday morning, employees in the finance department complain that the accounting software is running extremely slowly.

Your first step is to open the FortiGate dashboard. You look at the Top Applications widget and see that a streaming music service is consuming 70% of the internet bandwidth. That is not a security issue, but it is slowing down critical business applications. You check the Traffic Logs for the past hour to confirm which employees are using the streaming service, and then you create a firewall policy to block or throttle that application during business hours.

The next day, you receive an alert email from the FortiGate saying that an intrusion prevention system (IPS) signature matched a known exploit against a finance server. You immediately open the Security Logs and see the source IP address (a public IP from a foreign country), the destination IP (the finance server), and the action taken (the FortiGate blocked the attack). You note the incident in your incident response log, and you send an email to your manager confirming the attack was blocked. You also add that source IP to a local blocklist as a precaution.

A week later, during a compliance audit, the auditor asks for proof that the company monitors and logs all network activity. You produce the logs stored on your central FortiAnalyzer for the past six months. The auditor sees timestamps, source and destination IPs, allowed and blocked actions, and confirms your logging policy is compliant with regulations.

Here is what you actually do step by step:

Log into the FortiGate web interface using an administrator account with logging privileges.

Go to Log & Report > Log Settings to configure logging — enable traffic logging, event logging, and security logging for each firewall policy and security profile.

Under Log & Report > Log Setting > Log Configuration, choose a local destination (disk) or a remote destination such as a syslog server or a FortiAnalyzer device. Enter the IP address and port (default 514 for syslog) of the remote server.

Go to Log & Report > Alert Email Settings to create alert rules. For each rule, define the event type (e.g., IPS signature detected), the severity level (e.g., critical or higher), and the recipient email addresses. You can also set an email subject and enable or disable the alert.

Check the dashboard widgets — you can add, remove, and rearrange widgets like System Resources, Top Sources, Top Destinations, Security Events, and Active Sessions. The exam tests that you know which widget shows which data.

To search logs, go to Log & Report > Forward Traffic, Local Traffic, or Security Events, and use the filter fields (source IP, destination IP, port, action, date range). You can also save search queries as filters for future use.

Export logs by clicking the Export button on the log view page. You can choose CSV or custom format.

A common daily routine: review the top security events on the widget, check the system resource usage (memory and CPU) to see if the FortiGate is overloaded, and glance at the VPN status to make sure tunnels are up. Then, if you see anything unusual (a blocked traffic spike, a failed VPN connection, or a critical alert email), you investigate the logs and take corrective action. This workflow is exactly what the NSE4 exam expects you to be able to configure and explain.

How NSE4 Actually Tests This

The NSE4 exam tests logging, monitoring, and alerts in multiple ways. You will see multiple-choice questions about configuration steps, terminology, and best practices. There are also scenario-based questions where you must decide which log type to check or which dashboard widget to use.

Specific exam topics you must know:

Log destinations: local disk on the FortiGate, syslog server (any third-party or FortiAnalyzer), FortiAnalyzer appliance, and cloud logging via FortiGate Cloud. Know the advantages and disadvantages of each. For example: local logs are faster but vulnerable to loss; remote logs are safer but increase network traffic. The exam loves the term FortiAnalyzer as the best remote logging destination.

Log types: traffic logs, event logs, security logs, and flat logs. Memorise what each contains. A typical question: 'Which log type would you check to see if a user's web request was blocked by web filtering?' Answer: Security Logs (specifically the web filter sub-type).

Log severity levels: 0 to 7. Know that Emergency (0) is the highest severity and Debug (7) is only for troubleshooting. A question might ask: 'At what severity level should an alert be set for a critical IPS event?' Answer: Critical (2) or higher.

Dashboard widgets: know the names and purposes of at least 10 widgets: System Resources, Top Applications, Top Sources, Top Destinations, Security Events, Active Sessions, VPN Status, CPU Usage, Memory Usage, and Disk Usage. A question might show a screenshot and ask which widget is used to see the most blocked attacks.

Alert email settings: where to configure them (under Log & Report > Alert Email Settings), how to set SMTP server, authentication, and trigger conditions. The exam expects you to know that you can test alert email configuration with a 'send test email' button.

Log search and filters: you must know how to filter logs by date, source IP, destination IP, action, service, and severity. The exam tests that you can locate information quickly.

Log export: know the supported formats (CSV and custom). A question might ask: 'Which format allows you to open logs in a spreadsheet application?' Answer: CSV.

Common traps the exam sets:

Confusing 'traffic log' with 'security log'. A traffic log records all sessions; a security log records only blocked or suspicious events. If a question says 'a user accessed a blocked website', it is a security log event, not a traffic log event.

'Flat logs' sound outdated but appear in the exam. They are not structured and are hard to search. The exam tests that you know they are disabled by default and not recommended for modern use.

Alert vs. log message: alerts are notifications sent based on pre-defined conditions; logs are records stored for review. A question might say 'You want to receive an email when an IPS attack is blocked' — the correct answer is to configure an alert email, not just enable logging.

The dashboard widget names: they are case-sensitive and exactly as Fortinet defines them. 'Top Sources' is different from 'Top Source'. The exam will list plausible but incorrect names.

Configuring logging globally vs. per-policy: you must enable logging in the firewall policy (set logtraffic to enable or utm) and also in the global log settings. A common mistake is to enable only one of them.

Key definitions to memorise: - Syslog: standard protocol for sending log messages across a network. - SIEM: Security Information and Event Management system that collects and analyses logs from multiple sources. - Log buffer: temporary memory storage for logs before they are written to disk. - Log roll: automatic deletion of old logs to free space. - Event handler: a FortiGate feature that can trigger scripts or actions when certain events occur.

Key Takeaways

Logs are stored records of events; alerts are real-time notifications triggered by specific conditions.

You must enable logging per firewall policy — global logging settings do not make policies log automatically.

The three primary log types every administrator must know are traffic logs, event logs, and security logs.

Remote logging to a FortiAnalyzer or syslog server protects logs from being lost if the FortiGate fails.

The FortiGate dashboard is for real-time monitoring, not historical analysis — use logs for past events.

Alert email settings are configured under Log & Report > Alert Email Settings, where you define triggers and recipients.

Severity levels range from 0 (Emergency) to 7 (Debug); set alerts only for levels that demand action, like Critical or higher.

Flat logs are legacy and not recommended — modern FortiGate uses structured logs that are searchable and filterable.

A dashboard widget can be customised, resized, and moved to suit your monitoring needs — you are not stuck with defaults.

Archiving logs for compliance often requires storing them remotely for at least six months to meet regulations like GDPR and PCI DSS.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

Local Logging

Stored on the FortiGate's internal disk or SSD

Vulnerable to loss if the FortiGate crashes or is compromised

Faster access for immediate troubleshooting

Remote Logging

Sent to an external server like FortiAnalyzer or syslog server

Safe from local hardware failure or attack on the FortiGate

Enables centralised analysis across multiple devices

Logs

Passive records of past events

Stored in files for later review or compliance

No action triggered automatically when created

Alerts

Active notifications sent in real time

Configured to trigger email, SNMP, or syslog messages

Designed to get immediate attention from an administrator

Traffic Logs

Record every session through the firewall

Include allowed traffic, not just threats

Used for bandwidth analysis and usage monitoring

Security Logs

Record only events where security features take action

Show blocked attacks, malware, and policy violations

Used for incident investigation and threat analysis

Watch Out for These

Mistake

Once I enable logging globally, all firewall policies automatically log traffic.

Correct

You must enable logging individually on each firewall policy under the Logging section. Global settings only control storage format and destinations.

FortiGate architecture separates configuration layers. Beginners expect a master switch, but each policy has its own logging toggle for granular control.

Mistake

Alerts and logs are the same thing — an alert is just a type of log.

Correct

A log is a stored record of an event. An alert is a real-time notification sent by email, SNMP, or syslog when a pre-defined condition is met. They serve different purposes.

The terms are used loosely in general conversation, but the exam is strict about the distinction.

Mistake

If I send logs to a remote server, I do not need to keep any logs locally on the FortiGate.

Correct

You can choose local only, remote only, or both. Many administrators keep logs locally for immediate troubleshooting and also send them remotely for long-term storage. The exam tests the 'both' option as best practice.

Beginners often think remote logging completely replaces local storage, but local logs are still useful for quick access when the remote server is down.

Mistake

The dashboard shows historical data from months ago.

Correct

The dashboard shows real-time and near-real-time data only. Historical data is found in logs, which you must search and filter.

People associate dashboards with 'reports' that span time periods, but FortiGate's dashboard is a live view widget.

Mistake

Debug severity logs are useful for everyday monitoring.

Correct

Debug (severity 7) logs are extremely verbose and intended only for troubleshooting specific issues. They should be disabled in production because they can fill disk space quickly and slow down the system.

The word 'debug' sounds like it helps you understand problems, but it actually floods you with noise.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

What is the difference between a traffic log and a security log?

A traffic log records every session that passes through the FortiGate, regardless of whether it is allowed or blocked. A security log records only events where a security feature (antivirus, IPS, web filter, etc.) took action, such as blocking a malware download or blocking a malicious website.

Can I set up alerts to send emails without configuring a FortiAnalyzer?

Yes you can. Alert email settings are independent of FortiAnalyzer. You configure an SMTP server directly in the FortiGate under Log & Report > Alert Email Settings. You do not need a separate logging appliance to receive email alerts.

Why can I not see any logs after enabling logging globally?

The most common reason is that you forgot to enable logging in the individual firewall policies. Go to Policy & Objects > Firewall Policy, edit each policy, and ensure 'Log All Sessions' or 'Log Security Events' is checked.

How long do logs stay on the FortiGate local disk?

It depends on the log roll settings. By default, logs are kept until the disk reaches a configured percentage (e.g., 90% full), then the oldest logs are deleted. You can also set a maximum age in days. For long-term storage, you must send logs to a remote destination like FortiAnalyzer.

What does 'flat log' mean and should I use it?

A flat log is a legacy format where each log entry is a single line of unparsed text. It is difficult to search and filter. Modern FortiGate defaults to structured logs (CSV or Key-Value). You should avoid flat logs because they are not supported by most SIEM systems and are harder to analyse.

How do I know if my alert email test worked?

After clicking 'Send Test Email', check the email inbox of the recipient you specified. If it does not arrive within a few minutes, verify the SMTP server settings (address, port 25 or 587, and authentication credentials). Also check that the FortiGate can reach the SMTP server over the network.

Terms Worth Knowing

Keep going

You've finished Logging, Monitoring, and Alerts. Continue through the NSE4 study guide to build a complete picture of the exam.

Done with this chapter?