Howdy,

This may be the start of a rather large process, but the end goal is too good to not consider it.

I've recently placed a small Drupal installation within our intranet, with the view of it replacing the somewhat old wiki we currently use for our internal knowledge base. Nothing major there, but my next task is to get Nagios up and running and I was considering ... how could I push that data into Drupal?

Whilst chewing on this concept, I envisioned a larger, better sysadmin environment. Like, incorporating the strengths of Drupal to filter and display Nagios/rrdtool data, or to link that data with a simple (and expandable) asset registration system, or even to incorporate other applications like cfengine to push out updates and display the state of play through Drupal.

Has anyone else touched on this, or used something similar in their environments?

The idea of an all-in-one and *expandable* sysadmin environment based on Drupal is a very very tasty one.

Comments

superdave913’s picture

I think this would be a wonderful idea. Please keep me posted on any progress you make.

sepeck’s picture

Well, Drupal can import data from external sources. The new logging feature in Drupal is a basic implementation that is designed to use the syslog levels stuff from the RFC. I am not entirely sure that pushing data into Drupal would be the approach. Monitoring solutions have lots of data and the volume may stagger your poor data base if you import everything into Drupal. Maybe a module that can pull data or reports from a Nagios database? That would be kind of cool.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

MWLimburg’s picture

I've been tinkering with the Nagios c source (which is fun, as I don't know c but it's amazing what you can learn on the fly), and have massaged a new XHTML1 web interface in there. That's what really got me thinking about Drupal.

And yes, I'm thinking the same thing as you. My post-initial leanings so far are:

  • A module that would call the existing data and display the usual reports, graphs and the like.
  • Security over such content to be managed separately to Nagios.
  • Replace the CGI environment where possible, but initially, make it focused towards "the masses and managers" rather than the admin.
  • Incorporate drupal features into these, so for example, use the drupal comment system rather than the nagios one.

I should warn folks that whilst I do want to do this, there is no current time push for me to achieve this, mainly due to conflicting demands on my time. I have a new website I'm building that I've wanted to do for years, so that's priority one. But sitting here at work, it's something I think I might even be able to get sponsored.

So talk away, as I'm making notes :P

---
Mark Limburg -//- Weaving the Web since 1492

KrisBulman’s picture

any work in this? sounds like a brilliant idea

lmw94002’s picture

I am a big Nagios users, and use Drupal alot personally and in my "moonlighting". Would love to integrate two of my open source platforms.

jonbowyer’s picture

In my organisation we use nagios for monitoring our whole network, and also have a Drupal installation (with project issue tracking module) for bug and task management. We have been considering options for implementing a wiki / knowledgebase within our intranet (possibly within the same drupal site as the issue tracking) and have had thoughts about integrating this with nagios. Since nagios already has a record of all our hosts and services it would make sense for this information not to be duplicated, but rather to be accessed via a Drupal module which also "adds value" by providing additional features such as the addition of metadata and commenting, with the possibility of linking in to our issue tracking as well. This module could also provide enhanced status dashboards to replace the default nagios ones, and could perhaps allow configuration of nagios as well. Ultimately all user-interaction with nagios could be done through it, whilst also providing a framework for the documentation of our systems, services etc.

It sounds like this is a very similar concept to the proposal here, although perhaps with different initial priorities (our priorities would be first and foremost to provide knowledgebase facilities, with replacing the nagios dashboards etc as a later addition).

I'd be interested to hear if any work has yet been done on this? I may consider developing something along these lines myself although it's hard to say when I will get the time to do it or indeed if the development effort required can actually be justified.

polifemo’s picture

I was looking into integrating Drupal with Nagios and came across this thread. Is there still interest in this?

The issue I'm trying to resolve is slightly different as we have all the host and services information in Drupal and would like to control the Nagios config from Drupal.

If anyone is interested I would like to share some ideas.

johnbarclay’s picture

I'm in the same boat. I have site definitions (hostnames, modules used, etc. ) in drupal. I run some stuff on windows 2008, some on mac 10.4 and some on linux.

I would think this would be good add on to aegir (http://groups.drupal.org/aegir-hosting-system) but am not sure. If its not feasible to work it as an add on for aegir, it would be nice if a new module used the same content types and field definitions as aegir such that it could work alongside it and independently of it.

I don't use nagios yet, but it looks like a fit for what I'm doing. I would think a good architecture for such a module would be:

1. some cck content types for:
- sites
- monitoring tests (mysql, ping, http, etc.). Perhaps one content type for each type of monitoring test.
- monitoring contacts (the people and groups who would get notifications).

2. a simple module that adds a submit function to these content types that reconciled the nagios configuration files with the cck content types. That is whenever one of these content type records was submitted the module would reconcile the nagios configuration files with the cck content. I don't really know what nagios conf files look like.

I would gladly write such a module if someone would give me examples of what the nagios files should look like. I could then code 1 and 2 until they generated the correct Nagios conf files.

At that point maybe someone could help me install nagios and give me an hour long phone call and introduce me to nagios. I really don't want to write my own nagios, but am more of a programmer than a sys admin and need it on a linux machine and I'm more familiar with windows.

The tricky part would be telling which records in nagios were not managed by drupal such that the module would know which records to reconcile with the cck data and which to leave alone. This could be resolved with a seperate drupal table if nagios was only managed by one drupal instance or an additional conf file.

polifemo’s picture

Glad to see I'm not the only one thinking this way, I agree with you about the CCK content types.

The Nagios config files are very simple, a simple host config is as follows:

define host{
use generic-switch ; Inherit default values from a template
host_name linksys-srw224p ; The name we're giving to this switch
alias Linksys SRW224P Switch ; A longer name associated with the switch
address 192.168.1.253 ; IP address of the switch
hostgroups switches ; Host groups this switch is associated with
}

The documentation is really good and explains all the dependencies.

>The tricky part would be telling which records in nagios were not managed by drupal such that the module would know which records >to reconcile with the cck data and which to leave alone. This could be resolved with a seperate drupal table if nagios was only >managed by one drupal instance or an additional conf file.

The Nagios config strucuture actually makes this pretty simple as it allows both individual cfg files and directories to be specified , so all the Drupal generated configs can be kept in theyr own directory.

I'm not a programmer but I could write the code logic if you were willing to code it.

johnbarclay’s picture

At some point some help with nagios install will be great. To get started though, I think some cases will get us pretty far. It will also help figure out if we are talking about similar goals. I can then generate the cck types on a test site and write the code to generate the config files is you give me examples. I looked at aegir and compound eye for cck definitions to work from with no luck. Can we just start with your cck definitions and some fake data on a sample site? That way at least you won't have to change your ccks.

Test case 1:
A website that has several stakeholders who want to monitor it. The admin defines the site and a set of urls to test. Pings, tests for text, mysql queries for the backend, top and other server process queries to test health of server. each test has results sent to appropriate contacts.

polifemo’s picture

Not sure if we are talking about the same thing.

Do you mean that the users would look at the status of the through Drupal, or that the administrator manages the Nagios config through Drupal.

I started playing around with quering the drupal database using the PHP API and generate the config text file used by Nagios and it seems likes its doable as long as the table structure was known.

I received your email but I messed up my email since then, you can contact me at polifemos at conedsolutions dot com

jemond’s picture

I've used Nagios a bit. It's really handy for server monitoring. However, as a companion to Nagios we make a Drupal-level monitoring tool called Droptor, check it out:
http://drupal.org/project/droptor

It certainly doesn't have the server monitoring features of Nagios, but it does get your more Drupal specific data to monitor, review and organize.

danyelous’s picture

Any news about this idea?