GuidesREST APISlack CommunitySupport PortalOpsview 6.8+ Documentation

Opsview Agents Installation

Details on how to use an agent to monitor a device

Suggest Edits

Overview

As a general rule, to avoid any backwards compatibility issues with older less secured technology, Opsview recommends that the version of the agents used is aligned with the version of Opsview Montior that you are running.

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.

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 via our web site 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.

388

You can check Powershell has been configured successfully by running the command winrm quickconfig.

470

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 over 1 year ago