pmlogrewrite - Online nel cloud

PROGRAMMA:

NOME

pmlogrewrite - riscrivere gli archivi Performance Co-Pilot

SINOSSI

$PCP_BINADM_DIR/pmlogriscrivi [-Cdiqsvw ] [-c config] inlog [uscita]

DESCRIZIONE

pmlogrewrite legge un registro di archivio Performance Co-Pilot (PCP) identificato da inlog e
crea un accesso all'archivio PCP uscita. In condizioni di utilizzo normale, il -c l'opzione verrà utilizzata per
nominare uno o più file di configurazione che contengano le specifiche (vedi il RISCRITTURA
REGOLAMENTO SINTASSI sezione sottostante) che descrivono come i dati e i metadati da inlog dovrebbe essere
trasformato per produrre uscita.

Gli usi tipici per pmlogrewrite sarebbe quello di accogliere l'evoluzione delle prestazioni
Metric Domain Agents (PMDA) in cui i nomi, i metadati e la semantica delle metriche e la loro
i domini di istanza associati possono cambiare nel tempo, ad esempio promuovendo il tipo di una metrica da
un numero intero da 32 bit a 64 bit o la ridenominazione di un gruppo di metriche. Fare riferimento al ESEMPI
sezione per alcuni casi d'uso aggiuntivi.

pmlogrewrite è più utile dove PMDA cambia, o errori nell'ambiente di produzione,
si traducono in archivi che non possono essere combinati con pmlogextract(1). Pre-elaborando il
archivi con pmlogrewrite gli archivi risultanti possono essere uniti con
pmlogextract(1).

L'input inlog deve essere un registro di archivio PCP creato da pmlogger(1), o forse uno dei
strumenti che leggono e creano archivi PCP, ad es pmlogextract(1) e pmlogreduce(1).

Se no -c l'opzione è specificata, quindi viene semplicemente creato il comportamento predefinito uscita come una copia di
inlog. Questo è un po' più complicato di gatto(1), poiché ogni archivio PCP è composto da
diversi file fisici.

Mentre pmlogrewrite può essere utilizzato per riparare alcuni problemi di consistenza dei dati negli archivi PCP,
esiste anche una classe di attività di riparazione che non possono essere gestite da pmlogrewrite e
pmlogbel(1) può essere uno strumento utile in questi casi.

COMANDO LINE VERSIONI

Le opzioni della riga di comando per pmlogrewrite sono come segue:

-C Analizza le regole di riscrittura ed esci. uscita non è creato. quando -C è specificato,
anche questo imposta -v e -w in modo che tutti gli avvisi e i messaggi dettagliati vengano visualizzati come
config viene analizzato.

-c config
If config è un file o un collegamento simbolico, leggi e analizza le regole di riscrittura da lì.
If config è una directory, quindi tutti i file o collegamenti simbolici in quella directory
(esclusi quelli che iniziano con un punto ``.'') verranno utilizzati per fornire il
riscrittura delle regole. multiplo -c opzioni sono consentite.

-d Modalità disperata. Normalmente se si verifica un errore fatale, tutte le tracce del parziale
archivio PCP scritto uscita è rimosso. Con il -d opzione, il parzialmente creato
uscita il registro di archivio non viene rimosso.

-i Piuttosto che creare uscita, inlog viene riscritto al suo posto quando il -i opzione è
Usato. Viene creato un nuovo archivio utilizzando nomi di file temporanei e quindi rinominato in
inlog in modo tale che se si riscontrano errori (non avvisi), inlog
rimane inalterato.

-q Modalità rapida, dove se non ci sono azioni di riscrittura da eseguire (nessuna delle
dati globali, domini di istanza o metriche da inlog sarà cambiato), allora
pmlogrewrite uscirà (con stato 0, quindi successo) immediatamente dopo aver analizzato il
file di configurazione e uscita non è creato.

-s Quando le ``unità'' di una metrica vengono modificate, se la dimensione in termini di spazio,
tempo e conteggio non vengono modificati, quindi il fattore di scala viene modificato, ad es. BYTE in
KBYTE, o da MSEC-1 a USEC-1, o il composito MBYTE.SEC-1 a KBYTE.USEC-1. Il
la motivazione può essere (a) che i metadati originali erano sbagliati ma i valori in inlog
sono corretti o (b) i metadati stanno cambiando, quindi anche i valori devono cambiare.
Il predefinito pmlogrewrite comportamento corrisponde al caso (a). Se si applica il caso (b), utilizzare
, il -s opzione e i valori di tutte le metriche con una variazione del fattore di scala in ciascuna
il risultato verrà ridimensionato. Per un controllo più preciso sul ridimensionamento del valore, fare riferimento al
RISCALA opzione per il UNITA ' clausola della regola di riscrittura metrica descritta di seguito.

-v Aumenta la verbosità dell'output diagnostico.

-w Emetti avvisi. Normalmente pmlogrewrite tace per qualsiasi avviso che non lo sia
fatale e si prevede che per un particolare archivio, alcuni (o addirittura tutti) di
le specifiche di riscrittura potrebbero non essere applicabili. Ad esempio, le modifiche a un PMDA possono essere
catturato in una serie di regole di riscrittura, ma un singolo archivio potrebbe non contenere tutto
le metriche modificate né tutti i domini e/o istanze modificati.
Poiché questi casi sono previsti, non impediscono pmlogrewrite esecuzione, e
regole che non si applicano a inlog vengono ignorati in silenzio per impostazione predefinita. Allo stesso modo, alcuni
le regole di riscrittura potrebbero non comportare alcun cambiamento perché i metadati in inlog già corrisponde
l'intento della regola di riscrittura per correggere i dati da una versione precedente di un PMDA.
Il -w flag impone l'emissione di avvisi per tutti questi casi.

L'argomento uscita è richiesto in tutti i casi, tranne quando -i è specificato.

RISCRITTURA REGOLAMENTO SINTASSI

Un file di configurazione contiene zero o più regole di riscrittura come definito di seguito.

Le parole chiave e i caratteri di punteggiatura speciali sono mostrati di seguito in Italico grassetto carattere e sono
insensibile alle maiuscole, quindi METRIC, metrico e Metrico sono tutti equivalenti nelle regole di riscrittura.

Il carattere ``#'' introduce un commento e il resto della riga viene ignorato.
Altrimenti l'input è in un formato relativamente libero con spazi bianchi opzionali (spazi, tab o
newline) tra gli elementi lessicali nelle regole.

A globale la regola di riscrittura ha la forma:

GLOBAL { specifica globale ... }

where specifica globale è zero o più delle seguenti clausole:

HOSTNAME -> hostname

Modifica i record dell'etichetta nel uscita Archivio PCP, in modo che le metriche saranno
sembrano essere stati raccolti dall'host hostname.

ORARIO -> delta

Sia i valori delle metriche che i metadati del dominio dell'istanza in un archivio PCP trasportano
timestamp. Questa clausola impone la modifica di tutti i timestamp da delta, Dove
delta è un segno opzionale ``+'' (predefinito) o ``-'', un numero opzionale di
ore seguite da due punti ``:'', un numero facoltativo di minuti seguito da due punti
``:'', un numero di secondi, una frazione opzionale di secondi dopo un punto
``.''. L'esempio più semplice sarebbe ``30'' per aumentare i timestamp di 30
secondi. Un esempio più complesso sarebbe ``-23:59:59.999'' per spostare i timestamp
indietro di un millisecondo in meno di un giorno.

TZ -> "fuso orario"

Modifica i record dell'etichetta nel uscita Archivio PCP, in modo che le metriche saranno
sembrano essere stati raccolti da un host con un fuso orario locale di fuso orario.
fuso orario deve essere racchiuso tra virgolette e deve essere conforme al fuso orario valido
regole di sintassi per la piattaforma locale.

An indom la regola di riscrittura modifica un dominio di istanza e ha la forma:

INDOM dominio.serial { indomspec ... }

where dominio e serial identificare uno o più domini di istanza esistenti da inlog -
tipicamente dominio sarebbe un numero intero compreso tra 1 e 510 e serial sarebbe un intero
nell'intervallo da 0 a 4194304.

Come un caso speciale serial potrebbe essere un asterisco ``*'' che significa che la regola si applica a tutti
dominio di istanza con un numero di dominio di dominio.

Se un dominio di istanza designato non è in inlog la norma non ha effetto.

Il indomspec è zero o più delle seguenti clausole:

NOMINO "vecchio nome" -> "nuovo nome"

L'istanza identificata dal nome dell'istanza esterna vecchio nome viene rinominato in
nuovo nome. Entrambi vecchio nome e nuovo nome deve essere racchiuso tra virgolette.

Come caso speciale, il nuovo nome potrebbe essere la parola chiave DELETE (senza virgolette), e
poi l'istanza vecchio nome sarà cancellato da uscita che lo rimuove dal
metadati del dominio dell'istanza e rimuove tutti i valori di questa istanza per tutti i
metriche associate.

Se i nomi delle istanze contengono spazi incorporati, è necessario prestare particolare attenzione
preso in relazione alla regola di denominazione dell'istanza PCP che tratta il non-spazio principale
parte del nome dell'istanza come parte univoca del nome ai fini di
corrispondenza e garanzia di unicità all'interno di un dominio di istanza, fare riferimento a
pmdaInstance(3) per una discussione su questo problema.

A titolo illustrativo, si consideri l'ipotetico dominio di istanza per una metrica che
contiene 2 istanze con i seguenti nomi:
rosso
eek urk

Allora qualche possibile NOMINO le clausole potrebbero essere:

"eek" -> "giallo come un fiore"
Accettabile, vecchio nome "eek" corrisponde all'istanza "eek urk".

"rosso" -> "eek"
errore, nuovo nome "eek" corrisponde all'istanza "eek urk" esistente.

"eek urk" -> "rosso di un'altra tonalità"
errore, nuovo nome "rosso di un'altra tonalità" corrisponde all'istanza "rosso" esistente.

INDOM -> nuovodominio.notiziario

Modifica i metadati per il dominio dell'istanza e ogni metrica associata al
dominio di istanza. Come caso speciale, notiziario potrebbe essere un asterisco ``*'' che
significa usare serial dal indom regola di riscrittura, anche se questo è più utile quando
serial è anche un asterisco. Quindi ad esempio:
indom 29.* { indom -> 109.* }
sposterà tutti i domini dell'istanza dal dominio 29 al dominio 109.

INDOM -> DUPLICARE nuovodominio.notiziario

Un caso speciale del precedente INDOM clausola in cui il dominio di istanza è a
duplicato del dominio.serial dominio di istanza dal indom regola di riscrittura,
e quindi tutte le regole di mappatura vengono applicate al copiato nuovodominio.notiziario esempio
dominio. Ciò è utile quando un PMDA è suddiviso e lo stesso dominio dell'istanza deve
essere replicato per dominio dominio e dominio nuovodominio. Quindi, ad esempio, se il
metrica foo.uno e pippo.due sono entrambi definiti sul dominio di istanza 12.34 e
pippo.due viene spostato su un altro PMDA utilizzando il dominio 27, quindi la seguente riscrittura
regole potrebbero essere utilizzate:
indom 12.34 { indom -> duplicato 27.34 }
metrica foo.two { indom -> 27.34 pmid -> 27.*.* }

INST vecchio -> nuovo ID

L'istanza identificata dall'identificatore interno dell'istanza vecchio è rinumerato in
nuovo ID. Entrambi vecchio e nuovo ID sono numeri interi nell'intervallo da 0 a 231-1.

Come caso speciale, nuovo ID potrebbe essere la parola chiave DELETE e poi l'istanza vecchio
sarà cancellato da uscita che lo rimuove dai metadati del dominio dell'istanza
e rimuove tutti i valori di questa istanza per tutte le metriche associate.

A metrico la regola di riscrittura ha la forma:

METRIC metrico { specifica metrica ... }

where metrico identifica una o più metriche esistenti da inlog utilizzando una metrica
nome o la codifica interna per il PMID di una metrica come dominio.gruppo.articolo. In quest'ultimo
caso, tipicamente dominio sarebbe un numero intero compreso tra 1 e 510, gruppo sarebbe un
intero compreso tra 0 e 4095, e articolo sarebbe un numero intero compreso tra 0 e 1023.

Come casi speciali articolo potrebbe essere un asterisco ``*'' che significa che la regola si applica a tutti
metrica con un numero di dominio di dominio e un numero di cluster di gruppo, o gruppo potrebbe essere
un asterisco che significa che la regola si applica a ogni metrica con un numero di dominio di dominio
e un numero di articolo di articolo, o entrambi gruppo e articolo potrebbero essere asterischi e si applica la regola
a ogni metrica con un numero di dominio di dominio.

Se una metrica designata non è in inlog la norma non ha effetto.

Il specifica metrica è zero o più delle seguenti clausole:

DELETE

La metrica è completamente rimossa da uscita, sia i metadati che tutti i valori in
i risultati vengono cancellati.

INDOM -> nuovodominio.notiziario [ scegliere ]

Modifica i metadati per cambiare il dominio dell'istanza per questa metrica. Il nuovo
il dominio dell'istanza deve esistere in uscita.

Facoltativo scegliere clausola può essere utilizzata per selezionare un valore di input, o calcolare un
aggregare il valore dalle istanze in un risultato di input o assegnare un valore interno
identificatore di istanza a un singolo valore di output. se no scegliere clausola è specificata, il
il comportamento predefinito è copiare tutti i valori di input da ciascun risultato di input in un output
risultato, tuttavia se il dominio dell'istanza di input è singolare (indom PM_INDOM_NULL)
quindi a un valore di output deve essere assegnato un identificatore di istanza interno, che
è 0 per impostazione predefinita, a meno che non venga sovrascritto da a INST or NOMINO clausola come di seguito definita.

Le scelte per scegliere sono come segue:

USCITA PRIMO
scegli il valore della prima istanza da ogni risultato di input

USCITA ULTIMO scegli il valore dell'ultima istanza da ogni risultato di input

USCITA INST instillare
scegli il valore dell'istanza con identificatore di istanza interno
instillare da ogni risultato; la sequenza delle regole di riscrittura assicura la
USCITA l'elaborazione avviene prima della rinumerazione dell'identificatore dell'istanza da
qualsiasi associato indom regola, quindi instillare dovrebbe essere uno degli interni
identificatori di istanza che appaiono in inlog

USCITA NOMINO "Nome"
scegli il valore dell'istanza con Nome per la sua istanza esterna
nome da ogni risultato; la sequenza delle regole di riscrittura assicura la
USCITA l'elaborazione avviene prima della ridenominazione dell'istanza da qualsiasi associata
indom regola, quindi Nome dovrebbe essere uno dei nomi di istanze esterne che
appare in inlog

USCITA MIN scegli il valore più piccolo in ogni risultato (il tipo di metrica deve essere numerico
e l'istanza di output sarà 0 per un dominio di istanza non singolare)

USCITA MAX scegli il valore più alto in ogni risultato (il tipo di metrica deve essere numerico
e l'istanza di output sarà 0 per un dominio di istanza non singolare)

USCITA SUM scegli la somma di tutti i valori in ogni risultato (il tipo di metrica deve essere
l'istanza numerica e di output sarà 0 per un'istanza non singolare
dominio)

USCITA AVG scegli la media di tutti i valori in ogni risultato (il tipo di metrica deve essere
l'istanza numerica e di output sarà 0 per un'istanza non singolare
dominio)

Se il dominio dell'istanza di input è singolare (indom PM_INDOM_NULL) quindi indipendente da
in qualsiasi scegliere specifiche, c'è al massimo un valore in ogni risultato di input e quindi
PRIMO, ULTIMO, MIN, MAX, SUM e AVG sono tutti equivalenti e l'istanza di output
identificatore sarà 0.

In generale è un errore specificare un'azione di riscrittura per gli stessi metadati o
valori dei risultati più di una volta, ad es. più di uno INDOM clausola per lo stesso
dominio di istanza. L'unica eccezione è la possibile interazione tra i INDOM
clausole in indom e metrico regole. Ad esempio la metrica campione.bin is
definito sul dominio di istanza 29.2 in inlog e quanto segue è accettabile
(anche se ridondante):
indom 29.* { indom -> 109.* }
metrico sample.bin { indom -> 109.2 }
Tuttavia quanto segue è un errore, perché il dominio dell'istanza per campione.bin ha
due definizioni contrastanti:
indom 29.* { indom -> 109.* }
metrico sample.bin { indom -> 123.2 }

INDOM -> NULL[ scegliere ]

La metrica (che deve essere stata definita in precedenza su un dominio di istanza) è
essere modificato per essere una metrica singolare. Ciò comporta una modifica dei metadati e
comprimendo tutti i risultati per questa metrica in modo che più valori diventino un valore.

Facoltativo scegliere parte della clausola definisce come un valore per ogni risultato
dovrebbe essere calcolato e segue le stesse regole descritte per il non-NULL
INDOM caso sopra.

In assenza di scegliere, l'impostazione predefinita è USCITA PRIMO.

NOME -> nuovo nome

Rinomina la metrica nei metadati dell'archivio PCP che supporta le prestazioni
Spazio dei nomi delle metriche (PMNS). nuovo nome non deve corrispondere a nessun nome esistente nel
PMNS dell'archivio e deve seguire le regole sintattiche per i nomi di metrica validi come
delineato in pmns(5).

PMID -> nuovodominio.nuovo cluster.nuovo oggetto

Modifica i metadati e i risultati per rinumerare il PMID della metrica. come speciale
casi, nuovo cluster potrebbe essere un asterisco ``*'' che significa usare gruppo dal
metrico regola di riscrittura e/o articolo potrebbe essere un asterisco che significa uso articolo da
, il metrico regola di riscrittura. Questo è molto utile quando gruppo e / o articolo è altresì
un asterisco. Quindi ad esempio:
metrica 30.*.* { pmid -> 123.*.* }
sposterà tutte le metriche dal dominio 30 al dominio 123.

SEM -> notizie

Modificare la semantica della metrica. notizie dovrebbe essere la parte XXX del nome di
Uno dei PM_SEM_XXX macro definite in o pmCercaDesc(3), ad es
CONTATORE per PM_TYPE_COUNTER.

Non viene eseguita alcuna riscrittura del valore dei dati a seguito del SEM clausola, quindi il
l'utilità è limitata ai casi in cui una versione del PMDA associato era
esportazione della semantica errata per la metrica. pmlogreduce(1) può fornire un
alternativa nei casi in cui si desidera ricalcolare i valori dei risultati.

TIPO -> nuovo tipo

Modificare il tipo di metrica che altera i metadati e può modificare il
codifica dei valori nei risultati. nuovo tipo dovrebbe essere la parte XXX del nome di uno
di PM_TYPE_XXX macro definite in o pmCercaDesc(3), ad es FLOAT
per PM_TYPE_FLOAT.

La conversione del tipo è supportata solo nei casi in cui il tipo di metrica vecchio e nuovo è
numerico, quindi PM_TYPE_STRING, PM_TYPE_AGGREGATE e PM_TYPE_EVENT non sono consentiti.
Anche per i casi numerici, alcune conversioni possono produrre errori di runtime, ad es
integer overflow o tentativo di riscrivere un valore negativo in un tipo senza segno.

UNITA ' -> nuoveunità [ RISCALA ]

nuoveunità è sei valori separati da virgole. I primi 3 valori descrivono il
dimensione della metrica lungo le dimensioni di spazio, tempo e conteggio; questi sono
valori interi, generalmente 0, 1 o -1. I restanti 3 valori descrivono la scala di
i valori della metrica nelle dimensioni di spazio, tempo e conteggio. Scala spaziale
i valori dovrebbero essere 0 (se la dimensione dello spazio è 0), altrimenti la parte XXX del nome di
Uno dei PM_SPACE_XXX macro, ad es KBYTE per PM_TYPE_KBYTE. Valori della scala temporale
dovrebbe essere 0 (se la dimensione temporale è 0), altrimenti la parte XXX del nome di uno di
, il PM_TIME_XXX macro, ad es SEC per PM_TIME_SEC. I valori della scala di conteggio devono essere 0
(se la dimensione temporale è 0), altrimenti ONE per PM_COUNT_ONE.

Il PM_SPACE_XXX, PM_TIME_XXX e PM_COUNT_XXX le macro sono definite in
or pmCercaDesc(3).

Quando la scala viene modificata (ma la dimensione non viene modificata) la parola chiave opzionale
RISCALA può essere utilizzato per scegliere il ridimensionamento del valore secondo il -s opzione della riga di comando,
ma applicato solo a questa metrica.

Quando si modifica il numero di dominio per una metrica o un dominio di istanza, il nuovo numero di dominio
di solito corrisponde al numero di dominio di un PMDA esistente. Se questo non è il caso, allora
il nuovo numero di dominio non deve essere scelto a caso; consultare $PCP_VAR_DIR/pmns/stdpmid
per i numeri di dominio già assegnati ai PMDA.

ESEMPI

Per promuovere i valori delle metriche IOPS per disco a 64 bit per consentire l'aggregazione su a
lungo periodo di tempo per la pianificazione della capacità o perché il PMDA è cambiato per esportare a 64 bit
contatori e vogliamo convertire i vecchi archivi in ​​modo che possano essere elaborati insieme ai nuovi
archivi.
metrica disk.dev.read { type -> U64 }
metrica disk.dev.write { tipo -> U64 }
metrica disk.dev.total { tipo -> U64 }

Le istanze associate alla metrica del carico medio kernel.all.load potrebbe essere rinominato e
rinumerato dalle regole seguenti.
# per Linux PMDA, è definita la metrica kernel.all.load
# sul dominio di istanza 60.2
interno 60.2 {
inst 1 -> 60 iname "1 minuto" -> "60 secondi"
inst 5 -> 300 iname "5 minuto" -> "300 secondi"
inst 15 -> 900 iname "15 minuto" -> "900 secondi"
}

Se decidiamo di dividere le metriche ``proc'' dal PMDA di Linux, ciò comporterà
modifica del numero di dominio per il PMID di queste metriche e dell'istanza associata
domini. Le regole seguenti riscriverebbero un vecchio archivio in modo che corrisponda alle modifiche dopo il PMDA
Diviso.
# tutte le metriche proc di Linux sono in 7 cluster
metrica 60.8.* { pmid -> 123.*.* }
metrica 60.9.* { pmid -> 123.*.* }
metrica 60.13.* { pmid -> 123.*.* }
metrica 60.24.* { pmid -> 123.*.* }
metrica 60.31.* { pmid -> 123.*.* }
metrica 60.32.* { pmid -> 123.*.* }
metrica 60.51.* { pmid -> 123.*.* }
# solo un dominio di istanza per le metriche di processo di Linux
indom 60.9 { indom -> 123.0 }

Usa pmlogrewrite online utilizzando i servizi onworks.net