| Description | This article describes a troubleshooting use case for the syslog feature. |
| Scope | FortiGate vv7.0 onwards. |
| Solution |
There is a new process 'syslogd' was introduced from v7.0 in the FortiOS. When the syslog feature is enabled, the miglogd process is only used to generate logs, and then logs will be published to the subscribers such as syslogd.
In certain cases to troubleshoot Syslog, one step is to compare the log statistics between these two daemons with the following commands:
diagnose test application miglogd 4
Here is an example:
From the output, the log counts in the past two days are the same between these two daemons, which proves the Syslog feature is running normally.
The following command can be used to check the log statistics sent from FortiGate:
diagnose test application syslogd 4
In this case, 903 logs were sent to the configured Syslog server in the past seven days.
Note: If the connectivity is already established and some logs are not received on the Syslog server, it is worth checking if any filtering via free-style filters is configured on the FortiGate.
Take the configuration example below, this would effectively exclude all traffic logs, including 'information' and 'notice' levels from being sent out to the syslog server, greatly limiting visibility into traffic-logs.
config free-style The filter above would need to be adjusted to not filter out potentially useful logs. Refer to this KB article for more information on free-style filters: Technical Tip: Using syslog free-style filters - Fortinet Community.
To verify if the FortiGate is sending the required logs or excluding the correct logs, it is recommended to capture the traffic using FortiGate packet capture through GUI or via CLI as per the following documents: Troubleshooting Tip: Packet Capture on FortiOS GUI
Related articles: |
