Skip to main content
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Use a ferramenta audit-sum para resumir as mensagens de auditoria do StorageGRID

PDFs

Você pode usar a audit-sum ferramenta para contar as mensagens de log de auditoria de gravação, leitura, head e exclusão e para ver o tempo (ou tamanho) mínimo, máximo e médio para cada tipo de operação.

Antes de começar
Sobre esta tarefa

A audit-sum ferramenta, disponível no nó de administração principal, resume quantas operações de gravação, leitura e exclusão foram registradas e quanto tempo essas operações levaram.

Observação A `audit-sum`ferramenta destina-se principalmente ao uso pelo suporte técnico durante operações de resolução de problemas. O processamento de `audit-sum`consultas pode consumir uma grande quantidade de poder de processamento da CPU, o que pode afetar as operações do StorageGRID.

Este exemplo mostra a saída típica da audit-sum ferramenta. Este exemplo mostra quanto tempo as operações do protocolo levaram.

  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

A `audit-sum`ferramenta fornece contagens e horários para as seguintes mensagens de auditoria S3 e ILM em um log de auditoria.

Observação Os códigos de auditoria são removidos do produto e da documentação à medida que os recursos são descontinuados. Se você encontrar um código de auditoria que não esteja listado aqui, verifique as versões anteriores deste tópico para versões mais antigas do StorageGRID. Por exemplo, "StorageGRID 11.8 Usando a ferramenta audit sum".
Código Descrição Consulte

IDEL

Exclusão iniciada pelo ILM: registra quando o ILM inicia o processo de exclusão de um objeto.

"IDEL: Exclusão iniciada pelo ILM"

SDEL

S3 DELETE: Registra uma transação bem-sucedida para excluir um objeto ou bucket.

"SDEL: S3 DELETE"

SGET

S3 GET: Registra uma transação bem-sucedida para recuperar um objeto ou listar os objetos em um bucket.

"SGET: S3 GET"

SHEA

S3 HEAD: Registra uma transação bem-sucedida para verificar a existência de um objeto ou bucket.

"SHEA: S3 HEAD"

SPUT

S3 PUT: registra uma transação bem-sucedida para criar um novo objeto ou bucket.

"SPUT: S3 PUT"

A ferramenta audit-sum pode fazer o seguinte:

  • Processar logs de auditoria simples ou compactados. Por exemplo:

    audit-sum audit.log

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

  • Processar vários arquivos simultaneamente. Por exemplo:

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

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

  • Aceitar entrada de um pipe, o que permite filtrar e pré-processar a entrada usando o comando grep ou outros meios. Por exemplo:

    grep WGET audit.log | audit-sum

    grep bucket1 audit.log | audit-sum

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

Observação

Esta ferramenta não aceita arquivos compactados como entrada via pipe. Para processar arquivos compactados, forneça os nomes dos arquivos como argumentos de linha de comando ou use a ferramenta zcat para descompactar os arquivos primeiro. Por exemplo:

audit-sum audit.log.gz

zcat audit.log.gz | audit-sum

Você pode usar opções de linha de comando para resumir as operações em buckets separadamente das operações em objetos ou para agrupar resumos de mensagens por nome do bucket, por período ou por tipo de destino. Por padrão, os resumos mostram o tempo mínimo, máximo e médio de operação, mas você pode usar a opção size (-s) para visualizar o tamanho do objeto.

Use a opção help (-h) para ver as opções disponíveis. Por exemplo:

$ audit-sum -h

Passos

  1. Faça login no nó de administração principal:

    1. Digite o seguinte comando: ssh admin@primary_Admin_Node_IP

    2. Digite a senha listada no arquivo Passwords.txt.

    3. Digite o seguinte comando para alternar para root: su -

    4. Digite a senha listada no arquivo Passwords.txt.

      Quando você está logado como root, o prompt muda de $ para #.

  2. Se você deseja analisar todas as mensagens relacionadas às operações de escrita, leitura, head e exclusão, siga estas etapas:

    1. Digite o seguinte comando, onde /var/local/audit/export/audit.log representa o nome e o local do(s) arquivo(s) que você deseja analisar:

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

      Este exemplo mostra a saída típica da audit-sum ferramenta. Este exemplo mostra quanto tempo as operações do protocolo levaram.

        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

      Neste exemplo, as operações SGET (S3 GET) são as mais lentas em média, com 1,13 segundos, mas as operações SGET e SPUT (S3 PUT) apresentam tempos máximos longos, de cerca de 1.770 segundos.

    2. Para exibir as 10 operações de recuperação mais lentas, use o comando grep para selecionar apenas as mensagens SGET e adicione a opção de saída longa (-l para incluir os caminhos dos objetos:

      grep SGET audit.log | audit-sum -l

      Os resultados incluem o tipo (objeto ou bucket) e o caminho, o que permite usar o grep para pesquisar no log de auditoria outras mensagens relacionadas a esses objetos específicos.

    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

    + A partir deste exemplo de saída, você pode ver que as três solicitações GET mais lentas do S3 foram para objetos com cerca de 5 GB, que são muito maiores do que os outros objetos. O tamanho grande explica os tempos de recuperação mais lentos no pior caso.

  3. Se você deseja determinar os tamanhos dos objetos que estão sendo inseridos e recuperados da sua grade, use a opção size (-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

    Neste exemplo, o tamanho médio dos objetos para SPUT é inferior a 2,5 MB, mas o tamanho médio para SGET é muito maior. O número de mensagens SPUT é muito maior do que o número de mensagens SGET, indicando que a maioria dos objetos nunca é recuperada.

  4. Se você quiser determinar se as recuperações foram lentas ontem:

    1. Execute o comando no log de auditoria apropriado e use a opção group-by-time (-gt, seguida pelo período de tempo (por exemplo, 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

      Esses resultados mostram que o tráfego GET no S3 apresentou um pico entre 06:00 e 07:00. Os tempos máximo e médio foram consideravelmente maiores durante esse período e não aumentaram gradualmente conforme a contagem aumentava. Essas métricas sugerem que a capacidade foi excedida, possivelmente na rede ou na capacidade do grid de processar as solicitações.

    2. Para determinar o tamanho dos objetos recuperados a cada hora ontem, adicione a opção (`-s`size ao 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

      Esses resultados indicam que algumas recuperações muito grandes ocorreram quando o tráfego geral de recuperação estava no máximo.

    3. Para ver mais detalhes, use a "ferramenta audit-explain" para revisar todas as operações SGET durante essa hora:

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

    Se a saída do comando grep for esperada em várias linhas, adicione o comando less para exibir o conteúdo do arquivo de log de auditoria uma página (uma tela) por vez.

  5. Se você deseja determinar se as operações SPUT em buckets são mais lentas do que as operações SPUT em objetos:

    1. Comece usando a opção -go que agrupa as mensagens para operações de objeto e de bucket separadamente:

      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

      Os resultados mostram que as operações SPUT para buckets têm características de desempenho diferentes das operações SPUT para objetos.

    2. Para determinar quais buckets têm as operações SPUT mais lentas, use a opção -gb que agrupa as mensagens por 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. Para determinar quais buckets têm o maior tamanho de objeto SPUT, use as opções -gb 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