La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Utiliser l'outil audit-sum

11/07/2024 Contributeurs

Vous pouvez utiliser audit-sum l'outil pour compter les messages d'audit d'écriture, de lecture, de tête et de suppression et pour afficher le temps minimal, maximal et moyen (ou la taille) pour chaque type d'opération.

Avant de commencer

Vous avez "autorisations d'accès spécifiques".
Vous devez avoir le Passwords.txt fichier.
Vous devez connaître l'adresse IP du nœud d'administration principal.

Description de la 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 consignées, ainsi que la durée de ces opérations.

Cet audit-sum outil est principalement destiné au support technique lors des opérations de dépannage. Le traitement des audit-sum requêtes peut consommer une grande quantité de puissance CPU, ce qui peut avoir un impact sur les opérations StorageGRID.

Cet exemple montre les résultats typiques de l' `audit-sum`outil. Cet exemple montre la durée des opérations de protocoles.

  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

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

Les codes d'audit sont supprimés du produit et de la documentation, car les fonctionnalités sont 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 connaître les versions antérieures de SG. Par exemple "StorageGRID 11.8 à l'aide de la documentation de l'outil de somme d'audit", .

Code	Description	Reportez-vous à la section
IDEL	ILM initialisée – journaux lorsque l'ILM démarre le processus de suppression d'un objet.	"IDEL : suppression initiée ILM"
SDEL	SUPPRESSION S3 : journal une transaction réussie pour supprimer un objet ou un compartiment.	"SDEL : SUPPRESSION S3"
SGET	S3 GET : log une transaction réussie pour récupérer un objet ou répertorier les objets dans un compartiment.	"SGET : OBTENEZ S3"
SHEA	TÊTE S3 : consigne une transaction réussie pour vérifier l'existence d'un objet ou d'un compartiment.	"SHEA : TÊTE S3"
SPUT	S3 PUT : enregistre la réussite d'une transaction pour créer un nouvel objet ou un compartiment.	"SPUT : PUT S3"
WDEL	SUPPRESSION Swift : enregistre une transaction réussie pour supprimer un objet ou un conteneur.	"WDEL : SUPPRESSION rapide"
C'EST PARTI	SWIFT GET : log une transaction réussie pour récupérer un objet ou répertorier les objets dans un conteneur.	"WGET: SWIFT GET"
WHEA	SWIFT HEAD : consigne une transaction réussie afin de vérifier l'existence d'un objet ou d'un conteneur.	"WHEA: TÊTE SWIFT"
WPUT	SWIFT PUT : consigne une transaction réussie pour créer un nouvel objet ou conteneur.	"WPUT : PUT SWIFT"

Code

Description

Reportez-vous à la section

IDEL

ILM initialisée – journaux lorsque l'ILM démarre le processus de suppression d'un objet.

"IDEL : suppression initiée ILM"

SDEL

SUPPRESSION S3 : journal une transaction réussie pour supprimer un objet ou un compartiment.

"SDEL : SUPPRESSION S3"

SGET

S3 GET : log une transaction réussie pour récupérer un objet ou répertorier les objets dans un compartiment.

"SGET : OBTENEZ S3"

SHEA

TÊTE S3 : consigne une transaction réussie pour vérifier l'existence d'un objet ou d'un compartiment.

"SHEA : TÊTE S3"

SPUT

S3 PUT : enregistre la réussite d'une transaction pour créer un nouvel objet ou un compartiment.

"SPUT : PUT S3"

WDEL

SUPPRESSION Swift : enregistre une transaction réussie pour supprimer un objet ou un conteneur.

"WDEL : SUPPRESSION rapide"

C'EST PARTI

SWIFT GET : log une transaction réussie pour récupérer un objet ou répertorier les objets dans un conteneur.

"WGET: SWIFT GET"

WHEA

SWIFT HEAD : consigne une transaction réussie afin de vérifier l'existence d'un objet ou d'un conteneur.

"WHEA: TÊTE SWIFT"

WPUT

SWIFT PUT : consigne une transaction réussie pour créer un nouvel objet ou conteneur.

"WPUT : PUT SWIFT"

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

Traiter les journaux d'audit 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/log/*
Acceptez l'entrée d'un canal, qui vous permet de filtrer et de prétraiter l'entrée à l'aide de la grep commande 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

Cet outil n'accepte pas les fichiers compressés comme entrée de pipettes. Pour traiter des fichiers compressés, indiquez leurs noms de fichiers en tant qu'arguments de ligne de commande ou utilisez l' `zcat`outil pour décompresser d'abord les fichiers. Par exemple :

audit-sum audit.log.gz

zcat audit.log.gz | audit-sum

Vous pouvez utiliser les options de ligne de commande pour résumer les opérations sur des compartiments séparément des opérations sur des objets ou pour regrouper les résumés de messages par nom de compartiment, par période ou par type de cible. Par défaut, les résumés affichent le temps de fonctionnement minimal, maximal et moyen, mais vous pouvez utiliser l' `size (-s)`option pour examiner la taille de l'objet à la place.

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

$ audit-sum -h

Étapes

Connectez-vous au nœud d'administration principal :
1. Entrez la commande suivante : ssh admin@primary_Admin_Node_IP
2. Saisissez le mot de passe indiqué dans le Passwords.txt fichier.
3. Entrez la commande suivante pour basculer en root : su -
4. Saisissez le mot de passe indiqué dans le Passwords.txt fichier.
  
  Lorsque vous êtes connecté en tant que root, l'invite passe de $ à #.

Pour analyser tous les messages liés aux opérations d'écriture, de lecture, de tête et de suppression, procédez comme suit :

Entrez la commande suivante, où /var/local/log/audit.log représente le nom et l'emplacement du ou des fichiers à analyser :

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

Cet exemple montre les résultats typiques de l' `audit-sum`outil. Cet exemple montre la durée des opérations de protocoles.
```
  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 opérations les plus lentes en moyenne à 1.13 secondes, mais les opérations SGET et SPUT (S3 PUT) affichent toutes les deux de longues périodes de pire des cas d'environ 1,770 secondes.
Pour afficher les opérations de récupération 10 les plus lentes, utilisez la commande grep pour sélectionner uniquement les messages SGET et ajouter l'option de sortie longue (-l) pour inclure les chemins d'objet :

grep SGET audit.log | audit-sum -l

Les résultats incluent le type (objet ou compartiment) et le chemin, ce qui vous permet d'afficher le journal d'audit pour les 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

+ Dans cet exemple de sortie, vous pouvez constater que les trois demandes GET S3 les plus lentes étaient celles des objets d'une taille d'environ 5 Go (ce qui est beaucoup plus important que les autres objets). La grande taille tient compte des délais de récupération lents les moins importants.

Si vous voulez déterminer la taille des objets qui sont ingérés et récupérés à partir de votre grille, utilisez l'option taille (-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, mais la taille moyenne pour SGET est beaucoup plus grande. Le nombre de messages SPUT est beaucoup plus élevé que le nombre de messages SGET, ce qui indique que la plupart des objets ne sont jamais récupérés.

Si vous voulez déterminer si les récupérations étaient lentes hier :

Exécutez la commande dans le journal d'audit approprié et utilisez l'option Group-by-time (-gt(groupe par heure), 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 que S3 GÉNÈRE un trafic entre 06:00 et 07:00. Les temps maximum et moyen sont à la fois considérablement plus élevés à ces moments aussi, et ils n'ont pas augmenté progressivement à mesure que le comptage a augmenté. Cela suggère que la capacité a été dépassée quelque part, peut-être dans le réseau ou que la grille peut traiter les demandes.

Pour déterminer la taille des objets récupérés chaque heure d'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 se sont produites lorsque le trafic global de récupération était à son maximum.

Pour plus de détails, utilisez le "outil d'audit-explication" pour revoir toutes les opérations SGET pendant cette heure :

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

Si la sortie de la commande grep doit être de plusieurs lignes, ajoutez la less commande pour afficher le contenu du fichier journal d'audit, une page (un écran) à la fois.

Si vous souhaitez déterminer si les opérations SPUT sur les godets sont plus lentes que les opérations SPUT pour les objets :

Commencez par utiliser l' `-go`option, qui regroupe les messages pour les opérations d'objet et de compartiment séparément :

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 pour les compartiments ont des caractéristiques de performances différentes de celles des opérations SPUT pour les objets.

Pour déterminer les compartiments ayant les opérations SPUT les plus lentes, utilisez l' `-gb`option, 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

Pour déterminer quels compartiments ont la taille d'objet SPUT la plus élevée, utilisez les -gb options 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

Utiliser l'outil audit-sum

Creating your file...