0142 – Workgroups
This is for sending messages to roles. Several entities may join a Workgroup queue, and other entities may request chats with the workgroup (which then routes to the different entities when the chat is accepted by one of them). So, for alerting, we can send to the “alerting” workgroup, which will route to an appropriate AlertAgentBot.
0095 – Stream Initiation
For setting up a binary stream between two entities. This is cool because it could let us push all system checks to the nodes over the JabberNet. So we have a core stub ManagementAgent on each managed node, and it just logs on, and bootstraps itself.
0137 – Publishing SI Requests
For publishing available binary streams (using pubsub). So now our binary distribution nodes can publish available code, and our ManagementAgent stub can see what’s available for pulling.
0135 – File Sharing
Provides a way for entities to publish files to other entities. This looks kinda like what 0137 does, except farther evolved.
Combined, a bootstrap would be something like:
* Agent starts
* Agent checks local cache for code, loading what’s necessary.
* Agent receives pubsub list of available code
* Agent downloads (and caches) what it needs.
0136 – Message Archiving
For using the Jabber server as a persistent message store. Provides a method of adding, updating , and removing items from the store. This could be used as an audit log for the Agents.
Two bits of news from Open-ILS, the uber-cool project aiming to create a distributed, open-source library automation system.
Yesterday they posted an article on using jabber as their communication system:
I’d like to share a word on communication. We’ve decided to start with Jabber (www.jabber.org) as the communication layer between the various components. Jabber is great because it can be as simple as you want while allowing for practically limitless expansion. Given the open nature of Jabber, for example, we could write our own server components that ‘plug in’ to the jabber server and perform additional tasks on messages besides simply routing them through the messaging network.
Today they posted their November Executive Committee Report, which is a “where we’re at” report. The “Teaching a Programmer” section is fun.
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
Jabber Does Crypto
An article at FinancialCryptography.com discusses Jabber/OpenPGP integration, with a pointer to JEP-0027: Current Jabber OpenPGP Usage. Totally hot.
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