|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object | +--nsjsd
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 |
public static final int DEFAULT_PORT
Constructor Detail |
public nsjsd(java.lang.String strConfigFile)
strConfigFile
- --> String, the complete path to the configuration fileMethod Detail |
public java.io.File getCommandFile()
public java.util.Vector getHosts()
public java.util.Vector getAlias()
public void writeCommand(java.lang.String strMsg)
strMsg
- --> String, the message to write to the command filepublic static void fail(java.lang.Exception exc, java.lang.String strMsg)
exc
- --> Exception, the exception that forced this function to be calledstrMsg
- --> String, companion message to print to the command line.public static void printCommandLine()
public void writelog(java.lang.String strMsg)
strMsg
- --> String, the message to write to the log filepublic static void main(java.lang.String[] args)
args
- String --> the complete path to the configuration file.
|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |