Links that I have found interesting for May 28th:
- Rivermusings » Blog Archive » Events and Alerts – Chief Science Officer’s View – However, we neglected to appreciate that we had thrown away some very useful information. For instance, the reduction of events into alerts involved the disposal of the content of an event, in favour of updating attributes (such as count, last occurrence) of an alert.
With advancements/progression in database technology, RiverMuse can abandon the alert centric view of Netcool, and now embrace the world of events.RiverMuse defines an event as a point in the development of the state of a system. Some events warrant the creation of an alert. RiverMuse defines such alerts as a state of the system requiring intervention from an operator.
For every alert there may be many events, each being an agreed state of evolution of the alert (assignment, diagnosis, closure). There may be many events that never create an alert, but nevertheless must be recorded.
We make no assumptions about the retrospective importance of an event; we record everything.
- Dev Revival: Re-evaluating IT’s place in the Org Chart: Part 3 – Evaluation of the IT leader – Every member of the organization has an impact on the corporate strategy and tactics.
- Dev Revival: Re-evaluating IT’s place in the Org Chart: Part 2 – Evaluating IT’s needs – The CIO/CTO like every other resource in an organization needs the following four types of support from their supervisor:
· Sufficient political capital to propel their vision.
· Sufficient time with the supervisor to understand and implement the primary objectives.
· Proper opportunities to contribute to the organization.
· The ability to learn from their supervisor and grow as a resource. - Dev Revival: Re-evaluating IT’s place in the Org Chart: Part 1 – Business value – To aid in determining IT's business value, the following are a few real world examples of the types of value an IT organization is expected to provide. In your organization, IT most likely derives its value from a combination of these three examples. However, for this exercise we are trying to identify the greatest long term impact.
Comments on this entry are closed.
Heh, glad to see Rivermuse catching up. With OpenNMS we’ve had “events” forever. Events are simply a message bus. “Alarms” are created from events, and are very similar to old-school Netcool events.
OpenNMS has always allowed the events that create alarms to be retained (something Omnibus never did) although you can clear them as well if they are not important.
@Tarus
In my opinion, Netcool provides umpteen number of ways that one can pretty much define the incoming “event/alert” in a contextual way representing it as trap–>event–>fault
–>ticketed event; its only about knowing how to do it š
Not long ago, i was a part of a solution in which
>> when a trap came in; it reflected a Status to be trap
>> once it was enriched the status field changed to event,
>> After this correlation – if the event was root cause – status changed to fault
>> Past this step, if a auto ticket was created it would reflect the status…. ticketed event
et all…
It is very much possible to do aforementioned relatively easily with Omnibus + Automations or Omnibus + impact based on the complexity of workflow.
thoughts?
Doug,
Thanks for quoting dev revival. I am glad you found the post valuable.
Brian Blanchard
http://www.brian-blanchard.com