This document describes the steps to generate a diagnostic file from AMP For Endpoints Linux Connector. If you experience a technical issue with the Linux Connector, a Cisco Technical Support Engineer might want to analyze the log messages available in a diagnostic file.
Generate Diagnostic File
With the use of this command, you can generate a diagnostic file directly from the Linux Command Line Interface (CLI):
This creates a .7z file on your desktop. You can provide this file to Cisco Technical Assistance Center (TAC) for further analysis.
The Connector's debug mode provides additional verbosity to the logging. It allows more insight into a problem with the Connector. This section describes how to enable debug mode in a Connector.
Warning: Debug mode should be enabled only if Cisco requests this data. If you enable debug mode for a longer time, it can fill up the disk space very quickly and might prevent the Support Diagnostic file to gather the Connector Log due to excessive file size.
Use AMP Console
Enable Debug Mode
You can enable the debug mode in the current policy with steps 5 - 7 or create a new policy in debug mode with all these steps:
Step 1. Log into the AMP console.
Step 2. Select Managment > Policies.
Step 3. Locate the Policy that is applied to the end device or computer and click on the Policy, this will expand the Policy window. ClickDuplicate.
Step 4. After you clickDuplicate, the AMP console updates with the copied policy.
Step 5. ClickEdit, clickAdvanced Settings, and select clickAdministrative Featuresfrom the sidebar.
Step 6. ForConnector Log Level, selectDebugfrom the drop-down lists.
Step 7. ClickSavein order to save the changes.
Step 8. After saving the new policy, you need to create/change a group to include thenew policy, and theend devicewhere you want to generate debug information.
Disable Debug Mode
To disable debug mode, go through the same steps as you completed to enable the debug mode, but change the Connector Log Level to Default.
Use Command Line
Enable Debug Mode
If you experience any connectivity issues to the console, and you want to enable debug mode, run these commands on the CLI:
This is the output:
Daemon now logging at 'info' level until next policy update
Disable Debug Mode
To disable debug mode, use these commands:
/opt/cisco/amp/bin/ampcli ampcli>debuglevel 0
Daemon now logging at 'notice' level until next policy update
Support Tool Tuning while in Debug
The Connector’s daemon needs to be put into Debug Logging mode before beginning support file tuning. This is done via theAMP console, through the Connector’s policy settings atManagement -> Policies. Edit the policy and go to theAdministrative Featuressection under theAdvanced Settingstab. Change theConnector Log Levelsetting toDebug.
Next, save your policy. Once your policy has been saved, ensure it has been synchronized to the Connector. Run the Connector in this mode for at least 15-20 minutes prior to continuing with the rest of the tuning.
NB: When your tuning is complete, don’t forget to change theConnector Log Levelsetting back toDefaultso that the Connector runs in its most efficient and effective mode.
Running Support Tool
This method involves using the Support Tool, an application installed with the AMP Mac Connector. It can be accessed from the Applications folder by double-clicking on /Applications->Cisco AMP->Support Tool.app. This will generate a full support package containing additional diagnostic files.
An alternative, and quicker, method is to run the following command linefrom a Terminal session:
sudo /opt/cisco/amp/bin/ampsupport -x
The first option will result in a much smaller support file containing only the relevant tuning files. The second option provides a full support package which contains more information, such as logs, which may be required for tuning Process Exclusions (available in Connector versions 1.11.0 and newer).
Either way you choose to run it, Support Tool will generate a zip file on your ~home that contains two tuning support files: fileops.txt and execs.txt. fileops.txt contains a list of the most frequently created and modified files on your machine, these will be useful for Path/Wildcard Exclusions. execs.txt will contain the list of the most frequently executed files, these will be useful for Process Exclusions. Both lists are sorted by scan count, meaning the most frequently scanned paths appear at the top of the list.
Leave the Connector running in Debug mode for a 15-20 minute period, and then run the Support Tool. A good rule of thumb is that any files or paths that average 1000 hits or more during that time are good candidates to be excluded.
Creating Path, Wildcard, File Name, and File Extension Exclusions
One way to get started with Path Exclusion rules is finding the most frequently scanned file and folder paths from fileops.txt and then consider creating rules for those paths. Once the policy has been downloaded, monitor the new CPU usage. It might take 5 to 10 minutes after the policy is updated before you notice the CPU usage drop as it might take time for the daemon to catch up. If you are still seeing issues, run the tool again to see which new paths you observe.
A good rule of thumb is that anything with a log or journal file extension should be considered a suitable exclusion candidate.
Creating Process Exclusions
NOTE: Process Exclusions on Linux can only be implemented for ELF files. Users cannot implement Process Exclusions for file formats such as .sh (Shell Scripts).
A good tuning pattern is first identifying the processes with a high volume of executes from execs.txt, find the path to the executable, and create an exclusion for this path. However, there are some processes that should not be included, this includes:
General Utility Programs - It is not recommended to exclude general utility programs (ex: usr/bin/grep) without accounting for the following.
The user can determine what application is calling the process, (ex: find the parent process that is executing grep) and exclude the parent process. This should be done if and only if, the parent process can be safely made into a process exclusion. If the parent exclusion applies to children, then the calls to any children from the parent process will also be excluded.
The User that is executing the process can be determined. (ex: if a process is being called at a high volume by user "root", one can exclude the process, but only for specified user 'root", this will allow AMP to monitor executes of a given process by any user that is not "root").
NOTE:Process Exclusions are new in Connector versions 1.11.0 and newer. Because of this, general utility programs maybe be used as a path exclusion in Connector Versions 1.10.2 and older. However, this practice is only recommended when a performance trade-off is absolutely necessary.
Finding the Parent Process is important for Process Exclusions. Once the Parent Process and/or User of the process are found, the user can create the exclusion for a specific user and apply the process exclusion to children processes, which in turn will exclude noisy processes that cannot themselves be made into process exclusions.
Identify Parent Process
Follow steps 1-3 of Identifying the Parent Process from above.
Identify User of a process using one the following method:
Find the User ID of the given process from U: in the log line (ex: U:0).
From the Terminal window run the following command: getent passwd # | cut -d: -f1, where # is the User ID.
You should see output similar to:Username, whereUsernameis the User of the given process.
This Username can be added to a Process Exclusion under the User category to reduce the scope of the exclusion, which for certain Process Exclusions, is important.
NOTE: if the User of a process is the local user of the machine, and this exclusion must apply to multiple machines with different local users, the User category must be left blank to allow the Process Exclusion to apply to all users.