Sensing a theme? [Quicktime]
* Email is too hard. Let’s junk it.
* Let’s get rid of electronic mail, once and for all
* P2P smuggled in under cover of darkness
* Publish-Subscribe Framework for Jabber
* RPC over Jabber
Jabber Server Bits:
* Jabber::mod_perl – Mess with jabberd internals using perl
* ejabberd – A clusterable Jabber server written in erlang
* Jabber::RPC::HTTPgate – An HTTP/Jabber Gateway
* Jabber Notification Plugin for Nagios
You can add <x> elements to presence stanzas!
Ths means you can have the <show> and <status> tags human readable, and pass machine parsable information around via additional <x> stanzas. We could definitely use Presence for system montitoring.
POE XMPP code:
POE::Lego, put a small POE::Lego stub at the edge, with enough logic to pull down the modules from a server bot. edit all modules centrally. pubsub would be hott.
- Agent connects
- Agents disco’s a “lego-server”
- Agent pubsubs to lego-server.. (something to catch future published updates).. Disconnected operation though…
- Cache it locally
- and then pubsub for updates
- which redo an eval
Here are the four challenges I see to writing this Jabber Monitoring System…
First: disconnected operation. What happens to messages if my clients aren’t able to contact the server?
Second: message formatting. How do I format these messages so they’ll be machine readable on the other side?
Third: guaranteed order. I want messages to be processed in a certain order.
Fourth: Receiving and processing the messages. How do we route the messages to the correct place? How do we write programs to deal with the incoming messages?
For monitoring, what do you think of Machines publishing a list of current statuses, and the monitoring server subscribing to those publications?
One TCP connection per agent. Interface to allow shell scripts to use it.
It would be nice to make this an extendable perl package that can reload itself dynamically (ala geektalk). We could then add system checks dynamically. ..Which we could push over Jabber!
Machines advertise their state via “Presence”. A PHP Jabber page can query all that presence and tell us how they are.
now, regarding XML-RPC messages… I think they should age out
Design Goal: Must be able to do 10K on off the shelf hardware.
Design Goal: Must not be heavy on the host agent.
Netmon: Have the MonitorBot write to the status database directly.
AdminBot: Converts natural language commands into JabberBot::RPC calls, also converts Agent responses into human readable text.
the would then subscribe to pubsub published sources, each agent would be the owner of it’s own pubsub published source.
- The Agent would disco announce itself as an “alertpublisher”.
- Alertbots would then disco search for all alertpublishers.
- they would then subscribe to pubsub published sources, each agent would be the owner of it’s own pubsub published source.
- in this way, the central alertbot would be aggressively discovering and subscribing, the agent would merely be announcing it’s disco and registering its published source with pubsub
- ..And when it actually had something to say, it would be publishing a single message, and the server would be responsible for disseminating it..
- ,..And the multiple alertbots could each subscribe to All or a Subset of agents.
- so a collection of pubsub and disco with the agent as the publisher
Okay, so the idea is that Jabber could be used as a platform for all sorts of distributed system management functions, first and foremost, local machine monitoring, and statistics delivery.
Use Presence to determine if a system is up?
Notification of config changes.
When monitoring systems, create a spamassassin like scoring system to classify badness.
http://punjab.jabberstudio.org/ – Jabber over HTTP gateway
Send logs over Jabber. Watch logs and send interesting events over Jabber?
Have a jabberbot attach use DNotify to warn a central source of changes.
Size of backup report