Messaging Server Completed

[duncan.m...@gmail.com]

With the changes submitted in several revisions over the last few
days, pymon now has a messaging server :-)

I've given a great deal of consideration to the ways in which a
general notification system could be put into place. With the full
integration of the old pymon.rules into pymon.workflow, notifications
in trunk had to be disabled pending messaging work. To further
complicate matters, I wanted messaging to support:
* the usual notifications sent via SMTP (this will also work for
pages)
* RSS feeds for hosts, services and organizations;
* IRC/IM notifications
* potentially firing SNMP traps
* notification to telnet-based services su ch as MUDs, MUSHes, and
MUXes
* posting to web services (e.g., Twitter)

This seemed almost insane, but I didn't want to give it up without
considering all the options. However, this weekend, the flash of
insight came and a perfectly simple and easy-to-implement solution is
now in place :-)

What I did was create a new service that pymon runs on a separate
port. This messaging service is a dispatcher whose "message()" method
takes a message object as it's only parameter; in the code, the
service is called "Listener." The message type is checked, and based
on that, the appropriate network communications are engaged.

What this means is that any part of the pymon code can send messages
of any supported type, publishing notifications in a clean and
convenient manner. All that is required of any point in the pymon code
where we want to send/publish a notifications is that a client
connection be made to the messaging service and the client "send()"
method get called (which calls the "message()" method on the
Listener).

I still need to plug this into the workflow, but the service is
running, tested and operational in pymon trunk :-) Integration into
workflow simply means I have to clean up the old message rules and
then add a Listener client instantiation to the service workflow's
checkTransition() method.

As of now, only SMTP is implemented, but with the service written and
in place, adding another of the desired notification/publish systems
is simple a matter of creating an appropriate client for the
destination service, defining a new message type, and then adding a
check to the Listener's message dispatcher. In other words, writing
what amounts to a plugin :-)

This is rather exciting, because of the unique possibilities this
presents to the pymon user base. We can easily support a range of
notification systems that is essentially unlimited. In contrast to
other monitoring systems, this is extraordinary. I know products where
simply supporting more than conventional emails and pages is either $-
costly or time-costly.

I'll have messaging plugged into the workflow very soon, at which
point I will return to the DB layer work, scalability testing, and
adding more service check plugins.

[duncan.m...@gmail.com]

With the changes submitted in several revisions over the last few
days, pymon now has a messaging server :-)

I've given a great deal of consideration to the ways in which a
general notification system could be put into place. With the full
integration of the old pymon.rules into pymon.workflow, notifications
in trunk had to be disabled pending messaging work. To further
complicate matters, I wanted messaging to support:
* the usual notifications sent via SMTP (this will also work for
pages)
* RSS feeds for hosts, services and organizations;
* IRC/IM notifications
* potentially firing SNMP traps

* notification to telnet-based services such as MUDs, MUSHes, and
MUXes (I have clients that would like in-game notifications regarding
server status and all services that affect game play, such as DNS)

* posting to web services (e.g., Twitter)

This seemed almost insane, but I didn't want to give it up without
considering all the options. However, this weekend, the flash of
insight came and a perfectly simple and easy-to-implement solution is
now in place :-)

What I did was create a new service that pymon runs on a separate

port. This messaging service (in the code, the service is called
"Listener") is a dispatcher whose "message()" method takes a message
object as it's only parameter. The message type is checked, and based
on that, the appropriate network communications are initiated.

What this means is that any part of the pymon code can send messages
of any supported type, publishing notifications in a clean and
convenient manner. All that is required of any point in the pymon code
where we want to send/publish a notifications is that a client
connection be made to the messaging service and the client "send()"
method get called (which calls the "message()" method on the
Listener).

I still need to plug this into the workflow, but the service is
running, tested and operational in pymon trunk :-) Integration into
workflow simply means I have to clean up the old message rules and
then add a Listener client instantiation to the service workflow's
checkTransition() method.

As of now, only SMTP is implemented, but with the service written and
in place, adding another of the desired notification/publish systems
is simple a matter of creating an appropriate client for the
destination service, defining a new message type, and then adding a
check to the Listener's message dispatcher. In other words, writing
what amounts to a plugin :-)

The next notification "plugin" I will focus on may be RSS. Every
monitored node in pymon will publish a "URL/feeds" resource, but I
also want to provide the flexibility that would come with being able
to publish a feed anywhere one has write permissions (even on a remote
server). RSS pushes could then be configured on a by-host basis or
globally.

The other one I really want to see is an IRC client (not a bot).
Sending a notification to a specific channel (or set of channels) on
an IRC server will simply be a matter of instantiating an IRC client
(I already have written several), connecting to the IRC server, and
sending the text.

In general, the Listener is rather exciting, because of the unique

possibilities this presents to the pymon user base. We can easily
support a range of notification systems that is essentially unlimited.
In contrast to other monitoring systems, this is extraordinary. I know
products where simply supporting more than conventional emails and

pages is either $-costly or time-costly.

I'll have messaging plugged into the workflow very soon, at which
point I will return to the DB layer work, scalability testing, and
adding more service check plugins.

d