From OpenNMS

Admin Workflow

I propose a modification to the outline, starting with the Admin workflow.

First, we need to start with an overview of OpenNMS. David has a nice slide on this from the training materials.

At the heart of OpenNMS is eventd. All process either generate events, rely on events or both, so it needs to be shown in the architecture overview.

Second, to demonstrate events in class I always start off with a send-event.pl example. Just sending "uei.foo" to the system and seeing it show up goes a long way toward having the admin understand how events work.

From there I would probably have sections on traps, syslog and TL/1, since those would build on the student's understanding of events.

Third, a natural progression from events is notifications. Since currently notifications are triggered on events, it demonstrates a use of a process that consumes events from OpenNMS.

At this point, I would probably move on to service monitoring, followed by data collection, and then return back to events by discussing alarms, automations and the trouble ticket interface.

Alex: The overview of OpenNMS should go into the introduction (beginning of the book) as it is interesting both to users and admins; I would add a chapter to the admin part to cover the workflow mentioned above (it can be fairly large); the question is if we keep the details in separate chapters: The advantage of that would be that the explanation can stay clear of configuration and too much detail. That permits for smooth reading and comprehension. The reader can then go into the respective chapter to learn more about the details of the topic.