audit-sum ツールを使用します
変更を提案
PDF
ツールを使用して、書き込み、読み取り、HEAD、および削除の監査メッセージをカウントし、各処理タイプの最小、最大、平均時間（またはサイズ）を確認できます audit-sum。
-
そうだな "特定のアクセス権限"
-
ファイルが必要 `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監査メッセージの数と時間を提供します。
|
|
機能が廃止されたため、製品やドキュメントから監査コードが削除されました。ここに記載されていない監査コードが発生した場合は、古いSGリリースについてこのトピックの以前のバージョンを確認してください。たとえば、 "StorageGRID 11.8オーディットサムツールドキュメントを使用"です。 |
| コード | 製品説明 | を参照してください |
|---|---|---|
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.logaudit-sum 2019-08-12.txt.gz -
複数のファイルを同時に処理します。例：
audit-sum audit.log 2019-08-12.txt.gz 2019-08-13.txt.gzaudit-sum /var/local/log/* -
パイプからの入力を受け入れます。これにより、コマンドまたはその他の方法を使用して入力をフィルタリングおよび前処理 `grep`できます。例：
grep WGET audit.log | audit-sumgrep bucket1 audit.log | audit-sumgrep SPUT audit.log | grep bucket1 | audit-sum
|
|
このツールは、圧縮ファイルをパイプ付き入力として受け入れません。圧縮ファイルを処理するには、コマンドライン引数としてファイル名を指定するか、ツールを使用し `zcat`て最初にファイルを解凍します。例：
|
コマンドラインオプションを使用して、バケットに対する処理をオブジェクトに対する処理とは別にまとめたり、メッセージの概要をバケット名、期間、ターゲットタイプ別にグループ化したりできます。デフォルトでは、要約には最小処理時間、最大処理時間、平均処理時間が表示されますが、オプションを使用してオブジェクトサイズを確認することもできます size (-s)。
使用可能なオプションを表示するには、オプションを使用し `help (-h)`ます。例：
$ audit-sum -h
-
プライマリ管理ノードにログインします。
-
次のコマンドを入力します。
ssh admin@primary_Admin_Node_IP -
ファイルに記載されているパスワードを入力し `Passwords.txt`ます。
-
次のコマンドを入力してrootに切り替えます。
su - -
ファイルに記載されているパスワードを入力し `Passwords.txt`ます。
rootとしてログインすると、プロンプトがからに
#`変わります `$。
-
-
書き込み、読み取り、 HEAD 、削除の処理に関連するすべてのメッセージを分析するには、次の手順を実行します。
-
次のコマンドを入力します。 `/var/local/log/audit.log`は、分析するファイルの名前と場所を示します。
$ audit-sum /var/local/log/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.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
この例では、 SPUT の平均オブジェクトサイズは 2.5MB 未満ですが、 SGET の平均サイズははるかに大きいことがわかります。SPUT メッセージの数は SGET メッセージの数よりもはるかに多く、ほとんどのオブジェクトが読み出されていないことを示しています。
-
昨日の読み出しに時間がかかっていないかどうかを確認するには、次の手順を実行
-
該当する監査ログでコマンドを実行し、group-by-timeオプションを使用し(`-gt`ます。そのあとに期間（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
これらの結果は、S3 GETトラフィックが06：00~07：00の間に急増したことを示しています。この時間帯は最大時間と平均時間も大幅に長くなっており、データの増加に伴って徐々に長くなっているわけではありません。このことから、ネットワークまたはグリッドによる要求の処理能力のどこかでキャパシティを超えた可能性があります。
-
昨日読み出されたオブジェクトのサイズを1時間ごとに確認するには、sizeオプションを追加し(`-s`ます）。
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
この結果から、読み出しトラフィックの量が最大に達したときに、非常に大容量の読み出しが発生したことがわかります。
-
詳細を確認するには、を使用し"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 -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
上記の結果から、バケットに対する SPUT 処理とオブジェクトに対する SPUT 処理でパフォーマンス特性が異なることがわかります。
-
SPUT処理に最も時間がかかっているバケットを特定するには、オプションを使用し `-gb`ます。このオプションはバケットごとにメッセージをグループ化します。
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
-
SPUTオブジェクトサイズが最も大きいバケットを確認するには、オプションと `-s`オプションの両方を使用し `-gb`ます。
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
-