Skip to main content
È disponibile una versione più recente di questo prodotto.
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 per riepilogare i messaggi di audit di StorageGRID

PDF

Puoi usare lo strumento audit-sum per contare i messaggi di audit di scrittura, lettura, head ed eliminazione e per vedere il tempo minimo, massimo e medio (o la dimensione) per ciascun tipo di operazione.

Prima di iniziare
Informazioni su questa attività

Lo audit-sum strumento, disponibile sul nodo di amministrazione principale, riassume quante operazioni di scrittura, lettura ed eliminazione sono state registrate e quanto tempo hanno impiegato queste operazioni.

Nota Lo `audit-sum`strumento è pensato principalmente per l'uso da parte del supporto tecnico durante le operazioni di troubleshooting. L'elaborazione delle `audit-sum`query può consumare una grande quantità di potenza della CPU, il che potrebbe influire sulle operazioni di StorageGRID.

Questo esempio mostra l'output tipico dello audit-sum strumento. Questo esempio mostra quanto tempo hanno impiegato le 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

Lo `audit-sum`strumento fornisce conteggi e tempi per i seguenti messaggi di audit S3 e ILM in un file di log di audit.

Nota I codici di controllo vengono rimossi dal prodotto e dalla documentazione man mano che le funzionalità vengono deprecate. Se incontri un codice di controllo che non è presente in questo elenco, controlla le versioni precedenti di questo argomento per le release precedenti di StorageGRID. Ad esempio, "StorageGRID 11.8 Utilizzo dello strumento audit sum".
Codice Descrizione ${post_edited_translations.segment}

IDEL

Eliminazione avviata da ILM: registra quando ILM avvia il processo di eliminazione di un oggetto.

"IDEL: Eliminazione avviata da ILM"

${post_edited_translations.segment}

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

"SDEL: S3 DELETE"

${post_edited_translations.segment}

${post_edited_translations.segment}

"SGET: S3 GET"

SHEA

${post_edited_translations.segment}

"SHEA: S3 HEAD"

SPUT

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

"SPUT: S3 PUT"

Lo `audit-sum`strumento può fare quanto segue:

  • Elabora i log di controllo, sia semplici che compressi. Ad esempio:

    audit-sum audit.log

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

  • Elabora più file contemporaneamente. Ad esempio:

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

    audit-sum /var/local/audit/export/*

  • Accetta input da una pipe, che ti 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

Nota

Questo strumento non accetta file compressi come input tramite pipe. Per elaborare i file compressi, specifica i loro nomi come argomenti della riga di comando oppure utilizza lo zcat strumento per decomprimere prima i file. Ad esempio:

audit-sum audit.log.gz

zcat audit.log.gz | audit-sum

Puoi usare le opzioni della riga di comando per riepilogare le operazioni sui bucket separatamente da quelle sugli oggetti oppure per raggruppare i riepiloghi dei messaggi per nome del bucket, periodo di tempo o tipo di destinazione. Per impostazione predefinita, i riepiloghi mostrano il tempo di operazione minimo, massimo e medio, ma puoi usare l' `size (-s)`opzione per visualizzare invece la dimensione dell'oggetto.

Usa l' `help (-h)`opzione per vedere le opzioni disponibili. Per esempio:

$ audit-sum -h

Passaggi

  1. Accedi al nodo amministratore principale:

    1. Inserisci il seguente comando: ssh admin@primary_Admin_Node_IP

    2. Inserisci la password indicata nel file Passwords.txt.

    3. Inserisci il seguente comando per passare all'utente root: su -

    4. Inserisci la password indicata nel file Passwords.txt.

      Quando sei connesso come root, il prompt cambia da $ a #.

  2. Se vuoi analizzare tutti i messaggi relativi alle operazioni di scrittura, lettura, head ed eliminazione, segui questi passaggi:

    1. Inserisci il seguente comando, dove /var/local/audit/export/audit.log rappresenta il nome e il percorso del file o dei file che desideri analizzare:

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

      Questo esempio mostra l'output tipico dello audit-sum strumento. Questo esempio mostra quanto tempo hanno impiegato le 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, con un tempo di 1,13 secondi, ma sia le operazioni SGET che SPUT (S3 PUT) mostrano tempi massimi elevati, pari a circa 1.770 secondi.

    2. Per visualizzare le 10 operazioni di recupero più lente, usa il comando grep per selezionare solo i messaggi SGET e aggiungi l'opzione di output lunga (-l per includere i percorsi degli oggetti:

      grep SGET audit.log | audit-sum -l

      I risultati includono il tipo (oggetto o bucket) e il percorso, il che ti permette di cercare nel file di log di controllo altri messaggi relativi a questi specifici oggetti.

    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, puoi vedere che le tre richieste GET S3 più lente erano per oggetti di circa 5 GB di dimensione, molto più grandi rispetto agli altri oggetti. Le grandi dimensioni spiegano i tempi di recupero più lenti nel caso peggiore.

  3. Se vuoi determinare quali dimensioni di oggetti vengono inseriti e recuperati dalla tua griglia, usa l'opzione dimensione (-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, mentre la dimensione media per SGET è molto maggiore. Il numero di messaggi SPUT è molto più alto del numero di messaggi SGET, il che indica che la maggior parte degli oggetti non viene mai recuperata.

  4. Se vuoi verificare se ieri i recuperi sono stati lenti:

    1. Esegui il comando sul file di log di audit appropriato e usa 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 il traffico S3 GET ha raggiunto un picco tra le 06:00 e le 07:00. I tempi massimi e medi sono entrambi considerevolmente più elevati in questo intervallo di tempo e non sono aumentati gradualmente con l'aumentare del numero di richieste. Queste metriche suggeriscono che la capacità è stata superata, probabilmente nella rete o nella capacità della grid di elaborare le richieste.

    2. Per determinare la dimensione degli oggetti recuperati ogni ora ieri, aggiungi 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 alcuni recuperi di grandi dimensioni si sono verificati quando il traffico complessivo di recupero era al massimo.

    3. Per vedere più dettagli, usa "strumento audit-explain" per rivedere tutte le operazioni SGET durante quell'ora:

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

    Se ti aspetti che l'output del comando grep sia composto da molte righe, aggiungi il comando less per mostrare il contenuto del file di log di audit una pagina (una schermata) alla volta.

  5. Se vuoi determinare se le operazioni SPUT sui bucket sono più lente delle operazioni SPUT sugli oggetti:

    1. Inizia utilizzando l -go opzione, che raggruppa i messaggi per le operazioni su 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 prestazionali diverse rispetto alle operazioni SPUT per gli oggetti.

    2. Per determinare quali bucket presentano le operazioni SPUT più lente, usa l' `-gb`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

    3. Per determinare quali bucket hanno la dimensione dell'oggetto SPUT più grande, usa sia le opzioni -gb che -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