The Right Way to do Monitoring and Mass Administration

Over the weekend I flipped through these slides about Nanite (code), and it got me thinking about system monitoring (again), as well as mass administration tools (Puppet and its younger competitor Chef). The key bit from the talk is the idea of using a proven, off the shelf messaging server (RabbitMQ) as the communication bus among a set of processes running on many servers.

I would like very much to see a piece of software that puts these pieces together:

  1. Monitoring features, like those in Zabbix or other similar tools
  2. Mass administration features, like those in Puppet
  3. Run it over a messaging bus rather than a homegrown communication mechanism

Such a system would allow some very nice improvements:

  • The messaging bus could provide real time “presence” information.
  • Urgent events could be sent immediately, rather than polled.
  • Urgent administration changes could be sent over the same communication channel as normal operations, unlike (for example) the puppetrun mechanism is puppet.
  • The specification for how a server is configured could be integrated in to the specification for how it should be monitored. This would be an enormous improvement over the current state of the art (in open source tools anywhere) where these two concerns are separated in to tools that don’t talk to each other.

In addition to the feature improvements, I suspect that both kinds of tools (monitoring and administration) would find they can get by with a smaller codebase by outsourcing the communication bus to a messaging server.

Saying No to say Yes

In The Secrets of Consulting (a book, along with its sequel, about a lot more than consulting), Jerry Weinberg offered the Law of Raspberry Jam:

the wider you spread it, the thinner it gets

I thought about that a lot a few years ago when I attended the AYE conference (an experience I heartily recommend), along with the “Yes/No Medallion” that Jerry borrowed from Virginia Satir. Years onward, I am still struck by the  notion of saying No to say Yes. My inclination and habit is to say Yes to many projects, many features, many business ideas, many of everything. This has obvious benefits but also has a cost – sometimes I am spread too thin to have the impact I intend.

The fewer things I (we, you) focus on, the greater our impact on those top priorities. Of course there is inevitable pushback from associates, customers, and family members about Nos. This pushback is worth facing, because the more Nos, the more powerful the Yesses.

(An aside: in a half hour of online research, I was unable to definitively conclude where the name of the above Law originated.)