Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Utilisez l'outil audit-sum pour résumer les messages d'audit de StorageGRID

PDF

Vous pouvez utiliser l’ `audit-sum`outil pour compter les messages d’audit d’écriture, de lecture, d’en-tête et de suppression, ainsi que pour voir le temps (ou la taille) minimum, maximum et moyen pour chaque type d’opération.

Avant de commencer
À propos de cette tâche

L’ `audit-sum`outil, disponible sur le nœud d’administration principal, récapitule le nombre d’opérations d’écriture, de lecture et de suppression enregistrées ainsi que la durée de ces opérations.

Remarque L’ audit-sum`outil est principalement destiné à être utilisé par le support technique lors des opérations de dépannage. Le traitement des requêtes `audit-sum peut consommer une grande quantité de puissance CPU, ce qui peut avoir un impact sur le fonctionnement de StorageGRID.

Cet exemple illustre le résultat typique de l' `audit-sum`outil. Cet exemple montre la durée des opérations de protocole.

  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

L' `audit-sum`outil fournit le nombre et l'heure des messages d'audit S3 et ILM suivants dans un journal des audits.

Remarque Les codes d'audit sont supprimés du produit et de la documentation à mesure que les fonctionnalités deviennent obsolètes. Si vous rencontrez un code d'audit qui n'est pas répertorié ici, consultez les versions précédentes de cette rubrique pour les anciennes versions de StorageGRID. Par exemple, "StorageGRID 11.8 Utilisation de l'outil de somme du journal des audits".
Code Description Consultez

IDEL

Suppression initiée par ILM : journalise lorsque ILM lance le processus de suppression d’un objet.

"IDEL : Suppression initiée par ILM"

SDEL

S3 DELETE : Enregistre une transaction réussie de suppression d’un objet ou d’un compartiment.

"SDEL : S3 DELETE"

SGET

S3 GET : Enregistre une transaction réussie pour récupérer un objet ou lister les objets d’un compartiment.

"SGET : S3 GET"

SHEA

S3 HEAD : Enregistre une transaction réussie pour vérifier l’existence d’un objet ou d’un compartiment.

"SHEA : S3 HEAD"

SPUT

S3 PUT : Consigne une transaction réussie pour créer un nouvel objet ou compartiment.

"SPUT: S3 PUT"

L’ `audit-sum`outil peut effectuer les opérations suivantes :

  • Traitez les journaux des audits bruts ou compressés. Par exemple :

    audit-sum audit.log

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

  • Traitez plusieurs fichiers simultanément. Par exemple :

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

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

  • Acceptez les données d'entrée provenant d'un tube, ce qui vous permet de filtrer et de prétraiter l'entrée à l'aide de la commande grep ou d'autres moyens. Par exemple :

    grep WGET audit.log | audit-sum

    grep bucket1 audit.log | audit-sum

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

Remarque

Cet outil n'accepte pas les fichiers compressés en entrée via un tube. Pour traiter des fichiers compressés, indiquez leur nom en argument de ligne de commande ou utilisez l’outil zcat pour les décompresser au préalable. Par exemple :

audit-sum audit.log.gz

zcat audit.log.gz | audit-sum

Vous pouvez utiliser les options de ligne de commande pour synthétiser les opérations sur les compartiments séparément de celles sur les objets, ou pour regrouper les synthèses par nom de compartiment, par période ou par type de cible. Par défaut, les synthèses affichent la durée minimale, maximale et moyenne des opérations, mais vous pouvez utiliser l’ `size (-s)`option pour examiner la taille des objets à la place.

Utilisez l’ `help (-h)`option pour afficher les options disponibles. Par exemple :

$ audit-sum -h

Étapes

  1. Connectez-vous au nœud d'administration principal :

    1. Saisissez la commande suivante : ssh admin@primary_Admin_Node_IP

    2. Saisissez le mot de passe indiqué dans le fichier Passwords.txt.

    3. Saisissez la commande suivante pour passer en mode superutilisateur : su -

    4. Saisissez le mot de passe indiqué dans le fichier Passwords.txt.

      Lorsque vous êtes connecté en tant que root, l'invite passe de $ à #.

  2. Si vous souhaitez analyser tous les messages relatifs aux opérations d'écriture, de lecture, de head et de suppression, suivez ces étapes :

    1. Saisissez la commande suivante, où /var/local/audit/export/audit.log représente le nom et l’emplacement du ou des fichiers que vous souhaitez analyser :

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

      Cet exemple illustre le résultat typique de l' `audit-sum`outil. Cet exemple montre la durée des opérations de protocole.

        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

      Dans cet exemple, les opérations SGET (S3 GET) sont les plus lentes en moyenne à 1,13 seconde, mais les opérations SGET et SPUT (S3 PUT) affichent toutes deux des temps dans le pire des cas d'environ 1 770 secondes.

    2. Pour afficher les 10 opérations de récupération les plus lentes, utilisez la commande grep pour sélectionner uniquement les messages SGET et ajoutez l’option de sortie longue (-l pour inclure les chemins d’accès aux objets :

      grep SGET audit.log | audit-sum -l

      Les résultats incluent le type (objet ou compartiment) et le chemin, ce qui vous permet de rechercher dans le journal des audits d'autres messages relatifs à ces objets particuliers.

    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

    + Cet exemple de résultat montre que les trois requêtes S3 GET les plus lentes concernaient des objets d'environ 5 Go, soit une taille bien supérieure à celle des autres objets. La grande taille explique les temps de récupération les plus lents dans le pire des cas.

  3. Si vous souhaitez déterminer quelles tailles d’objets sont ingérées et récupérées depuis votre grille, utilisez l’option 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

    Dans cet exemple, la taille moyenne des objets pour SPUT est inférieure à 2,5 Mo, tandis que la taille moyenne pour SGET est bien plus importante. Le nombre de messages SPUT est nettement supérieur à celui des messages SGET, ce qui indique que la plupart des objets ne sont jamais récupérés.

  4. Si vous souhaitez déterminer si les récupérations ont été lentes hier :

    1. Exécutez la commande sur le journal des audits approprié et utilisez l’option group-by-time (-gt), suivie de la période (par exemple, 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

      Ces résultats montrent un pic de trafic GET S3 entre 06:00 et 07:00. Les temps maximum et moyen sont tous deux nettement plus élevés durant cette période, et ils n'ont pas augmenté progressivement à mesure que le nombre augmentait. Ces indicateurs suggèrent que la capacité a été dépassée, possiblement au niveau du réseau ou de la capacité de la grille à traiter les requêtes.

    2. Pour déterminer la taille des objets récupérés chaque heure hier, ajoutez l’option size (-s) à la commande :

      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

      Ces résultats indiquent que des récupérations très importantes ont eu lieu lorsque le trafic global de récupération était à son maximum.

    3. Pour plus de détails, utilisez la fonction "outil audit-explain" pour consulter toutes les opérations SGET effectuées pendant cette heure :

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

    Si la sortie de la commande grep est censée comporter plusieurs lignes, ajoutez la commande less pour afficher le contenu du journal des audits une page (un écran) à la fois.

  5. Si vous souhaitez déterminer si les opérations SPUT sur les compartiments sont plus lentes que les opérations SPUT sur les objets :

    1. Commencez par utiliser l’option -go, qui regroupe séparément les messages pour les opérations sur les objets et les compartiments :

      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

      Les résultats montrent que les opérations SPUT sur les compartiments présentent des caractéristiques de performance différentes de celles des opérations SPUT sur les objets.

    2. Pour déterminer quels compartiments présentent les opérations SPUT les plus lentes, utilisez l’option -gb qui regroupe les messages par compartiment :

      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. Pour déterminer quels compartiments ont la plus grande taille d'objet SPUT, utilisez à la fois les options -gb et -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