ActiveGate extension that remotely monitors Unix OS and process metrics by connecting via SSH and executing commands.
Unix/Linux is often used to run critical applications. A OneAgent is the best way to monitor such systems, however this is not always possible. Legacy unsupported versions or agreements with vendors may prevent you from installing a OneAgent on these important hosts. In these cases you can use the Remote Unix Monitoring extension to collect valuable telemetry on your hosts and the applications they are running. It works by connecting to your Unix/Linux hosts over SSH and running commands.
The following OSs are explicitly supported and can be selected in the configuration:
Many other distributions such as Ubuntu can be monitored by selecting 'Generic Linux.'
Calculation estimates yearly DDU usage:
(21 + (4 * <number of CPUs>) + (2 * <matching_filtered_processes>) + (2 * <process_groups>) + (3 * <matching_mounts>) + (8 * <network_interfaces>) + (2 * <disks>)) * 525.6
Once configured and 'OK' states reported you can see the custom devices by going to the 'Technologies and processes' page and selecting the group for 'Remote Linux.' You'll find your instances under the groups you have configured.
To create alerts go to settings and define custom events for alerting using the metrics asociated with this extension.
unzip -o -d /opt/dynatrace/remotepluginmodule/plugin_deployment custom.remote.python.remote_agent.zip
.../plugin_deployment/custom.remote.python.remote_agent/<plugin source and files>NOT
.../plugin_deployment/custom.remote.python.remote_agent/custom.remote.python.remote_agent/<plugin source and files>
Settings > Monitored technologies > Custom extensions > Upload extension
Create an endpoint for each cluster you would like to monitor. This is done in
Settings > Monitored technologies > Custom extensions > Remote Linux Monitor.
The parameters are:
Metrics will be reported to custom devices under the "Remote Linux" technology category. The Group and Device names will depend on your configuration.
Commands used are based on what is available in a 'vanilla' installation of the given OS, so typically no additional installs will be required.
Required commands must be available on the 'PATH' set for non-login shells, which can be different from login shells which is what you use when manually SSHing into a server. If you see log entries that commands are missing check that the command is available and that it is in the 'PATH' for non-login shells. If not, you can either correct this via configuration on the host or use the custom path configuration field to manually set a path to use.
You can test commands in non-login shells by running the ssh command with the command to run appended:
ssh <host> <command>
To view the path you can try:
ssh <host> "echo $PATH"
The logs under
%PROGRAMDATA% (windows) or
/var/lib (linux) give us more details in case of failures
The full path is
For some authentication errors you may need to check authentication/access logs on the target host for details as to why a connection is failing.
Debug logging should only be set when necessary and then reverted to avoid excessive logging.
Extend the platform,
empower your team.