Skip to main content
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

Colaboradores
PDFs

Você pode usar a audit-sum ferramenta para contar as mensagens de auditoria de gravação, leitura, cabeçalho e exclusão e ver o tempo mínimo, máximo e médio (ou tamanho) 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 demoraram.

Observação A audit-sum ferramenta destina-se principalmente ao uso por suporte técnico durante operações de solução de problemas. As consultas de processamento audit-sum podem consumir uma grande quantidade de energia 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 de protocolo demoraram.

  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 tempos para as seguintes mensagens de auditoria S3, Swift 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 obsoletos. Se você encontrar um código de auditoria que não está listado aqui, verifique as versões anteriores deste tópico para versões mais antigas do SG. Por exemplo, "StorageGRID 11,8 usando a documentação da ferramenta de soma de auditoria".
Código Descrição Consulte

IDEL

ILM iniciado Excluir: Registra quando ILM inicia o processo de exclusão de um objeto.

"IDEL: ILM iniciou Excluir"

SDEL

S3 DELETE: Registra uma transação bem-sucedida para excluir um objeto ou um 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 CABEÇA"

SPUT

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

"SPUT: S3 PUT"

WDEL

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

"WDEL: Swift DELETE"

WGET

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

"WGET: Rápido"

BEM-VINDO

Swift head: Registra uma transação bem-sucedida para verificar a existência de um objeto ou contentor.

"WHEA: CABEÇA rápida"

WPUT

Swift PUT: Registra uma transação bem-sucedida para criar um novo objeto ou contentor.

"WPUT: Swift PUT"

A audit-sum ferramenta pode fazer o seguinte:

  • Processe logs de auditoria simples ou compatados. Por exemplo:

    audit-sum audit.log

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

  • Processe vários arquivos simultaneamente. Por exemplo:

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

    audit-sum /var/local/log/*

  • Aceite a entrada de um pipe, que permite filtrar e pré-processar a entrada usando o grep comando 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 compatados como entrada pipeada. Para processar arquivos compatados, forneça seus nomes de arquivo como argumentos de linha de comando ou use a zcat ferramenta para descomprimir os arquivos primeiro. Por exemplo:

audit-sum audit.log.gz

zcat audit.log.gz | audit-sum

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

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

$ audit-sum -h

Passos

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

    1. Introduza o seguinte comando: ssh admin@primary_Admin_Node_IP

    2. Introduza a palavra-passe listada no Passwords.txt ficheiro.

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

    4. Introduza a palavra-passe listada no Passwords.txt ficheiro.

      Quando você estiver conetado como root, o prompt mudará de $ para #.

  2. Se você quiser analisar todas as mensagens relacionadas às operações de gravação, leitura, cabeçalho e exclusão, siga estas etapas:

    1. Digite o seguinte comando, onde /var/local/log/audit.log representa o nome e a localização do arquivo ou arquivos que você deseja analisar:

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

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

        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 de SGET (S3 GET) são as mais lentas em média em 1,13 segundos, mas as operações de SGET e SPUT (S3 PUT) mostram tempos piores longos de cerca de 1.770 segundos.

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

      grep SGET audit.log | audit-sum -l

      Os resultados incluem o tipo (objeto ou bucket) e o caminho, que permite que você grep o log de auditoria para 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 os três pedidos mais lentos de S3 GET foram para objetos de tamanho de cerca de 5 GB, que é muito maior do que os outros objetos. O tamanho grande é responsável pelos tempos de recuperação lentos do pior caso.

  3. Se você quiser determinar em que tamanhos de objetos estão sendo ingeridos e recuperados da grade, use a opção tamanho (-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 do objeto 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 são recuperados.

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

    1. Emita 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 S3 RECEBEM tráfego aumentado entre 06:00 e 07:00. Os tempos máximos e médios são consideravelmente mais elevados nestes tempos também, e eles não aumentaram gradualmente à medida que a contagem aumentou. Isso sugere que a capacidade foi excedida em algum lugar, talvez na rede ou na capacidade da grade de processar solicitações.

    2. Para determinar que objetos de tamanho estavam sendo recuperados a cada hora ontem, adicione a opção tamanho (-s) 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 seu máximo.

    3. Para ver mais detalhes, use o "ferramenta de auditoria-explicação" para rever 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 para ser muitas linhas, adicione o less comando para mostrar o conteúdo do arquivo de log de auditoria uma página (uma tela) de cada vez.

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

    1. Comece usando a -go opção, que agrupa as mensagens para operações de objeto e 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 do SPUT para buckets têm caraterísticas de desempenho diferentes das operações do SPUT para objetos.

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