Please follow these steps to check the issue:
Check if logs files (/var/log/fwlog/root/disklog) are still there.
If no, check if someone executed formatlogdisk command or deleted log files by mistake; if yes, go next step.
Check if mysqld still works:
Check “ps | grep mysqld” to verify the daemon is still running and without keep restarting
Check error.log & check dlog_indexd to see if there are error messages; referring to above section 8.1
Download error.log & check dlog_indexd for further investigation
You can also try to reboot FortiWeb to see if the log issue may disappear
- Execute db rebuild. if it still does not work, go to the next step.
- Diagnose hardware check to see if HD is ok. If no, then go RMA; if yes, keep the debug info and contact support.
Some possible causes:
HA-AA mode: In this mode, all the FortiWebs are active and requests are distributed over them. Every FortiWeb in this mode processes its own requests and keeps its own logs. If you do not see logs on one FortiWeb, check the logs on the other FortiWebs.
Database is rebuilding: Database is rebuilding: For some cases, it would take a long time to complete database rebuild (depending on how many logs there are existing). While the database is rebuilding, newly generated logs are postponed to be written to the database so that the newly generated logs are not available immediately on GUI. The logs are all saved in log files. No log would be lost. Please wait 1 or 2 days to see if there are new logs being generated.
Log version is transferring: In several hours or days (depends on number of existing logs) after upgrading from version earlier than 6.4.0 (5.x and 6.0.x-6.3.x) to 7.0, there might be delay to display new logs on GUI. This is caused by log version upgrade in 6.4.x & 7.0. It takes time to scan and process all existing logs.
Daemons issues: try DB rebuild
For other causes, please follow these steps to check the issue:
- Verify the configuration.
- Verify that logd and indexd are working normally and stably.
Check “diagnose debug application logd” to see if logd is receiving logs.
- if no, it indicates that FortiWeb function/daemons does not send logs to logd. You need to check the issue of corresponding daemons.
- if yes, go to the next step.
Check “diagnose debug application logd” output to see if logs have been saved to log files, or you can double check log files (tail -f /var/log/fwlog/root/disk/tlog.log, or elog.log/alog.log).
if no, check if the log disk is full:
Execute hardware health check to see if hard disk is normal.
if yes, go to next step
- Check dlog_indexd to see if logs are processed and delivered to the log database.
- Collect results of above diagnose steps and download error.log & check dlog_indexd for further investigation.
Check if system cpu usage is very high.
If CPU usage is very high, logs may not be able to be delivered to logd or written to disk, thus cannot be displayed immediately.
- Check if database is rebuilding or log version is transferring because of image upgrade (see details above). You could also check dlog_indexd file in backend shell to see if running
db rebuildor other daemons occupies resource and delays the new logs.