Monthly Archive for February, 2012

Nagios V-Shell 1.9 Released

Nagios V-Shell 1.9 includes major performance updates, and a re-implementation of PHP caching that should decrease V-Shell page load times anywhere from 40-75%.  I ran some benchmarking tests on a test system(Dual core desktop with 4GB of RAM) with 1800 hosts, and 7200 services.  This system runs with an average CPU load of 2.0-6.0 throughout the day, so the hardware is being pushed pretty hard already from the check load. V-Shell 1.8 created page load times anywhere from 18-28 seconds throughout the interface without APC caching enabled.  Needless to say, this is problematic for many users with larger environments.  The Core cgi’s were able to load anywhere from 2-11 seconds, with the service status page taking around 9-11 seconds to load all of the data.  My goal for 1.9 was to minimize any unnecessary processing, and optimize any functions that were inefficient or using slower PHP built-in functions.  The differences in 1.9 are substantial.  Without any caching enabled at all, I was able to decrease the average page load time to 9-14 seconds, which is 40-50% faster by itself.  Once I had the code optimized, I reworked the APC caching functionality.  If a user has PHP’s APC caching packages installed and enabled on their web server, V-Shell will cached the objects.cache file until it detects any changes in the file, while the data in the status.dat file will be cached based on a TTL (time to live) config option which now exists in 1.9.  Once the data is cached in APC, the page load times throughout the interface averaged between 4-5 seconds for all pages, which is a 75% decrease in load time on average.

My goal for the next version of V-Shell is to add support for mklivestatus and ndoutils for backend data, which will eliminate the need to parse the objects.cache file and status.dat files for systems with those backends.  This should further improve performance for larger installations.

Download Nagios V-Shell 1.9



Documentation: Nagios XI Component Development

Here at Nagios Enterprises we do our best to add new features and components that meet the needs of the community and our customer base.  We get new feature requests every week, but sometimes the request is something we’re not able to fulfill in time, or the customer’s need requires a more “home grown” solution to fit the needs of their environment.  For that reason, we’ve created some documentation for getting started with Nagios XI Component Development.  The document covers some basic concepts in XI component development that would be needed regardless of what the component does, and is intended for development and administrators who are already familiar with programming concepts.  This document covers the following topics:

  • Example Component Code
  • General Developer Guidelines
  • Setting Up XI For A Development Environment
  • Component Registration and Initialization
  • Using The Backend API To Get XML Data
  • Adding XI’s CSS and Javascript

This document is available on the Nagios Library.

Nagios XI Component Development

Nagios XI Google Map Component v1.1

The Nagios XI Google Map Component v1.1 displays host status as an overlay on a Google Map within Nagios XI. It uses lat/long coordinates defined in the “notes” config field to identify host location. Version 1.1 now support polylines for parent->child relationships. Any parent->child relationship that has coordinates defined for both hosts will now draw a polyline displayed between the two.  This can be useful for drawing a topology map on real geographic locations. Special thanks to Wesley Zhao for your work on this feature!


Continue reading ‘Nagios XI Google Map Component v1.1’

Bash and Python NRDP Clients for Nagios

Now available 2 new clients to send passive check results to Nagios Remote Data Processor (NRDP) server.

We have just released: Bash NRDP Client Python NRDP Client

You no longer need to install PHP or Perl on your client machines to run passive checks with NRDP.  Both of these implementations can accept result piped from STDIN and you can change the delimiters to whatever you like.

STDIN results should be in the following order, for HOST checks:

for SERVICE checks

Additionally, the bash version can take an XML file of check results formatted like so: