Class nsjsd

java.lang.Object
  |
  +--nsjsd

public class nsjsd
extends java.lang.Object

Name: Nagios Java Server

This piece is desinged as a companion to Nagios. It is designed to help provide information to Nagios, send it information regarding passive commands. This means that your Nagios installation should be configured to accept passive service updates (see the Nagios documentation regarding how to set that up).

Goal:
The goal of this project is to provide a set of reusable objects that can either be incorporated into another application or can be used standalone via the command line.

Much like the other passive service companion software already out there, such as the perl piece, this system is two pieces. There is a server that listens for connections and then there is a client that connects to the server and sends information to it. This piece is the server, which means that it will listen on certain designated ports for communications from authorized systems. I say authorized because there is a configuration file which must be present for this application to work. The configuration file must be passed in as a command line arguement (it must be the complete path and file name).

I opted to write this in java, as opposed to using one of the other applications, because I was having problems getting the others to run, quite frankly. My environment is FreeBSD (for the Nagios monitoring server), Novell and NT servers as my monitored systems. This meant that, although most of my monitoring would be done over NT, I'd need something for Novell. The perl app, would probably have run but I figured if I wrote one in Java I'd have all my bases covered. I have yet been able to get the NT monitors to work and have been frustrated with them. Although, with the Java, I may not be able to provide as much information as I would have with the NT monitors, I was able to get it working. (And it was a fun exercise.)

This object has been written to be run from the command line and requires the full path to the configuration file when instantiated. The client application has been written such that it can be encorporated and reused in other applications. It is a single object which has exposed methods allowing for manipulation and communication with this server. For information on the client application I suggest reading the java doc on the nsjc object.

Currently this application can only be run from the command line, however I would like to incorporate control features into the server in later versions. There are four supporting objects which, together with the nsjsd class, make up this application. All of the configuration information is loaded at startup and held within the nsjsd object. This means that runtime changes could be made to the configuration items, if it was written into the application.

For use information you can just run the application without any command line parameters. By doing this use information will print to the command line.

This class uses four supporting classes to run: Connection, Server, alias, and host. The host class holds information on which hosts can connect to this server and on which port. The alias class holds informaiton on transforming the host information retrieved from the connection, into a common name. The Server class is the class which does the active listening. The Connection class is the class which accepts the connection from the Server and interprets the information from the connection.

The configuration file can contain four different types of items: command_file, log_file, host, and alias. The file must contain the first two items, and at least a single host. Aliases are optional. (For sample configuration file see the file nsjsd.cfg-sample.) The command file is the file which the test results will be written to (see the command file information in the Nagios documentation). The log file will be the file that the nsjsd application will write information to. The host item consists of the host name, a colon, followed by the port that the host is allowed to connect on. The nsjsd application will launch one Server object per port. So if you have 25 host records each with a different port, then you'll spawn 25 Server objects. The alias record is there to help transform the connecting machine's name into a name that is recognized by Nagios. This record type came about because I have having problems with the Java object inetAddress, it wouldn't return the name of the host in a very predictable manner. In some cases it would return the host name fine, in other cases it would just return the IP address. So you can now specify alias records. The alias record is the name of the alias, a colon, followed by the actual host name (this actual host name, is the name used to match to the Nagios host). So if you're system continually returns the IP address as the host when you call the getCanonicalName from the inetAddress object you'll be able to use an alias record to transform the IP address into a host name.

If you make a change to the configuration file, you will need to stop and restart the application as realtime updates aren't yet available and the file is read at startup.

License:
The is application is freely distributed. I only ask that if you incorporate or reuse any of these components you make mention of where you got them from and my email address.

Nagios is a registered trademark of Ethan Galstad.


Field Summary
static int DEFAULT_PORT
          Default port that the server will monitor in the event none is specified
 
Constructor Summary
nsjsd(java.lang.String strConfigFile)
          Name: nsjsd
          Desc: This is the only constructor for the object.
 
Method Summary
static void fail(java.lang.Exception exc, java.lang.String strMsg)
          Name: fail
          Desc: This function will print an error message to the command line along with any exception information that is passed in with it.
 java.util.Vector getAlias()
          Name: get Alias
          Desc: This method is provided so that other objects can get the internal Vector of Aliases at any time.
 java.io.File getCommandFile()
          Name: get Command File
          Desc: This method returns the command file obtained from the config file.
 java.util.Vector getHosts()
          Name: get Hosts
          Desc: This method is provided so that other objects can get the internal Vector of Hosts at any time.
static void main(java.lang.String[] args)
          This routine is run when the object is instantiated from the command line.
static void printCommandLine()
          Name: print Command Line
          Desc: This function will print to the command line usage information.
 void writeCommand(java.lang.String strMsg)
          Name: write Command
          Desc: This function will write information to the command file as designated in the config file.
 void writelog(java.lang.String strMsg)
          Name: write log
          Desc: This function will write information to the log file as designated in the config file.
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Field Detail

DEFAULT_PORT

public static final int DEFAULT_PORT
Default port that the server will monitor in the event none is specified

See Also:
Constant Field Values
Constructor Detail

nsjsd

public nsjsd(java.lang.String strConfigFile)
Name: nsjsd
Desc: This is the only constructor for the object. It takes a single parameter which is the complete path to the configuration file. For syntax of the configuration file see the sample file itself.

Parameters:
strConfigFile - --> String, the complete path to the configuration file
Method Detail

getCommandFile

public java.io.File getCommandFile()
Name: get Command File
Desc: This method returns the command file obtained from the config file.

Returns:
File --> the File object that represents the config file.

getHosts

public java.util.Vector getHosts()
Name: get Hosts
Desc: This method is provided so that other objects can get the internal Vector of Hosts at any time. This means that most configuration objects can be changed (providing admin tools are written) and will take affect immediately.

Returns:
Vector --> the list of Hosts from the configuration file

getAlias

public java.util.Vector getAlias()
Name: get Alias
Desc: This method is provided so that other objects can get the internal Vector of Aliases at any time. This means that most configuration objects can be changed (providing admin tools are written) and will take affect immediately.

Returns:
Vector --> the list of Alias info from the configuration file

writeCommand

public void writeCommand(java.lang.String strMsg)
Name: write Command
Desc: This function will write information to the command file as designated in the config file. It is synchronized because the individual threads will be calling this method to write to the file. This may prove to be a bottle neck, if you have a lot of different threads running and accepting information all the time. If this is the case, move this function to the Connection object. Just note that is is meant to be a choking point, as I wanted to make sure that if there were a lot of writes to the file, they would be completed sequentially and processes wouldn't write over other processes' information. This should help maintain the integrity of the file. This method appends the date to the beginning of the string and a new line character to the end of the string before writing it to the file.

Parameters:
strMsg - --> String, the message to write to the command file

fail

public static void fail(java.lang.Exception exc,
                        java.lang.String strMsg)
Name: fail
Desc: This function will print an error message to the command line along with any exception information that is passed in with it. After printing the error to the command line it will stop the code.

Parameters:
exc - --> Exception, the exception that forced this function to be called
strMsg - --> String, companion message to print to the command line.

printCommandLine

public static void printCommandLine()
Name: print Command Line
Desc: This function will print to the command line usage information.


writelog

public void writelog(java.lang.String strMsg)
Name: write log
Desc: This function will write information to the log file as designated in the config file. It is synchronized because the individual threads will be calling this method to write to the log file. This may prove to be a bottle neck, if you have a lot of different threads running and accepting information all the time. If this is the case, move this function to the Server object. Just note that is is meant to be a choking point, as I wanted to make sure that if there were a lot of writes to the file, they would be completed sequentially and processes wouldn't write over other processes' information. This should help maintain the integrity of the file.

Parameters:
strMsg - --> String, the message to write to the log file

main

public static void main(java.lang.String[] args)
This routine is run when the object is instantiated from the command line. There is a single mandatory command line parameter, which is the complete path to the configuration file.

Parameters:
args - String --> the complete path to the configuration file.