IT Monitoring for Networks, Applications, Virtual Servers and the Cloud
IT Monitoring for Networks, Applications, Virtual Servers and the Cloud
A plugin is a way of adding functionality to Opsview. Think of an adblocker for Google Chrome or the Facebook app for your iPhone, both of these add functionality to a system (the systems in these cases being Google Chrome and an iPhone).
In Opsview's case, a plugin is used to monitor something (a service, a product, an item). Examples of this could be...
The examples above are just some basic ones so you can get your head around what a plugin can monitor. A plugin can use existing APIs to integrate with a lot of different systems! (Salesforce, AWS, OpenStack, Elastic, UCS, etc..).
A plugin can be created in a range of languages such as Bash, Python or Perl. Currently, the majority of plugins are written in Perl and use the Monitoring::Plugin (previously Nagios::Plugin). Since Opsview is currently based on Nagios, all Nagios plugins can work in Opsview (see the Nagios Exchange for a full list of Nagios plugins).
Whilst a plugin may return data (and its respective units of measurement) to graph and some helpful return text that can be seen within the Opsview Monitor UI, it must return a status in the form of a number from 0-3 (explained below). This fairly minor constraint means you can easily write plugins in nearly any language, for almost any technology you wish.
The plugin return status is interpreted by the Opsview Monitor as the status of the check, so it can show alerts on the dashboard or send out notifications or take other action.
Performance data is returned after the “pipe” symbol (|). This output is normally hidden from the user, but this is what ends up as the data in the graphs and is stored in the ODW (Opsview Data Warehouse) for reporting. The performance data is returned in a special format that allows you to define the units and value; multiple performance metrics can be returned by a single plugin.
The majority of plugins can be defined as using an agent or being agentless.
Agentless - Agentless plugins run on the same machine running Opsview Monitor rather than the host being monitored, performing their checks usually by querying an API. An example of this is the "check_tcp" agentless plugin that queries a port of the host, from Opsview Monitor on its machine, to see if it can establish a TCP connection.
Agent - Agent based plugins require that the NRPE (Nagios Remote Plugin Executor) daemon be running on the host. Opsview Monitor sends a command to the daemon to be executed on the host. Therefore to execute the "check_load" plugin, the "check_nrpe" plugin would be called on the host by Opsview Monitor with the option "-c check_load ...", running the "check_load" plugin on the host, and returning the result to Opsview Monitor.
When a plugin is placed in Opsview it needs to be configured. Configuration may include:
In order to more easily access repeated values, macros and variables are used. A macro is specific to a host, a common one being $HOSTADDRESS$ - whenever you see this, it will be replaced by the address of your host (eg. 192.168.169.169).
Variables are similar, except that you must configure them for a particular host, for example they may be your login credentials for a database. A variable may be single or multi-valued. The variable ORACREDENTIALS (Oracle database credentials) may contain your username as its first argument and password as second; these are accessed by %ORACREDENTIALS:1% and %ORACREDENTIALS:2% respectively. For a variable that is only a single value, %ORACREDENTIALS% will be substituted by the string in the "value" field.
A plugin does not do anything by itself until it has been placed in Opsview and configured after which it will then carry out its job. Opsview by default 'calls' (activates) a service check every 5 minutes so it will carry out its job and obtain a status result - the timing in which Opsview calls a service check can be changed if need be.
From the image below:
A plugin is a script that does some checking and returns a status and some data, a service check is that plugin in Opsview Monitor with configuration like host address and whether or not to use SSL etc.
Service checks can often be grouped practically, for example "check_load" (checks CPU load), "check_memory" (checks available memory) and "check_swap" (checks amount of swap memory). A grouping of these service checks is called a Host Template.
The benefit of this is that, if for example you have several hosts running a PostgreSQL database, you can simply apply the appropriate Host Template (Database - PostgreSQL) to each of them, rather than having to apply all the service checks to each one.
An Opspack is a file containing configuration data for a Host Template (plugins and their configuration). This file can be imported into your Opsview Monitor system to add extra monitoring functionality. Conversely, a Host Template can be exported to create an Opspack for installing on another system.
This page will show you how to import an Opspack. This can be done from the Host Templates menu seen below:
An Example of the Host Template Menu.
To import an Opspack, begin by selecting the 'Import Opspack' button on the top left of the page.
An Example of the Import Opacks menu.
How to Import Opspack:
Select the Opspack file you wish to import (e.g. application-apache-solr.opspack)
Note: The loader will display either of the follow
Import: A new Opspack file ready to be imported.
Existing: An existing Opspack file ready to be overwritten.
Error: An error has occurred during the upload process
An Example of the Loader.
Select 'Import' or 'Overwrite'
Your import of an Opspack has been successfully completed.
How to Export an Opspack:
Click on specific Host Template's contextual menu
Verify your export and click 'Export'
Your browser will download the Host Template.
If you want to use the command line to create an Opspack this link will give you the instructions for the process: https://www.opsview.com/resources/blog/how-create-opsview-opspack
The Opspack marketplace is a sharing platform for Opspacks to be uploaded and downloaded. It allows Opspacks that have been created by Opsview and users to share new Opspacks.
Find the Opspack you want to download and then go onto the page with the information about it. Underneath the description of the the Opspack will be a large download button with the name and version of the Opspack written on it.
When clicked the download will start through your browser and the Opspack will be saved to your download section or where you have specified your downloads to be stored.
The Opspack will then need to be imported into your Opspack system and then setup by following the installation guide on the Opspack page.
On the Opsview Opspack Marketplace click the upload my Opspack button.
Then fill in the information required to save your Opspack:
Opspack name - What does your Opspack monitor
Opspack description - A description of what the Opspack is monitoring
Runs on - Opsview(Agentless) or an agent
Opspack - upload the actual Opspack
Installation notes - A description of the setup of the Opspack (variables/SNMP/host template)
Opspack Type - select the type of software the Opspack will be monitoring
Then, once everything is complete, click Save and ensure the "Accept terms and conditions" has been ticked.