audit-sumツールを使用してStorageGRID監査メッセージを要約する
変更を提案
PDF
`audit-sum`ツールを使用して、書き込み、読み取り、ヘッド、削除の監査メッセージをカウントし、各操作タイプの最小、最大、平均時間（またはサイズ）を確認できます。
-
"特定のアクセス権限"があります。
-
あなたは `Passwords.txt`ファイルを持っています。
-
プライマリ管理ノードのIPアドレスを把握している必要があります。
`audit-sum`ツールは、プライマリ管理ノードで使用でき、ログに記録された書き込み、読み取り、および削除操作の回数と、これらの操作にかかった時間を要約します。
|
The `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およびILM監査メッセージの件数と時刻を提供します。
|
|
監査コードは、機能が廃止されると、製品およびドキュメントから削除されます。ここに記載されていない監査コードが見つかった場合は、古い StorageGRID リリースについて、このトピックの以前のバージョンを確認してください。例えば、 "StorageGRID 11.8 監査合計ツールの使用"。 |
| Code | 説明 | 参照先 |
|---|---|---|
IDEL |
ILMによる削除開始：ILMがオブジェクトの削除プロセスを開始したときにログを記録します。 |
|
SDEL |
S3 DELETE：オブジェクトまたはバケットを削除するトランザクションが成功したことをログに記録します。 |
|
SGET |
S3 GET：オブジェクトを取得したり、バケット内のオブジェクトを一覧表示したりするトランザクションが成功したことをログに記録します。 |
|
SHEA |
S3 HEAD: オブジェクトまたはバケットの存在を確認するために、トランザクションが成功したことをログに記録します。 |
|
SPUT |
S3 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/audit/export/* -
パイプからの入力を受け付け、 `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としてログインすると、プロンプトが `$`から `#`に変わります。
-
-
書き込み、読み取り、ヘッド、削除操作に関連するすべてのメッセージを分析する場合は、次の手順に従ってください。
-
次のコマンドを入力してください。ここで、 `/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メッセージのみを選択し、長い出力オプション(
-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のサイズのオブジェクトに対するものであり、これは他のオブジェクトよりもはるかに大きいサイズです。データのサイズが大きいことが、最悪の場合のデータ取得時間の遅延の原因となっています。
-
-
グリッドに取り込まれるオブジェクトとグリッドから取り出されるオブジェクトのサイズを判定したい場合は、サイズオプション (
-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.5 MB未満ですが、SGETの平均サイズははるかに大きくなっています。SPUTメッセージの数はSGETメッセージの数よりもはるかに多く、これはほとんどのオブジェクトが取得されていないことを示しています。
-
昨日のデータ取得が遅かったかどうかを確認する場合は、次の手順に従ってください。
-
適切な監査ログでコマンドを実行し、時間によるグループ化オプション（(
-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トラフィックが午前6時から午前7時の間に急増したことを示しています。この期間中、最大時間と平均時間はどちらもかなり長くなっており、カウント数の増加に伴って徐々に増加したわけではありません。これらの指標は、ネットワークまたはグリッドのリクエスト処理能力において、容量が超過したことを示唆しています。
-
昨日、毎時間どのサイズのオブジェクトが取得されていたかを確認するには、サイズオプション (
-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オブジェクトサイズが最大となるものを特定するには、 `-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
-