search

HariSekhon / Nagios-Plugins

450+ AWS, Hadoop, Cloud, Kafka, Docker, Elasticsearch, RabbitMQ, Redis, HBase, Solr, Cassandra, ZooKeeper, HDFS, Yarn, Hive, Presto, Drill, Impala, Consul, Spark, Jenkins, Travis CI, Git, MySQL, Linux, DNS, Whois, SSL Certs, Yum Security Updates, Kubernetes, Cloudera etc...
https://www.linkedin.com/in/HariSekhon
Other
1.14k stars 506 forks source link
aws cassandra cloud cloudera consul docker elasticsearch hacktoberfest hadoop hbase jenkins kafka kubernetes linux mysql nagios-plugins rabbitmq redis solr zookeeper

readme

Advanced Nagios Plugins Collection

GitHub stars GitHub forks Contributors Lines of Code My LinkedIn GitHub Last Commit

Codacy CodeFactor Quality Gate Status Maintainability Rating Reliability Rating Security Rating Vulnerabilities

Linux Mac Docker Dockerfile DockerHub Pulls DockerHub Build Automated StarTrack StarCharts

CI Builds Overview Jenkins Concourse GoCD TeamCity

CircleCI BuildKite AppVeyor Drone Codefresh Cirrus CI Semaphore Buddy Shippable Travis CI

Azure DevOps Pipeline GitLab Pipeline BitBucket Pipeline AWS CodeBuild GCP Cloud Build

Repo on GitHub Repo on GitLab Repo on Azure DevOps Repo on BitBucket

ShellCheck JSON YAML XML Validation Kics Grype Semgrep Semgrep Cloud Trivy

Docker Build (Alpine) Docker Build (Debian) Docker Build (Fedora) Docker Build (Ubuntu)

GitHub Actions Ubuntu Mac Mac 11 Mac 12 Ubuntu Ubuntu 20.04 Ubuntu 22.04 Debian Debian 10 Debian 11 Debian 12 Fedora Alpine Alpine 3

Python versions Python 3.7 Python 3.8 Python 3.9 Python 3.10 Python 3.11

Perl versions Perl

git.io/nagios-plugins

Largest, most advanced collection of production-grade Nagios monitoring code (over 450 programs)

Specialised plugins for AWS, Hadoop, Big Data & NoSQL technologies, written by a former Clouderan (Cloudera was the first Hadoop Big Data vendor) and ex-Hortonworks consultant.

Supports most major open source NoSQL technologies, Pub-Sub / Message Buses, CI, Web and Linux based infrastructure, including:

Supports a a wide variety of compatible Enterprise Monitoring systems.

Most enterprise monitoring systems come with basic generic checks, while this project extends their monitoring capabilities significantly further in to advanced infrastructure, application layer, APIs etc.

If running against services in Cloud or Kubernetes, just target the load balancer address or the Kubernetes Service or Ingress addresses.

Also useful to be run on the command line for testing or in scripts for dependency availability checking, and comes with a selection of advanced HAProxy configurations for these technologies to make monitoring and scripting easier for clustered technologies.

Fix requests, suggestions, updates and improvements are most welcome via Github issues or pull requests (in which case GitHub will give you credit and mark you as a contributor to the project :) ).

Hari Sekhon

Cloud & Big Data Contractor, United Kingdom

My LinkedIn
(you're welcome to connect with me on LinkedIn)

Make sure you run make update if updating and not just git pull as you will often need the latest library submodules and probably new upstream libraries too

Quick Start

  1. Git clone this repo and compile dependencies by running make
    OR
  2. Download pre-built self-contained Docker image

Execute each program on the command line with --help to see its options.

Ready-to-run Docker Image

All plugins and their pre-compiled dependencies can be found ready-to-run on DockerHub, if you have Docker installed, fetch this project like so:

docker pull harisekhon/nagios-plugins

List all plugins:

docker run harisekhon/nagios-plugins

Run any given plugin by suffixing it to the docker run command:

docker run harisekhon/nagios-plugins <program> <args>

eg.

docker run harisekhon/nagios-plugins check_ssl_cert.pl --help

There are also :centos (:latest), :alpine, :debian, :fedora and :ubuntu tagged docker images available, as well as :python and :perl only images.

You should tag the build locally as :stable or date-time stamped and run off that tag to avoid it getting auto-replaced by newer :latest builds, to control updates to suit your schedule and prevent random delays from docker runs pulling down newer builds from DockerHub.

Automated Build from Source

curl -L https://git.io/nagios-plugins-bootstrap | sh

or


git clone https://github.com/HariSekhon/Nagios-Plugins

cd nagios-plugins

make

Now run any plugin with --help to find out which switches to use.

Make sure to read Detailed Build Instructions further down for more information.

Optional: Generate self-contained Perl scripts with all dependencies built in to each file for easy distribution

After the make build has finished, if you want to make self-contained versions of all the perl scripts with all dependencies included for copying around, run:

make fatpacks

The self-contained scripts will be available in the fatpacks/ directory.

Quick Plugins Guide

There are over 400 programs in this repo so these are just some of the highlights.

Quick Links

Hadoop Ecosystem

Attivio, Blue Talon, Datameer, Platfora, Zaloni plugins are also available for those proprietary products related to Hadoop.

Hadoop Distributions

SQL-on-Hadoop

Service Discovery & Coordination

Cloud

Docker / Containerization

If running docker checks from within the nagios plugins docker image then you will need to expose the socket within the container, like so:

$ docker run -v /var/run/docker.sock:/var/run/docker.sock harisekhon/nagios-plugins check_docker_container_status.py -H unix:///var/run/docker.sock --container myContainer
 OK: Docker container 'myContainer' status = 'running', started at '2020-06-03T14:03:09.78303932Z' | query_time=0.0038s

See also DockerHub build status nagios plugin further down in the CI section.

Search

NoSQL

SQL Databases

Publish - Subscribe / Message Queues

These programs check these message brokers end-to-end via their API, by acting as both a producer and a consumer and checking that a unique generated message passes through the broker cluster and is received by the consumer at the other side successfully. They report the publish, consumer and total timings taken, against which thresholds can be applied, and are also available as perfdata for graphing.

CI - Continuous Integration & Build Systems - Git, Jenkins, Travis CI & DockerHub Automated Builds

Infrastructure - Internet - Web, DNS, SSL, Domains

Infrastructure - Linux - OS, Network, Puppet, RAID, SSH, Clusters, Yum Security Updates

... and there are many more plugins than we have space to list here, have a browse!

This code base is under active development and there are many more cool plugins pending import.

See also other 3rd Party Nagios Plugins you might be interested in.

Compatibility / Translation Plugins

These allow you to use any standard nagios plugin with other non-Nagios style monitoring systems by prefixing the nagios plugin command with these programs, which will execute and translate the outputs:

Usage --help

All plugins come with --help which lists all options as well as giving a program description, often including a detailed account of what is checked in the code. You can also find example commands in the tests/ directory.

Environment variables are supported for convenience and also to hide credentials from being exposed in the process list eg. $PASSWORD. These are indicated in the --help descriptions in brackets next to each option and often have more specific overrides with higher precedence eg. $ELASTICSEARCH_HOST takes priority over $HOST, $REDIS_PASSWORD takes priority over $PASSWORD etc.

Make sure to run the automated build or install the required Perl CPAN / Python PyPI modules first before calling --help.

Kerberos Security Support

Perl HTTP Rest-based plugins have implicit Kerberos support via LWP as long as the LWP::Authen::Negotiate CPAN module is installed (part of the automated make build). This will look for a valid TGT in the environment ($KRB5CCNAME) and if found will use it for SPNego.

Most Python HTTP Rest-based plugins for technologies / APIs with authentication have a --kerberos switch which supercedes --username/--password and can be used on technologies that support SPNego Kerberos authentication. It will either use the TGT from the environment cache ($KRB5CCNAME) or if $KRB5_CLIENT_KTNAME is present will kinit from the keytab specified in $KRB5_CLIENT_KTNAME to a unique path per plugin to prevent credential cache clashes if needing to use different credentials for different technologies.

Automating Kerberos Tickets - if running a plugin by hand for testing then you can initiate your TGT via the kinit command before running the plugin but if running automatically in a monitoring server then use the standard k5start kerberos utility as a service to auto-initiate and auto-renew your TGT so that your plugins always authenticate to Kerberized services with a current valid TGT.

To use different kerberos credentials per plugin you can export KRB5CCNAME=/different/path before executing each plugin, and have multiple k5start instances maintaining each one.

High Availability / Multi-Master testing

Testing high availability and multi-master setups is best done through a load balancer.

HAProxy configurations are provided for all the major technologies under the haproxy-configs/ directory for many of the technologies tested in this project, including:

See Also

The following is pulled from my DevOps Python Tools repo (currently one of my favourite repos):

./check_elasticsearch_cluster_status.pl --host $(./find_active_server.py --http --port 9200 node1 node2 node3)

There are now also simplified subclassed programs so you don't have to figure out the switches for more complex services like Hadoop and HBase, just provide hosts as simple arguments and they'll return the current active master!

These are especially useful for ad-hoc scripting or quick command line tests.

Configuration for Strict Domain / FQDN validation

Strict validations include host/domain/FQDNs using TLDs which are populated from the official IANA list. This is done via the Lib and PyLib submodules for Perl and Python plugins respectively - see those repos for details on configuring to permit custom TLDs like .local or .intranet (both already supported by default as they're quite common customizations).

Quality

Most of the plugins I've read from Nagios Exchange and Monitoring Exchange (now Icinga Exchange) in the last decade have not been of the quality required to run in production environments I've worked in (ever seen plugins written in Bash with little validation, or mere 200-300 line plugins without robust input/output validation and error handling, resulting in "UNKNOWN: (null)" when something goes wrong - right when you need them - then you know what I mean). That prompted me to write my own plugins whenever I had an idea or requirement.

That naturally evolved in to this, a relatively Advanced Collection of Nagios Plugins, especially when I began standardizing and reusing code between plugins and improving the quality of all those plugins while doing so.

Goals

Several plugins have been merged together and replaced with symlinks to the unified plugins bookmarking their areas of functionality, similar to some plugins from the standard nagios plugins collection.

Some plugins such as those relating to Redis and Couchbase also have different modes and expose different options when called as different program names, so those symlinks are not just cosmetic. An example of this is write replication, which exposes extra options to read from a slave after writing to the master to check that replication is 100% working.

Perl ePN optimization is not supported at this time as I was running 13,000 production checks per Nagios server years ago (circa 2010) without ePN optimization - it's not worth the effort and isn't available in any of the other languages anyway.

Python plugins are all pre-byte-compiled as part of the automated build.

Modern scaling should be done using distributed computing, open source examples include Icinga2 and Shinken. Shinken's documentation cites an average 4 core server @ 3Ghz as supporting 150,000 checks per 5 minutes, which aligns with my own experience with Nagios Core. Using the latest hardware and proper setup could probably result in even higher scale before having to move to distributed monitoring architecture.

Libraries

Having written a large number of Nagios Plugins in the last 10 years in a variety of languages (Python, Perl, Ruby, Bash, VBS) I abstracted out common components of a good robust Nagios Plugin program in to libraries of reusable components that I leverage very heavily in all my modern plugins and other programs found under my other repos here on GitHub, which are now mostly written in Perl or Python using these custom libraries, for reasons of both concise rapid development and speed of execution.

These libraries enables writing much more thoroughly validated production quality code, to achieve in a quick 200 lines of Perl or Python what might otherwise take 2000-3000 lines to do properly (including some of the more complicated supporting code such as robust validation functions with long complex regexs with unit tests, configurable self-timeouts, warning/critical threshold range logic, common options and generated usage, multiple levels of verbosity, debug mode etc), dramatically reducing the time to write high quality plugins down to mere hours and at the same time vastly improving the quality of the final code through code reuse, as well as benefitting from generic future improvements to the underlying libraries.

This gives each plugin the misleading appearance of being very short, because only the some of the very core logic of what you're trying to achieve is displayed in the plugin itself, mostly composition of utility functions, and the error handling is often handled in custom libraries too, so it may appear that a simple one line field extraction or 'curl()' or 'open_file()' utility function call has no error handling at all around it but under the hood the error handling is handled inside the function inside a library, same for HBase Thrift API connection, Redis API connection etc so the client code as seen in the top level plugins knows it succeeded or otherwise the framework would have errored out with a specific error message such as "connection refused" etc... there is a lot of buried error checking code and a lot of utility functions so many operations become one-liners at the top level instead of huge programs that are hard to read and maintain.

I've tried to keep the quality here high so a lot of plugins I've written over the years haven't made it in to this collection, there are a lot still pending import, a couple others check_nsca.pl and check_syslog-ng_stats.pl are in the more/ directory until I get round to reintegrating and testing them with my current framework to modernize them, although they should still work with the tiny utils.pm from the standard nagios plugins collection.

I'm aware of Nagios::Plugin but my libraries have a lot more utility functions and I've written them to be highly convenient to develop with.

Older Plugins

Some older plugins may not adhere to all of the criteria above so most have been filed away under the older/ directory (they were used by people out there in production so I didn't want to remove them entirely). Older plugins also indicate that I haven't run or made updates to them in a few years so they're in basic maintenance mode and may require minor tweaks or updates.

If you're new remember to check out the older/ directory for more plugins that are less current but that you might find useful such as RAID checks for Linux MD Raid, 3ware / LSI MegaRaid / Dell Perc Raid Controllers (which are actually rebranded LSI MegaRaid so you can use the same check - I also recommend the widely used Dell OpenManage Check).

Contributions

Feedback, Feature Requests, Improvements and Patches are welcome.

Patches are accepted in the form of Github pull requests, for which you will receive attribution automatically as Github tracks these merges.

Support for Updates / Bugs Fixes / Feature Requests

Please raise a Github Issue ticket for if you need updates, bug fixes or new features. Github pull requests are more than welcome.

Since there are a lot of programs covering a lot of different technologies in this project, so remember to look at the software versions each program was written / tested against (documented in --help for each program, also found near the top of the source code in each program). Newer versions of software seem to change a lot these days especially in the Big Data & NoSQL space so plugins may require updates for newer versions.

Please make sure you have run make update first to pull the latest updates including library sub-modules and build the latest CPAN / PyPI module dependencies, (see Quick Setup above).

Make sure you run the code by hand on the command line with -v -v -v for additional debug output and paste the full output in to the issue ticket. If you want to anonymize your hostnames/IP addresses etc you may use the scrub.pl tool found in my DevOps Perl Tools repo.

Detailed Build Instructions

Automated Build


git clone https://github.com/HariSekhon/Nagios-Plugins

cd nagios-plugins

make build

Some plugins like check_yum.py can be copied around independently but most newer more sophisticated plugins require the co-located libraries I've written so you should git clone && make on each machine you deploy this code to or just use the pre-built Docker image which has all plugins and dependencies inside.

You may need to install the GNU make system package if the make command isn't found (yum install make / apt-get install make)

To build just the Perl or Python dependencies for the project you can do make perl or make python.

If you only want to use one plugin, you can do make perl-libs or make python-libs and then just install the potential one or two dependencies specific to that one plugin if it has any, which is much quicker than building the whole project.

make builds will install yum rpms / apt debs dependencies automatically as well as a load of Perl CPAN & Python PyPI libraries. To pick and choose what to install follow the Manual Build section instead

This has become quite a large project and will take at least 10 minutes to build. The build is automated and tested on RHEL / CentOS 5/6/7 & Debian / Ubuntu systems.

Make sure /usr/local/bin is in your $PATH when running make as otherwise it'll fail to find cpanm

Python VirtualEnv / Perlbrew localized installs

The automated build will use 'sudo' to install required Perl CPAN & Python PyPI libraries to the system unless running as root or it detects being inside Perlbrew or VirtualEnv. If you want to install some of the common Perl / Python libraries such as Net::DNS and LWP::* using your OS packages instead of installing from CPAN / PyPI then follow the Manual Build section instead.

Offline Setup

Download the Nagios Plugins, Lib and Pylib git repos as zip files:

https://github.com/HariSekhon/Nagios-Plugins/archive/master.zip

https://github.com/HariSekhon/lib/archive/master.zip

https://github.com/HariSekhon/pylib/archive/master.zip

Unzip all and move Lib and Pylib to the lib and pylib folders under nagios plugins.

unzip nagios-plugins-master.zip
unzip pylib-master.zip
unzip lib-master.zip

mv -v nagios-plugins-master nagios-plugins
mv -v pylib-master pylib
mv -v lib-master lib
mv -vf pylib nagios-plugins/
mv -vf lib nagios-plugins/

Proceed to install CPAN and PyPI modules for whichever programs you want to use using your usual procedure - usually an internal mirror or proxy server to CPAN and PyPI, or rpms / debs (some libraries are packaged by Linux distributions).

All CPAN modules are listed in setup/cpan-requirements*.txt and lib/setup/cpan-requirements*.txt.

All PyPI modules are listed in requirements.txt and pylib/requirements.txt.

Internal PyPI Mirror example (JFrog Artifactory, CloudRepo or similar):

sudo pip install --index https://host.domain.com/api/pypi/repo/simple --trusted host.domain.com -r requirements.txt -r pylib/requirements.txt

Proxy example:

sudo pip install --proxy hari:mypassword@proxy-host:8080 -r requirements.txt -r pylib/requirements.txt
Mac OS X

The automated build also works on Mac OS X but you will need to download and install Apple XCode development libraries. I also recommend you get HomeBrew to install other useful tools and libraries you may need like OpenSSL, Snappy and MySQL for their development headers and tools such as wget (these packages are automatically installed if Homebrew is installed on Mac OS X):

brew install openssl snappy mysql wget
OpenSSL Fixes
Perl CPAN Crypt::SSLeay

To avoid the following cpan install error:

fatal error: 'openssl/opensslv.h' file not found
#include <openssl/opensslv.h>

specify the path to the OpenSSL lib installed by HomeBrew:

sudo OPENSSL_INCLUDE=/usr/local/opt/openssl/include OPENSSL_LIB=/usr/local/opt/openssl/lib cpan Crypt::SSLeay
Perl CPAN DBD::mysql

Ensure the DBI cpan module is installed as well as the openssl HomeBrew package.

You may need to add the OpenSSL library path explicitly in mysql_config to avoid the following error:

Checking if libs are available for compiling...
Can't link/include C library 'ssl', 'crypto', aborting.

Once you're sure that OpenSSL is installed via HomeBrew (done as part of the automated build), find mysql_config and edit the line

libs="-L$pkglibdir"

to

libs="-L$pkglibdir -L/usr/local/opt/openssl/lib"
Python Pip

You may get errors trying to install to Python library paths even as root on newer versions of Mac, sometimes this is caused by pip 10 vs pip 9 and downgrading will work around it:

sudo pip install --upgrade pip==9.0.1
make
sudo pip install --upgrade pip
make

ZooKeeper Checks

If you want to use any of the ZooKeeper content znode based checks (eg. for HBase / SolrCloud etc) based on check_zookeeper_znode.pl or any of the checksolrcloud*_zookeeper.pl programs you will also need to install the zookeeper libraries which has a separate build target due to having to install C bindings as well as the library itself on the local system. This will explicitly fetch the tested ZooKeeper 3.4.8, you'd have to update the ZOOKEEPER_VERSION variable in the Makefile if you want a different version.

make zookeeper

This downloads, builds and installs the ZooKeeper C bindings which Net::ZooKeeper needs. To clean up the working directory afterwards run:

make clean-zookeeper

Manual Build

Fetch my library repos which are included as submodules (they're shared between this and other repos containing various programs I've written over the years).


git clone https://github.com/HariSekhon/Nagios-Plugins

cd nagios-plugins

git submodule init

git submodule update

Then install the Perl CPAN and Python PyPI modules as listed in the next sections.

For Mac OS X see the Mac OS X section from Automated Build instructions.

Perl CPAN Modules

If installing the Perl CPAN or Python PyPI modules via your package manager or by hand instead of via the Automated Build From Source section, then read the requirements.txt and setup/cpan-requirements.txt files for the lists of Python PyPI and Perl CPAN modules respectively that you need to install.

You can install the full list of CPAN modules using this command:

sudo cpan $(sed 's/#.*//' setup/cpan-requirements*.txt lib/setup/cpan-requirements*.txt)

and install the full list of PyPI modules using this command:

sudo pip install -r requirements.txt -r pylib/requirements.txt
Net::ZooKeeper (for various ZooKeeper content checks for Kafka, HBase, SolrCloud etc)
check_zookeeper_znode.pl
check_zookeeper_child_znodes.pl
check_hbase_*_znode.pl
check_solrcloud_*_zookeeper.pl

The above listed programs require the Net::ZooKeeper Perl CPAN module but this is not a simple cpan Net::ZooKeeper, that will fail. Follow these instructions precisely or debug at your own peril:

# install C client library
export ZOOKEEPER_VERSION=3.4.8
[ -f zookeeper-$ZOOKEEPER_VERSION.tar.gz ] || wget -O zookeeper-$ZOOKEEPER_VERSION.tar.gz http://www.mirrorservice.org/sites/ftp.apache.org/zookeeper/zookeeper-$ZOOKEEPER_VERSION/zookeeper-$ZOOKEEPER_VERSION.tar.gz
tar zxvf zookeeper-$ZOOKEEPER_VERSION.tar.gz
cd zookeeper-$ZOOKEEPER_VERSION/src/c
./configure
make
sudo make install

# now install Perl module using C library with the correct linking
cd ../contrib/zkperl
perl Makefile.PL --zookeeper-include=/usr/local/include/zookeeper --zookeeper-lib=/usr/local/lib
LD_RUN_PATH=/usr/local/lib make
sudo make install

After this check it's properly installed by doing

perl -e "use Net::ZooKeeper"

which should return no errors if successful.

Other Dependencies

Some plugins, especially ones under the older/ directory such as those that check 3ware/LSI raid controllers, SVN, VNC etc require external binaries to work, but the plugins will tell you if they are missing. Please see the respective vendor websites for 3ware, LSI etc to fetch those binaries and then re-run those plugins.

The check_puppet.rb plugin uses Puppet's native Ruby libraries to parse the Puppet config and as such will only be run where Puppet is properly installed.

The check_logserver.py "Syslog to MySQL" plugin will need the Python MySQL module to be installed which you should be able to find via your package manager. If using RHEL/CentOS do:

sudo yum install MySQL-python

or try install via pip, but this requires MySQL to be installed locally in order to build the Python egg...

sudo easy_install pip
sudo pip install MySQL-python

Updating

Run make update. This will git pull and then git submodule update which is necessary to pick up corresponding library updates.

If you update often and want to just quickly git pull + submodule update but skip rebuilding all those dependencies each time then run make update-no-recompile (will miss new library dependencies - do full make update if you encounter issues).

Testing

There are full multi-level suites of tests against this repository and its libraries.

Continuous Integration is run on this repo with tests for success and failure scenarios:

To trigger all tests run:

make test

which will start with the underlying libraries, then move on to top level integration tests and finally functional tests using docker containers if docker is available.

Bugs & Workarounds

Kafka dependency NetAddr/IP/InetBase autoload bug

If you encounter the following error when trying to use check_kafka.pl:

Can't locate auto/NetAddr/IP/InetBase/AF_INET6.al in @INC

This is an upstream bug related to autoloader, which you can work around by editing NetAddr/IP/InetBase.pm and adding the following line explicitly near the top just after package NetAddr::IP::InetBase;:

use Socket;

On Linux this is often at /usr/local/lib64/perl5/NetAddr/IP/InetBase.pm and on Mac /System/Library/Perl/Extras/<version>/NetAddr/IP/InetBase.pm. You can find the location using perl_find_library_path.pl NetAddr::IP::InetBase or perl_find_library_path.sh NetAddr::IP::InetBase from the DevOps Perl Tools and DevOps Bash Tools repos.

You may also need to install Socket6 from CPAN.

This fix is now fully automated in the Make build by patching the NetAddr/IP/InetBase.pm file and always including Socket6 in dependencies (UPDATE: this fix is broken on recent versions of Mac due to the addition of System Integrity Protection which doesn't allow editing the system files even with sudo to root - a workaround would be to install the libraries to a local PERLBREW and fix there).

Alternatively you can try the Python version check_kakfa.py which works in similar fashion.

MongoDB dependency Readonly library bug

The MongoDB Perl driver from CPAN doesn't seem to compile properly on RHEL5 based systems. PyMongo rewrite was considered but the extensive library of functions results in better code quality for the Perl plugins, it's easier to just upgrade your OS to RHEL6.

The MongoDB Perl driver does compile on RHEL6 but there is a small bug in the Readonly CPAN module that the MongoDB CPAN module uses. When it tries to call Readonly::XS, a MAGIC_COOKIE mismatch results in the following error:

Readonly::XS is not a standalone module. You should not use it directly. at /usr/local/lib64/perl5/Readonly/XS.pm line 34.

The workaround is to edit the Readonly module and comment out the eval 'use Readonly::XS' on line 33 of the Readonly module.

This is located here on Linux:

/usr/local/share/perl5/Readonly.pm

and here on Max OS X:

/Library/Perl/5.16/Readonly.pm
IO::Socket::SSL doesn't respect ignoring self-signed certs in recent version(s) eg. 2.020

Recent version(s) of IO::Socket::SSL (2.020) seem to fail to respect options to ignore self-signed certs. The workaround is to create the hidden touch file below in the same top-level directory as the library to make this it include and use Net::SSL instead of IO::Socket::SSL.

touch .use_net_ssl

Python SSL certificate verification problems

If you end up with an error like:

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:765)

It can be caused by an issue with the underlying Python + libraries due to changes in OpenSSL and certificates. One quick fix is to do the following:

sudo pip uninstall -y certifi &&
sudo pip install certifi==2015.04.28

Enterprise Monitoring Systems

Compatible Monitoring Solutions

The biggest advantage of Nagios-compatible monitoring systems is the multitude of Nagios Plugins created by domain experts in each field to monitor almost everything out there.

Nagios Plugins are widely and freely available across the internet, especially at the original Nagios Exchange and the newer Icinga Exchange (at which you'll see this project at the top of the most viewed list).

The following enterprise monitoring systems are compatible with Nagios Plugins and this project:

Incompatible Monitoring Solutions

Metrics Graphing Integrations

Graphite, InfluxDB, Prometheus, OpenTSDB, PNP4Nagios

Many monitoring systems will already auto-graph the performance metric data from these nagios plugins via PNP4Nagios but you can also forward it to newer more specialised metrics monitoring and graphing systems such as Graphite, InfluxDB, OpenTSDB and Prometheus (this last one is the most awkward as it requires pull rather than passively receiving).

The above list of enterprise monitoring systems documents each one's integration capabilities with links to their documentation.

Metrics Collection Integrations

You can also execute these Nagios Plugins outside of any nagios-compatible monitoring server and forward just the metrics to the major metrics monitoring systems using the following tools:

Other Metrics Integration Add-Ons
Antiquated Monitoring Solutions You Probably Shouldn't Still Be Using Today

etc...

You may also be interested in the feature matrix on the Wikipedia page - Comparison of network monitoring systems.

More 3rd Party Nagios Plugins

This is a list of the best and most interesting 3rd party plugins, several of which I have used or come across over the years that deserve mention, usually due to their better quality than the typical Nagios Exchange / Monitoring Exchange plugins.

git.io/nagios-plugins

Star History

Star History Chart

More Core Repos

Knowledge

Readme Card Readme Card

DevOps Code

Readme Card Readme Card Readme Card Readme Card

Containerization

Readme Card Readme Card

CI/CD

Readme Card Readme Card

DBA - SQL

Readme Card

DevOps Reloaded

Readme Card Readme Card Readme Card Readme Card Readme Card

Templates

Readme Card Readme Card

Misc

Readme Card Readme Card

The rest of my original source repos are here.

Pre-built Docker images are available on my DockerHub.