Tarus Balog and Ethan Galstad join us this week from the OpenNMS devjam. We get an update on OpenNMS and Nagios, talk open core, Rackspace OpenStack, and more.
Download the episode directly right here, subscribe to the feed in iTunes or other podcatcher to have episodes downloaded automatically, or just click play below to listen to it right here:
Show Notes
- The history of OpenNMS devjams.
- Update on Nagios, esp. Nagios XI.
- Update on OpenNMS.
- What are people using Nagios and OpenNMS for at the moment (in addition to the usual)?
- Nagios: app folks needing stuff to monitor, traditional cost controlling swapping out more expensive stuff.
- OpenNMS: some high-scale uses…
- John asks why it is that these projects can (sometimes) innovate faster, adding more features, than larger, commercial stacks.
- How do OpenNMS and Nagios deal with high-scale data? We get into good code, architecture, but also bump up against things like Cassandra as a data-store.
- The open-core muck-bucket gets tipped over. Tarus’ recent post on the topic, and also RedMonk’s Stephen O’Grady has written on it recently.
- Rackspace OpenStack – see my interview on the topic.
- @DEVOPS_BORAT
- Quick OSCON overview.
Disclosure: The OpenNMS Group and OpsCode are clients. See the RedMonk client list for other relevant clients.
Good discussion, and of interest to me as we've been evaluating monitoring options for our cloud-based applications… We punted on using Nagios for our cloud implementation because there wasn't (that we could find) an easy API-way of getting new boxes into it via automation, you had to parse config files and restart. Is there some other more clever way with Nagios of doing that?
There's probably, or should be, some Puppet or Chef integration for that. There's similar stuff with Zenoss (Core?).
And… I'm glad you liked the episode 😉
Hmm, there's Puppet/Chef integrations but in the end they parse config and restart Nagios, it appears. This is bad because I don't want my monitoring system (which often has a pretty large mess of URL monitor checks queued up) going up and down… Causes a lot of transitory 'reds' and is a problem on a heavily loaded monitoring system.
http://www.truereligions.in/