audit-sumツールを使用する
変更を提案
PDF
を使用できます audit-sum 書き込み、読み取り、HEAD、削除の各監査メッセージをカウントし、それぞれの処理タイプの最小、最大、平均時間（またはサイズ）を表示するツールです。
-
特定のアクセス権限が必要です。
-
を用意しておく必要があります
Passwords.txtファイル。 -
プライマリ管理ノードの IP アドレスを確認しておく必要があります。
。 audit-sum ツールはプライマリ管理ノードで使用でき、ログに記録された書き込み、読み取り、削除の処理数と、それらの処理に要した時間を取得できます。
|
。 audit-sum ツールは、主にトラブルシューティング処理の際にテクニカルサポートが使用することを目的としています。処理中です audit-sum クエリは大量のCPUパワーを消費する可能性があるため、StorageGRID の処理に影響を及ぼす場合があります。
|
次の例は、からの一般的な出力を示しています audit-sum ツール。この例は、プロトコル処理に要した時間を示しています。
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 ツールは、監査ログ内の次のS3、Swift、およびILM監査メッセージの数と時間を取得します。
| コード | 説明 | を参照してください |
|---|---|---|
ARCT |
アーカイブをクラウド階層から取得します |
|
▽ SCT 。△ |
アーカイブストア - クラウド階層 |
|
IDEL |
ILM Initiated Delete ： ILM がオブジェクトを削除する処理を開始すると記録されます。 |
|
SDEL |
S3 DELETE ：オブジェクトまたはバケットを削除するトランザクションの成功をログに記録します。 |
|
SGET |
S3 GET ：バケット内のオブジェクトを読み出しまたはリストアップするトランザクションの成功をログに記録します。 |
|
Shea |
S3 HEAD ：オブジェクトまたはバケットの存在を確認するトランザクションの成功をログに記録します。 |
|
SPUT |
S3 PUT ：オブジェクトまたはバケットを新規に作成するトランザクションの成功をログに記録します。 |
|
WDEL |
Swift DELETE ：オブジェクトまたはコンテナを削除するトランザクションの成功をログに記録します。 |
|
wget |
Swift GET ：コンテナ内のオブジェクトを読み出しまたはリストアップするトランザクションの成功をログに記録します。 |
|
WHEA |
Swift HEAD ：オブジェクトまたはコンテナの存在を確認するトランザクションの成功をログに記録します。 |
|
WPUT |
Swift PUT ：オブジェクトまたはコンテナを新規に作成するトランザクションの成功をログに記録します。 |
。 audit-sum ツールは、プレーン形式または圧縮形式の監査ログを処理できます。例：
audit-sum audit.log
audit-sum 2019-08-12.txt.gz
。 audit-sum ツールは、複数のファイルを一度に処理することもできます。例：
audit-sum audit.log 2019-08-12.txt.gz 2019-08-13.txt.gz
audit-sum /var/local/audit/export/*
最後に、 audit-sum ツールは、パイプからの入力を受け入れることもできます。これにより、を使用して、入力をフィルタ処理および前処理できます grep コマンドまたはその他の手段。例：
grep WGET audit.log | audit-sum
grep bucket1 audit.log | audit-sum
grep SPUT audit.log | grep bucket1 | audit-sum
|
このツールは、圧縮ファイルをパイプ付き入力として受け入れません。圧縮ファイルを処理するには、ファイル名をコマンドライン引数として指定するか、を使用します zcat 最初にファイルを解凍するツール。例：
|
audit-sum audit.log.gz
zcat audit.log.gz | audit-sum
コマンドラインオプションを使用して、バケットに対する処理をオブジェクトに対する処理とは別にまとめたり、メッセージの概要をバケット名、期間、ターゲットタイプ別にグループ化したりできます。デフォルトでは、概要には最小、最大、平均の処理時間が表示されますが、を使用することもできます size (-s) オブジェクトサイズを表示するオプションです。
を使用します help (-h) 使用可能なオプションを表示するためのオプション。例：
$ audit-sum -h
-
プライマリ管理ノードにログインします。
-
次のコマンドを入力します。
ssh admin@primary_Admin_Node_IP -
に記載されているパスワードを入力します
Passwords.txtファイル。
-
-
書き込み、読み取り、 HEAD 、削除の処理に関連するすべてのメッセージを分析するには、次の手順を実行します。
-
次のコマンドを入力します
/var/local/audit/export/audit.log分析するファイルの名前と場所を表します。$ audit-sum /var/local/audit/export/audit.log
次の例は、からの一般的な出力を示しています
audit-sumツール。この例は、プロトコル処理に要した時間を示しています。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
この例では、平均処理時間では SGET （ S3 GET ）処理が 1.13 秒と最も長い一方で、最大処理時間では SGET 処理と SPUT （ S3 PUT ）処理がどちらも約 1 、 770 秒と一番長くなっています。
-
最も時間がかかった読み出し処理を10件表示するには、grepコマンドを使用してSGETメッセージのみを選択し、long出力オプションを追加します (
-l）オブジェクトパスを含めるには：grep SGET audit.log | audit-sum -l結果にはタイプ（オブジェクトまたはバケット）とパスが含まれます。この情報を使用して、監査ログを grep してこれらのオブジェクトに関連する他のメッセージを出力できます。
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+ この出力例からは、最も時間がかかった 3 個の S3 GET 要求が、他のオブジェクトよりもはるかに大きい約 5GB のオブジェクトに対して実行されたことがわかります。サイズが大きいと、最悪の場合の読み出し時間が長くなります。
-
-
グリッドに取り込まれているオブジェクトとグリッドから読み出されているオブジェクトのサイズを特定するには、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
この例では、 SPUT の平均オブジェクトサイズは 2.5MB 未満ですが、 SGET の平均サイズははるかに大きいことがわかります。SPUT メッセージの数は SGET メッセージの数よりもはるかに多く、ほとんどのオブジェクトが読み出されていないことを示しています。
-
昨日の読み出しに時間がかかっていないかどうかを確認するには、次の手順を実行
-
該当する監査ログに対してコマンドを問題 処理し、group-by-timeオプションを使用します (
-gt）に続けて期間（例：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
上記の結果は、 06 ： 00 と 07 ： 00 の間に S3 GET トラフィックが急増したことを示しています。この時間帯は最大時間と平均時間も大幅に長くなっており、データの増加に伴って徐々に長くなっているわけではありません。このことから、ネットワークまたはグリッドによる要求の処理能力のどこかでキャパシティを超えた可能性があります。
-
どのサイズのオブジェクトが前日に読み出されていたかを1時間単位で確認するには、sizeオプションを追加します (
-s）をコマンドに追加します。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
この結果から、読み出しトラフィックの量が最大に達したときに、非常に大容量の読み出しが発生したことがわかります。
-
詳細を確認するには、を使用します
audit-explainその時間にすべてのSGET処理を確認するためのツール：grep 2019-09-05T06 audit.log | grep SGET | audit-explain | less
grepコマンドの出力が多くの行になると予想される場合は、を追加します
less監査ログファイルの内容を一度に1ページ（1画面）表示するコマンド。
-
-
バケットに対する SPUT 処理にオブジェクトに対する SPUT 処理よりも時間がかかっているかどうかを確認するには、次の手順を実行します。
-
最初にを使用します
-goオプション。オブジェクト処理とバケット処理でメッセージをグループ化します。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
上記の結果から、バケットに対する SPUT 処理とオブジェクトに対する SPUT 処理でパフォーマンス特性が異なることがわかります。
-
SPUT処理に最も時間がかかっているバケットを特定するには、を使用します
-gbオプション。バケットごとにメッセージをグループ化します。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
-
SPUTオブジェクトのサイズが最も大きいバケットを特定するには、両方を使用します
-gbおよび-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
-