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

PDFs

Você pode usar o audit-sum ferramenta para contar as mensagens de auditoria de gravação, leitura, cabeçalho e exclusão e para 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

O audit-sum A 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 O audit-sum A ferramenta destina-se principalmente ao uso pelo suporte técnico durante operações de solução de problemas. Processamento audit-sum consultas 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 do audit-sum ferramenta. Este exemplo mostra quanto tempo demoraram as operações do protocolo.

  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

O audit-sum A ferramenta fornece contagens e tempos para as seguintes mensagens de auditoria do 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, pois 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 SG. Por exemplo, "Documentação da ferramenta de soma de auditoria do StorageGRID 11.8" .
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 EXCLUIR"

SGET

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

"SGET: S3 OBTER"

KARITÉ

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

"SHEA: CABEÇA S3"

CUSPIR

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 contêiner.

"WDEL: Swift EXCLUIR"

WGET

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

"WGET: GET rápido"

WHEA

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

"WHEA: CABEÇA Rápida"

WPUT

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

"WPUT: PUT rápido"

O audit-sum ferramenta pode fazer o seguinte:

  • Processe logs de auditoria simples ou compactados. 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/*

  • Aceitar entrada de um pipe, o 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 compactados como entrada canalizada. Para processar arquivos compactados, forneça seus nomes de arquivo como argumentos de linha de comando ou use o zcat ferramenta 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 operações em buckets separadamente de operações em objetos ou para agrupar resumos de mensagens por nome de bucket, por período de tempo 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 o size (-s) opção para olhar o tamanho do objeto.

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

$ audit-sum -h

Passos

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

    1. Digite o seguinte comando: ssh admin@primary_Admin_Node_IP

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

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

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

      Quando você está logado como root, o prompt muda 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 o local do arquivo ou arquivos que você deseja analisar:

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

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

        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) mostram tempos longos de pior caso, de cerca de 1.770 segundos.

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

      grep SGET audit.log | audit-sum -l

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

  3. Se você quiser determinar quais tamanhos de objetos estão sendo ingeridos e recuperados de sua grade, use a opção de 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 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. Emita o comando no log de auditoria apropriado e use a opção group-by-time(-gt ), seguido 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 S3 GET atingiu o pico entre 06:00 e 07:00. Os tempos máximo e médio também são consideravelmente maiores nesses momentos e não aumentam gradualmente conforme a contagem aumenta. 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 o tamanho dos objetos que foram recuperados a cada hora ontem, adicione a opção de 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 máximo.

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

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

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

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

    1. Comece usando o -go opção, que agrupa 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 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 o -gb opção, que agrupa 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 ambos -gb e o -s opções:

      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