Monitor di Oracle con System Center 2012 Operations Manager – Configurazione probe OLEDB e avvio monitoring
Proseguiamo con la seconda parte dell’articolo di Daniele Grandini dedicato al monitoring di database Oracle con System Center Operations Manager 2012. Nella prima parte dell’articolo abbiamo visto come configurare la connessione OLEDB per l’accesso da MOM.
Daniele Grandini si occupa di system management per ambienti distribuiti dal 1995. E’ community lead di UGI SystemCenter e dal 2009 è MVP per System Center Cloud and Datacenter Management. Attualmente progetta soluzioni basate su Microsoft System Center per Progel spa, dove guida un gruppo di lavoro di 10 persone.
In questo secondo appuntamento vedremo come sfruttare l’OLEDB provider di Oracle già apportunamente configurato in System Center Operations Manager per realizzare un controllo di disponibilità di un sistema Oracle.
Passi necessari per creare un probe Oracle utilizzando la Operations Console di Operations Manager:
- ☒ Installare sui sistemi sonda l’Oracle OLEDB provider – nella prima parte
- ☒ Configurare la connettività dai sistemi sonda verso le istanze Oracle utilizzando gli strumenti forniti da Oracle – nella prima parte
- ☐ Creare un OLEDB probe in Operations Manager
- ☐ Definire un account per consentire al probe l’accesso a Oracle
Creare un OLEDB probe in Operations Manager
Terminata la configurazione ed il test del provider Oracle è ora possibile configurare un probe in Operations Manager. La procedura mostrata è identica per qualsiasi OLEDB provider, valida per Oracle, ma ad esempio valida anche per DB2. Per creare il probe occorre spostarsi nello spazio Authoring della Operations Console e lanciare Add Monitoring Wizard nel quale scegliere “OLE DB data Source”.
Il primo passaggio consiste nel definire un nome e un management pack per il probe. È buona norma definire un management pack dedicato per tutte le integrazioni di monitor e questa non fa eccezioni. AI fini del nostro esempio chiameremo il nostro probe “Oracle DB probe” e (con poca fantasia) allo stesso modo nomineremo il management pack che può essere creato dalla medesima pagina.
 |
 |
Terminata la fase di predisposizione generale è il momento di entrare nello specifico del monitor e occorre fare una premessa: è molto probabile che la stazione dalla quale viene usata la console di amministrazione non sia il sistema da usare come sonda sul quale è stato installato l’Oracle OLEDB provider, per questo motivo nel wizard non sarà possibile selezionare il provider Oracle. La cosa è però di poco conto, infatti correggeremo manualmente la connection string con i riferimenti corretti. Nella definizione della connection string dovremo quindi scegliere un provider generico e ricordare di selezionare “Use simple authentication Runas...”. Questa spunta ci permetterà di indicare le credenziali con cui fare accesso a Oracle.
Una volta completato il wizard per la costruzione della connection string, come anticipato, dovremo correggerla con i riferimenti ad Oracle. Il Provider diventerà OraOLEDB.Oracle e il Data Source dovrà essre valorizzato con l’alias definito nel TNSNames.ORA (nel nostro esempio ORCL). La connection string diventa dunque: “Provider=OraOLEDB.Oracle;Data Source=ORCL;User Id=…”. In ultimo è possibile (opzionalmente) anche specificare una query, in questo caso potremo definire delle soglie sui tempi di risposta della query stessa.
Possiamo quindi definire tre tipi di soglie: tempo di connessione, tempo di ritorno della query, tempo totale di ritorno di tutte le righe della query. Ai nostri fini definiamo una soglia di 3” (3000 millisecondi) sul tempo di ritorno della query misurato sulla prima riga restituita.
In ultimo occorre scegliere il sistema (o i sistemi) da usare come sonde, come anticipato devono essere sistemi windows con l’agente Operations Manager installato, su cui sia presente l’OLEDB provider di Oracle e che possano raggiungere i sistemi Oracle oggetto del monitor. Attenzione deve essere posta anche alla frequenza con cui verrà eseguita la query, in base alla complessità della query stessa, il default di 2 minuti potrebbe essere troppo frequente.
Terminato il wizard le regole di gestione e monitor saranno distribuite su tutti i sistemi sonda, questo può richiedere qualche minuto.
Definizione dell’account di connessione
Anche se la procedura guidata è terminata, non tutto è pronto perché le sonde possano connettersi a Oracle. Durante la costruzione del probe tramite il wizard, abbiamo indicato la necessità di autenticarsi a Oracle con una “simple authentication”, ossia con nome utente e password, non abbiamo però ancora indicato al sistema quali credenziali utilizzare. I prossimi passaggi ci permetteranno di completare anche questo ultimo aspetto.
Dovremo dunque:
- Creare un “runas account” di tipo “basic authentication”
- Distribuire l’account su tutti i sistemi sonda individuati
- Associare l’account appena creato con il “runas profile” generato dal wizard
Come prima cosa, nello spazio Administration alla voce “Run as configuration” occorre creare un nuovo “Run As Account” di tipo “Basic Authentication” (in questo punto l’interfaccia non è consistente, quello che nel wizard è chiamata Simple Authentication nella configurazione dell’account diventa Basic Authentication)
 |
 |
É necessario quindi distribuire l’account sui sistemi sonda individuate, è bene utilizzare sempre l’opzione “more secure” per fare questo in modo da essere in grado di distribuire le credenziali selettivamente solo sui sistemi interessanti. Per quanto le credenziali vengano trasferite e memorizzate in modo crittografato è comunque buona norma mantenerne il controllo ed evitare che siano distribuite su qualsiasi sistema con un agente Operations Manager.
 |
 |
Una volta creato l’account e distribuito sui sistemi sonda, occorre istruire il Sistema perchè l’account venga utilizzato per l’esecuzione del probe, in Operations Manager questo avviene associandolo al “Run As Profile”. Per fare questo è sufficiente spostarsi alla voce “Profiles” e selezionare il profilo creato per noi dal wizard, avrà come prefisso il nome per il probe inserito nel wizard.
1. Selezionare il profilo
2. Associare l’account
3. Selezionare l’account precedentemente definito
Terminato questo ultimo passaggio il probe per Oracle sarà pianificato sui sistemi sonda individuati e inizierà la propria funzione di monitor di disponibilità. Una volta comprese le operazioni necessarie la definizione di un probe è questione di pochi minuti (al netto dell’installazione dell’Oracle OLEDB provider). Avrete probabilmente impiegato più tempo a leggere questa guida che non a definire un OLEDB probe.
Verifica del risultato
Per verificare il risultato del nostro lavoro occorre spostarsi nello spazio di “Monitor” e selezionare la vista “OLE DB Data Source State” nella cartella “Synthetic Transaction”. Per ogni sonda definita troveremo una riga con l’indicazione dello stato dei controlli.
In ultimo, per i più curiosi, la risposta a una domanda che qualcuno avrà iniziato a porsi: quali controlli ha generato il wizard? In base alle risposte date durante la compilazione dello stesso i monitor definiti possono essere diversi. Il modo più semplice per avere un quadro completo è quello di interrogare Operations Manager. Per fare questo occorre spostarsi nello spazio “Authoring” e nel folder “OLE DB Data Source” selezionare il nostro probe e quindi nel menu contestuale (click destro) scegliere “View Management Pack Objects…” e quindi “Monitors”:
Il risultato è una vista di tutti i monitor generati dal wizard. Se avete seguito questa guida passo passo, troverete due monitor attivi:
- Data Source Status Monitor – che verifica la raggiungibilità dell’istanza Oracle
- Execution Time Monitor – che verifica i tempi di esecuzione della query impostata
In conclusione, con gli strumenti nativi di Operations Manager e senza ricorrere allo sviluppo di codice, ma semplicemente utilizzando l’interfaccia amministrativa, è possibile implementare un controllo di disponibilità di Oracle che misuri la raggiungibilità e le performance tramite query specifiche.
Ovviamente il monitor di un componente così importante come un RDBMS non può arrestarsi alla disponibilità, per completare i controlli occorre sviluppare un proprio Management Pack o affidarsi ad una soluzione commerciale per Operations Manager.