Opsview Agents Installation
Details on how to use an agent to monitor a device
Overview
There are three basic approaches to monitoring devices on your network
- The device sends details into Opsview Monitor when events happen or on a regular schedule (see SNMP Traps and Passive Checks )
- Opsview Monitor run checks to test network connectivity to the host and the services it provides ( Active Checks and SNMP Polling )
- Opsview Monitor talks to an agent installed on the device to see what is happening 'on the inside'
This document discusses how to achieve the last item in the list.
Using the ITRS Infrastructure Agent
The ITRS Infrastructure Agent is the recommended agent to install on monitored servers, and supports both Windows and Linux.
The Infrastructure Agent enables communication between systems by running a daemon that Opsview Monitor Collectors can use to interrogate the status of the system. It provides some default plugins (for checking on RAM, CPU, and DISK, amongst others) that Host Templates within Opsview Monitor can make use of straight away, but can be extended with additional plugins.
For installation details on any distribution see Infrastructure Agent Installation.
Warning
We do not recommend manually installing or upgrading the Infrastructure Agent on servers which run Opsview Monitor itself, as these already have packages managed by Opsview Deploy.
Using the Opsview Agent (deprecated)
Opsview Agent Deprecation
The Opsview Agent and the steps below are now deprecated, and we instead recommend use of the ITRS Infrastructure Agent.
Please follow the instructions above for the most up-to-date information.
Linux Servers
We provide an agent package for all supported platforms for the Opsview Master within our repositories which will be installed automatically when you install any of Opsview Components.
For monitored hosts we also make agent packages available for other platforms through the Opsview Download page. Installing this package will start a daemon that Opsview Monitor Collectors can use to interrogate the health of the system. It provides some default plugins (for checking on RAM, CPU and DISK, amongst others) that Host Templates within Opsview Monitor can make use of straight away.
You will need to ensure firewall access is open from relevant Collectors to port 5666.
You may also use any NRPE compatible agent and plugins, but you may need to configure both the agent and Opsview Monitor to make best use of it.
Installation
On Debian and Ubuntu
sudo apt install /path/to/downloaded/opsview-agent*.deb
On RHEL, OL and CentOS
sudo rpm -Uvh /path/to/downloaded/opsview-agent*.rpm
Note: The agent installation may fail on systems where SELinux is enabled; the agent should successfully install the second time it is attempted
Microsoft Windows Servers
Agent Based Monitoring
Similar to Linux Servers above, an agent can be installed on the system. This agent is available on https://www.opsview.com and also includes some plugins usable with pre-defined Host Templates in Opsview Monitor.
You may also use any NRPE compatible agent and plugins (such as NSClient++), but you may need to configure both the agent and Opsview Monitor to make best use of it.
Powershell Agentless Monitoring
Overview
An alternative method to monitor Microsoft Windows servers is to use agentless monitoring. This is where access is granted to run powershell scripts to specific users over a secure channel. The plugins used are stored within Opsview Monitor and are sent to the Windows server for execution, with the results being returned. This allows for centrally managing the Windows plugins and there is no need to keep agent software up to date on the target devices.
Installation
By default, Windows hosts will not allow PowerShell remote scripts to run, and so it must be enabled. This can be configured manually by the Windows Host administrator, or automatically using our recommended way which is using the following Powershell script on the Windows Host. This, can be downloaded from: https://downloads.opsview.com/ConfigureRemoting.ps1.
You need version 5.x of Powershell for Powershell Agentless Monitoring. Check your Powershell version by running $PSVersionTable.PSVersion within a Powershell terminal.
You need to run the ConfigureRemoting.ps1 script with Administrator privileges using a Powershell terminal. This will configure firewall rules, self-signed SSL certificates and authentication for PowerShell remote access.
You can check Powershell has been configured successfully by running the command winrm quickconfig.
By default, port 5985 and/or port 5986 must be opened from the Opsview monitoring server to the Windows host you wish to check. WinRM utilises the HTTP/HTTPS protocol and can be configured to use certificates to secure the data in transit.
Test to ensure the service is listening run:
For HTTP: netstat -an | findstr 5985
For HTTPS: netstat -an | findstr 5986
When using basic authentication with WinRM, the following commands must also be entered on the windows host:
winrm set winrm/config/service/auth '@{Basic="true"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/client/auth '@{Basic="true"}'
If you see a 500 error (which is a known issue on Windows Server 2016) you may need to install WinRM-IIS-Ext. Run the following command Add-WindowsFeature winrm-IIS-Ext.
Test connectivity from the orchestrator/collector to the windows host. Substitute for the IP of the windows host. A return of 0 means the connectivity is ok.
For HTTP: nc -z -w1 <ip> 5985;echo $?
For HTTPS: nc -z -w1 <ip> 5986;echo $?
Usage
Opsview 6.0 onwards will have the winrm package installed automatically and have the check_by_winrm.py plugin installed by default. This plugin is used by monitoring plugins to be run on the Windows Host.
check_by_winrm.py usage is as follows:
$ ./check_by_winrm.py
-H <HOST>: The IP address or resolvable name of the Windows host
-P <PORT>: The TCP port for connecting to the Windows host. Defaults to 5985 (HTTP) or 5986 (HTTPS)
-u <USER>: The Windows username; required unless using certificate transport
-p <PASS>: The Windows password; required unless using certificate transport or pre-authenticated kerberos transport
-t <TRANSPORT>: The authentication mechanism. One of: basic|certificate|kerberos|ntlm|credssp
-s <SCHEME>: Either HTTP or HTTPS
-i: Ignore certificate validation errors when using HTTPS
-C <CA_CERT_PATH>: The CA certificate (bundle) to be used for validating the HTTPS certificate on the server
-c <CERT_PATH>: The client certificate when using certificate transport
-k <CERT_KEY_PATH>: The client certificate key when using certificate transport
-D: Whether kerberos delegation should be used (default: False). This enables the PowerShell script to use your Kerberos ticket to jump to other hosts. Only useful when using Kerberos transport.
-r: The read timeout seconds when reading back from the WinRM connection
-o: The operation timeout seconds when waiting for a WinRM operation to complete
<SCRIPT>: The name of the powershell script to execute. This should be either relative to CWD, absolute, or relative to the plugins.d directory
<PARAMS>: The parameters to pass to the powershell script, if required.
Example Usage:
$ check_by_winrm.py -H '192.168.16.230' -u 'windows_user' -p 'windows_password' -t 'basic' -s http check_windows_base.ps1 -m cpu_usage
WinRM Host Variables
check_by_winrm.py uses the WINRM_TRANSPORT variables. These variables are:
- WINRM_TRANSPORT - Authentication Transport Type - One of: Basic, Certificate, Kerberos, NTLM, or CredSSP
- WINRM_TRANSPORT:1 - Username for Windows user
- WINRM_TRANSPORT:2 - Password for Windows user
- WINRM_TRANSPORT:3 - One of: HTTP or HTTPS
- WINRM_TRANSPORT:4 - Extra Arguments - Can be used for any additional arguments for check_by_winrm.py
These should be set on each host that uses check_by_winrm.py
Reload to submit your changes. Any hosts configured with Opspacks that use check_by_winrm.py should now be able to remotely run their Powershell monitoring plugins. See the Opspacks section for more details.
Updated 5 months ago