Filtrare gli allarmi da inviare alla console Tivoli

Ciao a tutti,

mi è capitato da un cliente di dover trovare la soluzione ad una richiesta particolare: inviare solo un determinato set di allarmi alla console Tivoli attraverso il connettore IBM Netcool/OMNIBUS

Occorre premettere che il connettore IBM Netcool/OMNIBUS realizzato dalla IBM stessa, fornisce già di suo alcuni criteri di filtro. Consente ad esempio di specificare DA quali gruppi di oggetti prendere gli allarmi

oppure DA quali target (ovvero le classi)

Considerando la flessibilità che un sistema di monitoraggio dinamico deve avere, ritengo opportuno non configurare, a meno di necessità puntuali, nessuno dei 2 filtraggi appena esposti in quanto potrebbero limitare l’invio di allarmi generati da nuovi MP (custom o realizzati dai vendor). Va comunque ricordato che filtrare per gruppi e/o per classi, non permette di limitare la tipologia di allarmi in quanto in questo modo tutti gli allarmi per le istanze di quel dato gruppo/classe vengono inviati.

La richiesta del cliente si cala perfettamente in questo scenario ovvero, non essere limitato a priori ed avere al contempo la possibilità di scegliere quali allarmi inviare e magari anche da quale server. Analizzando ulteriormente i settaggi messi a disposizione dal connettore, ho pensato di utilizzare un filtraggio basato su “Resolution State”.

In questo modo ho la possibilità di far fluire attraverso il connettore, solo gli allarmi desiderati ovvero quelli che si trovano in un dato “Resolution State”. Ma come fare per rendere automatico il cambio di “Resolution State” e far si che gli allarmi vengano inviati alla console Tivoli senza intervento dell’utente? Per la soluzione proposta ho preso spunto da questo articolo http://blogs.msdn.com/b/steverac/archive/2010/08/17/updating-custom-alert-fields-using-subscriptions-and-powershell.aspx in cui si parla della modifica dei CustomFields (per esattezza 10) che ogni allarme contempla. Quindi per realizzare la soluzione ho creato/configurato quanto di seguito:

1. Ho dapprima creato il “Resolution State” custom che m’identifica gli allarmi da inviare

2. Poi modificato la configurazione del connettore per filtrare gli allarmi in base al “Resolution State” stabilito

3. Ho realizzato uno script, di cui allego il testo, da dare in pasto alla subscription (illustrata brevemente di seguito). Da notare che lo script deve essere personalizzato con il nome FQDN del server RMS e con l’ID corrispondente al “Resolution State” implementato al punto 1.

#Get alertid parameter
Param($alertid)
$alertid = $alertid.toString()
# Load SCOM snap-inn
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"
$rms = "My RMS Server"

# Connect to SCOM - change management server to your RMS
new-managementGroupConnection -ConnectionString: $rms | Out-Null
set-location "OperationsManagerMonitoring::"

# Get specific alert based on criteria
$alert = Get-Alert -Criteria "Id = '$alertid' and ResolutionState = 0"

# Set Alert Resolution State to 2 that means alert will be forwarded to Omnibus through connector
$alert.ResolutionState = "2"; $alert.Update("") ;
exit

4. Ho configurato quanto necessario per l’automatismo in base a quanto riportato nell’articolo http://blogs.msdn.com/b/steverac/archive/2010/08/17/updating-custom-alert-fields-using-subscriptions-and-powershell.aspx. Non mi soffermerò sulla creazione del channel e del subscriber, ma solo sulla subscription poiché è qui che viene realmente effettuato il filtraggio degli eventi. In particolare la subscription è configurata per eseguire lo script solo sugli allarmi che rispondano a determinati requisiti quali ad esempio:

a. Un “Resolution State” di partenza ovvero il “New”. L’operazione di filtro, infatti, deve essere fatta solo sui nuovi allarmi.

b. Un determinato allarme (così come chiesto dal cliente)

La subscription che ho realizzato è stata pertanto configurata nel seguente modo:

Gli allarmi inviati ai fini di test sono stati generati da un MP realizzato appositamente per la fase di test. In tale MP ho creato 2 regole che andavano ad interrogare l’Application Event Log, sollevando un errore in caso di presenza degli Event ID 900 o 1000 o di stop del servizio “Print Spooler”

A questo punto la vostra curiosità vi avrà fatto sorgere una domanda più che legittima, ovvero: dove è che posso filtrare il server di cui inviare gli allarmi del caso?

Il meccanismo fino ad ora descritto ci permette di inviare un dato allarme (o un set di allarmi) proveniente da uno qualsiasi dei server monitorati su cui il MP contenete l’allarme scelto si applica. Se vogliamo ulteriormente filtrare gli allarmi selezionati anche in base al server di provenienza, dovremmo aggiungere un’ulteriore condizione alla subscription sopra descritta. La condizione da aggiungere è “Raised by any instance in a specified group”. Ovviamente prima di poter specificare il gruppo, dovremo crearlo e popolarlo con le singole istanze della classe su cui insiste l’allarme. Quest’ultima frase merita un chiarimento: occorre tenere presente che in Operations Manager gli allarmi vengono generati da monitor o da regole che insistono su classi di oggetti. Pertanto se ad esempio voglio avere l’allarme “The Windows Internet Information Service Web Server is Unavailable“ solamente dal server MyWebServer, dovrò inserire nel gruppo l’istanza “IIS 2003 Web Server”specifica.

Spero che questo post sia d’aiuto per tutti coloro che vogliono effettuare un invio selettivo di allarmi verso un sistema di monitoraggio diverso da Operations Manager.

Happy filtering and connecting