Introduction
Shinken Enterprise includes a set of scalable internal mechanisms for checking the status of hosts and services on your network. These are called modules and can be loaded by the various Shinken Enterprise daemons involved in data acquisition (Poller daemons, Receiver daemons, Arbiter Daemon)Shinken Enterprise also relies on external programs (called check plugins) to monitor a very wide variety of devices, applications and networked services.
What Are Plugins?
Plugins are compiled executables or scripts (Perl scripts, shell scripts, etc.) that can be run from a command line to check the status of a host or servicecheck. Shinken Enterprise uses the results from plugins to determine the current status of hosts and services checks on your network and obtain performance data about the monitored service.
...
The value of this type of plugin architecture is that you can monitor just about anything you can think of.
If you can automate the process of checking something, you can monitor it with Shinken Enterprise .
There are already literally thousands of plugins that have been created in order to monitor basic resources such as processor load, disk usage, ping rates, etc.
If you want to monitor something else, take a look at the documentation on Plugins API and roll your own. It's simple!The downside to this type of plugin architecture is the fact that Shinken Enterprise has absolutely no idea about what is monitored.
You could be monitoring network traffic statistics, data error rates, room temperate, CPU voltage, fan speed, processor load, disk space, or the ability of your super-fantastic toaster to properly brown your bread in the morning...
Shinken Enterprise doesn't understand the specifics of what's being monitored - it just tracks changes in the state of those resources.
Only the plugins know exactly what they're monitoring and how to perform the actual checks..
What Plugins Are Available?
...
They use basic monitoring protocols including: WMI, SNMP, SSH, NRPE, TCP, UDP, ICMP, OPC, LDAP and more
They can monitor pretty much anything:
- Unix/Linux, Windows, and Netware Servers
- Routers, Switches, VPNs
- Network services: "HTTP", "POP3", "IMAP", "FTP", "SSH", "DHCP"
...
Obtaining Plugins
Shinken Enterprise also organizes monitoring configuration packages. These are pre-built for fast no nonsense deployments.
They include the check command definitions, service templates, host templates, discovery rules and integration hooks to the Community web site.
The integration with the community web site permits deployment and updates of monitoring packs.
Get started with :ref:`Shinken Enterprise Monitoring Packages "Packs" <contributing/create-and-push-packs>` today.
are delivered with numerous plugins.
You can obtain new one from various website in the Nagios community world, and especially theses onesThe plugins themselves are not distributed with Shinken Enterprise , but you can download the official Monitoring-plugins and many additional plugins created and maintained by Shinken Enterprise users from the following locations:
- Monitoring Plugins Project: https://www.monitoring-plugins.org
- Nagios plugin exchange: https://exchange.nagios.org/
How Do I Use Plugin X?
Most plugins will display basic usage information when you execute them using "-h" or "--help" on the command line.
For example, if you want to know how the ** check_http * plugin works or what options it accepts, you should try executing the following command:
| Code Block | ||
|---|---|---|
| ||
./check_http --help |
...
| Anchor | ||||
|---|---|---|---|---|
|
Plugin API
Plugin Overview
Scripts and executables must do two things (at least) in order to work as Shinken Enterprise plugins:
- Exit with one of several possible return values (Return Code)
- Return at least one line of text output to "STDOUT" ( Plugin Output )
The inner workings of your plugin are not important to Shinken Enterprise , interface between them is important.
...
The basic format for plugin output is shown below:
TEXT OUTPUT | OPTIONAL PERFDATALONG TEXT LINE 1LONG TEXT LINE 2...LONG TEXT LINE N | PERFDATA LINE 2PERFDATA LINE 3... PERFDATA LINE N
The performance data is optional.
If a plugin returns performance data in its output, it must separate the performance data from the other text output using a pipe (|) symbol.
Additional lines of long text output are also optional.
Plugin Output Examples
Let's see some examples of possible plugin output...
...
| Code Block | ||
|---|---|---|
| ||
DISK OK - free space: /var 3326 MB (56%); |
If this plugin was used to perform a service check, the entire line of output will be stored in the $SERVICEOUTPUT$ data.
...
| Code Block | ||
|---|---|---|
| ||
DISK OK - freeused space: /var 3326 MB (56%); | /=2643MB;5948;5958;0;5968var=3326 |
If this plugin was used to perform a service check, the portion of output (left of the pipe separator) will be stored in the <$SERVICEOUTPUT$> data and the portion of output (right of the pipe separator) will be stored in the $SERVICEPERFDATA$ data.
A perfdata is composed at a minimum of:
| Code Block |
|---|
key=value |
For example:
/var=3326
Then in option you can have more information:
key=valueUNIT;warning;critical;minimumvalue;maximalvalue
For example:
/var=3326MB;5948;5958;0;5968
You can have as mush perfdata as you want, just by separating values with space:
| Code Block |
|---|
HTTP OK: HTTP/1.1 200 OK - 20156 bytes in 0.271 second response time |time=0.270634s;;;0.000000 size=20156B;;;0 |
Plugin Output Length Restrictions
...