Checkmk
DeutschEnglishEspañolFrançais
Cloud (SaaS) masterlatest (2.4.0)2.2.02.1.02.0.01.6.0
to checkmk.com
Important

This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved.

1. Introduzione

Checkmk offre opzioni complete per il monitoraggio dei database Oracle. Con il plug-in dell'agente Checkmk puoi recuperare non solo i tablespace di un database o le sessioni attive, ma anche molti altri tipi di metriche. Un elenco completo delle opzioni di monitoraggio con i nostri plug-in di controllo è disponibile nel catalogo dei plug-in di controllo. Aggiungiamo regolarmente nuovi plug-in e aggiorniamo quelli esistenti, quindi vale sempre la pena consultare il catalogo. Tra gli altri, Checkmk può monitorare i seguenti valori:

Per poter monitorare i database è necessario solo il plug-in dell'agente, oltre all'agente sul server database. Attualmente sono supportati i sistemi operativi Linux, Solaris, AIX e Windows. Il plug-in dell'agente per Linux, Solaris e AIX si chiama mk_oracle e per Windows mk_oracle.ps1. Non sono necessari altri software aggiuntivi per il monitoraggio, né sul server Checkmk né sul server database.

Molti dei passaggi per impostare il monitoraggio sono gli stessi sia per Linux che per Windows. Per questo motivo, descriveremo prima i passaggi generali, poi quelli specifici per il rispettivo gruppo di sistemi operativi e infine l'agent bakery nelle edizioni commerciali.

2. Configurazione iniziale

I file di configurazione con i contenuti di esempio presentati in questo e nei successivi capitoli si trovano sul server Checkmk - sia tramite la linea di comando che tramite l'interfaccia web di Checkmk. In Checkmk Raw seleziona Setup > Agents e nelle edizioni commerciali Setup > Agents > Windows, Linux, Solaris, AIX > Related. In tutte le edizioni troverai le voci di menu per i diversi file system. I file di configurazione si trovano nel box Example Configurations.

2.1. Creare un utente del database

In linea di massima, la prima configurazione è rapida e richiede solo tre passaggi. Il primo passo, ovviamente, è quello di avere un utente che sia anche autorizzato a interrogare i database. Se non stai usando Real Application Cluster (RAC), crea un utente in ogni database da monitorare. Il modo in cui si accede a un'istanza varia a seconda del sistema operativo installato. Per Linux, ad esempio, puoi farlo impostando sempre prima l'istanza in questione come variabile d'ambiente in cui deve essere creato un utente. Normalmente si passa prima all'utente oracle, ma questo può variare a seconda della configurazione:

root@linux# su - oracle
oracle@linux$ export ORACLE_SID=MYINST1

Quindi logga all'istanza e crea un utente per il monitoraggio. Per ottenere tutti i dati, sono necessari i seguenti permessi. Nell'esempio seguente, l'utente appena creato si chiama checkmk. Puoi anche specificare qualsiasi altro nome desiderato:

sqlplus> create user checkmk identified by myPassword;
sqlplus> grant select_catalog_role to checkmk;
sqlplus> grant create session to checkmk;
sqlplus> connect checkmk/myPassword
sqlplus> exit

Puoi scoprire come funziona esattamente il login a un'istanza specifica nella documentazione di Oracle.

Database a supporto multiutente

Puoi anche configurare il login per i database multiutente. Di solito questo viene eseguito nella configurazione utilizzando un utente speciale e con il prefisso C##. L'assegnazione dei permessi è un po' diversa rispetto agli utenti normali, poiché è necessario specificarli per tutti i container attuali e per tutti i container futuri:

sqlplus> create user c##checkmk identified by myPassword;
sqlplus> alter user c##checkmk set container_data=all container=current;
sqlplus> grant select_catalog_role to c##checkmk container=all;
sqlplus> grant create session to c##checkmk container=all;
sqlplus> exit

2.2. Creare la configurazione

Dopo aver creato un utente, il passo successivo è quello di abilitare il plug-in dell'agente a ricevere queste informazioni. Il modo più semplice è quello di definire gli stessi dati di login per tutte le istanze e impostare una configurazione predefinita nella configurazione. Ora sull'host Oracle crea un nuovo file di configurazione mk_oracle.cfg per Linux, AIX, Solaris o mk_oracle_cfg.ps1 per Windows. Nell'esempio seguente si può vedere il file per i sistemi Unix-like:

/etc/check_mk/mk_oracle.cfg
# Syntax:
# DBUSER='USERNAME:PASSWORD'
DBUSER='checkmk:myPassword'

Per Windows la procedura è molto simile: in questo caso la variabile viene impostata in uno script di PowerShell:

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
# Syntax:
# $DBUSER = @("USERNAME","PASSWORD")
$DBUSER = @("checkmk","myPassword")

L'utente standard è tutto ciò che il plug-in dell'agente richiede. Tutte le altre opzioni che puoi impostare nei sistemi Unix o in Windows sono opzionali.

2.3. Usare il portafoglio Oracle

In alternativa all'indicazione dell'utente direttamente e con una password in un file di configurazione, puoi anche utilizzare l'Oracle Wallet. Questo ha il vantaggio di non dover più archiviare i dati di accesso in forma non criptata sul server Checkmk e sull'host Oracle. Quindi, anche se hai definito i diritti di accesso del file di configurazione sull'host Oracle, i dati di accesso hanno comunque lasciato il server e si trovano sul server Checkmk finché utilizzi l'Agent bakery.

L'Oracle Wallet a sua volta archivia i dati di accesso crittografati sull'host da monitorare in modo che possano essere utilizzati, ma non devono essere resi noti esplicitamente i dati di login. Checkmk può quindi utilizzare questo wallet in modo che i dati di accesso siano noti solo all'amministratore del database (DBA). Crea - o il DBA può creare - un wallet sul server appropriato:

root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -create

Il plug-in dell'agente accederà a questo file in seguito, ogni volta che verrà stabilita una connessione a un'istanza. Per poter trovare anche i dati dell'utente necessari, dovrai inserirli una volta nel wallet. Nell'esempio seguente aggiungi l'utente checkmk per l'istanza MYINST1:

root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -createCredential MYINST1 checkmk myPassword

Affinché il plug-in dell'agente sappia dove cercare il portafoglio, deve trovare due file. Il primo file è sqlnet.ora in cui si trovano le informazioni sulla posizione del portafoglio. Il secondo file -tnsnames.ora- definisce l'indirizzo dell'istanza in modo che possa essere indirizzata anche tramite il suo alias. Affinché il plug-in dell'agente possa accedere a questi file, è possibile specificare il percorso in Linux, Solaris e AIX utilizzando la variabile d'ambiente TNS_ADMINQuesto è particolarmente utile se i file esistono già. In alternativa, puoi crearli esplicitamente. Windows richiede addirittura di specificarli manualmente.

Per prima cosa crea il file sqlnet.ora. Il plug-in dell'agente cerca i dati di login in questo file, quindi è necessario inserire il percorso corretto del file wallet appena creato. Assicurati di impostare il parametro SQLNET.WALLET_OVERRIDE su TRUE:

/etc/check_mk/sqlnet.ora
LOG_DIRECTORY_CLIENT = /var/log/check_mk/oracle_client
DIAG_ADR_ENABLED = OFF

SQLNET.WALLET_OVERRIDE = TRUE
WALLET_LOCATION =
 (SOURCE=
   (METHOD = FILE)
   (METHOD_DATA = (DIRECTORY=/etc/check_mk/oracle_wallet))
 )

Ora il plug-in sa quali credenziali devono essere utilizzate. Per poter accedere anche all'indirizzo corretto, crea tnsnames.ora come secondo file. La sintassi esatta si trova nella documentazione Oracle, ma a titolo di esempio il file potrebbe avere questo aspetto:

/etc/check_mk/tnsnames.ora
MYINST1
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = MYINST1_ALIAS)
    )
  )

Con questo passaggio hai creato i prerequisiti per rimuovere i dati di accesso dal file di configurazione del plug-in dell'agente. Al posto dei dati di accesso, inserisci semplicemente un / (slash):

/etc/check_mk/mk_oracle.cfg
DBUSER='/:'

Naturalmente potrai aggiungere altri dati di accesso al portafoglio in un secondo momento. Il file tnsnames.ora dovrà quindi essere modificato come necessario.

Infine, modifica i permessi dei file e delle directory creati manualmente in questa sezione in modo che i diritti di accesso all'esecuzione siano impostati correttamente. Il plug-in dell'agente eseguito come root passerà al proprietario dei binari Oracle (ad esempio $ORACLE_HOME/bin/sqlplus) prima di eseguirli. Come minimo, il gruppo del proprietario dei binari Oracle deve quindi avere accesso in lettura ai file creati manualmente in /etc/check_mk/. Nell'esempio seguente, assumiamo che il gruppo sia oinstall.

I comandi seguenti cambiano il gruppo in oinstall:

root@linux# chgrp oinstall /etc/check_mk/sqlnet.ora /etc/check_mk/tnsnames.ora
root@linux# chgrp -R oinstall /etc/check_mk/oracle_wallet

Questi comandi assicurano che il gruppo possa leggere la directory oracle_wallet e il suo contenuto:

root@linux# chmod g+x /etc/check_mk/oracle_wallet
root@linux# chmod -R g+r /etc/check_mk/oracle_wallet

I permessi dovrebbero avere un aspetto simile a questo:

root@linux# tree -ugpR /etc/check_mk
[drwxr-xr-x root     root    ]  /etc/check_mk
├── [drwxr-x--- root   oinstall ]  oracle_wallet
│   └── [-rw-r----- root   oinstall ]  cwallet.sso
│   └── [-rw-r----- root   oinstall ]  cwallet.sso.lck
│   └── [-rw-r----- root   oinstall ]  ewallet.p12
│   └── [-rw-r----- root   oinstall ]  ewallet.p12.lck
├── [-rw-r--r-- root   oinstall ]  sqlnet.ora
├── [-rw-r--r-- root   oinstall ]  tnsnames.ora

L'output del comando mostra solo i file e le directory in questione.

3. Impostazione per Linux, Solaris e AIX

3.1. Percorsi del plug-in e della configurazione

Nei sistemi Unix Checkmk utilizza un plug-in dell'agente uniforme. Da un lato, questo riduce il lavoro di manutenzione, poiché le query SQL non vengono duplicate, dall'altro devi prestare attenzione a un solo plug-in dell'agente. Su tutti i sistemi supportati, i percorsi dei file per gli agenti sono gli stessi o molto simili. In particolare, hai bisogno delle seguenti directory:

Sistema operativo Percorso del plug-in Percorso della configurazione

Linux, Solaris, AIX

/usr/lib/check_mk_agent/plugins/

/etc/check_mk/

Linux con systemd

/usr/lib/check_mk_agent/plugins/<Number>

/etc/check_mk/

AIX

/usr/check_mk/lib/plugins/

/usr/check_mk/conf/

3.2. Installazione del plug-in dell'agente

Dopo aver creato un utente nella configurazione iniziale e averlo memorizzato nel file di configurazione, installa il plug-in dell'agente. Copia il file mk_oracle dalla directory del server Checkmk ~/share/check_mk/agents/plugins/ alla directory plug-in dell'host Oracle descritta sopra.

Important

Il plug-in dell'agente per i sistemi Unix-like mk_oracle non funziona bene con systemd (vedi Werk #13732). Sui sistemi con systemd, devi quindi eseguire il plug-in dell'agente in modo asincrono. Ciò significa che non devi installare il plug-in dell'agente direttamente sotto /usr/lib/check_mk_agent/plugins/, ma in una sottocartella /usr/lib/check_mk_agent/plugins/<Number>/. <Number> indica l'intervallo di esecuzione in secondi. Si consiglia l'esecuzione una volta al minuto, ovvero /usr/lib/check_mk_agent/plugins/60/. Quando si effettua la configurazione tramite l'agent bakery, è possibile utilizzare l'opzione Host uses xinetd or systemd della regola Oracle, che è impostata su xinetd per impostazione predefinita.

Assicurati che il plug-in dell'agente sia eseguibile e correggilo se necessario:

root@linux# cd /usr/lib/check_mk_agent/plugins/
root@linux# ls -lA
-rw-r--r-- 1 root root 120808 Jan 25 11:29 mk_oracle
root@linux# chmod +x mk_oracle
root@linux# ls -lA
-rwxr-xr-x 1 root root 120808 Jan 25 11:29 mk_oracle

3.3. Opzioni avanzate

Nella configurazione iniziale hai già appreso le prime variabili per ottenere i dati di monitoraggio dalle istanze Oracle. Tuttavia, a seconda dello scenario applicativo, avrai bisogno di ulteriori possibilità per un migliore controllo individuale del monitoraggio di ciascuna istanza. Troverai queste opzioni nelle sezioni seguenti.

Configurazione avanzata degli utenti

Con il login standard puoi utilizzare tutte o quasi tutte le istanze di un database. Tuttavia, ci sono casi speciali in cui hai bisogno di dati di accesso individuali per istanze specifiche. Nel file di configurazione hai quindi a disposizione le seguenti tre opzioni per specificare gli utenti:

Parametro Descrizione

DBUSER

Il valore predefinito se non sono stati definiti dati di accesso individuali per l'istanza del database.

DBUSER_MYINST1

Dati di accesso per un'istanza di database specifica, in questo caso per l'istanza MYINST1. I dati di accesso vengono utilizzati solo per questa istanza.

ASMUSER

Dati di accesso speciali per l'Automatic Storage Management (ASM).
Importante: Per un ASM è possibile specificare un solo login alla volta.

Queste variabili consentono anche altre opzioni oltre al nome utente e alla password. Puoi anche stabilire se l'utente è un SYSDBA o un SYSASM, su quale combinazione di indirizzo e porta l'istanza ascolta e persino quale alias TNS (TNSALIAS) deve essere utilizzato. Tuttavia, queste specifiche sono sempre - a differenza di utente e password - facoltative. Oltre all'esempio precedente, una configurazione può avere il seguente aspetto:

/etc/check_mk/mk_oracle.cfg
# Syntax
# DBUSER='USERNAME:PASSWORD:ROLE:HOST:PORT:TNSALIAS'
DBUSER='checkmk:myPassword'

DBUSER_MYINST1='cmk_specific1:myPassword1:SYSDBA:localhost:1521'
DBUSER_MYINST2='cmk_specific2:myPassword2::localhost::INST2'

ASMUSER='cmk_asm:myASMPassword:SYSASM'

Alcune spiegazioni per l'esempio precedente:

  • Puoi definire un numero qualsiasi di dati di accesso individuali, che sono sempre preferiti a quelli standard.

  • Ogni opzione è separata dalle altre da un : (due punti).

  • Se un campo opzionale viene omesso nel mezzo della stringa, è necessario codificare un punto e virgola, come nel caso della voce DBUSER_MYINST2, in cui non sono stati specificati né il ruolo né la porta.

  • Se dopo un certo punto non sono più necessari campi opzionali, puoi omettere i due punti, come nel caso della voce ASMUSER, in cui non sono stati specificati né host né porta né alias TNS.

Includere o escludere le istanze

In alcuni casi potresti non voler includere determinate istanze nel monitoraggio, ad esempio perché si tratta di un parco giochi per sviluppatori o per altri motivi. Per semplificare al massimo la configurazione in queste situazioni, hai a disposizione diverse opzioni per escludere completamente o parzialmente una o più istanze:

Parametro Descrizione

ONLY_SIDS

Qui puoi stabilire quali istanze devono essere monitorate. Un'istanza è denominata dal suo identificatore di sistema (SID). Si tratta di un elenco positivo che ignora tutte le istanze che non sono esplicitamente elencate. Questo parametro è molto utile se il numero di istanze da monitorare è inferiore al numero di istanze da ignorare.

SKIP_SIDS

A differenza di ONLY_SIDS, questo è un elenco negativo in cui vengono monitorate tutte le istanze tranne quelle esplicitamente elencate. Questo parametro è molto utile se il numero di istanze da ignorare è inferiore al numero di istanze da monitorare.

EXCLUDE_<SID>

Con questo parametro puoi escludere parzialmente un'istanza escludendo alcune sezioni dell'istanza dal monitoraggio. In questo modo, definisci un elenco negativo delle sezioni di un'istanza. Puoi anche escludere tutte le sezioni con il valore ALL e e quindi fare come se aggiungessi l'istanza a SKIP_SIDS.
Importante: Per i SID ASM non puoi utilizzare questa procedura, ma puoi invece utilizzare SKIP_SIDS="+ASM1 …​".

Avrai già intuito che l'ordine in cui vengono processati questi parametri determina il risultato. Le voci vengono infatti processate per istanza esattamente in sequenza, come mostrato nella tabella precedente. Pertanto, se la variabile ONLY_SIDS è impostata, SKIP_SIDS non viene più valutata né viene controllato se la variabile EXCLUDE_<SID> è impostata su ALL per questa istanza. Se ONLY_SIDS non è impostata, il sistema procede in base alla sequenza. In caso di dubbio, cioè come comportamento predefinito, l'istanza verrà monitorata di conseguenza.

Di seguito è riportato un esempio in cui tutte le variabili sono impostate e il comportamento è quello che si ottiene:

/etc/check_mk/mk_oracle.cfg
ONLY_SIDS='INST1 INST2 INST5'
SKIP_SIDS='INST7 INST3 INST2'
EXCLUDE_INST1='ALL'
EXCLUDE_INST2='tablespaces rman'

Poiché l'elenco positivo della prima riga ha sempre la priorità, la seconda e la terza riga non vengono più valutate. Solo la quarta (ultima) riga verrà considerata in un secondo momento, poiché l'istanza deve essere valutata solo parzialmente.

In pratica, ha senso utilizzare solo una delle variabili per determinare il numero di istanze da monitorare.

Determinare i dati da recuperare

Come hai appreso nella sezione precedente, non solo è possibile disabilitare completamente le istanze, ma anche monitorarle solo parzialmente. Le esigenze operative sono diverse ed è particolarmente pratico quando non è auspicabile che alcune sezioni di lunga durata siano incluse in ogni aspetto o quando, ad esempio, sono richieste solo informazioni di base dalle istanze di test. Per limitare le sezioni a livello globale, imposta direttamente le variabili corrispondenti - per limitare solo alcune istanze puoi inserire la variabile EXCLUDE_<SID> che hai già imparato a conoscere nella sezione precedente. Le variabili globali sono:

Parametro Descrizione

SYNC_SECTIONS

Sezioni che devono essere interrogate in modo sincrono, cioè ogni volta che l'agente viene eseguito. Poiché l'intervallo di tempo per le interrogazioni è di 60 secondi per impostazione predefinita, le query SQL utilizzate devono essere eseguite in modo altrettanto veloce. Se la variabile non viene specificata, vengono interrogate tutte le sezioni.

ASYNC_SECTIONS

Le sezioni che devono essere interrogate in modo asincrono, cioè solo ogni x minuti. Il tempo di validità dei dati è determinato dalla variabile CACHE_MAXAGE, riportata di seguito in questa tabella.

SYNC_ASM_SECTIONS

Per le sezioni ASM si applica lo stesso meccanismo descritto nella descrizione generale della variabile SYNC_SECTIONS.

ASYNC_ASM_SECTIONS

Qui per le sezioni ASM si applica lo stesso meccanismo descritto nella descrizione generale della variabile ASYNC_SECTIONS.

CACHE_MAXAGE

Questa variabile viene utilizzata per determinare per quanto tempo i dati recuperati in modo asincrono rimangono validi. Se il valore della variabile non viene specificato, viene utilizzato un valore predefinito di 600 secondi (10 minuti). Assicurati che il periodo di tempo non sia inferiore all'intervallo in cui l'agente Checkmk consegna i dati (60 secondi per impostazione predefinita), altrimenti i dati potrebbero essere considerati obsoleti e non consegnati dall'agente.

MAX_TASKS

Numero di SID che vengono processati in parallelo. Il valore predefinito è 1.

Il meccanismo consente quindi di impostare una configurazione predefinita nel file di configurazione e di sovrascriverla per le singole istanze, a seconda delle necessità. Una configurazione potrebbe quindi avere il seguente aspetto, ad esempio:

/etc/check_mk/mk_oracle.cfg
# DEFAULTS:
# SYNC_SECTIONS="instance sessions logswitches undostat recovery_area processes recovery_status longactivesessions dataguard_stats performance locks"
# ASYNC_SECTIONS="tablespaces rman jobs ts_quotas resumable"
# SYNC_ASM_SECTIONS="instance processes"
# ASYNC_ASM_SECTIONS="asm_diskgroup"
# CACHE_MAXAGE=600

SYNC_ASM_SECTIONS='instance'
ASYNC_SECTIONS='tablespaces jobs rman resumable'

CACHE_MAXAGE=300

EXCLUDE_INST1='undostat locks'
EXCLUDE_INST2='jobs'

Come puoi vedere nell'esempio, solo la sezione instance viene interrogata per le istanze ASM e su tutte le istanze regolari viene specificato un set minimo di sezioni asincrone. Inoltre, sull'istanza INST1 le sezioni sincrone undostat e locks verranno omesse. Poiché le sezioni sincrone non sono specificate esplicitamente, tutte le sezioni sincrone vengono recuperate da tutte le altre istanze. Nell'istanza INST2, a sua volta, vengono interrogate solo tre delle quattro sezioni asincrone, dato che jobs è stata esclusa. Infine, la cache di 10 minuti viene ridotta a 5 minuti (300 secondi), un tempo sufficiente per ottenere tutti i dati.

Important

Se nel file di configurazione definisci quali sezioni vuoi recuperare e con quale metodo (puoi anche modificare una sezione asincrona in una sezione sincrona), devi specificaretutte le sezioni che devono essere eseguite nella rispettiva area.

Ad esempio, se vuoi solo locks dalla query sincrona, specifica l'intero elenco sincrono e ometti semplicemente locks:

/etc/check_mk/mk_oracle.cfg
# Just exclude 'locks' from sync sections:
SYNC_SECTIONS='instance sessions logswitches undostat recovery_area processes recovery_status longactivesessions dataguard_stats performance'

Lo stesso vale per le altre tre variabili in cui è possibile determinare le sezioni.

Configurare l'alias TNS e TNS_ADMIN

L'alias TNS è un nome di facile utilizzo per una connessione al database. TNS è l'acronimo della tecnologia di rete Oracle Transparent Network Substrate. Un alias TNS permette di stabilire una connessione a un'istanza del database senza dover inserire ogni volta tutti i dettagli della connessione (come il nome host, il numero di porta o il nome del servizio). Gli alias TNS sono definiti nel file tnsnames.ora. La sezione relativa a Oracle Wallet contiene un esempio di come definire un alias TNS.

TNS_ADMIN è una variabile d'ambiente che indica la directory in cui si trovano i file di configurazione di Oracle come sqlnet.ora e tnsnames.ora. Per impostazione predefinita, TNS_ADMIN è impostato da Oracle su $ORACLE_HOME/network/admin. Nel file di configurazione, puoi assegnare un percorso diverso a TNS_ADMIN, come nell'esempio seguente per un'installazione Oracle specifica:

/etc/check_mk/mk_oracle.cfg
export TNS_ADMIN=/opt/oracle/product/19c/dbhome_1/network/admin/

Solo se la variabile non è impostata, viene impostata dal plug-in dell'agente su /etc/check_mk/.

Diritti di accesso all'esecuzione

Per motivi di sicurezza, il plug-in dell'agente mk_oracle non esegue più i binari Oracle sotto l'utente root. Questo riguarda i programmi sqlplus, tnsping e - se disponibile -crsctl. Invece, mk_oracle, ad esempio, passa al proprietario del file $ORACLE_HOME/bin/sqlplus prima di eseguire sqlplus. Questo assicura che i programmi Oracle vengano eseguiti solo da un utente non privilegiato e quindi impedisce a un utente Oracle malintenzionato di sostituire un binario come sqlplus e di eseguirlo come utente root.

Tip

Puoi scoprire in quale versione patch di Checkmk è stata apportata questa modifica nei Werk #15327 e #15328.

L'esecuzione di programmi Oracle da parte di un utente non privilegiato può causare problemi quando si utilizza un portafoglio Oracle, in quanto questo utente potrebbe non essere in grado di accedere ai file specifici del portafoglio. L'utente non privilegiato ha bisogno dei permessi per leggere i file $TNS_ADMIN/sqlnet.ora e $TNS_ADMIN/tnsnames.ora, per eseguire la cartella del portafoglio e per leggere i file nella cartella del portafoglio. Non dovresti avere problemi con i diritti di accesso se hai cambiato il gruppo dei file e delle directory come descritto alla fine della sezione sul portafoglio Oracle.

Il plug-in dell'agente ti aiuta nella diagnosi e verifica se ci sono problemi di accesso ai file indicati e li visualizza nel test di connessione. La procedura esatta per la diagnosi e la correzione dei diritti di accesso è disponibile nella Knowledge Base di Checkmk.

3.4. Monitorare i database remoti

Nei sistemi Unix, non solo puoi recuperare le istanze in esecuzione a livello locale, ma puoi anche accedere a quelle remote e recuperare i database in esecuzione. Questo, ad esempio, è vantaggioso se non hai accesso al sistema sottostante, ma vuoi comunque monitorare il database. È anche possibile monitorare i database remoti da un host su cui è in esecuzione il plug-in dell'agente, ma non un database Oracle.

Per monitorare i database remoti, è necessario che sull'host su cui è installato il plug-in dell'agente siano soddisfatti i seguenti requisiti:

  • La libreria di accesso AIO di Linux è installata. In Red Hat Enterprise Linux e nelle distribuzioni binary compatibili, il pacchetto si chiama libaio.

  • È installato l'Oracle Instant Client.

  • Il programma sqlplus è già presente nell'installazione o potrebbe essere stato installato come pacchetto di estensione del client.

Di regola, le condizioni sono già soddisfatte se esiste un'installazione di Oracle sull'host, altrimenti installa i pacchetti appropriati per farlo.

Affinché il plug-in dell'agente possa connettersi al database remoto, devi innanzitutto memorizzare i dati di accesso nel file di configurazione. Questi sono simili ai dettagli di DBUSER, già visti nella configurazione avanzata dell'utente, ma ci sono alcune specifiche aggiuntive obbligatorie:

/etc/check_mk/mk_oracle.cfg
# Syntax:
# REMOTE_INSTANCE_[ID]='USER:PASSWORD:ROLE:HOST:PORT:PIGGYBACKHOST:SID:VERSION:TNSALIAS'

REMOTE_INSTANCE_1='check_mk:mypassword::myRemoteHost:1521:myOracleHost:MYINST3:11.2'
REMOTE_INSTANCE_myinst1='/:::myRemoteHost:1521::MYINST1:11.2:INST1'

REMOTE_ORACLE_HOME='/usr/lib/oracle/11.2/client64'

Nell'esempio, due istanze remote vengono configurate con due righe. Affinché ogni riga di testo sia unica, alla fine di ogni variabile viene definito un ID, che può essere scelto liberamente, basta che sia unico per ogni file di configurazione. Come avrai già notato, la specifica della porta è seguita da altri valori, in parte opzionali e in parte necessari per stabilire una connessione.

Il primo nuovo valore PIGGYBACKHOST è impostato su myOracleHost per l'istanza MYINST3. Questa specifica assegna i risultati della query tramite il meccanismo piggyback all'host specificato. Se questo è presente come host in Checkmk, i nuovi servizi appariranno di conseguenza su di esso invece che sull'host in cui è in esecuzione il plug-in dell'agente o da cui sono stati prelevati i dati. Non vedi questa specifica sulla seconda istanza MYINST1: l'assegnazione a un altro host è opzionale.

Il secondo nuovo valore SID è il nome dell'istanza. Poiché il plug-in dell'agente non può vedere quali istanze sono in esecuzione sull'host remoto, è necessario specificare una riga di configurazione per ogni istanza remota: questo valore è quindi obbligatorio e non opzionale.

Il terzo valore VERSION è obbligatorio ed è dovuto al fatto che molti metadati sono disponibili solo se ci si trova direttamente sull'host. Pertanto non si può omettere la specifica della versione, che determina quali query SQL possono essere passate all'istanza. Nell'esempio, entrambe le istanze remote utilizzano la versione 11.2.

Il quarto e ultimo valore TNSALIAS è di nuovo facoltativo e può essere utilizzato se si accede all'istanza remota tramite Oracle Wallet o LDAP/Active Directory. Se l'istanza risponde solo a un alias TNS specifico, puoi specificarlo qui. Per la seconda istanza remota, TNSALIAS ha il valore INST1.

Per assicurarti che anche il programma sqlplus venga trovato, usa la variabile REMOTE_ORACLE_HOME per specificare dove si trova il client Oracle sull'host che esegue il plug-in dell'agente. Solo così saranno disponibili tutte le risorse necessarie per le query.

Quando si interrogano le istanze remote, ci sono alcune restrizioni e caratteristiche speciali:

  • Dal momento che hai inserito esplicitamente le istanze remote nel file di configurazione, non puoi escludere queste istanze utilizzando SKIP_SIDS, e in cambio non devi includerle utilizzando ONLY_SIDS.

  • Le istanze con lo stesso nome (SID) non possono essere assegnate allo stesso host. Questo è particolarmente importante se stai recuperando istanze da più host remoti e/o locali in cui vengono utilizzati nomi identici.

4. Impostazione per Windows

4.1. Percorsi del plug-in e della configurazione

Su Windows, PowerShell viene utilizzato come linguaggio di script per monitorare i database Oracle. La funzionalità è simile al plug-in dell'agente nei sistemi Unix, ma ne contiene solo una parte. Per utilizzare il plug-in dell'agente in Windows, è necessaria la versione 5.x o superiore di PowerShell e le seguenti directory:

Sistema operativo Percorso del plug-in Percorso della configurazione

Windows

C:\ProgramData\checkmk\agent\plugins

C:\ProgramData\checkmk\agent\config

4.2. Installazione del plug-in dell'agente

Dopo aver creato un user agent nella configurazione iniziale e averlo memorizzato nel file di configurazione, installa il plug-in dell'agente. I plug-in dell'agente per Windows sono memorizzati sull'host durante l'installazione dell'agente Checkmk per Windows. Sull'host Oracle, copia il file mk_oracle.ps1 dalla directory C:\Program Files (x86)\checkmk\service\plugins\ nella directory dei plug-in descritta sopra. In alternativa, puoi fare riferimento al file nel percorso di installazione aggiornando il file di configurazione dell'agente Checkmk.

4.3. Caratteristiche speciali in Windows

Windows normalmente impedisce l'esecuzione degli script PowerShell se non sono stati firmati. Ora puoi aggirare questo problema molto facilmente modificando le policy per l'esecuzione degli script PowerShell per l'utente che esegue l'agente Checkmk:

PS C:\ProgramData\checkmk\agent\> Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine
PS C:\ProgramData\checkmk\agent\> Get-ExecutionPolicy -Scope LocalMachine
Bypass

Questa opzione è utile se vuoi testare per un breve periodo uno script o il funzionamento generale dell'agente Checkmk. Per evitare di compromettere la sicurezza del tuo sistema, ripristina questa impostazione sui server di produzione al termine dei test:

PS C:\Program\checkmk\agent\> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
PS C:\Program\checkmk\agent\> Get-ExecutionPolicy -Scope LocalMachine
RemoteSigned

È comprensibile che tu non voglia cambiare le linee guida ogni 60 secondi, quindi imposta un'eccezione permanente solo per gli script interessati. Anche il file di configurazione del plug-in dell'agente deve essere aggiunto alle eccezioni. Per facilitare la lettura, in questo esempio l'output è stato completamente omesso:

PS C:\ProgramData\checkmk\agent\> Unblock-File -Path .\plugins\mk_oracle.ps1
PS C:\ProgramData\checkmk\agent\> Unblock-File -Path .\config\mk_oracle_cfg.ps1

4.4. Opzioni avanzate

Nella configurazione iniziale hai già appreso le prime variabili per ottenere i dati di monitoraggio dalle tue istanze Oracle. A seconda dello scenario applicativo, tuttavia, avrai rapidamente bisogno di altre opzioni per poter controllare il monitoraggio meglio e individualmente per ogni istanza. Le opzioni disponibili anche in Windows sono descritte nelle sezioni seguenti.

Configurazione avanzata degli utenti

Come in Linux, puoi definire non solo un login standard per il plug-in dell'agente di Windows, ma anche dati di accesso individuali per le singole istanze. Hai quindi a disposizione le stesse tre opzioni per specificare gli utenti:

Parametro Descrizione

DBUSER

Il valore predefinito se non sono stati definiti dati di accesso individuali per l'istanza del database.

DBUSER_MYINST1

Dati di accesso per un'istanza di database specifica, in questo caso per l'istanza MYINST1. I dati di accesso vengono utilizzati solo per questa istanza.

ASMUSER

Dati di accesso speciali per l'Automatic Storage Management (ASM).
Importante: Per un ASM è possibile specificare un solo login alla volta.

Inoltre, è possibile specificare altre opzioni oltre al nome dell'utente o alla password: anche queste voci aggiuntive sono facoltative, ma ogni voce deve essere compilata se viene utilizzata. Una configurazione può quindi avere il seguente aspetto, ad esempio:

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
# Syntax
# DBUSER = @("USERNAME", "PASSWORD", "ROLE", "HOST", "PORT")
# Default
# DBUSER = @("", "", "", "localhost", "1521")
$DBUSER = @("checkmk", "myPassword", "SYSDBA", "localhost", "1521")

@DBUSER_MYINST1 = @("cmk_specific1", "myPassword1", "", "10.0.0.73")
@DBUSER_MYINST2 = @("cmk_specific2", "myPassword2", "SYSDBA", "localhost", "1531")

@ASMUSER = @("cmk_asm", "myASMPassword", "SYSASM")

Alcune spiegazioni relative all'esempio precedente:

  • Puoi definire un numero qualsiasi di dati di accesso individuali, che sono sempre preferiti a quelli standard.

  • Ogni opzione è definita in un elenco. L'ordine delle voci non è arbitrario, quindi l'ordine non può essere riorganizzato.

  • Quando un campo opzionale rimane invariato ma un campo successivo deve essere modificato, entrambi i campi devono essere specificati correttamente, come nel caso dell'edizione DBUSER_MYINST2, dove HOST è ancora impostato su localhost anche se solo PORT deve essere modificato.

  • Se i campi opzionali non sono più necessari dopo un certo punto, possono essere omessi, come nel caso della voce ASMUSER, in cui è stato specificato solo il ruolo dell'utente.

  • Se all'utente non deve essere assegnato alcun ruolo speciale, ma HOST o PORT devono essere personalizzati, è sufficiente inserire una coppia di virgolette/doppi apici ("") in questa posizione.

Abilitare e disabilitare le istanze

Anche in Windows, non sempre si desidera includere alcune istanze. I motivi sono già stati descritti nella sezione dedicata a Linux. Due dei tre parametri che conosci in Linux possono essere utilizzati anche in Windows:

Parametro Descrizione

ONLY_SIDS

Qui puoi stabilire quali istanze devono essere monitorate. Un'istanza è denominata dal suo identificatore di sistema (SID). Si tratta di un elenco positivo, che ignora tutte le istanze che non sono esplicitamente elencate. Questo parametro è molto utile se il numero di istanze da monitorare è inferiore al numero di istanze da ignorare.

EXCLUDE_<sid>

Poiché il parametro SKIP_SIDS non è disponibile in Windows, puoi usare EXCLUDE_<SID> solo per escludere le istanze e quindi definire un elenco negativo. Puoi farlo impostando il valore della variabile su ALL. Puoi anche usare questo parametro per escludere parzialmente un'istanza, escludendo alcune sezioni dell'istanza dal monitoraggio. In questo modo, definisci un elenco negativo delle sezioni di un'istanza.
Importante: un'istanza (+ASM) non può essere completamente disattivata con questa opzione.

Il processo viene eseguito per ogni istanza nell'ordine mostrato nella tabella precedente. Quindi prima viene controllato se l'istanza si trova in ONLY_SIDS e solo dopo se alcune sezioni devono essere escluse. Se la variabile EXCLUDE_<SID> è impostata su ALL, nessuna sezione verrà eseguita.

Di seguito è riportato un esempio in cui ogni variabile è mostrata una sola volta:

C:\ProgramData\checkmk\agent\configurazione\mk_oracle_cfg.ps1
$ONLY_SIDS = @("MYINST1", "MYINST3")
$EXCLUDE_INST1 = "tablespaces rman"
$EXCLUDE_INST3 = "ALL"

Nota che ONLY_SIDS è un elenco, mentre EXCLUDE_INST1 è una stringa contenente sezioni separate da spazi.

Determinare i dati da prelevare

La specificazione di quali sezioni devono essere effettivamente recuperate avviene nello stesso modo di Linux e il seguente è solo un esempio per una configurazione Windows:

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
# DEFAULTS:
# $SYNC_SECTIONS = @("instance", "sessions", "logswitches", "undostat", "recovery_area", "processes", "recovery_status", "longactivesessions", "dataguard_stats", "performance", "locks")
# $ASYNC_SECTIONS = @("tablespaces", "rman", "jobs", "ts_quotas", "resumable")
# $SYNC_ASM_SECTIONS = @("instance", "processes")
# $ASYNC_ASM_SECTIONS = @("asm_diskgroup")
# $CACHE_MAXAGE = 600

$SYNC_ASM_SECTIONS = @("instance")
$ASYNC_SECTIONS = @("tablespaces", "jobs", "rman", "resumable")

$CACHE_MAXAGE = 300

$EXCLUDE_INST1 = "undostat locks"
$EXCLUDE_INST2 = "jobs'
Important

Se nel file di configurazione definisci quali sezioni vuoi recuperare e con quale metodo (puoi anche modificare una sezione asincrona in una sezione sincrona), devi specificaretutte le sezioni che devono essere eseguite nella rispettiva area.

Ad esempio, se vuoi solo locks dalla query sincrona, specifica l'intero elenco sincrono e ometti semplicemente locks:

C:\ProgramData\checkmk\agent\configurazione\mk_oracle_cfg.ps1
# Just exclude 'locks' from sync sections:
$SYNC_SECTIONS = @("instance", "sessions", "logswitches", "undostat", "recovery_area", "processes", "recovery_status", "longactivesessions", "dataguard_stats", "performance")

Lo stesso vale per le altre tre variabili in cui vengono determinate le sezioni.

Diritti di accesso all'esecuzione

Per motivi di sicurezza, il plug-in dell'agente mk_oracle.ps1 esegue i binari Oracle come amministratore solo se questi programmi possono essere modificati solo dagli amministratori. Gli amministratori in Windows sono l'account LocalSystem e i membri del gruppo integrato Administrators. Questo vale per i programmi sqlplus.exe, tnsping.exe e - se disponibile -crsctl.exe. Il plug-in dell'agente mk_oracle.ps1 non esegue nessuno di questi programmi se gli utenti non amministrativi dispongono di uno dei permessi Write, Modify o Full control per il file. In questo modo si evita il rischio per la sicurezza che gli utenti non privilegiati eseguano i programmi come amministratore.

Tip

Puoi scoprire in quale versione patch di Checkmk è stata apportata questa modifica in Werk #15843.

Se necessario, modifica i diritti di accesso rimuovendo i suddetti permessi degli utenti non amministrativi per i programmi. Il plug-in dell'agente ti aiuta nella diagnosi e controlla se gli utenti non amministrativi hanno accesso ai file menzionati e li visualizza nel test di connessione. La procedura esatta per la diagnosi e la correzione dei diritti di accesso è disponibile nella Knowledge Base di Checkmk.

Se non ti è possibile regolare i permessi per i programmi Oracle in modo sicuro, puoi consentire a singoli utenti e gruppi di eseguire i programmi:

C:\ProgramData\checkmk\agent\configurazione\mk_oracle_cfg.ps1
# Oracle plugin will allow users and groups in the list to have write access to the Oracle binaries
$WINDOWS_SAFE_ENTRIES=@("NT AUTHORITY\Authenticated Users", "<Domain>\<User>")

Solo se non c'è altro modo per garantire il monitoraggio di Oracle, puoi disattivare il controllo dei diritti di accesso come ultima opzione.

Important

Se disattivi il controllo dei diritti di accesso, il plug-in dell'agente non funzionerà più in modo sicuro.
C:\ProgramData\checkmk\agent\configura\mk_oracle_cfg.ps1
# Oracle plugin will not check if the used binaries are write-protected for non-admin users
$SKIP_ORACLE_SECURITY_CHECK=1

Tuttavia, esiste anche un altro modo per eseguire il plug-in dell'agente, senza diritti di amministratore. Puoi personalizzare l'esecuzione del plug-in dell'agente ed eseguirlo, ad esempio, sotto il gruppo locale di Windows Users. Per farlo, modifica il file di configurazione check_mk.user.yml dell'agente di Windows, ad esempio in questo modo:

C:\ProgramData\checkmk\agent\check_mk.user.yml
plugins:
    enabled: yes
    execution:
        - pattern: $CUSTOM_PLUGINS_PATH$\mk_oracle.ps1
          async: yes
          group: Users
          run: true

Nelle edizioni commerciali, queste voci possono essere create dall'Agent bakery con la regola dell'agente Run plug-ins and local checks using non-system account.

4.5. Monitoraggio dei database remoti

Il monitoraggio di database remoti non è attualmente possibile utilizzando il plug-in dell'agente per Windows. Pertanto, se vuoi monitorare database remoti, devi disporre di un host con un sistema operativo Unix compatibile.

5. Configurazione con l'Agent bakery

La configurazione può essere notevolmente semplificata nelle edizioni commerciali con l'Agent Bakery, in quanto si evitano errori di sintassi nei file di configurazione e si possono implementare più facilmente gli adattamenti agli ambienti in evoluzione. La differenza principale rispetto a una configurazione manuale è che devi lavorare sull'host Oracle solo alla linea di comando se vuoi effettuare configurazioni speciali specifiche per Oracle. Puoi eseguire la configurazione con l'Agent Bakery per Linux, Solaris, AIX e Windows.

Tuttavia, non puoi configurare tutte le funzioni del plug-in dell'agente con l'Agent Bakery, ad esempio se si tratta di funzioni che richiedono un intervento importante e conoscenze specialistiche approfondite. Di conseguenza, le query SQL personalizzate non possono essere configurate con l'Agent Bakery.

Tramite Setup > Agents > Windows, Linux, Solaris, AIX e il menu Agents > Agent rules, troverai la pagina con il set di regole Oracle databases (Linux, Solaris, AIX, Windows). Crea una nuova regola con Add rule. Qui troverai tutte le opzioni disponibili per la configurazione del plug-in dell'agente:

Rule for configuring Oracle in the Agent Bakery.

Molte opzioni ti saranno familiari grazie al manuale di configurazione. Come descritto, ci sono opzioni che non sono disponibili per tutti i sistemi operativi. Il titolo di queste opzioni indica per quali sistemi operativi possono essere utilizzate.

5.1. Configurazione degli utenti

Nella configurazione più semplice per un sistema operativo Unix, la regola sarà simile a questa:

Simplest rule for configuring Oracle in the Agent Bakery.

Nell'agent bakery hai anche la possibilità di creare utenti standard e di creare eccezioni per istanze specifiche. Le opzioni, separate nel file di configurazione con i due punti (per Linux & Co.) o come voci dell'elenco (per Windows), si trovano sotto Login Defaults come opzioni individuali che puoi compilare secondo le tue necessità. Naturalmente, puoi anche utilizzare il portafoglio Oracle in questo caso, cambiando semplicemente Authentication method in Use manually created Oracle password wallet.

La configurazione dell'Automatic Storage Management (ASM) avviene in modo analogo tramite l'opzione Login for ASM, mentre le eccezioni per istanze specifiche sono inserite in Login for selected databases, come descritto nella configurazione avanzata dell'utente per Linux, Solaris, AIX e Windows.

5.2. Opzioni avanzate

La seguente tabella elenca le altre opzioni del set di regole Oracle databases (Linux, Solaris, AIX, Windows), insieme a un riferimento a dove trovare una descrizione dell'opzione:

Opzione Descrizione

Host uses xinetd or systemd (Linux/AIX/Solaris only)

Questa opzione deve essere attivata per i sistemi Unix-like con xinetd/systemd. Con systemd l'esecuzione asincrona del plug-in dell'agente è obbligatoria - all'intervallo specificato dall'utente. Puoi trovare maggiori informazioni a riguardo nell'installazione del plug-in dell'agente.

Instances to monitor

Questa opzione riassume diverse opzioni del file di configurazione con cui puoi includere o escludere istanze per Linux, Solaris, AIX o Windows.

Add pre or postfix to TNSALIASes (Linux/AIX/Solaris only)

Questa opzione ti permette di estendere l'alias TNS a livello globale o per un'istanza specifica.

Sections - data to collect

In questa opzione sono elencate tutte le sezioni disponibili, che possono essere configurate individualmente a livello globale e che corrispondono alle variabili SYNC_SECTIONS e ASYNC_SECTIONS e, per ASM, alle loro controparti SYNC_ASM_SECTIONS e ASYNC_ASM_SECTIONS. Per maggiori informazioni, consulta la sezione relativa ai dati da prelevare per Linux, Solaris, AIX o Windows.

Exclude some sections on certain instances

Se non vuoi utilizzare EXCLUDE_<SID> per escludere l'intera istanza, ma solo per escludere alcune sezioni, puoi farlo con questa opzione, come descritto per Linux, Solaris, AIX o Windows.

Cache age for background checks

Specifica per quanto tempo le sezioni asincrone devono rimanere valide: il valore predefinito è 600 secondi (10 minuti).

Sqlnet Send timeout

Questa opzione viene aggiunta al file sqlnet.ora e imposta un timeout valido per tutte le istanze.

Remote instances (Linux/AIX/Solaris only)

Configura le istanze remote con questa opzione. Contiene tutti gli elementi della configurazione che già conosci. Per specificare l'ID della variabile, tramite Unique ID puoi scegliere tra varie opzioni. Devi solo assicurarti che l'ID sia unico all'interno della configurazione.

ORACLE_HOME to use for remote access (Linux/AIX/Solaris only)

Qui puoi determinare dove il plug-in dell'agente trova il programma sqlplus. Devi inserire un valore in questo punto se vuoi monitorare un'istanza remota, ma sqlplus non può essere trovato tramite le variabili d'ambiente.

TNS_ADMIN to use for sqlnet.ora and tnsnames.ora (Linux/AIX/Solaris only)

Se i due file si trovano in una directory diversa da /etc/check_mk/, puoi utilizzare questa opzione per specificare il nome del percorso tramite la variabile d'ambiente TNS_ADMIN.

sqlnet.ora permission group (Linux/AIX/Solaris only)

Inserisci qui il gruppo Linux dell'utente non privilegiato che possiede i binary Oracle in modo che questo utente possa leggere il file sqlnet.ora creato dall'agent bakery. Per un'installazione Oracle standard, oinstall può essere utilizzato come gruppo.
Ulteriori informazioni sono disponibili nella sezione Diritti di accesso all'esecuzione per Linux. Vengono menzionati anche altri file e directory, es. tnsnames.ora, che non vengono creati dall'agent bakery. Anche per questi file e directory creati manualmente devi impostare manualmente i permessi necessari.

Oracle binaries permissions check (Windows only)

Qui puoi configurare il controllo dei diritti di accesso per i binary Oracle, consentendo a singoli utenti e gruppi non amministrativi di eseguire i programmi. Dovresti disattivare il controllo solo se sai cosa stai facendo. Puoi trovare maggiori informazioni su questo tema nella sezione Diritti di accesso all'esecuzione per Windows.

6. Istanze in cluster

6.1. Database standby

Oracle supporta i cosiddetti database standby che possono svolgere compiti specifici e che di solito sono semplicemente delle copie dei database di produzione o primari. Questi concetti di database richiedono anche meccanismi di monitoraggio speciali. Puoi trovare maggiori informazioni su questi meccanismi nelle sezioni seguenti.

Con Active Data Guard (ADG)

Una volta ottenuta la licenza e l'attivazione dell'ADG, non dovrai apportare alcuna modifica alla configurazione del plug-in dell'agente, poiché potrai leggere da un'istanza standby in qualsiasi momento senza dover interrompere la sincronizzazione con l'istanza primaria.

Senza Data Guard (DG) attivo

Se le istanze non hanno ADG, l'utente che deve recuperare i dati di monitoraggio dalle istanze in standby deve avere il ruolo SYSDBA. Questo permesso consente all'utente di recuperare almeno una parte dei dati, anche se l'istanza primaria si guasta e l'istanza sul server in standby non è ancora stata cambiata da MOUNTED a OPEN.

Assegna il permesso all'utente autorizzato a recuperare i dati dalle istanze.Importante: il funzionamento potrebbe essere diverso dall'esempio seguente. Qui il ruolo è assegnato all'utente creato nell'esempio di configurazione iniziale:

sqlplus> grant sysdba to checkmk;

Per consentire ai dati di essere interrogati dal plug-in dell'agente sul server standby in caso di errore, crea l'utente sull'istanza primaria e poi copia il file password sul server standby. Infine, nel file di configurazione del plug-in, imposta il ruolo dell'utente su SYSDBA:

/etc/check_mk/mk_oracle.cfg
# Syntax:
# DBUSER='USER:PASSWORD:ROLE:HOST:PORT:TNSALIAS'
DBUSER='checkmk:myPassword:sysdba'

Si noti che l'indicazione di un host, di una porta o di un alias TNS è facoltativa e può essere omessa. Inoltre, il plug-in dell'agente deve essere installato sull'host dell'istanza primaria e sugli host delle istanze standby.

Impostazione dei servizi del cluster

Per quanto riguarda Checkmk, è necessario - indipendentemente dal fatto che si utilizzi ADG o DG - personalizzare i servizi e assegnarli a un host del cluster. I plug-in di controllo corrispondenti sono già stati preparati in modo tale da poter essere configurati anche come servizi del cluster. Crea un host del cluster in Checkmk e aggiungi ad esso i singoli host Oracle su cui sono in esecuzione le istanze primarie e standby come nodi. Quindi assegna i seguenti servizi a questo host del cluster:

  • ORA .* RMAN Backup

  • ORA .* Job

  • ORA .* Tablespaces

In questo modo non dovrai più preoccuparti da quale istanza provengono i dati e avrai garantito un monitoraggio continuo dei servizi sopra citati, anche in caso di cambio di istanza primaria.

6.2. Cluster di applicazioni reali (RAC)

Poiché in un RAC i dati vengono archiviati a livello centrale, è sufficiente creare l'utente per il plug-in dell'agente una sola volta. Solo il plug-in dell'agente deve essere installato e configurato su ogni nodo del cluster Oracle.

Importante: configura sempre tu stesso i nodi del cluster e non interrogare l'ascoltatore Oracle SCAN: solo così potrai assicurarti che l'accesso tramite il plug-in dell'agente funzioni correttamente.

Impostazione dei servizi del cluster

Oltre ai servizi assegnati all'host del cluster nell'ambito di un Data Guard (attivo), devi assegnare anche i seguenti servizi all'host del cluster per garantire un monitoraggio continuo in caso di switch over:

  • ASM.* Diskgroup

  • ORA .* Recovery Area

7. Query SQL personalizzate (Custom SQLs)

7.1. Perché le query SQL personalizzate?

Con il plug-in dell'agente Checkmk fornisce già un gran numero di query SQL con cui puoi monitorare le istanze del tuo database. Per renderle adatte alla più ampia gamma possibile di requisiti tecnici e di contenuto, sono ovviamente mantenute in un modulo molto generalizzato.

Per poter soddisfare i requisiti individuali di ogni azienda per il monitoraggio di un database specifico, Checkmk offre la possibilità di creare query SQL personalizzate( in breveSQL personalizzate ) e di recuperarle con il plug-in dell'agente. Queste query SQL personalizzate vengono poi riconosciute automaticamente e monitorate come servizi propri nell'interfaccia web.

Tip

È possibile utilizzare query SQL personalizzate solo in Linux, Solaris e AIX. Questa opzione non è disponibile in Windows.

7.2. Semplici query SQL personalizzate

Scrivere query SQL

Il modo più semplice per connettere un SQL di questo tipo è utilizzare Oracle Database: Per farlo, crea prima il file MyCustomSQL.sql nella directory di configurazione dell'agente sull'host su cui deve essere eseguito l'SQL.

Il seguente è un file fittizio che illustra la sintassi:

/etc/check_mk/MyCustomSQL.sql
/*Syntax help in comments. The first word is alwyas the key word and ends with a ":"*/

/*details:Text to display in the service detail output*/
prompt details: Some details for the service output;

/*perfdata:METRIKNAME=CURRENTVALUE;WARN;CRIT;MAX METRIKNAME=CURRENTVALUE2;WARN;CRIT;MAX*/
prompt perfdata:MyMetricName1=10;15;20;30 MyMetricName2=16;15;20;30;
prompt perfdata:MyMetricName3=21;15;20;30 MyMetricName4=15;15;20;30;

/*long:Text to display in the long output of the service*/
prompt long: Here comes some long output for the service;
prompt long: Here comes some more long output for the service;

/*exit:Status of the service as a number*/
prompt exit:2;

L'esempio mostra da un lato che è possibile definire un numero qualsiasi di istruzioni in un file di questo tipo, dall'altro che la sintassi è molto simile a quella di un check locale, soprattutto per quanto riguarda le metriche. In dettaglio, questa sintassi è molto più potente in questo caso, perché è possibile generare un output a più righe, che viene poi processato dal server Checkmk come servizio. In linea di principio, tutte le righe sono opzionali e non devono essere riempite.

Le keyword possibili sono in dettaglio:

  • details: Qui puoi stabilire cosa deve essere visualizzato nel servizio generato Summary. Questa riga è introdotta dalla keyword e dai due punti. Il resto della riga è l'output.

  • perfdataAll'interno di una riga, puoi creare un numero qualsiasi di metriche, ognuna separata da uno spazio. Puoi anche distribuire l'output delle metriche su più righe, ma inizia sempre con la keyword perfdata:.

  • longSe il servizio deve avere un output lungo per il campo Details, puoi specificarlo qui. Puoi anche usare questa keyword più volte per creare più righe nel campo Details.

  • exitLe assegnazioni note 0, 1, 2, 3 sono disponibili per gli stati OK, WARN, CRIT, SCONOSCIUTO.

Tip

Non è necessario definire manualmente la keyword elapsed. Essa viene generata automaticamente nel tempo di esecuzione per verificare quanto tempo hanno impiegato le dichiarazioni che hai definito per essere processate.

Configurare il plug-in dell'agente

Ora che hai definito il tuo primo, semplicissimo SQL, rendilo noto al plug-in dell'agente mk_oracle. Questo avviene tramite il noto file di configurazione, che puoi espandere di conseguenza:

/etc/check_mk/mk_oracle.cfg
SQLS_SECTIONS="mycustomsection1"

mycustomsection1 () {
    SQLS_SIDS="INST1"
    SQLS_DIR="/etc/check_mk"
    SQLS_SQL="MyCustomSQL.sql"
}

Con la prima opzione (SQLS_SECTIONS) stabilisci quali singole sezioni vuoi che vengano eseguite. Nota che per sezione si intende una parte dell'output del plug-in dell'agente e non una parte di un'istanza del database. Nell'esempio, abbiamo specificato solo una sezione (mycustomsection1) e l'abbiamo descritta in modo più dettagliato direttamente dopo. Ogni sezione è in realtà una piccola funzione chiamata dal plug-in dell'agente.

In questa funzione puoi determinare ulteriori dettagli e specificare per quali istanze (SQLS_SIDS) si applica questa sezione. Inoltre, definisci anche dove si trova il file con le istruzioni SQL (SQLS_DIR) e il nome di questo file (SQLS_SQL).

Questa semplice configurazione è sufficiente per poter vedere il risultato in Checkmk. Per farlo, esegui una scoperta del servizio e attiva il nuovo servizio. In seguito vedrai il nuovo servizio insieme agli altri nella panoramica dell'host:

The new service created by custom SQL queries in the service list.

7.3. Opzioni avanzate

Le possibilità di monitoraggio con query SQL personalizzate vanno ovviamente oltre il semplice esempio mostrato sopra. Di seguito troverai una panoramica delle variabili disponibili che puoi utilizzare nel file di configurazione mk_oracle.cfg. Per una descrizione dettagliata, puoi anche richiamare il plug-in dell'agente mk_oracle con l'opzione --help.

Tip

Le variabili che possono essere impostate solo al di fuori o solo all'interno di una funzione di sezione sono contrassegnate di conseguenza. Tutte le altre possono essere definite in entrambe le sezioni. Se vengono impostate al di fuori di una sezione, saranno applicate globalmente a tutte le sezioni.
Variabile Breve descrizione Opzionale

SQLS_SECTIONS

Le funzioni di sezione autodefinite che devono essere eseguite dal plug-in dell'agente.
Questa variabile può essere impostata solo globalmente (al di fuori di una funzione di sezione).

No

SQLS_SIDS

Le istanze che devono eseguire le sezioni.

No

SQLS_DIR

Il percorso della directory in cui sono memorizzati i file con le query SQL personalizzate.

No

SQLS_SQL

Il file che contiene le istruzioni SQL per una sezione.

No

SQLS_SECTION_NAME

Il nome della sezione da valutare con un plug-in di controllo per le query SQL personalizzate.

Sì

SQLS_SECTION_SEP

Il separatore dei singoli elementi in una riga dell'output, definito come un ID ASCII decimale. Questa variabile può essere utilizzata solo in combinazione con la variabile SQLS_SECTION_NAME. Ti consigliamo di definire il tuo separatore per le tue sezioni e di utilizzare l'ID ASCII 124 per il carattere pipe (|), poiché il plug-in dell'agente separa sempre gli elementi dell'output in caso di errore con |, nel formato <SID>|FAILURE|<error description>. I seguenti caratteri non possono essere utilizzati come separatore: ; [ ] =

Sì

SQLS_ITEM_NAME

Specifica una parte del nome del servizio generato. Per valore predefinito, il nome del servizio è composto da SID e dal nome del file con le query SQL personalizzate. Il valore di questa variabile sostituisce il nome del file nel nome del servizio.
Questa variabile può essere impostata solo localmente (all'interno di una funzione di sezione) e non può essere utilizzata insieme alla variabile SQLS_SECTION_NAME.

Sì

SQLS_MAX_CACHE_AGE

Esegue lo stesso compito di CACHE_MAXAGE- ma per le query SQL personalizzate.

Sì

SQLS_DBUSER

Definisce un utente individuale per una sezione.

Sì

SQLS_DBPASSWORD

Definisce la password dell'utente definito con SQLS_DBUSER.

Sì

SQLS_DBSYSCONNECT

Solo se l'utente definito con SQLS_DBUSER è SYSDBA o SYSOPER devi definire il ruolo associato (SYSDBA o SYSOPER) con questa variabile.

Sì

SQLS_TNSALIAS

Definisce un alias TNS individuale per una sezione.

Sì

7.4. Utilizzo di plug-in di controllo personalizzati

Se le possibilità offerte dalla sintassi descritta sopra non sono sufficienti, puoi anche utilizzare la variabile SQLS_SECTION_NAME per produrre i nomi del tuo plug-in per una o più query SQL e definire il tuo separatore con SQLS_SECTION_SEP. Tuttavia, questo richiede che tu abbia scritto un plug-in di controllo appropriato e che lo abbia incluso nella tua istanza Checkmk.

Se hai scritto un tale plug-in di controllo, sei completamente libero di valutare l'output delle sezioni autodefinite del plug-in dell'agente e puoi procedere per la tua strada. Poiché questo metodo è il più completo e anche il più difficile, viene qui menzionato solo per completezza. Presuppone che tu sappia come scrivere un plug-in di controllo basato sull'agente e integrarlo nel sito. Dopodiché assegna le query SQL personalizzate con le variabili a questo plug-in di controllo.

8. Opzioni di diagnostica

In Linux, la diagnostica viene eseguita richiamando il plug-in dell'agente mk_oracle con varie opzioni. Con mk_oracle --help puoi visualizzare una panoramica di tutte le opzioni disponibili.

8.1. Test delle connessioni

Tip

Il test di connessione descritto di seguito controlla anche se i diritti di accesso necessari sono impostati durante l'esecuzione su Linux o Windows. Se mancano i diritti di accesso, questi vengono visualizzati con suggerimenti specifici per la loro correzione. La procedura esatta per la diagnosi e la correzione dei diritti di accesso è disponibile nella Knowledge Base di Checkmk.

Linux, Solaris, AIX

Se hai problemi di connessione a una o più istanze di un server Oracle, la prima cosa da fare è controllare i parametri di base. Se avvii il plug-in dell'agente con l'opzione -t, questo visualizza i dettagli di una connessione. Nota che al plug-in dell'agente devono essere forniti in anticipo i percorsi del suo file di configurazione e dei dati cache del plug-in. Nell'output le sezioni fittizie sono state omesse per motivi di leggibilità.

L'esempio seguente riguarda un server Linux con systemd, sul quale il plug-in dell'agente viene eseguito in modo asincrono ogni 60 secondi:

root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -t --no-spool
---login----------------------------------------------------------------
    Operating System:       Linux
    ORACLE_HOME (oratab):   /u01/app/oracle/product/11.2.0/xe
    Logincheck to Instance: XE
    Version:                11.2
    Login ok User:          checkmk on ORA-SRV01 Instance XE
    SYNC_SECTIONS:          instance dataguard_stats processes longactivesessions sessions recovery_status undostat logswitches recovery_area performance
    ASYNC_SECTIONS:         tablespaces rman jobs ts_quotas resumable
------------------------------------------------------------------------

Su un server Linux con xinetd, chiama invece mk_oracle per il test di connessione come segue:

root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -t

Poiché è più probabile che questa chiamata venga effettuata in caso di errore, riceverai anche altre informazioni: sia la stringa di connessione utilizzata per la connessione che i primi 100 caratteri del messaggio di errore restituito durante il tentativo di connessione. Con l'aiuto di queste informazioni, potrai identificare rapidamente semplici problemi di configurazione e correggerli di conseguenza.

Windows

Il plug-in dell'agente non accetta alcun parametro in Windows. Per testare la connessione in questo caso, limita temporaneamente le sezioni da recuperare a instance e attiva l'opzione DEBUG:

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
# Syntax:
# $DBUSER = @("USERNAME", "PASSWORD")
$DBUSER = @("checkmk", "myPassword")

SYNC_SECTIONS = @("instance")
ASYNC_SECTIONS = @("")
DEBUG = 1

Esegui quindi il plug-in dell'agente manualmente. Anche in questo caso, otterrai informazioni sul modo in cui il plug-in tenta di accedere alle istanze. L'output potrebbe essere simile a questo, ad esempio:

PS C:\ProgramData\checkmk\agent\plugins\> .\mk_oracle.ps1
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of DBVERSION software = xxx112020xxx
<<<oracle_instances>>>
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of inst_name = xxxXExxx
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of DBVERSION database = xxx112020xxx
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of the_section = sql_instance
2020-08-23T12:48:20.3930944+02:00 DEBUG:now calling multiple SQL
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of sql_connect in dbuser = checkmk/myPassword@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SID=XE))) as sysdba
<<<oracle_instance>>>
XE|FAILURE|...

8.2. Log

Linux, Solaris, AIX

Se non è possibile trovare l'errore verificando una semplice connessione, il passo successivo è quello di creare un file di log che registra tutti i passaggi del plug-in dell'agente. Non dimenticare le variabili d'ambiente necessarie. Nell'esempio seguente, l'output delle sezioni è stato omesso per migliorare la leggibilità.

Ecco la chiamata per un server Linux con systemd, sul quale il plug-in dell'agente viene eseguito in modo asincrono ogni 60 secondi:

root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -l --no-spool
Start logging to file: /var/lib/check_mk_agent/log/mk_oracle.log

Ecco la chiamata di mk_oracle per il log su un server Linux con xinetd:

root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -l

Puoi utilizzare il file di log generato per identificare con precisione su quale riga dello script si è verificato il problema.

Windows

La registrazione in Windows funziona in modo simile al test di connessione descritto sopra. Se la connessione è stabile, puoi aggiungere le sezioni reali al file di configurazione e ottenere un output di log completo.

8.3. Debug

Linux, Solaris, AIX

Se non riesci ad arrivare al problema nemmeno con l'aiuto del log, come ultima opzione il plug-in dell'agente fornisce l'output completo di tutti i passaggi per l'analisi degli errori. Questo output è quindi il metodo più completo e sicuramente più difficile da leggere per arrivare alla causa di un problema e dovrebbe quindi essere usato solo come ultima risorsa.

Quello che segue è un esempio di debug su un server Linux con systemd, sul quale il plug-in dell'agente viene eseguito in modo asincrono ogni 60 secondi:

root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -d --no-spool

Ecco la chiamata di mk_oracle per il debug su un server Linux con xinetd:

root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -d

Importante: in questo output i dati sensibili come le password non sono mascherati, quindi tutto è leggibile in chiaro.

Windows

Una funzionalità simile è disponibile in Windows. Tuttavia, poiché non è possibile passare alcun argomento al plug-in dell'agente, dovrai switchare il tracciamento manualmente:

PS C:\ProgramData\checkmk\agent\plugins\> Set-PSDebug -Trace 1
PS C:\ProgramData\checkmk\agent\plugins\> .\mk_oracle.ps1

8.4. Messaggi di errore nei file di log di Oracle

L'utente del database per il monitoraggio di solito non richiede il ruolo SYSDBA. Tuttavia, tieni presente che il plug-in dell'agente mk_oracle può generare messaggi di errore (non rilevanti per il monitoraggio) con i database multiutente che potrebbero non essere scritti nei file di log del database Oracle a causa della mancanza del privilegio SYSDBA. Questo può portare, ad esempio, a messaggi di errore Oracle del tipo ORA-01031: insufficient privileges in un file di log di avviso.

9. File e directory

9.1. Sull'host Oracle in Linux, Solaris e AIX

Percorso dei file Descrizione

/usr/bin/check_mk_agent

L'agente Checkmk che raccoglie tutti i dati sull'host.

/usr/lib/check_mk/plugins/mk_oracle/

Il plug-in dell'agente Oracle nella directory abituale per i plug-in dell'agente. Nota che il nome del plug-in in AIX è leggermente diverso: /usr/check_mk/lib/plugins/mk_oracle

/etc/check_mk/oracle.cfg

Il file di configurazione del plug-in dell'agente. Anche in questo caso, AIX è diverso: /usr/check_mk/conf/mk_oracle.cfg

/etc/check_mk/sqlnet.ora

Il file di configurazione necessario per Oracle Wallet.

/etc/check_mk/tnsnames.ora

Il file di configurazione che contiene gli alias TNS. I file di esempio si trovano anche nell'installazione di Oracle, ma poiché il percorso varia da installazione a installazione, non è possibile specificarlo in modo standardizzato.

9.2. Sull'host Oracle in ambiente Windows

Percorso del file Descrizione

C:\Program Files (x86)\checkmk\service\check_mk_agent.exe

L'agente Checkmk che raccoglie tutti i dati sull'host.

C:\ProgramData\checkmk\agent\plugins\mk_oracle.ps1

Il plug-in dell'agente Oracle nella directory abituale per i plug-in dell'agente.

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1

Il file di configurazione del plug-in dell'agente.

C:\ProgramData\checkmk\agent\config\sqlnet.ora

Il file di configurazione necessario per il portafoglio Oracle.

C:\ProgramData\checkmk\agent\config\tnsnames.ora

Il file di configurazione che contiene gli alias TNS. I file di esempio si trovano anche nell'installazione di Oracle, ma poiché il percorso varia da installazione a installazione, non è possibile specificarlo in modo standardizzato.

9.3. Sul server Checkmk

Percorso del file Descrizione

~/share/check_mk/agents/plugins/mk_oracle

Il plug-in dell'agente per i sistemi Unix-like, che recupera i dati sull'host Oracle.

~/share/check_mk/agents/plugins/mk_oracle_crs

Questo plug-in dell'agente per i sistemi Unix-like fornisce i dati a un Oracle Cluster Manager.

~/share/check_mk/agents/windows/plugins/mk_oracle.ps1

Il plug-in dell'agente per Windows, che recupera i dati sull'host Oracle.

~/share/check_mk/agents/cfg_examples/

Ecco dei file di configurazione di esempio per i sistemi Unix-like nei file mk_oracle.cfg, sqlnet.ora e tnsnames.ora.

~/share/check_mk/agents/windows/cfg_examples/mk_oracle_cfg.ps1

Un esempio di file di configurazione per Windows.
In questa pagina