Memorizzazione e persistenza delle metriche
DataStage® registra varie informazioni sulle esecuzioni dei lavori, che possono essere visualizzate per le esecuzioni nelle schermate Dettagli esecuzioni e Metriche esecuzioni. Le metriche possono anche essere archiviate per un periodo più lungo, creando un repository di metriche in un database.
- informazioni sull'esecuzione del lavoro, come il nome e l'ora di avvio/arresto,
- informazioni sugli stadi e sui collegamenti, come le righe lette/scritte per ogni stadio e collegamento,
- altre informazioni, come i valori dei parametri per una corsa.
Con il servizio ds-metrics
, è possibile impostare l'archiviazione delle metriche a livello di progetto per tutti i flussi DataStage flussi. Mentre le metriche sono abilitate di default per i flussi, è necessario abilitare manualmente le metriche persistenti a livello di progetto. Per ulteriori informazioni sulla visualizzazione dell'esecuzione del lavoro e delle metriche, vedere Visualizzazione dei dettagli dell'esecuzione del lavoro e delle metriche dell'esecuzione.
Prerequisito
IBMDataStage supporta l'invio dei DataStage dati di metrica a un database di metrica separato. PostgreSQL è il database designato per l'archiviazione delle metriche e offre una soluzione leggera, non intesa come archivio di dati operativi. Consente agli utenti di eseguire le proprie ricerche per ottenere informazioni sulle prestazioni lavorative. A seconda delle preferenze del cliente, il database PostgreSQL può essere ospitato all'interno dello stesso ambiente, gestito su una macchina virtuale o all'interno di un servizio Cloud Pak for Data ambiente, su una macchina virtuale o gestito all'interno di un servizio PostgreSQL.
Creazione di una connessione
Nella scheda Gestisci del tuo Cloud Pak for Data progetto, vai su DataStage > Metrics Repository e abilita le metriche persistenti. Specificare un tipo di connessione, configurare le proprietà e i dettagli di sicurezza e testare la connessione per verificare che funzioni.
ds-metrics
. Per assicurarsi che un database sia pulito e cancellare eventuali dati di ds-metrics
e precedenti, eseguire i seguenti comandi.drop schema if exists ds_metrics cascade;
drop table if exists public.databasechangelog;
drop table if exists public.databasechangeloglock;
Per utilizzare un database con ds-metrics
, l'utente del database deve avere sia il permesso di creare schemi nel database, sia il permesso di creare tabelle nello schema public
. Per verificare i permessi per la creazione di tabelle e schemi, accedere al database ed eseguire la seguente query come utente che richiede i permessi.select has_database_privilege(current_database(), 'create'), has_schema_privilege('public', 'create');
se si dispone dei permessi create-schema e create-table, la query restituisce true,
true
.Conservazione metriche
Il campo di conservazione Metrics controlla la frequenza, se presente, con cui l' ds-metrics
e rimuove i vecchi dati dal database. Se si abilita l'opzione Limite massimo, è possibile scegliere tra le impostazioni Giorni o Corse. Ad esempio, se si impostano 30 giorni, metriche cancella tutte le informazioni relative al lavoro e a tutte le sue esecuzioni quando un lavoro ha più di 30 giorni. Se si impostano 100 corse, metriche mantiene le 100 corse più recenti ed elimina quelle più vecchie. Il campo di conservazione Metriche si applica solo ai dati metrici relativi al progetto in cui sono attivate le impostazioni. Se il database è condiviso con un altro progetto, le impostazioni di conservazione non influiscono sui dati di quel progetto.
Dopo aver salvato le impostazioni di connessione, si attiva ds-metrics
per cancellare la cache della connessione. Quando si esegue un lavoro nel progetto, ds-metrics
si collega al database per la prima volta. Dopo aver stabilito una connessione, popola lo schema di ds-metrics
dopo l'inizializzazione o lo migra se lo schema nel database è una versione precedente.
Struttura del database
Nel database delle metriche, la maggior parte delle tabelle è nello schema " ds-metrics
". public.databasechangelog
e public.databasechangeloglock
sono tabelle interne extra nello schema pubblico che vengono utilizzate per tenere traccia delle versioni dello schema del database.
Schemi tabellari
Per le tabelle, lo schema principale è lo schema di programmazione orientato agli oggetti ( ds_metrics
).
job
- Memorizza le informazioni relative al lavoro quando inizia un ciclo di lavoro.
job_run
- Memorizza le informazioni relative al lavoro in corso mentre è in esecuzione.
job_run_parameter
- Memorizza i parametri per un lavoro in esecuzione quando inizia un lavoro.
job_run_log
- Memorizza le righe non informative di un processo quando questo termina.
job_run_stage_metrics
- Memorizza le metriche per le fasi di un lavoro in corso mentre un lavoro è in esecuzione.
job_run_link_metrics
- Memorizza le metriche per i collegamenti in un processo mentre un processo è in esecuzione.
version
- Memorizza la versione di
ds-metrics
che ha inizializzato l'ultimo database, a meno che il database non sia stato impostato manualmente.
instance
- Memorizza le informazioni sulle istanze di px-runtime.
pod
- Memorizza le informazioni relative al conduttore px-runtime e ai pod di calcolo.
pod_disk
- Memorizza le informazioni sui dischi montati sui pod.
pod_metrics
- Memorizza le metriche della CPU e della memoria nel tempo.
disk_metrics
- Memorizza le metriche delle dimensioni del disco nel tempo.