La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Utilizzare lo strumento audit-sum

11/07/2024 Collaboratori

PDF

È possibile utilizzare audit-sum lo strumento per contare i messaggi di controllo di scrittura, lettura, testa ed eliminazione e per visualizzare il tempo (o le dimensioni) minimo, massimo e medio per ogni tipo di operazione.

Prima di iniziare

Si dispone di "autorizzazioni di accesso specifiche".
È necessario disporre del Passwords.txt file.
È necessario conoscere l'indirizzo IP del nodo di amministrazione primario.

A proposito di questa attività

`audit-sum`Lo strumento, disponibile nel nodo amministrativo principale, riepiloga il numero di operazioni di scrittura, lettura ed eliminazione registrate e il tempo necessario per tali operazioni.

audit-sum`Lo strumento è destinato principalmente all'uso da parte del supporto tecnico durante le operazioni di risoluzione dei problemi. Le query di elaborazione `audit-sum possono consumare una grande quantità di potenza della CPU, che potrebbe avere un impatto sulle operazioni StorageGRID.

Questo esempio mostra l'output tipico audit-sum dello strumento. Questo esempio mostra il tempo impiegato dalle operazioni del protocollo.

  message group           count     min(sec)        max(sec)    average(sec)
  =============           =====     ========        ========    ============
  IDEL                      274
  SDEL                   213371        0.004          20.934           0.352
  SGET                   201906        0.010        1740.290           1.132
  SHEA                    22716        0.005           2.349           0.272
  SPUT                  1771398        0.011        1770.563           0.487

`audit-sum`In un audit log, il tool fornisce conteggi e tempi per i seguenti messaggi di audit S3, Swift e ILM.

I codici di controllo vengono rimossi dal prodotto e dalla documentazione poiché le funzioni sono obsolete. Se si riscontra un codice di controllo non elencato qui, controllare le versioni precedenti di questo argomento per le versioni SG precedenti. Ad esempio, "StorageGRID 11,8 utilizzando la documentazione dello strumento di checksum".

Codice	Descrizione	Fare riferimento a.
IDEL	ILM Initiated Delete (eliminazione avviata da ILM): Registra quando ILM avvia il processo di eliminazione di un oggetto.	"IDEL: Eliminazione avviata da ILM"
SDEL	S3 DELETE (ELIMINA S3): Registra una transazione riuscita per eliminare un oggetto o un bucket.	"SDEL: ELIMINAZIONE S3"
SGET	S3 GET: Registra una transazione riuscita per recuperare un oggetto o elencare gli oggetti in un bucket.	"SGET: S3 GET"
SHEA	S3 HEAD: Registra una transazione riuscita per verificare l'esistenza di un oggetto o di un bucket.	"SHEA: TESTA S3"
SPUT	S3 PUT: Registra una transazione riuscita per creare un nuovo oggetto o bucket.	"SPUT: S3 PUT"
WDEL	Eliminazione rapida: Registra una transazione riuscita per eliminare un oggetto o un container.	"WDEL: ELIMINAZIONE rapida"
WGET	Swift GET: Registra una transazione riuscita per recuperare un oggetto o elencare gli oggetti in un container.	"WGET: Swift GET"
WHEA	Swift HEAD: Registra una transazione riuscita per verificare l'esistenza di un oggetto o di un container.	"WHEA: TESTA veloce"
WPUT	Swift PUT: Registra una transazione riuscita per creare un nuovo oggetto o container.	"WPUT: MESSA rapida"

Codice

Descrizione

Fare riferimento a.

IDEL

ILM Initiated Delete (eliminazione avviata da ILM): Registra quando ILM avvia il processo di eliminazione di un oggetto.

"IDEL: Eliminazione avviata da ILM"

SDEL

S3 DELETE (ELIMINA S3): Registra una transazione riuscita per eliminare un oggetto o un bucket.

"SDEL: ELIMINAZIONE S3"

SGET

S3 GET: Registra una transazione riuscita per recuperare un oggetto o elencare gli oggetti in un bucket.

"SGET: S3 GET"

SHEA

S3 HEAD: Registra una transazione riuscita per verificare l'esistenza di un oggetto o di un bucket.

"SHEA: TESTA S3"

SPUT

S3 PUT: Registra una transazione riuscita per creare un nuovo oggetto o bucket.

"SPUT: S3 PUT"

WDEL

Eliminazione rapida: Registra una transazione riuscita per eliminare un oggetto o un container.

"WDEL: ELIMINAZIONE rapida"

WGET

Swift GET: Registra una transazione riuscita per recuperare un oggetto o elencare gli oggetti in un container.

"WGET: Swift GET"

WHEA

Swift HEAD: Registra una transazione riuscita per verificare l'esistenza di un oggetto o di un container.

"WHEA: TESTA veloce"

WPUT

Swift PUT: Registra una transazione riuscita per creare un nuovo oggetto o container.

"WPUT: MESSA rapida"

Lo audit-sum strumento può effettuare le seguenti operazioni:

Elaborazione di registri di audit semplici o compressi. Ad esempio:

audit-sum audit.log

audit-sum 2019-08-12.txt.gz
Elaborazione simultanea di più file. Ad esempio:

audit-sum audit.log 2019-08-12.txt.gz 2019-08-13.txt.gz

audit-sum /var/local/log/*
Accettare l'input da una pipe, che consente di filtrare e pre-elaborare l'input utilizzando il grep comando o altri mezzi. Ad esempio:

grep WGET audit.log | audit-sum

grep bucket1 audit.log | audit-sum

grep SPUT audit.log | grep bucket1 | audit-sum

Questo strumento non accetta i file compressi come input di tipo pipped. Per elaborare i file compressi, fornire i nomi dei file come argomenti della riga di comando o utilizzare zcat lo strumento per decomprimere prima i file. Ad esempio:

audit-sum audit.log.gz

zcat audit.log.gz | audit-sum

È possibile utilizzare le opzioni della riga di comando per riepilogare le operazioni sui bucket separatamente dalle operazioni sugli oggetti o per raggruppare i riepiloghi dei messaggi in base al nome del bucket, al periodo di tempo o al tipo di destinazione. Per impostazione predefinita, i riepiloghi mostrano il tempo di funzionamento minimo, massimo e medio, ma è possibile utilizzare l' `size (-s)`opzione per esaminare le dimensioni dell'oggetto.

Utilizzare l' `help (-h)`opzione per visualizzare le opzioni disponibili. Ad esempio:

$ audit-sum -h

Fasi

Accedere al nodo di amministrazione principale:
1. Immettere il seguente comando: ssh admin@primary_Admin_Node_IP
2. Immettere la password elencata nel Passwords.txt file.
3. Immettere il seguente comando per passare alla directory principale: su -
4. Immettere la password elencata nel Passwords.txt file.
  
  Quando si è collegati come root, il prompt cambia da $ a #.

Se si desidera analizzare tutti i messaggi relativi alle operazioni di scrittura, lettura, testa ed eliminazione, attenersi alla seguente procedura:

Immettere il seguente comando, dove /var/local/log/audit.log rappresenta il nome e la posizione del file o dei file che si desidera analizzare:

$ audit-sum /var/local/log/audit.log

Questo esempio mostra l'output tipico audit-sum dello strumento. Questo esempio mostra il tempo impiegato dalle operazioni del protocollo.
```
  message group           count     min(sec)        max(sec)    average(sec)
  =============           =====     ========        ========    ============
  IDEL                      274
  SDEL                   213371        0.004          20.934           0.352
  SGET                   201906        0.010        1740.290           1.132
  SHEA                    22716        0.005           2.349           0.272
  SPUT                  1771398        0.011        1770.563           0.487
```
In questo esempio, le operazioni SGET (S3 GET) sono le più lente in media a 1.13 secondi, ma le operazioni SGET e SPUT (S3 PUT) mostrano tempi lunghi nel caso peggiore di circa 1,770 secondi.
Per visualizzare le operazioni di recupero 10 più lente, utilizzare il comando grep per selezionare solo i messaggi SGET e aggiungere l'opzione di output lungo (-l) per includere i percorsi oggetto:

grep SGET audit.log | audit-sum -l

I risultati includono il tipo (oggetto o bucket) e il percorso, che consentono di eseguire il grep del log di audit per altri messaggi relativi a questi oggetti specifici.

Total:          201906 operations
    Slowest:      1740.290 sec
    Average:         1.132 sec
    Fastest:         0.010 sec
    Slowest operations:
        time(usec)       source ip         type      size(B) path
        ========== =============== ============ ============ ====
        1740289662   10.96.101.125       object   5663711385 backup/r9O1OaQ8JB-1566861764-4519.iso
        1624414429   10.96.101.125       object   5375001556 backup/r9O1OaQ8JB-1566861764-6618.iso
        1533143793   10.96.101.125       object   5183661466 backup/r9O1OaQ8JB-1566861764-4518.iso
             70839   10.96.101.125       object        28338 bucket3/dat.1566861764-6619
             68487   10.96.101.125       object        27890 bucket3/dat.1566861764-6615
             67798   10.96.101.125       object        27671 bucket5/dat.1566861764-6617
             67027   10.96.101.125       object        27230 bucket5/dat.1566861764-4517
             60922   10.96.101.125       object        26118 bucket3/dat.1566861764-4520
             35588   10.96.101.125       object        11311 bucket3/dat.1566861764-6616
             23897   10.96.101.125       object        10692 bucket3/dat.1566861764-4516

+ Da questo esempio di output, è possibile notare che le tre richieste S3 GET più lente erano per oggetti di dimensioni pari a circa 5 GB, che sono molto più grandi degli altri oggetti. Le grandi dimensioni rappresentano i tempi di recupero lenti dei casi peggiori.

Per determinare le dimensioni degli oggetti inseriti e recuperati dalla griglia, utilizzare l'opzione dimensioni (-s):

audit-sum -s audit.log

  message group           count       min(MB)          max(MB)      average(MB)
  =============           =====     ========        ========    ============
  IDEL                      274        0.004        5000.000        1654.502
  SDEL                   213371        0.000          10.504           1.695
  SGET                   201906        0.000        5000.000          14.920
  SHEA                    22716        0.001          10.504           2.967
  SPUT                  1771398        0.000        5000.000           2.495

In questo esempio, la dimensione media degli oggetti per SPUT è inferiore a 2.5 MB, ma la dimensione media per SGET è molto maggiore. Il numero di messaggi SPUT è molto superiore al numero di messaggi SGET, a indicare che la maggior parte degli oggetti non viene mai recuperata.

Se si desidera determinare se i recuperi sono stati lenti ieri:

Immettere il comando nel registro di controllo appropriato e utilizzare l'opzione Group-by-Time (-gt), seguita dal periodo di tempo (ad esempio, 15M, 1H, 10S):

grep SGET audit.log | audit-sum -gt 1H

  message group           count    min(sec)       max(sec)   average(sec)
  =============           =====     ========        ========    ============
  2019-09-05T00            7591        0.010        1481.867           1.254
  2019-09-05T01            4173        0.011        1740.290           1.115
  2019-09-05T02           20142        0.011        1274.961           1.562
  2019-09-05T03           57591        0.010        1383.867           1.254
  2019-09-05T04          124171        0.013        1740.290           1.405
  2019-09-05T05          420182        0.021        1274.511           1.562
  2019-09-05T06         1220371        0.015        6274.961           5.562
  2019-09-05T07          527142        0.011        1974.228           2.002
  2019-09-05T08          384173        0.012        1740.290           1.105
  2019-09-05T09           27591        0.010        1481.867           1.354

Questi risultati mostrano che S3 OTTIENE un incremento del traffico tra le 06:00 e le 07:00. Anche in questi casi, i tempi massimi e medi sono notevolmente più elevati e non sono aumentati gradualmente con l'aumentare del numero. Ciò suggerisce che la capacità è stata superata da qualche parte, ad esempio nella rete o nella capacità della rete di elaborare le richieste.

Per determinare le dimensioni degli oggetti recuperati ogni ora ieri, aggiungere l'opzione size (-s) al comando:

grep SGET audit.log | audit-sum -gt 1H -s

  message group           count       min(B)          max(B)      average(B)
  =============           =====     ========        ========    ============
  2019-09-05T00            7591        0.040        1481.867           1.976
  2019-09-05T01            4173        0.043        1740.290           2.062
  2019-09-05T02           20142        0.083        1274.961           2.303
  2019-09-05T03           57591        0.912        1383.867           1.182
  2019-09-05T04          124171        0.730        1740.290           1.528
  2019-09-05T05          420182        0.875        4274.511           2.398
  2019-09-05T06         1220371        0.691  5663711385.961          51.328
  2019-09-05T07          527142        0.130        1974.228           2.147
  2019-09-05T08          384173        0.625        1740.290           1.878
  2019-09-05T09           27591        0.689        1481.867           1.354

Questi risultati indicano che si sono verificati alcuni recuperi molto grandi quando il traffico di recupero complessivo era al massimo.

Per ulteriori dettagli, utilizzare il "tool di verifica-spiegazione" per rivedere tutte le operazioni SGET durante quell'ora:

grep 2019-09-05T06 audit.log | grep SGET | audit-explain | less

Se si prevede che l'output del comando grep sia costituito da molte righe, aggiungere il less comando per visualizzare il contenuto del file di registro di controllo una pagina (una schermata) alla volta.

Se si desidera determinare se le operazioni SPUT sui bucket sono più lente delle operazioni SPUT per gli oggetti:

Iniziare utilizzando l' `-go`opzione, che raggruppa i messaggi per le operazioni di oggetti e bucket separatamente:

grep SPUT sample.log | audit-sum -go

  message group           count     min(sec)        max(sec)    average(sec)
  =============           =====     ========        ========    ============
  SPUT.bucket                 1        0.125           0.125           0.125
  SPUT.object                12        0.025           1.019           0.236

I risultati mostrano che le operazioni SPUT per i bucket hanno caratteristiche di performance diverse rispetto alle operazioni SPUT per gli oggetti.

Per determinare quali bucket hanno le operazioni SPUT più lente, utilizzare -gb l'opzione, che raggruppa i messaggi per bucket:

grep SPUT audit.log | audit-sum -gb

  message group                  count     min(sec)        max(sec)    average(sec)
  =============                  =====     ========        ========    ============
  SPUT.cho-non-versioning        71943        0.046        1770.563           1.571
  SPUT.cho-versioning            54277        0.047        1736.633           1.415
  SPUT.cho-west-region           80615        0.040          55.557           1.329
  SPUT.ldt002                  1564563        0.011          51.569           0.361

Per determinare quali bucket hanno la dimensione massima dell'oggetto SPUT, utilizzare sia le -gb opzioni e -s:

grep SPUT audit.log | audit-sum -gb -s

  message group                  count       min(B)          max(B)      average(B)
  =============                  =====     ========        ========    ============
  SPUT.cho-non-versioning        71943        2.097        5000.000          21.672
  SPUT.cho-versioning            54277        2.097        5000.000          21.120
  SPUT.cho-west-region           80615        2.097         800.000          14.433
  SPUT.ldt002                  1564563        0.000         999.972           0.352

Utilizzare lo strumento audit-sum

Creating your file...