Monitoraggio IBM Db2

Il sensore è compatibile con IBM Db2, 10.5 e versioni successive.

La tabella seguente riporta l'ultima versione supportata e la politica di assistenza:

Per ulteriori informazioni sulla politica di assistenza, consultare la sezione "Strategia di assistenza per i sensori".

Il sensore non supporta il monitoraggio delle istanze di Db2 con il meccanismo DATA_ENCRYPT di sicurezza dell'autenticazione.

Per questa tecnologia, Instana supporta il tracciamento lato client per i seguenti linguaggi e runtime:

• Java
• Node.js
• PHP
• .NET Framework
• .NET Core

Per utilizzare una porta personalizzata, un database, un utente, una password, un'istanza o una frequenza di polling, è necessario configurare i seguenti campi nel file di configurazione dell'agente <agent_install_dir>/etc/instana/configuration.yaml:

Affinché l'agente di Instana possa connettersi in modo sicuro al tuo server Db2, è necessario configurarlo qui <agent_install_dir>/etc/instana/configuration.yaml:

Instana supporta il monitoraggio locale per IBM Db2 all'indirizzo Red Hat OpenShift Container Platform. Le istanze del database di tipo « IBM Db2 » nell'ambiente container vengono create come « StatefulSets ». Viene eseguito il rendering dallo stesso template pod utilizzando le risorse personalizzate (CR). Di seguito è riportata una configurazione di esempio per IBM Db2 :

com.instana.plugin.db2:
  local:
    - host: 'c-db2ucluster-sample-one-db2u.openshift-operators.svc'
      instance: 'db2inst1'
      port: '50000'
      environment: 'OCP'
      tabschema: 'SYSTOOLS'
      user: 'db2inst1'
      password: 'db2inst1'
      availabilityZone: 'DB2 Monitoring'
      poll_rate: 5 # seconds
      databases:
        - 'BLUDB'
    - host: 'c-db2ucluster-sample-two-db2u.openshift-operators.svc'
      instance: 'db2inst1'
      port: '50000'
      environment: 'OCP'
      tabschema: 'SYSTOOLS'
      user: 'db2inst1'
      password: 'db2inst1'
      availabilityZone: 'DB2 Monitoring'
      poll_rate: 5 # seconds
      databases: # multiple databases are supported
        - 'database1'
        - 'database2'
 

Se nello stesso nodo di lavoro sono presenti più istanze di ` IBM Db2 `, è possibile aggiungerle tutte nello stesso file di configurazione.

L'host URL dei servizi IBM Db2 è costituito dalla combinazione del nome del servizio e dello spazio dei nomi nel cluster OpenShift Container Platform in cui vengono create le istanze del database. Il file « URL » ha solitamente il formato *serviceName*.*namespace*.svc. Ad esempio, se c-db2ucluster-sample-one è il nome del servizio e openshift-operators è lo spazio dei nomi, l' URL e dell'host è c-db2ucluster-sample-one-db2u.openshift-operators.svc.

Se ricrei un pod, utilizza lo stesso nome del servizio per conservare la cronologia del database in Instana.

Il timeout di accesso definisce il tempo di attesa massimo, in secondi, del sensore per la connessione al database. È possibile impostare un timeout di accesso nel sensore Instana Db2 utilizzando la loginTimeout proprietà nel configuration.yaml file. Se la connessione non viene ottenuta entro l'intervallo loginTimeout specificato, viene visualizzato un errore di connessione. Il valore predefinito per questa proprietà è 5 secondi. La proprietà è facoltativa ed è applicabile sia per le configurazioni locali che remote. Il seguente esempio mostra come personalizzare la proprietàloginTimeout :

      port: '50000'
      tabschema: 'SYSTOOLS'
      user: 'db2inst1'
      password: 'db2inst1'
      poll_rate: 5 # seconds
      loginTimeout: 20 #value in seconds
 

È possibile personalizzare l'intervallo di tempo per ottenere un conteggio delle attese di blocco e delle query di lunga durata nel sensore Instana Db2 utilizzando la lockAndLongQueryInterval proprietà nel configuration.yaml file. Per impostazione predefinita, il tempo impiegato dal sensore per classificare una query o un blocco come di lunga esecuzione è di 100 secondi. Questa metrica può essere utilizzata per le configurazioni di avvisi o eventi. La proprietà lockAndLongQueryInterval è facoltativa ed è applicabile sia per le configurazioni locali che remote. Il seguente esempio mostra come personalizzare questa proprietà:

      port: '50000'
      tabschema: 'SYSTOOLS'
      user: 'db2inst1'
      password: 'db2inst1'
      poll_rate: 5 # seconds
      lockAndLongQueryInterval: 60 # value in seconds
 

Ora è possibile personalizzare l'intervallo di tempo per la raccolta delle metriche runstats e reorg. Per personalizzare l'intervallo di tempo, utilizzare la proprietà customRunStatsPollRate nel file configuration.yaml . Per impostazione predefinita, le metriche vengono raccolte ogni 180 minuti. La proprietà customRunStatsPollRate è facoltativa ed è applicabile sia per le configurazioni locali che remote. Il seguente esempio mostra come personalizzare questa proprietà:

      port: '50000'
      tabschema: 'SYSTOOLS'
      user: 'db2inst1'
      password: 'db2inst1'
      poll_rate: 5 # seconds
      customRunStatsPollRate: 30 # value in minutes
 

È ora possibile personalizzare il numero di righe visualizzate per le dimensioni della tabella per schema. Per personalizzare il numero di righe, utilizzare la proprietà tableSizeRowsLimit nel file configuration.yaml . Per impostazione predefinita, vengono visualizzate soltanto le prime 50 tabelle per dimensione per schema. La proprietà tableSizeRowsLimit è facoltativa ed è applicabile sia per le configurazioni locali che remote. Il seguente esempio mostra come personalizzare questa proprietà:

      port: '50000'
      tabschema: 'SYSTOOLS'
      user: 'db2inst1'
      password: 'db2inst1'
      poll_rate: 5 # seconds
      tableSizeRowsLimit: 100 # number of rows to fetch
 

JSON I Web Token (JWT) sono un meccanismo di autenticazione supportato da Db2 ed è ora supportato dai sensori Db2 a partire dalla versione 1.0.27. Per consentire all'agente Instana di supportare la connessione JWT al tuo server Db2, devi configurare il <agent_install_dir>/etc/instana/configuration.yaml file come segue:

Il monitoraggio di più istanze è supportato sia per il monitoraggio locale che remoto. Di seguito è riportato un esempio di come è possibile configurarlo all'interno del file configuration.yaml :

È possibile monitorare l'istanza Db2 pureScale sia localmente che in remoto. I seguenti esempi mostrano come configurare il controllo locale e remoto per un'istanza Db2 pureScale nel file configuration.yaml :

È necessario assegnare le seguenti autorizzazioni all'account utente Db2 utilizzato da Instana :

GRANT DBADM ON DATABASE TO USER db2inst1;

oppure

GRANT DATAACCESS ON DATABASE TO USER db2inst1;
GRANT SQLADM ON DATABASE TO USER db2inst1;
 

o EXECUTE sulle seguenti funzioni / viste o procedure della tabella:

GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_CONTAINER TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_TRANSACTION_LOG TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_DATABASE TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_TABLESPACE TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_PKG_CACHE_STMT TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_AGENT TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_HADR TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_CONNECTION TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_UTILITY TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_WORKLOAD TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_UNIT_OF_WORK TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.MON_GET_INSTANCE TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.PD_GET_DIAG_HIST TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.PD_GET_LOG_MSGS TO USER db2inst1;
GRANT SELECT ON SYSIBMADM.MON_TRANSACTION_LOG_UTILIZATION TO USER db2inst1;
GRANT SELECT ON TABLE SYSCAT.INDEXES TO USER db2inst1;
GRANT SELECT ON TABLE SYSCAT.TABLES TO USER db2inst1;
GRANT SELECT ON TABLE SYSIBMADM.MON_CURRENT_SQL TO USER db2inst1;
GRANT SELECT ON TABLE SYSIBMADM.DB_HISTORY TO USER db2inst1;
GRANT SELECT ON TABLE SYSIBMADM.DBCFG TO USER db2inst1;
GRANT SELECT ON TABLE SYSIBMADM.MON_CONNECTION_SUMMARY TO USER db2inst1;
GRANT SELECT ON TABLE SYSIBMADM.MON_DB_SUMMARY TO USER db2inst1;
GRANT SELECT ON TABLE SYSIBMADM.MON_LOCKWAITS TO USER db2inst1;
GRANT SELECT ON TABLE SYSIBMADM.SNAP_REORG TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.DB_GET_CFG() TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.DBM_GET_CFG TO USER db2inst1;
GRANT EXECUTE ON FUNCTION SYSPROC.ENV_GET_INST_INFO TO USER db2inst1;

SYSIBMADM.SNAP_REORG

GRANT SELECT ON TABLE SYSIBMADM.SNAPTAB_REORG TO USER db2inst1;

Esempio:

db2 connect to db
 

db2 "grant dataaccess, sqladm on database to user db2inst1"
 

db2 "grant execute on FUNCTION SYSPROC.MON_GET_DATABASE to USER db2inst1"
 

Note:

• È stata abilitata una configurazione di polling per un sensore LUW dell' IBM Db2. Con questa funzione, è possibile impostare una configurazione personalizzata per il recupero delle statistiche a intervalli richiesti e disabilitare anche le statistiche irrilevanti.
• Se si utilizza la configurazione di polling personalizzata, questa impostazione ha la priorità rispetto alle impostazioni di sistema predefinite.
• La personalizzazione del polling è abilitata solo per le statistiche descritte nella tabella nella sezione Statistiche configurabili . Le statistiche per le quali la personalizzazione del polling non è abilitata vengono raccolte meno frequentemente e sono vitali per il sistema. Per ulteriori informazioni sulle statistiche raccolte e sull'intervallo di polling predefinito, consultare la sezione Statistiche configurabili .
• Non è possibile impostare la configurazione dell'intervallo su un valore inferiore a quello predefinito. Se si effettua una configurazione non corretta, questa voce viene spostata nel successivo bucket di configurazione con frequenza di polling più elevata disponibile.
• Se si omettono le statistiche dagli elementi configurabili (le statistiche non vengono aggiunte a nessuno dei bucket poll_intervals o disabled_metrics ), vengono automaticamente aggiunte al successivo bucket superiore disponibile. Tuttavia, se non esiste alcun bucket di questo tipo, viene spostato nell'elenco di metriche disabilitate.
• Gli intervalli di polling possono essere personalizzati per il monitoraggio locale e remoto. Impostare tutti gli intervalli di polling in secondi.
• I nomi di statistiche e bucket (disabled_metrics, poll_rate_1, poll_rate_2, poll_rate_3e poll_rate_4) sono fissi. È necessario denominarli come mostrato nella tabella nella sezione Statistiche di configurazione o come nella seguente configurazione di esempio.

Per personalizzare il polling per il monitoraggio locale e remoto, configurare come segue:

      poll_rate: 5 # seconds
      custom_polling:
        disabled_metrics:
          metrics: DBM_CONFIG_STATS, AGENT_STATS #Stats that you don't want to be monitored
        poll_rate_1:
          poll_interval: 30
          metrics: TOP_QUERIES_STATS, TABLE_SPACE_STATS
        poll_rate_2:
          poll_interval: 200
          metrics: ELAPSED_TIME_STATS, WORKLOAD_STATS, TOP_TOTAL_STMT_IDS_STATS
        poll_rate_3:
          poll_interval: 900
          metrics: LOG_DISK_WAIT_STATS, DB_CONFIG_STATS, UNIT_OF_WORK_STATS
        poll_rate_4:
          poll_interval: 2000
          metrics: HADR_STATS, VMON_LOCK_STATS
      databases:
        - 'database1'
 

È possibile raccogliere metriche personalizzate che vanno oltre quelle standard utilizzando le funzioni di tabell DB2. Specificare le funzioni delle tabelle e le metriche che si desidera raccogliere; il sensore genererà automaticamente le query SQL appropriate in base alla configurazione e esporterà tutte le metriche nel formato Prometheus.

È possibile impostare la configurazione delle metriche personalizzate per il monitoraggio locale e remoto di IBM Db2 nel file di configurazione <agent_install_dir>/etc/instana/configuration.yaml dell'agente come segue:

• ID processo
• Porta
• Versione
• Ora di inizio / Ora di attività