Efficient Solutions

Increasing Font Size in Event list
1) Click start ->run
2) enter regedit and hit OK
3)Navigate to following destination
HKEY_CURRENT_USER\Software\Micromuse\OMNIbus\CurrentVersion\Desktop Settings\<username>\Preferences
<username> here is your user ID

4) Increase the font size of below field
DWORD value “el_font_height” – Allows the user to set their preferred font height
Values can be in the range of decimal 8 to 72

5) Restart your Netcool Omnibus Event Conductor and Open an Event list

1. Click “My Computer”
2. Open the Control Panel
3. Select Time Options
3a. Classic View: Open Reginal and Language Options.
3b. Category View: Date, Time, Language and Regional Options.
4. Click “Change the format of numbers, dates, and times”.
5. Select the “Regional Options” tab.
6. Next to the box that shows your selected language click “Customize”.
7. Click the “Time” tab.
8. In the “Time Format” box enter:
8a. Standard Format: “h:mm:ss:tt”
8b. Military Format: “HH:mm:ss”

Some product/consulting companies charge upto 25K USD for integration of FM-FM/FM-PM products. One has to be careful of such offerings because not only they have a one time cost, but also they come with a continual license fee for the gateway. BAD!! So let me save you some money by generalizing this process by an example of integrating two highly used NMS solutions – Tivoli Netcool [from IBM] and NAGIOS [Open source offering]. Integration from Nagios to Netcool is simple [not sure why people pay tones of money for this] and can be done in couple different ways:

Overview

1. Asynchronous uni-directional data flow [from Nagios SBI to Netcool] : In this method of integration, Netcool shall receive events  as forwarded, but shall not acknowledge the event back in Nagios. This is useful when Nagios is not used by operators for RT monitoring.
2. Synchronous bi-directional data flow: An event in Nagios will flow to Netcool and will be confirmed back in Nagios as recieved by Netcool. On every update on the event [such as journal entry, acknowledgements] the event in Netcool, status shall be updated in Nagios.

Either options work based on the business/solution requirements. So without further ado:

Implementation:

1. Asynchronous uni-directional data flow [from Nagios SBI to Netcool]

To understand the implementation, I shall divide the steps as southbound implementation and northbound implementation. Southbound implementation refers to the changes/configuration on Nagios end, and Northbound implementation refers to updates in Netcool.

Southbound updates [On Nagios];

a) Create a script to send tcp socket messages or snmp traps or direct JDBC insert to NBI.

You can use snmptrap command for writing the script, if you are not a SNMP guy you can use a simple script to do socket message communication/JDBC inserts into Objectserver. Test this script.

sample snmp script:

Send trap

# Arguments:

# $1 = Management Station

# $2 = Community String

# $3 = host_name

# $4 = service_description (Description of the service)

# $5 = return_code (An integer that determines the state

# of the service check, 0=OK, 1=WARNING, 2=CRITICAL,

# 3=UNKNOWN).

# $6 = plugin_output (A text string that should be used

# as the plugin output for the service check)

#

# Sample

# /usr/bin/snmptrap -v 2c -c $2 $1 ” NAGIOS-NOTIFY-MIB::nSvcEvent nSvcHostname s “$3″ nSvcDesc s “$4″ nSvcStateID i $5 nSvcOutput s “$6″

b) Define a global event handler in Nagios: Global event handler will help execute the script on every state change on Nagios instance and will communicate, failure and seizure of the problem. How to configure GEH: http://nagios.sourceforge.net/docs/2_0/eventhandlers.html

Northbound updates [On Netcool]

If SNMP:

a) Download the Nagios MIB and compile with MIB2Rules

http://sourceforge.net/projects/nagiosplug/files/nagiosmib/

b) Update the rules file and include it  in mttrapd main ruleset

If socket:

a) Update the socket probe to parse message based on delimiters

b) Ensure all mandatory objectsesrver fields are accounted for

If JDBC:

a) Ensure all mandatory objectsesrver fields are accounted for

b) **CAUTION** Watch the objectserver profiler for IDUC consumption, as this is not so much of a conventional approach

DID YOU CATCH THE HEADFAKE?

Nagios an Netcool were just examples, you can integrate most FM-FM/FM-PM solutions using the aforementioned procedure, you just need to know the NBI data model, SBI data model, right triggers on the SBI system and right listner on NBI system. Made your life easy, din’t I? So start saving your company some money now!!

In the next post, I will talk about method 2 {bidirectional data flow}. Keep visiting!!

In my previous post, I talked about what events should one manage and what should be discarded; in this post I want to touch a topic that has caused most pain to Netcool as a Event Management System. I am sure this has also been an issue with most other products in the SA, FMS space.

Very often I come across clients where ignorant system administrators use the MIB2Rules tool to create *Production ready* rules file which are included in the MTTRAPD rules file. Over a period of time, as MIB’s are added to the queue of requests for additional Fault/Event management requests – the rules garbage piles on. As a result monitoring gets out of hand and Network operations starts complaining about the quality of alarming. The complains increase and the quality of the Product is challenged.

To these organizations/system administrators; I want to assert – STOP THE ABUSE!! MIB2RULES is not intended to be used assuming that every rules file generated is the best fit solution for the facility/infrastructure for which the MIB is compiled. By NO MEANS MIB2RULES SHOULD BE USED TO BYPASS THE EVENT ENGINEERING PROCESS.

Event engineering process is the only way to improve and maintain the quality of alarming and meet expectations of the Operations users. So that leads us to the question – What is event engineering?

Event engineering is an engineering process of defining the events, the symptoms associated, probable organizational impacts and intended audience. Furthermore, event engineering process defines the visual association like severity, escalation procedures and any related enrichment information which would help user to respond to the event, if required.

So this leads us to what constitutes of an event; in my perspective an event should minimum constitute of the following fields from fault reporting standards: ManagedObject, ProbableCause, SpecificProblem, Severity, AlertGroup, AlertKey, Manager, Agent and Summary.

At the system level events can be depicted with various lifecycle or escalation points using powerful tools like Impact; this is something that I highly encourage but do not mandate. What I do strongly recommend is the process of engineering events better!!

Following the aforementioned within 10 weeks, I have succeeded in taking experience of the end users from 2/10 to 7/10 when it comes to Service Assurance solution in place. No, it’s not a secret, its just pure old Network management practices which were followed even in early 90’s but were somehow killed by Vendors/Sales folks to show the value of the box. Check out any new vendor site you will find “8 hours to Event Management”; setup in a day sort of slogans which have taken the quality of entire landscape to be below par.

Irrespective of the tool, the fundamentals of instrumentation have never changed. D L Parnas in his famous paper – “RDP – Fake it!!” has talked about following the procedure as close as possible and with this post I recommend the very same principle for managing infrastructure, networks, services and customers with the same rigour and formality.

Bottomline: Tools don’t/should’nt change Strategy, Organizations, Principles- They just align with the aforementioned to achieve the common purpose. Something to think about!