| Description |
This article describes how to obtain a quick overview of the amount of logs recorded for an ADOM in the last 7 days, and how to ensure that new logs have been received when the debug command is run. |
| Scope | FortiAnalyzer 6.x. |
| Solution |
To gain a quick overview of the amount of logs recorded for an ADOM in the last 7 days and ensure the logs are still being received, use the following debug command:
# diagnose fortilogd logvol-adom <adom-name>
In the example, the debug command is run 5 times on the 15th of November from 15:35:49 to 15:37:00. Note that for readability, data for November 13, 12, and 11 has been replaced with '---' in the command output snippet below.
In the above example command output, note the following:
1) The amount of logs received by the 'ADOM-1' ADOM on the 15th of November between 15:35:49 and 15:37:00 increases from 2.31 MB to 2.72 MB (numbers surrounded by a green frame) which confirms that any or all of the devices and/or VDOMs belonging to this ADOM are still sending logs.
2) The average amount of logs received over the last 7 days is dynamically recomputed and increases accordingly (numbers surrounded by a red frame).
When a device is configured in 'multi-vdom' mode with the VDOMs dispatched to different ADOMs, where each ADOM potentially manages several VDOMs, it can be difficult to know whether a specific VDOM is sending logs at any given time: while the debug commands of the fortilogd process provide data at the ADOM level, they do not provide any specific data on each VDOM managed by the ADOMs. The below example screenshots showcase a device composed of 4 VDOMs wherein the 'root' and 'vdom-1' VDOMs are managed by the 'root' ADOM, while the 'vdom-2' and 'vdom-3' VDOMs are managed by the 'ADOM-1' ADOM:
The 'vdom-2' and 'vdom-3' VDOMs are both managed by 'ADOM-1'. The number of logs received by ADOM-1 globally increases when using the 'diagnose fortilogd logvol-adom <adom-name>' command, making it impossible to tell whether 'vdom-3' is sending logs effectively. To find this information, use the debug command 'diagnose test application fortilogd 4' as a complementary command and monitor whether the 'last_recv_time' variable of each VDOM belonging to ADOM-1 increases over time.
In the following example, both debug commands are run 3 times on November, 16 from 10:39:00 to 10:44:15.
In the first capture below, the cumulative file size of logs received by 'ADOM-1' is 389.31 KB (number surrounded by a green frame) while the 'last_recv_time' variable for both 'vdom-2' and 'vdom-3' is set to the UNIX epoch date and time stamp value of '1668591540' (numbers surrounded by an orange frame), which corresponds to Wed Nov 16 2022 10:39:00 GMT+0100.
In the second capture below, the size of logs received by 'ADOM-1' increased to 530.36 KB overall. The 'last_recv_time' variable for 'vdom-2' is set to the UNIX epoch date and time stamp value of '1668591715', which corresponds to Wed Nov 16 2022 10:41:55 GMT+0100. Meanwhile, the 'last_recv_time' variable for 'vdom-3' is still set to '1668591540' (meaning it has not increased since the previous capture)
In the third capture below, the size of logs received by 'ADOM-1' increased to 711.78 KB overall. The 'last_recv_time' variable for 'vdom-2' is set to the UNIX epoch date and time stamp value of '1668591855', which corresponds to Wed Nov 16 2022 10:44:15 GMT+0100. Meanwhile, the 'last_recv_time' variable for "vdom-3" is still set to '1668591540' (which, again, means it has not increased since the previous capture)
It's possible to conclude from the 3 captures above that, if the logs were indeed received by 'ADOM-1' during the 5 minutes monitoring period, those logs were all received from 'vdom-2' and not 'vdom-3'. This indicates a potential problem in the logging process for vdom-3. |
