Verwenden Sie das Audit-Sum-Tool
Änderungen vorschlagen
PDFs
Mit dem Tool können audit-sum Sie die Audit-Meldungen schreiben, lesen, Kopf und löschen sowie die minimale, maximale und durchschnittliche Zeit (oder Größe) für jeden Operationsart anzeigen.
-
Sie haben "Bestimmte Zugriffsberechtigungen".
-
Sie müssen über die
Passwords.txtDatei verfügen. -
Sie müssen die IP-Adresse des primären Admin-Knotens kennen.
Das audit-sum auf dem primären Admin-Knoten verfügbare Tool fasst zusammen, wie viele Schreib-, Lese- und Löschvorgänge protokolliert wurden und wie lange diese Vorgänge gedauert haben.
|
Das audit-sum Tool ist in erster Linie für den Einsatz durch den technischen Support bei der Fehlerbehebung vorgesehen. Verarbeitungsabfragen audit-sum können eine hohe CPU-Leistung verbrauchen, was sich auf die StorageGRID-Vorgänge auswirken kann.
|
Dieses Beispiel zeigt eine typische Ausgabe des audit-sum Tools. Dieses Beispiel zeigt, wie lange Protokollvorgänge dauerte.
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
Das audit-sum Tool bietet Zählungen und Uhrzeiten für die folgenden S3-, Swift- und ILM-Audit-Meldungen in einem Revisionsprotokoll.
|
|
Audit-Codes werden aus dem Produkt und der Dokumentation entfernt, da Funktionen veraltet sind. Wenn ein Audit-Code angezeigt wird, der hier nicht aufgeführt ist, überprüfen Sie die früheren Versionen dieses Themas auf ältere SG-Versionen. "StorageGRID 11.8 mit der Dokumentation des Audit Sum Tools"Beispiel: . |
| Codieren | Beschreibung | Siehe |
|---|---|---|
IDEL |
ILM initiated Delete: Protokolliert, wenn ILM den Prozess des Löschens eines Objekts startet. |
|
SDEL |
S3 DELETE: Protokolliert eine erfolgreiche Transaktion zum Löschen eines Objekts oder Buckets. |
|
SGET |
S3 GET: Protokolliert eine erfolgreiche Transaktion, um ein Objekt abzurufen oder die Objekte in einem Bucket aufzulisten. |
|
SHEA |
S3 HEAD: Protokolliert eine erfolgreiche Transaktion, um zu überprüfen, ob ein Objekt oder ein Bucket vorhanden ist. |
|
SPUT |
S3 PUT: Protokolliert eine erfolgreiche Transaktion, um ein neues Objekt oder einen neuen Bucket zu erstellen. |
|
WDEL |
Swift DELETE: Protokolliert eine erfolgreiche Transaktion zum Löschen eines Objekts oder Containers. |
|
WGET |
Swift GET: Protokolliert eine erfolgreiche Transaktion, um ein Objekt abzurufen oder die Objekte in einem Container aufzulisten. |
|
WHEA |
Swift HEAD: Protokolliert eine erfolgreiche Transaktion, um das Vorhandensein eines Objekts oder Containers zu überprüfen. |
|
WPUT |
Swift PUT: Protokolliert eine erfolgreiche Transaktion, um ein neues Objekt oder einen neuen Container zu erstellen. |
Das audit-sum Tool kann Folgendes tun:
-
Verarbeiten Sie einfache oder komprimierte Prüfprotokolle. Beispiel:
audit-sum audit.logaudit-sum 2019-08-12.txt.gz -
Mehrere Dateien gleichzeitig verarbeiten. Beispiel:
audit-sum audit.log 2019-08-12.txt.gz 2019-08-13.txt.gzaudit-sum /var/local/log/* -
Eingaben von einer Pipe akzeptieren, wodurch Sie die Eingabe mit dem Befehl oder anderen Mitteln filtern und vorverarbeiten
grepkönnen. Beispiel:grep WGET audit.log | audit-sumgrep bucket1 audit.log | audit-sumgrep SPUT audit.log | grep bucket1 | audit-sum
|
|
Dieses Tool akzeptiert keine komprimierten Dateien als Piper Input. Um komprimierte Dateien zu verarbeiten, geben Sie ihre Dateinamen als Befehlszeilenargumente ein, oder verwenden Sie das
|
Mit Befehlszeilenoptionen können Operationen für Buckets separat von Operationen für Objekte zusammengefasst oder Nachrichtenübersichten nach Bucket-Namen, Zeitraum oder Zieltyp gruppieren. Standardmäßig werden in den Zusammenfassungen die minimale, maximale und durchschnittliche Betriebsdauer angezeigt, Sie können jedoch die Option verwenden, um die size (-s) Objektgröße zu überprüfen.
Verwenden Sie die help (-h) Option, um die verfügbaren Optionen anzuzeigen. Beispiel:
$ audit-sum -h
-
Melden Sie sich beim primären Admin-Node an:
-
Geben Sie den folgenden Befehl ein:
ssh admin@primary_Admin_Node_IP -
Geben Sie das in der Datei aufgeführte Passwort ein
Passwords.txt. -
Geben Sie den folgenden Befehl ein, um zu root zu wechseln:
su - -
Geben Sie das in der Datei aufgeführte Passwort ein
Passwords.txt.Wenn Sie als root angemeldet sind, wechselt die Eingabeaufforderung von
$zu#.
-
-
Wenn Sie alle Nachrichten analysieren möchten, die mit Schreibvorgängen, Lese-, Kopf- und Löschvorgängen zusammenhängen, führen Sie die folgenden Schritte aus:
-
Geben Sie den folgenden Befehl ein, wobei
/var/local/log/audit.logfür den Namen und den Speicherort der oder der Dateien steht, die Sie analysieren möchten:$ audit-sum /var/local/log/audit.logDieses Beispiel zeigt eine typische Ausgabe des
audit-sumTools. Dieses Beispiel zeigt, wie lange Protokollvorgänge dauerte.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
In diesem Beispiel sind SGET (S3 GET) Vorgänge im Durchschnitt mit 1.13 Sekunden die langsamsten. SGET und SPUT (S3 PUT) Vorgänge weisen jedoch lange Schlimmstfallszeiten von etwa 1,770 Sekunden auf.
-
Um die langsamsten 10 Abruffunktionen anzuzeigen, verwenden Sie den grep-Befehl, um nur SGET-Nachrichten auszuwählen und die Long-Ausgabeoption hinzuzufügen(
-l, um Objektpfade einzuschließen:grep SGET audit.log | audit-sum -lDie Ergebnisse umfassen den Typ (Objekt oder Bucket) und den Pfad, mit dem Sie das Audit-Protokoll für andere Meldungen zu diesen speziellen Objekten grep erstellen können.
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+ Aus diesem Beispielausgang sehen Sie, dass die drei langsamsten S3-GET-Anfragen für Objekte mit einer Größe von ca. 5 GB waren, was viel größer ist als die anderen Objekte. Die große Größe berücksichtigt die langsamen Abrufzeiten im schlimmsten Fall.
-
-
Wenn Sie festlegen möchten, welche Größe von Objekten in Ihr Raster aufgenommen und aus diesem abgerufen werden soll, verwenden Sie die Größenoption (
-s):audit-sum -s audit.logmessage 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
In diesem Beispiel liegt die durchschnittliche Objektgröße für SPUT unter 2.5 MB, die durchschnittliche Größe für SGET ist jedoch deutlich größer. Die Anzahl der SPUT-Meldungen ist viel höher als die Anzahl der SGET-Nachrichten, was darauf hinweist, dass die meisten Objekte nie abgerufen werden.
-
Wenn Sie feststellen möchten, ob die Abrufvorgänge gestern langsam waren:
-
Geben Sie den Befehl im entsprechenden Audit-Protokoll ein und verwenden Sie die Option Group-by-time (
-gt), gefolgt von dem Zeitraum (z.B. 15M, 1H, 10S):grep SGET audit.log | audit-sum -gt 1Hmessage 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
Diese Ergebnisse zeigen, dass S3 VERKEHR zwischen 06:00 und 07:00 Spikes. Auch die max- und Durchschnittszeiten sind zu diesen Zeiten deutlich höher, und sie stiegen nicht schrittweise auf, wenn die Zahl erhöht wurde. Dies deutet darauf hin, dass die Kapazität irgendwo überschritten wurde, vielleicht im Netzwerk oder in der Fähigkeit des Grids, Anfragen zu verarbeiten.
-
Um zu bestimmen, welche Größe Objekte wurden abgerufen jede Stunde gestern, fügen Sie die Größe Option (
-s), um den Befehl:grep SGET audit.log | audit-sum -gt 1H -smessage 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
Diese Ergebnisse zeigen, dass einige sehr große Rückrufe auftraten, als der gesamte Abrufverkehr seinen maximalen Wert hatte.
-
Weitere Informationen finden Sie im, "Audit-Explain-Tool"um alle SGET-Vorgänge während der betreffenden Stunde zu überprüfen:
grep 2019-09-05T06 audit.log | grep SGET | audit-explain | less
Wenn die Ausgabe des grep-Befehls viele Zeilen enthalten soll, fügen Sie den Befehl hinzu, um den
lessInhalt der Audit-Log-Datei jeweils eine Seite (ein Bildschirm) anzuzeigen. -
-
Wenn Sie feststellen möchten, ob SPUT-Operationen auf Buckets langsamer sind als SPUT-Vorgänge für Objekte:
-
Mit der Option wird gestartet
-go, bei der Meldungen für Objekt- und Bucket-Vorgänge getrennt gruppiert werden:grep SPUT sample.log | audit-sum -gomessage 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
Die Ergebnisse zeigen, dass SPUT-Operationen für Buckets unterschiedliche Leistungseigenschaften haben als SPUT-Operationen für Objekte.
-
Um zu ermitteln, welche Buckets die langsamsten SPUT-Vorgänge haben, verwenden Sie die
-gbOption, welche Meldungen nach Bucket gruppiert:grep SPUT audit.log | audit-sum -gbmessage 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
-
Um zu ermitteln, welche Buckets die größte SPUT-Objektgröße aufweisen, verwenden Sie die
-gbOptionen und-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
-