Checkmk
DeutschEnglish
master2.3.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 puoi non solo recuperare i tablespace di un database o le sue 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 dare un'occhiata al catalogo. Tra le altre cose, Checkmk può monitorare i seguenti valori:

Per poter monitorare i database è necessario solo il plug-in dell'agente, oltre all'agente sul server del database. Attualmente sono supportati i sistemi operativi Linux, Solaris, AIX e Windows. Il plug-in dell'agente per i sistemi operativi di tipo Unix (Linux, Solaris, AIX) si chiama mk_oracle e per Windows mk_oracle.ps1. Non è richiesto alcun software aggiuntivo per il monitoraggio, né sul server Checkmk né sul server del database.

Molti dei passaggi per configurare il monitoraggio sono gli stessi sia per Linux che per Windows. Le differenze sono evidenziate nel capitolo sulla configurazione su Linux, Solaris, AIX e Windows. Con la funzione Agent Bakery delle edizioni commerciali, hai la possibilità di configurare l'installazione per diversi ambienti da un unico posto.

2. Configurazione iniziale

I file di configurazione con contenuti di esempio presentati in questo e nei capitoli seguenti sono disponibili sul server Checkmk, sia tramite la riga di comando che tramite l'interfaccia web di Checkmk. In Checkmk Community seleziona Setup > Agents e nelle edizioni commerciali Setup > Agents > Windows, Linux, Solaris, AIX > Related. In tutte le edizioni troverai voci di menu per i diversi sistemi operativi. I file di configurazione si trovano nella casella Example Configurations.

2.1. Creazione di un utente del database

In linea di massima, la prima configurazione è veloce e richiede solo tre passaggi. Il primo passo, ovviamente, è avere un utente che sia autorizzato a interrogare i database. A meno che tu non stia 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, puoi farlo, ad esempio, impostando sempre prima l'istanza pertinente 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
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Quindi accedi all'istanza e crea un utente per il monitoraggio. Per ottenere tutti i dati, sono necessarie le seguenti autorizzazioni. 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
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Puoi scoprire esattamente come funziona l'accesso a un'istanza specifica nella documentazione Oracle.

Database multi-tenant

Puoi anche configurare l'accesso per i database multi-tenant. Questo viene solitamente eseguito nella configurazione utilizzando un utente speciale e con il prefisso C##. L'assegnazione dei permessi è leggermente diversa rispetto agli utenti regolari, poiché devi 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
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

2.2. Creazione della configurazione

Dopo aver creato un utente, il passo successivo è abilitare il plug-in dell'agente per ricevere in seguito queste informazioni. Il modo più semplice è definire gli stessi dati di accesso per tutte le istanze e impostare un valore predefinito nella configurazione.

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX

Crea il file di configurazione mk_oracle.cfg sull'host Oracle:

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

L'utente standard è tutto ciò di cui il plug-in dell'agente ha realmente bisogno. Tutte le altre opzioni che puoi impostare nei sistemi di tipo Unix o in Windows sono facoltative.

2.3. Utilizzo di Oracle Wallet

In alternativa alla specifica diretta dell’utente e della password in un file di configurazione, puoi anche utilizzare Oracle Wallet. Questo ha il vantaggio che non è più necessario memorizzare i dati di accesso in forma non crittografata sul server Checkmk e sull'host Oracle. Quindi, anche se hai definito i diritti di accesso del file di configurazione sull'host Oracle in modo adeguato, i dati di accesso hanno comunque lasciato il server e si trovano sul server Checkmk fintanto che utilizzi l'Agent Bakery.

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

root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -create
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Il plug-in dell'agente accederà a questo file in seguito ogni volta che dovrà essere stabilita una connessione a un'istanza. Affinché possano essere trovati anche i dati utente necessari, devi inserirli una volta nel wallet. Nell'esempio seguente aggiungi quindi l'utente checkmk per l'istanza MYINST1:

root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -createCredential MYINST1 checkmk myPassword
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
Accesso in scrittura agli appunti negato!

Affinché il plug-in dell'agente sappia dove cercare il wallet, deve trovare due file. Il primo file è sqlnet.ora, in cui si trovano le informazioni relative alla posizione del wallet. Il secondo file — tnsnames.ora — definisce l'indirizzo dell'istanza in modo che possa essere raggiungibile anche tramite il suo alias. Per consentire al plug-in dell'agente di accedere a questi file, puoi specificare il percorso su Linux, Solaris e AIX utilizzando la variabile d'ambiente TNS_ADMIN. Questo è particolarmente utile se i file esistono già. In alternativa, puoi crearli esplicitamente. Windows richiede addirittura che tu li specifichi manualmente.

Per prima cosa crea il file sqlnet.ora. Il plug-in dell'agente cerca in questo file i dati di accesso, quindi qui devi inserire il percorso corretto del file wallet che hai 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 utilizzare. Affinché acceda anche all'indirizzo corretto, crea tnsnames.ora come secondo file. La sintassi esatta è disponibile nella documentazione Oracle, ma a titolo di esempio il file potrebbe apparire così:

/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 una barra (/):

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

Ovviamente puoi aggiungere ulteriori dati di accesso al wallet in un secondo momento. Il file tnsnames.ora dovrà quindi essere semplicemente modificato secondo necessità.

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 (come $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, supponiamo che il gruppo sia oinstall.

I seguenti comandi 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
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Questi comandi assicurano poi 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
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Le autorizzazioni dovrebbero quindi apparire più o meno così:

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
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

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

3. Configurazione per Linux, Solaris, AIX e Windows

Puoi configurare il monitoraggio sia su sistemi Unix-like che su Windows. Tuttavia, alcune opzioni non sono disponibili o lo sono solo in misura limitata su Windows. Le sezioni seguenti contengono tutte le informazioni necessarie per configurare il monitoraggio nei vari ambienti.

3.1. Percorsi dei plug-in e di configurazione

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX

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

Sistema operativo Percorso del plug-in Percorso di 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/
Windows

3.2. Installazione del plug-in dell'agente

Dopo aver creato un utente durante la configurazione iniziale e averlo salvato nel file di configurazione, installa il plug-in dell'agente.

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX

Copia il file mk_oracle dalla directory ~/share/check_mk/agents/plugins/ del server Checkmk alla directory dei plug-in dell’host Oracle descritta sopra.

Important

Il plug-in dell'agente per sistemi di tipo Unix 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 in /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. Consigliamo un'esecuzione ogni minuto, ovvero /usr/lib/check_mk_agent/plugins/60/. Durante la configurazione tramite Agent Bakery, puoi farlo utilizzando l'opzione "Host uses xinetd or systemd" della regola Oracle, che è impostata di default su xinetd.

Assicurati di rendere eseguibile il plug-in dell'agente:

root@linux# cd /usr/lib/check_mk_agent/plugins/
root@linux:/usr/lib/check_mk_agent/plugins# ls -lA
-rw-r--r-- 1 root root 120808 Jan 25 11:29 mk_oracle
root@linux:/usr/lib/check_mk_agent/plugins# chmod +x mk_oracle
root@linux:/usr/lib/check_mk_agent/plugins# ls -lA
-rwxr-xr-x 1 root root 120808 Jan 25 11:29 mk_oracle
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!
Windows

3.3. Opzioni avanzate

Nella configurazione iniziale hai già imparato a conoscere le prime variabili per ottenere i dati di monitoraggio dalle tue istanze Oracle. Tuttavia, a seconda dello scenario applicativo, avrai presto bisogno di ulteriori possibilità per un controllo migliore e personalizzato del monitoraggio per ogni istanza. Troverai queste opzioni nelle sezioni seguenti. Alcune delle opzioni sono disponibili solo in ambienti di tipo Unix.

Configurazione utente avanzata

Con il login standard puoi utilizzare le istanze regolari o eventualmente anche tutte le istanze di un database. Tuttavia, ci sono casi particolari in cui sono necessari dati di accesso individuali per istanze specifiche. Nel file di configurazione hai quindi le seguenti tre opzioni per specificare gli utenti:

Parametro Descrizione

DBUSER

L'impostazione predefinita se non sono stati definiti dati di accesso individuali per l'istanza del database.

DBUSER_MYINST1

Dati di accesso per un'istanza specifica del database — 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 offrono ulteriori opzioni oltre al nome utente e alla password. Puoi anche determinare se l'utente è un SYSDBA o un SYSASM, su quale combinazione di indirizzo e porta l'istanza è in ascolto e persino — per i sistemi di tipo Unix — quale alias TNS (TNSALIAS) deve essere utilizzato. Tuttavia, queste specifiche sono sempre — a differenza di nome utente e password — opzionali.

Il file di configurazione creato all'inizio può quindi essere esteso come segue, ad esempio:

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX
/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 relative all'esempio sopra riportato:

  • Puoi definire un numero qualsiasi di dati di accesso individuali. Questi hanno sempre la precedenza rispetto allo standard.

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

  • Se un campo opzionale viene omesso nel mezzo della stringa, è necessario inserire un punto e virgola, come nella voce "DBUSER_MYINST2", dove 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 nella voce ASMUSER, dove non sono stati specificati né host, né porta, né alias TNS.

Windows

Inclusione o esclusione di istanze

In alcuni casi potresti non voler includere particolari istanze nel monitoraggio. Questo potrebbe essere perché si tratta solo di un ambiente di prova per gli sviluppatori, o per altri motivi. Per rendere la configurazione il più semplice possibile nelle singole situazioni, hai a disposizione varie opzioni per escludere totalmente o parzialmente una o più istanze:

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX
Parametro Descrizione

ONLY_SIDS

Qui puoi decidere quali istanze devono essere monitorate. Un'istanza viene identificata dal suo identificatore di sistema (SID). Si tratta di un elenco positivo, che ignora tutte le istanze non 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, questa è una lista negativa in cui vengono monitorate tutte le istanze tranne quelle esplicitamente elencate qui. Questo parametro è molto adatto se il numero di istanze da ignorare è inferiore al numero di quelle da monitorare.

EXCLUDE_<SID>

Con questo parametro puoi escludere parzialmente un'istanza, escludendo dal monitoraggio determinate sezioni dell'istanza. In questo modo, definisci un elenco negativo delle sezioni di un'istanza. Puoi anche escludere tutte le sezioni con il valoreALL e ottenere così lo stesso risultato che otterresti aggiungendo l'istanza aSKIP_SIDS .
Importante: per i SID ASM non puoi utilizzare questa procedura, ma puoi invece utilizzareSKIP_SIDS="+ASM1 …​" .

L'avrai già intuito: L'ordine in cui questi parametri vengono elaborati determina il risultato. Le voci vengono infatti elaborate per istanza esattamente nella sequenza mostrata nella tabella sopra. Pertanto, se la variabile ONLY_SIDS è impostata, SKIP_SIDS non viene più valutato né viene verificato se la variabile EXCLUDE_<SID> è impostata su ALL per questa istanza. Se ONLY_SIDS non è impostato, il sistema procede secondo la sequenza. In caso di dubbio, ovvero come comportamento predefinito, l'istanza verrà monitorata di conseguenza.

Di seguito trovi un esempio in cui tutte le variabili sono impostate e come si comporta il sistema:

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

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

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

Windows

Determinare i dati da recuperare

Come hai imparato nella sezione precedente, non solo è possibile disabilitare completamente le istanze, ma anche monitorarle solo parzialmente. I requisiti operativi sono diversi, ed è particolarmente pratico quando non è auspicabile includere determinate sezioni a lunga esecuzione in tutto, o quando sono richieste solo informazioni di base dalle istanze di test, ad esempio. Per limitare le sezioni a livello globale, imposta direttamente le variabili corrispondenti; per limitare solo determinate istanze puoi inserire la variabile EXCLUDE_<SID> di cui hai già parlato nella sezione precedente. Le variabili globali sono:

Parametro Descrizione

SYNC_SECTIONS

Sezioni da interrogare in modo sincrono, cioè ogni volta che l'agente viene eseguito. Poiché l'intervallo di interrogazione è di 60 secondi per impostazione predefinita, le query SQL utilizzate devono essere eseguite con la stessa rapidità. Se la variabile non è specificata, vengono interrogate tutte le sezioni.

ASYNC_SECTIONS

Sezioni da interrogare in modo asincrono, cioè solo ogni x minuti. La durata di validità dei dati è determinata dalla variabile CACHE_MAXAGE, riportata più avanti in questa tabella.

SYNC_ASM_SECTIONS

Qui 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 serve a determinare per quanto tempo i dati recuperati in modo asincrono rimangono validi. Se il valore della variabile non è specificato, viene utilizzato un valore predefinito di 600 secondi (10 minuti). Assicurati che l'intervallo di tempo non sia più breve dell'intervallo con cui l'agente Checkmk invia i dati (60 secondi per impostazione predefinita). Altrimenti, i dati potrebbero essere considerati obsoleti e non inviati dall'agente.

MAX_TASKS

Numero di SID elaborati in parallelo. Il valore predefinito è 1.

Il meccanismo ti permette quindi di impostare un valore predefinito nel file di configurazione e di sovrascriverlo per singole istanze, se necessario. Una configurazione potrebbe quindi apparire così, ad esempio:

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX
/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'
Windows

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

Important

Se nel file di configurazione definisci quali sezioni desideri recuperare e con quale metodo — puoi anche trasformare una sezione asincrona in una sincrona — devi specificare tutte 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:

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX
/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'
Windows

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

Configurazione di TNS Alias e TNS_ADMIN (solo Linux, Solaris, AIX)

L'alias TNS è un nome intuitivo per una connessione al database. TNS sta per Transparent Network Substrate, la tecnologia di rete Oracle. Un alias TNS permette di stabilire una connessione a un'istanza di database senza dover inserire ogni volta tutti i dettagli di connessione (come nome host, numero di porta o nome del servizio). Gli alias TNS sono definiti nel file tnsnames.ora in ambienti di tipo Unix. La sezione su Oracle Wallet contiene un esempio di come definire un alias TNS.

TNS_ADMIN è una variabile d'ambiente che punta alla directory in cui si trovano i file di configurazione 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 una specifica installazione Oracle:

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

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

Diritti di accesso all'esecuzione

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX

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

Tip

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

L'esecuzione dei programmi Oracle da parte di un utente senza privilegi può causare problemi quando si utilizza un portafoglio Oracle, poiché questo utente potrebbe non essere in grado di accedere ai file specifici del portafoglio. L'utente senza privilegi 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, purché tu abbia modificato il gruppo dei file e delle directory come descritto alla fine della sezione su Oracle Wallet.

Il plug-in dell'agente ti aiuta nella diagnosi e verifica se ci sono problemi nell'accesso ai file menzionati, visualizzandoli nel test di connessione. La procedura esatta per diagnosticare e correggere i diritti di accesso è disponibile nella Knowledge Base di Checkmk.

Windows

3.4. Monitoraggio di database remoti (solo Linux, Solaris, AIX)

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

Per il monitoraggio dei database remoti, sull'host su cui è installato il plug-in dell'agente devono essere soddisfatti i seguenti requisiti:

  • La libreria di accesso AIO per Linux deve essere installata. Su Red Hat Enterprise Linux e distribuzioni binariamente compatibili, il pacchetto si chiama libaio.

  • Oracle Instant Client deve essere installato.

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

Di norma, le condizioni sono già soddisfatte se sull'host è presente un'installazione Oracle. In caso contrario, installa i pacchetti appropriati per farlo.

Affinché il plug-in dell'agente possa connettersi al database remoto, devi prima memorizzare i dati di accesso nel file di configurazione. Questi sono simili alle specifiche per DBUSER, che avrai già incontrato nella configurazione utente avanzata. Tuttavia, ci sono una serie di specifiche obbligatorie aggiuntive:

/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. Questi possono essere scelti liberamente — devono solo essere unici per ogni file di configurazione. Come avrai probabilmente già notato, la specifica della porta è ora seguita da ulteriori valori. Questi sono 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 lì invece che sull'host dove è in esecuzione il plug-in dell'agente o da cui sono stati recuperati i dati. Non vedi questa specifica sulla seconda istanza MYINST1 — l'assegnazione a un altro host è facoltativa.

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 facoltativo.

Il terzo valore VERSION è obbligatorio e ciò è dovuto anche al fatto che molti metadati sono disponibili solo se ci si trova direttamente sull'host. Pertanto, non è possibile 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 accedi all'istanza remota tramite Oracle Wallet o LDAP/Active Directory. Nel caso in cui l'istanza risponda solo a uno specifico alias TNS, puoi specificare questo alias qui. Per la seconda istanza remota, TNSALIAS ha il valore INST1.

Per assicurarti che venga trovato anche il programma sqlplus, 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 eseguono query su istanze remote, ci sono alcune restrizioni e caratteristiche speciali:

  • Poiché hai inserito esplicitamente le istanze remote nel file di configurazione, non puoi escludere queste istanze utilizzando SKIP_SIDS e, di conseguenza, non è necessario includerle utilizzando ONLY_SIDS.

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

4. Configurazione con Agent Bakery

CEE La configurazione può essere notevolmente semplificata nelle edizioni commerciali con Agent Bakery, poiché si evitano errori di sintassi nei file di configurazione e gli adattamenti agli ambienti in evoluzione possono essere implementati più facilmente. La differenza principale rispetto a una configurazione manuale è che devi lavorare sulla riga di comando dell'host Oracle solo se desideri effettuare configurazioni specifiche per Oracle. Puoi eseguire la configurazione con Agent Bakery per Linux, Solaris, AIX e Windows.

Tuttavia, non è possibile configurare tutte le funzioni del plug-in dell'agente con 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 in 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 configurare il plug-in dell'agente:

Rule for configuring Oracle in the Agent Bakery.

Molte opzioni ti saranno familiari dalla configurazione manuale. Come descritto lì, 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.

4.1. Configurazione degli utenti

Nella configurazione più semplice per un sistema operativo di tipo Unix, la regola avrà un aspetto simile a questo:

Simplest rule for configuring Oracle in the Agent Bakery.

In Agent Bakery hai anche la possibilità di creare utenti standard e di definire eccezioni per istanze specifiche. Le opzioni separate da due punti (per Linux & Co.) o come voci di un elenco (per Windows) nel file di configurazione si trovano in Login Defaults come singole opzioni, che puoi poi compilare di conseguenza. Naturalmente, qui puoi anche utilizzare Oracle Wallet semplicemente cambiando Authentication method in Use manually created Oracle password wallet.

Puoi configurare l'Automatic Storage Management (ASM) allo stesso modo utilizzando l'opzione Login for ASM, e inserire le eccezioni per istanze specifiche sotto Login for selected databases, come descritto nella configurazione utente avanzata.

4.2. Opzioni avanzate

La tabella seguente elenca le restanti opzioni nel 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 di tipo Unix con xinetd / systemd. Con systemd l'esecuzione asincrona del plug-in dell'agente è obbligatoria, all'intervallo specificato. Per ulteriori informazioni, consulta Installazione del plug-in dell'agente.

Instances to monitor

Questa opzione combina diverse opzioni nel file di configurazione che ti consentono di 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

Tutte le sezioni disponibili sono elencate sotto questa opzione e possono essere configurate individualmente a livello globale. Corrispondono quindi alle variabili SYNC_SECTIONS e ASYNC_SECTIONS e, per ASM, alle loro controparti SYNC_ASM_SECTIONS e ASYNC_ASM_SECTIONS. Per ulteriori informazioni, consulta la sezione sui dati da recuperare.

Exclude some sections on certain instances

Se vuoi escludere solo alcune sezioni anziché l'intera istanza con EXCLUDE_<SID>, puoi specificarlo utilizzando questa opzione, come descritto nella sezione sui dati da recuperare.

Cache age for background checks

Specifica qui 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 che si applica a 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 qui 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 usare questa opzione per specificare il 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 proprietario dei file binari Oracle, in modo che questo utente possa leggere il file sqlnet.ora creato da Agent Bakery. Per un'installazione standard di Oracle, è possibile utilizzare oinstall come gruppo.
Per ulteriori informazioni, consulta la sezione Diritti di accesso durante l'esecuzione. Questa sezione elenca anche altri file e directory per Linux, come tnsnames.ora, che non vengono creati da Agent Bakery. Per questi file e directory creati manualmente devi specificare manualmente anche i permessi necessari.

Oracle binaries permissions check (Windows only)

Qui puoi configurare il controllo dei diritti di accesso per i binari Oracle consentendo a singoli utenti e gruppi non amministrativi di eseguire i programmi. Dovresti disattivare il controllo solo se sai esattamente cosa stai facendo. Puoi trovare ulteriori informazioni su questo argomento nella parte relativa a Windows della sezione Diritti di accesso durante l'esecuzione.

5. Istanze in cluster

5.1. Database di standby

Oracle supporta i cosiddetti database di standby, in grado di eseguire attività specifiche e che solitamente sono semplici copie dei database di produzione o primari. Anche questi concetti relativi ai database richiedono meccanismi di monitoraggio speciali. Puoi trovare ulteriori informazioni su questi meccanismi nelle sezioni seguenti.

Con Active Data Guard (ADG)

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

Senza Active Data Guard (DG)

Se le istanze non dispongono di ADG, l'utente con cui devono essere recuperati i dati di monitoraggio dalle istanze di standby necessita del ruolo "SYSDBA". Questa autorizzazione consente all'utente di recuperare almeno una parte dei dati, anche se l'istanza primaria si guasta e l'istanza sul server di standby non è ancora stata modificata da MOUNTED a OPEN.

Assegna l'autorizzazione all'utente autorizzato a recuperare i dati dalle istanze. Importante: il funzionamento potrebbe differire dall'esempio seguente. Qui il ruolo viene assegnato all'utente così come creato nell'esempio di configurazione iniziale:

sqlplus> grant sysdba to checkmk;
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Per consentire al plug-in dell'agente di interrogare i dati sul server di standby in caso di errore, crea l'utente sull'istanza primaria, quindi copia il file delle password sul server di 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'

Tieni presente che specificare un host, una porta o un alias TNS è facoltativo e può essere omesso. Inoltre, il plug-in dell'agente deve ovviamente essere installato sull'host dell'istanza primaria così come sugli host delle istanze di standby.

Configurazione dei servizi del cluster

Dal lato Checkmk, è necessario — indipendentemente dal fatto che tu stia utilizzando 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 di cluster in Checkmk e aggiungi come nodi i singoli host Oracle su cui sono in esecuzione le istanze primaria e di standby. Quindi assegna i seguenti servizi a questo host di cluster:

  • ORA .* RMAN Backup

  • ORA .* Job

  • ORA .* Tablespaces

A questo punto non dovrai più preoccuparti di quale istanza provengano i dati e avrai garantito un monitoraggio senza interruzioni dei servizi sopra menzionati, anche in caso di commutazione dell'istanza primaria.

5.2. Real Application Cluster (RAC)

Poiché in un RAC esiste un archivio centrale per i dati, in questo caso è sufficiente creare l'utente per il plug-in dell'agente una sola volta. È necessario installare e configurare il plug-in dell'agente solo su ciascun nodo del cluster Oracle.

Importante: configura sempre tu stesso i nodi del cluster e non interrogare il listener Oracle SCAN. Questo è l’unico modo per garantire che l’accesso tramite il plug-in dell’agente funzioni correttamente.

Configurazione dei servizi del cluster

È inoltre opportuno configurare i servizi del cluster per un RAC. Oltre ai servizi che assegni all’host del cluster in un (Active) Data Guard, assegna anche i seguenti servizi all’host del cluster per garantire un monitoraggio senza interruzioni in caso di switch over:

  • ASM.* Diskgroup

  • ORA .* Recovery Area

6. Query SQL personalizzate (SQL personalizzate)

6.1. Perché le query SQL personalizzate?

Con il suo plug-in agente, Checkmk offre già un gran numero di query SQL con cui puoi monitorare le tue istanze di database. Per renderle adatte alla più ampia gamma possibile di requisiti tecnici e di contenuto, sono ovviamente mantenute in una forma molto generica.

Per poter soddisfare le esigenze individuali di ogni azienda per il monitoraggio di un database specifico, Checkmk offre la possibilità di creare le proprie query SQL personalizzate (abbreviate in SQL personalizzate) e di farle recuperare tramite il plug-in dell'agente. Queste query SQL personalizzate vengono poi automaticamente riconosciute e monitorate come servizi propri nell'interfaccia web.

Tip

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

6.2. Query SQL personalizzate semplici

Scrivere query SQL

Il modo più semplice per collegare una query SQL di questo tipo è utilizzare il plug-in Oracle Database: Custom SQLs check. Per farlo, crea innanzitutto il file MyCustomSQL.sql nella directory di configurazione dell’agente sull’host su cui deve essere eseguita la query SQL.

Di seguito è riportato un esempio che illustra la sintassi:

/etc/check_mk/MyCustomSQL.sql
/*Syntax help in comments. The first word is always 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;
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

L'esempio mostra da un lato che puoi definire un numero qualsiasi di istruzioni in un file di questo tipo. D'altro canto, la sintassi è molto simile a quella di un controllo locale, specialmente per quanto riguarda le metriche. In dettaglio, questa sintassi è molto più potente in questo caso, perché puoi generare un output su più righe, che viene poi elaborato sul server Checkmk come un servizio. In linea di principio, tutte le righe sono opzionali e non è necessario compilarle.

Ecco in dettaglio le parole chiave disponibili:

  • details: Qui puoi determinare cosa deve essere visualizzato nell'Summary del servizio generato. Questa riga inizia con la parola chiave e due punti. Il resto della riga è l'output.

  • perfdata: Le metriche vengono passate con questa parola chiave. All’interno di una riga puoi creare un numero qualsiasi di metriche, separate da uno spazio. Puoi anche distribuire l’output delle metriche su più righe. Basta iniziare sempre con la parola chiave perfdata:.

  • long: Se il servizio deve avere un output lungo per il campo Details, puoi specificarlo qui. Puoi anche usare questa parola chiave più volte per creare più righe nel campo Details.

  • exit: Se l'output deve avere un determinato stato, puoi specificarlo qui. Le assegnazioni note 0, 1, 2, 3 sono disponibili per gli stati OK, WARN, CRIT, UNKNOWN.

Tip

Non devi definire manualmente la parola chiave elapsed. Viene generata automaticamente in fase di esecuzione per verificare quanto tempo ci hanno messo a elaborarsi le istruzioni che hai definito.

Configurazione del plug-in dell'agente

Ora che hai definito il tuo primo, semplicissimo SQL, fallo conoscere al plug-in dell'agente mk_oracle. Questo si fa tramite il solito 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) determini quali singole sezioni desideri che vengano eseguite. Tieni presente che per sezione si intende una parte dell'output del plug-in dell'agente — e non una parte di un'istanza di database. Nell'esempio, abbiamo specificato solo una sezione (mycustomsection1) e l'abbiamo descritta più dettagliatamente subito dopo. Ogni sezione è in realtà una piccola funzione chiamata dal plug-in dell'agente.

In questa funzione puoi quindi definire ulteriori dettagli e specificare a 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 un service discovery e attiva il nuovo servizio. In seguito vedrai questo nuovo servizio insieme agli altri servizi nella panoramica degli host:

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

6.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 sezione sono contrassegnate di conseguenza. Tutte le altre possono essere definite in entrambe le sezioni. Se vengono impostate al di fuori di una sezione, si applicano 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 la/le sezione/i.

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 che valuti con un plug-in di controllo personalizzato per le query SQL personalizzate.

Sì

SQLS_SECTION_SEP

Il separatore dei singoli elementi in una riga dell'output, definito come ID ASCII decimale. Questa variabile può essere utilizzata solo in combinazione con la variabile SQLS_SECTION_NAME. Ti consigliamo di definire un separatore personalizzato 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 separatori: ; [ ] =

Sì

SQLS_ITEM_NAME

Specifica una parte del nome del servizio generato. Per impostazione predefinita, il nome del servizio è composto dal SID e dal nome del file contenente 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). Non può essere utilizzata insieme alla variabile SQLS_SECTION_NAME.

Sì

SQLS_MAX_CACHE_AGE

Esegue la stessa operazione 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 creato 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ì

6.4. Utilizzo dei propri plug-in di controllo

Se le possibilità della sintassi descritta sopra non sono sufficienti, puoi anche usare la variabile SQLS_SECTION_NAME per generare i tuoi nomi di sezione per una o più query SQL e definire il tuo separatore con SQLS_SECTION_SEP. Tuttavia, questo richiede che tu abbia anche scritto un plug-in di controllo appropriato e lo abbia incluso nel tuo sito Checkmk.

Se hai scritto un plug-in di controllo di questo tipo, sei completamente libero di valutare l'output delle sezioni autodefinite del plug-in dell'agente e puoi procedere a modo tuo. Poiché questo metodo è il più completo, ma anche il più difficile, lo menzioniamo qui solo per completezza. Si presuppone che tu sappia come scrivere un plug-in di controllo basato su agente e integrarlo nel sito. Dopodiché assegni le query SQL personalizzate con le variabili a questo plug-in di controllo.

7. Opzioni di diagnostica

Il plug-in dell'agente mk_oracle (Linux, Solaris, AIX) o mk_oracle.ps1 (Windows) ti offre varie opzioni per la diagnosi degli errori. Le sezioni seguenti contengono informazioni sulla diagnosi nei vari ambienti.

7.1. Verifica delle connessioni

Se hai problemi a connetterti a una o più istanze su un server Oracle, la prima cosa che puoi fare è controllare i parametri di base.

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

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX

Se avvii il plug-in dell'agente con l'opzione -t, vengono visualizzati i dettagli di una connessione. Tieni presente che al plug-in dell'agente devono essere forniti in anticipo i percorsi del file di configurazione e dei dati memorizzati nella cache del plug-in. Nell'output le sezioni fittizie sono state omesse per facilitare la lettura.

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
------------------------------------------------------------------------
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

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
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Poiché questa chiamata viene effettuata più spesso in caso di errore, riceverai anche ulteriori informazioni: sia la stringa di connessione utilizzata per la connessione, sia i primi 100 caratteri del messaggio di errore restituito durante il tentativo di connessione. Grazie a queste informazioni, puoi identificare rapidamente semplici problemi di configurazione e correggerli di conseguenza.

Windows

7.2. Registrazione

Se l'errore non può essere individuato controllando una semplice connessione, il passo successivo è creare un file di log, che registra tutte le operazioni del plug-in dell'agente.

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX

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 csystemde, su cui 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
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

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

root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -l
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!
Windows

Puoi utilizzare i messaggi di log generati per identificare con estrema precisione in quale riga dello script si è verificato il problema.

7.3. Debug

Se non riesci a individuare il 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 il più difficile da leggere, per arrivare alla causa di un problema, e dovrebbe quindi essere utilizzato solo come ultima risorsa.

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX

Di seguito è riportato un esempio di debug su un server Linux con unsystemde, su cui 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
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

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
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!
Tip

I dati sensibili come le password non vengono mascherati in questo output. Tutto è quindi leggibile in chiaro.
Windows

7.4. Messaggi di errore nei file di log di Oracle

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

8. File e directory

8.1. Sull'host Oracle

Linux, Solaris, AIX
Windows
Linux, Solaris, AIX
Percorso del file Descrizione

/usr/bin/check_mk_agent

L'agente Checkmk che raccoglie tutti i dati relativi all'host.

/usr/lib/check_mk/plugins/mk_oracle/

Il plug-in dell'agente Oracle nella solita directory per i plug-in degli agenti. Nota che il percorso su AIX è leggermente diverso: /usr/check_mk/lib/plugins/mk_oracle

/etc/check_mk/oracle.cfg

Il file di configurazione per il 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 Oracle, ma poiché il percorso varia da installazione a installazione, non è possibile specificarlo in modo standardizzato.
Windows

8.2. Sul server Checkmk

Percorso del file Descrizione

~/share/check_mk/agents/plugins/mk_oracle

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

~/share/check_mk/agents/plugins/mk_oracle_crs

Questo plug-in agente per sistemi di tipo Unix fornisce 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 alcuni file di configurazione di esempio per sistemi simili a Unix nei file mk_oracle.cfg, sqlnet.ora e tnsnames.ora.

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

Un file di configurazione di esempio per Windows.
Last modified: Thu, 26 Mar 2026 08:22:01 GMT via commit e952de58f
In questa pagina