-
Notifications
You must be signed in to change notification settings - Fork 2
Analyzing Sensor Storage Performance
After each successful sensor run, the results of the run are stored in the database during the storage phase of that sensor. If database performance (or storage server performance) is sluggish these storage times can become long. It can be helpful to know which sensors are taking the longest to store their results, because then you can analyze whether that sensor is needed or if there are configuration changes you can make to that sensor to help performance.
The attached script can be used to analyze a discovery run and give total and average storage times for all the sensor types that ran and stored results. Download storage.jy and additionally for Windows storage.bat to $COLLATION_HOME/custom (create if necessary). Run storage.bat (Windows) or storage.jy (Linux) without any arguments to see the usage. Output is in CSV format with a header describing the columns.
Note that the script assumes that the discovery was run to completion. If the discovery was aborted or if sensors end in a storage error this might affect the results of script output.
Best Practices
Sensors
- Supported Target Systems
- Generic Server Sensor (lsof)
- Enhanced CPU Discovery
- Discovering Batch Jobs
- Duplicate Reducer
- VMware Instance Extention
- RHEL Cluster Discovery
- Collecting certs with nmap
- MQ Discovery
- Windows Discovery
- Oracle Discovery
- IIS Discovery
- Ping Sensor
- Collect Config Files Recursively
- Shallow Server Discovery
- Host Storage Sensor