| Description | This article describes some key tips for interpreting a performance report from a FortiDLP agent to assist in troubleshooting performance-related issues. |
| Scope | FortiDLP. |
| Solution |
Agent performance reports help diagnose and resolve high CPU or memory usage on managed nodes.
For example, the report could identify performance issues caused by:
Information on gathering performance reports locally, remotely, or automatically can be found in this document: Viewing FortiDLP Agent performance reports.
The performance report can be accessed by unzipping the zip file and opening index.html (Once unzipped, this is located at performance-report/index.html) in a browser. This will display a page collating the performance data in a human-readable format. Each of the most relevant sections is detailed below: Resources. This section captures Agent resource utilization trends as an exponential moving average (EMA) over time. This is a good place to start looking at a performance report, as it can help to confirm whether the agent was consuming an unusually high number of resources, and whether this was consistent over the past hour, or just a single spike. By hovering over a specific data point or referencing the table, it can also be determined which specific process was causing spikes.
In the example above, it can be seen that contentng.exe is utilizing an unusually high amount of CPU. As this is the process responsible for content inspection, it may be the case that there is one or more misconfigured policies that are doing an unexpectedly high amount of content inspection. In this case, it may be useful to next look at the Policy execution times section of the performance report (see below).
If there are no apparent CPU or memory spikes, it should first be verified that the performance report was taken at the time that the user was experiencing performance issues, as the report will only contain up to the last 60 minutes of data. If this is the case and there are still no spikes, then other possible causes of performance issues separate from the FortiDLP Agent should be investigated. For example, it should be verified that all FortiDLP paths/processes are excluded from any antivirus scanning.
Top Processes. This section highlights system event process trends over time. System event counts are recorded in 1-minute intervals for up to 15 minutes, with the most recent data shown on the left of its column. Note that excluded processes will display with the suffix 'excluded'.
If there is a process in this table with a Total count significantly higher than others, and the process is not significant for DLP use cases, then it may be worth disabling Agent monitoring for the process by adding it to the list of excluded processes in the relevant Creating Agent configuration groups.
It could also be the case that these system events are triggering a large number of policies/content inspection, which could also be contributing to performance issues. This can be supported by evidence from the Policy execution times and Policy Invocations sections (see below).
Policy execution times. This section captures policy execution trends over time. Execution times are recorded in 1-minute intervals for up to 60 minutes, with the most recent data shown on the left of its column.
Often, the most useful part of this table to look at is the Total execution time (ms) column at the far right of the table. If this is a significant proportion of the 15-minute interval over which it was collected, then this indicates that that specific policy is spending a significant amount of time doing work (and therefore likely utilizing a significant amount of resources).
The configuration of this policy should be analyzed in the FortiDLP console to see whether it can be made more efficient. For example, if it is a Sensitive file opened policy, could this be restricted to a specific folder or specific file types? This would greatly reduce the number of files on which the Agent is running content inspection, which could lead to performance improvements.
Policy Invocations. This section captures policy invocation trends by process and source event type, known as an entry point. Policy invocation counts are recorded in 1-minute intervals for up to 60 minutes, with the most recent data shown on the left of its column. Note that unidentified processes will display with an empty process name and binary path, and will be aggregated per entry point.
Note that a high number of invocations does not necessarily mean there will be a high number of detections. Invocations simply refer to any time policy work needs to be done to check whether a policy has been violated.
This table can be used to highlight the processes that are most frequently invoking policies. If a process is frequently invoking policies, then the best next options are:
Policy-initiated actions. This section provides information about policy-initiated actions. It can be useful to verify whether there are any misconfigured policy actions. For example, an excessive number of screenshots is being taken for specific policies.
Muted processes. This section captures processes that are not monitored on macOS. These processes, which produce excessive file events, have been automatically muted to prevent sustained high CPU usage by the Agent.
|
