GuidesREST APISlack CommunitySupport PortalOpsview 6.8+ Documentation

## 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


On RHEL, OL and CentOS

_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:

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 <ip> 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:

Example 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.