Utiliser l'outil audit-sum
Suggérer des modifications
PDF
Vous pouvez utiliser le audit-sum outil permettant de compter les messages d'audit d'écriture, de lecture, d'en-tête et de suppression, ainsi que les temps minimum, maximum et moyen (ou taille) pour chaque type d'opération.
-
Vous devez disposer d'autorisations d'accès spécifiques.
-
Vous devez avoir le
Passwords.txtfichier. -
Vous devez connaître l'adresse IP du nœud d'administration principal.
Le audit-sum Disponible sur le nœud d'administration principal, cet outil récapitule le nombre d'opérations d'écriture, de lecture et de suppression enregistrées et la durée de ces opérations.
|
Le audit-sum l'outil est principalement destiné au support technique lors des opérations de dépannage. En cours de traitement audit-sum Les requêtes peuvent consommer une très grande quantité d'énergie dans le processeur, ce qui peut affecter les opérations de StorageGRID.
|
Cet exemple montre une sortie type 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
Le audit-sum Dans un journal d'audit, l'outil indique le nombre et la durée des messages d'audit S3, Swift et ILM suivants :
| Code | Description | Reportez-vous à la section |
|---|---|---|
ARCT |
Archivage depuis le Tier cloud |
|
ASCT |
Tier cloud du magasin d'archivage |
|
IDEL |
ILM initialisée – journaux lorsque l'ILM démarre le processus de suppression d'un objet. |
|
SDEL |
SUPPRESSION S3 : journal une transaction réussie pour supprimer un objet ou un compartiment. |
|
SGET |
S3 GET : log une transaction réussie pour récupérer un objet ou répertorier les objets dans un compartiment. |
|
SHEA |
TÊTE S3 : consigne une transaction réussie pour vérifier l'existence d'un objet ou d'un compartiment. |
|
SPUT |
S3 PUT : enregistre la réussite d'une transaction pour créer un nouvel objet ou un compartiment. |
|
WDEL |
SUPPRESSION Swift : enregistre une transaction réussie pour supprimer un objet ou un conteneur. |
|
C'EST PARTI |
SWIFT GET : log une transaction réussie pour récupérer un objet ou répertorier les objets dans un conteneur. |
|
WHEA |
SWIFT HEAD : consigne une transaction réussie afin de vérifier l'existence d'un objet ou d'un conteneur. |
|
WPUT |
SWIFT PUT : consigne une transaction réussie pour créer un nouvel objet ou conteneur. |
Le audit-sum l'outil peut traiter des journaux d'audit simples ou compressés. Par exemple :
audit-sum audit.log
audit-sum 2019-08-12.txt.gz
Le audit-sum l'outil peut également traiter plusieurs fichiers en même temps. Par exemple :
audit-sum audit.log 2019-08-12.txt.gz 2019-08-13.txt.gz
audit-sum /var/local/audit/export/*
Enfin, le audit-sum l'outil peut également accepter l'entrée d'un tuyau, ce qui vous permet de filtrer et de prétraiter l'entrée à l'aide de l' grep commande ou autre moyen. 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 fichier comme arguments de ligne de commande ou utilisez le zcat outil de décompression des fichiers en premier. 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 indiquent le temps de fonctionnement minimum, maximum et moyen, mais vous pouvez utiliser le size (-s) option pour regarder la taille de l'objet.
Utilisez le help (-h) pour voir les options disponibles. Par exemple :
$ audit-sum -h
-
Connectez-vous au nœud d'administration principal :
-
Saisissez la commande suivante :
ssh admin@primary_Admin_Node_IP -
Entrez le mot de passe indiqué dans le
Passwords.txtfichier.
-
-
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/audit/export/audit.logreprésente le nom et l'emplacement du ou des fichiers à analyser :$ audit-sum /var/local/audit/export/audit.log
Cet exemple montre une sortie type de l'
audit-sumoutil. 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'accès aux objets :grep SGET audit.log | audit-sum -lLes 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.
-
-
Pour déterminer la taille des objets en cours d'ingestion et d'extraction à partir de 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, 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 sur le journal d'audit approprié et utilisez l'option group-by-time (
-gt), suivi 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 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
audit-explainOutil pour passer en revue toutes les opérations du SGET au cours de cette heure :grep 2019-09-05T06 audit.log | grep SGET | audit-explain | less
Si la sortie de la commande grep est censée être de nombreuses lignes, ajoutez le
lesscommande 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 le
-gooption, qui regroupe les messages pour les opérations liées aux objets et aux compartiments 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 godets dont les opérations SPUT sont les plus lentes, utiliser le
-gboption, 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 plus grande taille d'objet SPUT, utilisez les deux
-gbet le-soptions :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
-