StorageGRIDでログ管理を構成する
変更を提案
PDF
必要に応じて、監査レベル、プロトコルヘッダー、監査メッセージおよびログの保存場所を設定します。
すべての StorageGRID ノードは、システムアクティビティとイベントを追跡するために監査メッセージとログを生成します。監査メッセージとログは、監視とトラブルシューティングに不可欠なツールです。
オプションで、"外部syslogサーバを設定する"監査情報をリモートで保存できます。外部サーバーを使用することで、監査データの完全性を損なうことなく、監査メッセージのログ記録によるパフォーマンスへの影響を最小限に抑えることができます。外部 syslog サーバーは、大規模なグリッドを使用している場合、複数の種類の S3 アプリケーションを使用している場合、またはすべての監査データを保持したい場合に特に役立ちます。
-
"対応ウェブブラウザ" を使用して Grid Manager にサインインしています。
-
あなたは"メンテナンス権限またはルートアクセス権限"があります。
-
外部 syslog サーバーを設定する予定がある場合は、"外部syslogサーバを使用する際の考慮事項"を確認し、手順に従っている必要があります。
-
TLS または RELP/TLS プロトコルを使用して外部 syslog サーバーを設定する予定がある場合は、必要なサーバー CA 証明書とクライアント証明書、およびクライアント秘密鍵が必要です。
監査メッセージレベルを変更する
監査ログ内の以下のメッセージカテゴリごとに、異なる監査レベルを設定できます。
| 監査カテゴリ | デフォルトの設定 | 詳細情報 |
|---|---|---|
システム |
平常時 |
|
ストレージ |
エラー |
|
管理 |
平常時 |
|
クライアント読み取り |
平常時 |
|
クライアントの書き込み |
平常時 |
|
ILM |
平常時 |
|
クロスグリッド複製 |
エラー |
|
アップグレード中は、監査レベルの設定はすぐには有効になりません。 |
-
Configuration > Monitoring > Log management を選択します。
-
監査メッセージのカテゴリごとに、ドロップダウンリストから監査レベルを選択します。
監査レベル 説明 消灯
このカテゴリからの監査メッセージはログに記録されません。
エラー
エラーメッセージのみがログに記録されます。結果コードが「成功」（SUCS）ではなかった監査メッセージです。
平常時
標準的なトランザクションメッセージがログに記録されます。これは、このカテゴリの手順に記載されているメッセージです。
デバッグ
非推奨です。このレベルは、通常の監査レベルと同じように動作します。
特定のレベルに含まれるメッセージには、より上位のレベルでログに記録されるメッセージも含まれます。例えば、Normal レベルにはすべての Error メッセージが含まれます。
S3 アプリケーションのクライアント読み取り操作の詳細な記録が必要ない場合は、必要に応じて Client Reads 設定を Error に変更して、監査ログに記録される監査メッセージの数を減らすことができます。 -
* 保存 * を選択します。
HTTPリクエストヘッダーを定義する
クライアントの読み取りおよび書き込み監査メッセージに含めたいHTTPリクエストヘッダーを、オプションで定義できます。
-
*監査プロトコルヘッダー*セクションで、クライアントの読み取りおよび書き込み監査メッセージに含めるHTTPリクエストヘッダーを定義します。
0個以上の文字に一致させるには、アスタリスク（*）をワイルドカードとして使用します。リテラルのアスタリスクに一致させるには、エスケープシーケンス（\*）を使用します。
-
必要に応じて、*別のヘッダーを追加*を選択して、追加のヘッダーを作成します。
リクエストにHTTPヘッダーが含まれている場合、それらは監査メッセージのHTRHフィールドに含まれます。
監査プロトコルのリクエストヘッダーは、*クライアント読み取り*または*クライアント書き込み*の監査レベルが*オフ*でない場合にのみログに記録されます。 -
*保存*を選択します
ログの保存場所を設定する
デフォルトでは、監査メッセージとログは、それらが生成されたノードに保存されます。ディスク容量を過剰に消費しないように、定期的にローテーションされ、最終的には削除されます。監査メッセージとログの一部を外部に保存したい場合は、外部syslogサーバを使用する。
ログファイルを内部的に保存する場合は、ログストレージ用のテナントとバケットを選択し、ログアーカイブを有効にしてください。
外部のsyslogサーバーを使用する
外部 syslog サーバーをオプションで設定することで、監査ログ、アプリケーションログ、セキュリティイベントログをグリッド外の場所に保存できます。
|
|
外部syslogサーバーを使用しない場合は、この手順をスキップして、ログの保存場所を選択に進んでください。 |
|
この手順で利用可能な構成オプションが要件を満たすのに十分な柔軟性を備えていない場合は、 `audit-destinations`エンドポイントを使用して追加の構成オプションを適用できます。これらのエンドポイントは、"グリッド管理API"のプライベート API セクションにあります。たとえば、異なるノードグループに異なる syslog サーバーを使用する場合は、API を使用できます。 |
syslog情報を入力する
外部 syslog サーバーの設定ウィザードにアクセスし、StorageGRID が外部 syslog サーバーにアクセスするために必要な情報を入力します。
-
「ローカルノードと外部サーバー」タブから、「外部 syslog サーバーの設定」を選択します。または、以前に外部 syslog サーバーを設定していた場合は、「外部 syslog サーバーの編集」を選択します。
外部 syslog サーバーの設定ウィザードが表示されます。
-
ウィザードの Enter syslog info の手順で、Host フィールドに外部 syslog サーバーの有効な完全修飾ドメイン名または IPv4 アドレスもしくは IPv6 アドレスを入力します。
-
外部 syslog サーバーの宛先ポートを入力してください（1～65535 の整数である必要があります）。デフォルトのポート番号は 514 です。
-
監査情報を外部 syslog サーバに送信するために使用するプロトコルを選択してください。
TLS または RELP/TLS の使用を推奨します。これらのオプションのいずれかを使用するには、サーバー証明書をアップロードする必要があります。証明書を使用することで、グリッドと外部 syslog サーバー間の接続を安全に保つことができます。詳細については、"セキュリティ証明書を管理する" を参照してください。
すべてのプロトコルオプションは、外部 syslog サーバーによるサポートと設定が必要です。外部 syslog サーバーと互換性のあるオプションを選択する必要があります。
Reliable Event Logging Protocol （RELP） は、syslog プロトコルの機能を拡張して、イベントメッセージの確実な配信を実現します。RELP を使用すると、外部の syslog サーバーを再起動する必要がある場合に、監査情報の損失を防ぐことができます。 -
*続行*を選択します。
-
TLS または RELP/TLS を選択した場合は、サーバー CA 証明書、クライアント証明書、およびクライアント秘密鍵をアップロードしてください。
-
使用する証明書またはキーの 参照 を選択してください。
-
証明書またはキーファイルを選択してください。
-
ファイルをアップロードするには、*開く*を選択してください。
証明書またはキーファイル名の横に緑色のチェックマークが表示され、アップロードが正常に完了したことを知らせます。
-
-
*続行*を選択します。
syslogコンテンツの管理
外部 syslog サーバに送信する情報を選択できます。
-
ウィザードの「syslogコンテンツの管理」ステップで、外部syslogサーバに送信する監査情報の種類をそれぞれ選択します。
-
監査ログを送信：StorageGRID のイベントとシステムアクティビティを送信します
-
セキュリティイベントの送信：不正なユーザーがサインインしようとしたときや、ユーザーがrootとしてサインインしたときなどのセキュリティイベントを送信します。
-
アプリケーションログの送信：トラブルシューティングに役立つ"StorageGRIDソフトウェアログファイル"を送信します。内容は以下のとおりです：
-
bycast-err.log -
bycast.log -
jaeger.log -
nms.log（管理ノードのみ） -
prometheus.log -
raft.log -
hagroups.log
-
-
アクセスログの送信：リモートシステムからの Grid Manager、Tenant Manager、設定済みロードバランサーエンドポイント、およびグリッドフェデレーション要求に対する外部リクエストの HTTP アクセスログを送信します。
-
-
ドロップダウンメニューを使用して、送信する監査情報の各カテゴリについて、重大度とファシリティ（メッセージの種類）を選択してください。
重要度とファシリティの値を設定することで、ログをカスタマイズ可能な方法で集計し、分析を容易にすることができます。
-
Severity については、Passthrough を選択するか、0～7の間の重要度値を選択してください。
値を選択すると、選択した値がこのタイプのすべてのメッセージに適用されます。重要度を固定値で上書きすると、さまざまな重要度に関する情報が失われます。
重大度 説明 パススルー
外部 syslog に送信される各メッセージが、ノードにローカルでログ記録されたときと同じ重大度値を持つようにします。
-
監査ログの場合、重要度は「info」です。
-
セキュリティイベントの場合、重大度の値はノード上の Linux ディストリビューションによって生成されます。
-
アプリケーションログの場合、問題の内容に応じて、重要度は「info」から「notice」まで変化します。例えば、NTPサーバーを追加してHAグループを設定すると「info」という値が表示されますが、SSMまたはRSMサービスを意図的に停止すると「notice」という値が表示されます。
-
アクセスログの場合、重要度は「info」です。
0
緊急事態：システムが使用不能です
1
警告：直ちに行動を起こす必要があります
2
Critical：重大な状態
3
エラー：エラー条件
4
警告：警告条件
5
注意：正常だが重要な状態
6
情報提供：情報メッセージ
7
デバッグ: デバッグレベルのメッセージ
-
-
Facilty については、Passthrough を選択するか、0～23の間の設備値を選択してください。
値を選択すると、その値はこのタイプのすべてのメッセージに適用されます。施設情報を固定値で上書きすると、さまざまな施設に関する情報が失われます。
ファシリティ 説明 パススルー
外部 syslog に送信される各メッセージが、ノードにローカルでログ記録されたときと同じファシリティ値を持つようにします：
-
監査ログの場合、外部 syslog サーバーに送信されるファシリティは「local7」です。
-
セキュリティイベントの場合、ファシリティ値はノード上のLinuxディストリビューションによって生成されます。
-
アプリケーションログの場合、外部 syslog サーバーに送信されるアプリケーションログには、以下のファシリティ値があります：
-
bycast.log：ユーザーまたはデーモン -
bycast-err.log：ユーザー、デーモン、local3、またはlocal4 -
jaeger.log： local2 -
nms.log： local3 -
prometheus.log： local4 -
raft.log： local5 -
hagroups.log： local6
-
-
アクセスログの場合、外部 syslog サーバーに送信されるファシリティは「local0」です。
0
kern（カーネルメッセージ）
1
ユーザー（ユーザーレベルのメッセージ）
2
メール
3
デーモン（システムデーモン）
4
auth （セキュリティ／認証メッセージ）
5
syslog （syslogd によって内部的に生成されたメッセージ）
6
lpr（ラインプリンタサブシステム）
7
ニュース（ネットワークニュースサブシステム）
8
UUCP
9
cron （クロックデーモン）
10
セキュリティ（セキュリティ／認証メッセージ）
11
FTP
12
NTP
13
logaudit（ログ監査）
14
logalert（ログアラート）
15
clock （clock デーモン）
16
local0を使用したチャンク アップロード署名要求がサポートされるようになりました。
17
local1を使用したチャンク アップロード署名要求がサポートされるようになりました。
18
local2を使用したチャンク アップロード署名要求がサポートされるようになりました。
19
local3を使用したチャンク アップロード署名要求がサポートされるようになりました。
20
local4を使用したチャンク アップロード署名要求がサポートされるようになりました。
21
local5
22
local6を使用したチャンク アップロード署名要求がサポートされるようになりました。
23
local7を使用したチャンク アップロード署名要求がサポートされるようになりました。
-
-
*続行*を選択します。
テストメッセージを送信する
外部 syslog サーバーの使用を開始する前に、グリッド内のすべてのノードが外部 syslog サーバーにテストメッセージを送信するよう要求する必要があります。外部 syslog サーバーにデータを送信する前に、これらのテストメッセージを使用してログ収集インフラストラクチャ全体を検証する必要があります。
|
外部 syslog サーバーの設定は、外部 syslog サーバーがグリッド内の各ノードからテストメッセージを受信し、そのメッセージが想定どおりに処理されたことを確認するまで使用しないでください。 |
-
テストメッセージを送信しない場合（外部の syslog サーバーが正しく設定されており、グリッド内のすべてのノードから監査情報を受信できることが確実な場合）は、スキップして完了 を選択してください。
緑色のバナーは、設定が保存されたことを示します。
-
それ以外の場合は、テストメッセージを送信する（推奨）を選択します。
テスト結果は、テストを停止するまでページに表示され続けます。テストの実施中も、監査メッセージは以前に設定した宛先に引き続き送信されます。
-
syslog サーバーの設定中または実行時にエラーが発生した場合は、エラーを修正してから、テストメッセージを送信 を再度選択してください。
エラーの解決に役立てるには、"外部 syslog サーバのトラブルシューティング"を参照してください。
-
すべてのノードがテストに合格したことを示す緑色のバナーが表示されるまでお待ちください。
-
syslog サーバーを確認し、テストメッセージが想定どおりに受信および処理されているかどうかを確認してください。
UDPを使用している場合は、ログ収集インフラストラクチャ全体を確認してください。UDPプロトコルは、他のプロトコルほど厳密なエラー検出ができません。 -
「停止して終了」を選択します。
*監査とsyslogサーバー*ページに戻ります。緑色のバナーは、syslogサーバーの設定が保存されたことを示します。
StorageGRID の監査情報は、外部 syslog サーバーを含む宛先を選択するまで、外部 syslog サーバーに送信されません。
ログの保存場所を選択
監査ログ、セキュリティイベントログ、"StorageGRIDアプリケーションログ"、およびアクセスログの送信先を指定できます。
|
|
StorageGRID はデフォルトでローカルノードの監査先を使用し、監査情報を `/var/local/log/localaudit.log`に保存します。 `/var/local/log/localaudit.log`を使用する場合、Grid Manager と Tenant Manager の監査ログエントリがストレージノードに送信される可能性があります。最新のエントリを持つノードを確認するには、 `run-each-node --parallel "zgrep MGAU /var/local/log/localaudit.log | tail"`コマンドを使用します。 外部 syslog サーバを設定した場合にのみ利用できる宛先もあります。 |
-
ログの場所 ＞ ローカルノードと外部サーバー を選択します。
-
ログの種類ごとにログの保存場所を変更するには、別のオプションを選択してください。
*ローカルノードのみ*および*外部 syslog サーバー*は通常、より優れたパフォーマンスを提供します。 オプション 説明 ローカルノードのみ（デフォルト）
監査メッセージ、セキュリティイベントログ、およびアプリケーションログは、管理ノードには送信されません。その代わりに、それらは生成したノード（「ローカルノード」）にのみ保存されます。各ローカルノードで生成された監査情報は、 `/var/local/log/localaudit.log`に保存されます。
注記：StorageGRID は定期的にローテーションでローカルログを削除し、空き容量を確保します。ノードのログファイルが 1 GB に達すると、既存のファイルが保存され、新しいログファイルが作成されます。ログファイルのローテーション制限は 21 ファイルです。ログファイルの 22 番目のバージョンが作成されると、最も古いログファイルが削除されます。平均して、各ノードには約 20 GB のログデータが保存されます。ログを長期間保存するには、ログの保存にはテナントとバケットを使用する。
管理者ノード／ローカルノード
監査メッセージは管理ノードの監査ログに送信され、セキュリティイベントログとアプリケーションログは、それらを生成したノードに保存されます。監査情報は以下のファイルに保存されます：
-
管理ノード（プライマリおよび非プライマリ）：
/var/local/audit/export/audit.log -
すべてのノード： `/var/local/log/localaudit.log`ファイルは通常、空であるか存在しません。一部のメッセージの追加コピーなど、二次的な情報が含まれている場合があります。
外部のsyslogサーバ
監査情報は外部 syslog サーバーに送信され、ローカルノードにも保存されます(
/var/local/log/localaudit.log）。送信される情報の種類は、外部 syslog サーバーの設定方法によって異なります。このオプションは、外部syslogサーバを設定しました 後にのみ有効になります。管理ノードと外部syslogサーバ
監査メッセージは監査ログ（(
/var/local/audit/export/audit.log）に送信され、管理ノード上で監査情報が外部 syslog サーバーに送信されてローカルノード（(/var/local/log/localaudit.log）に保存されます。送信される情報の種類は、外部 syslog サーバーの設定方法によって異なります。このオプションは、外部syslogサーバを設定しました を設定した後にのみ有効になります。 -
-
* 保存 * を選択します。
警告メッセージが表示されます。
-
監査情報の送信先を変更することを確認するには、OK を選択してください。
新しいログは、お客様が選択した宛先に送信されます。既存のログファイルは現在の場所にそのまま残ります。
バケットを使用する
ログは定期的にローテーションされます。同じグリッド内の S3 バケットを使用して、ログを長期間保存します。
-
「ログの保存場所」>「バケットを使用する」を選択します。
-
「アーカイブログを有効にする」チェックボックスを選択します。
-
表示されているテナントとバケットが使用したいものでない場合は、*テナントとバケットの変更*を選択し、次に*テナントとバケットの作成*または*テナントとバケットの選択*を選択してください。
テナントとバケットを作成する-
新しいテナント名を入力してください。
-
新しいテナントのパスワードを入力して確認してください。
-
新しいバケット名を入力してください。
-
「作成して有効化」を選択します。
テナントとバケットを選択-
プルダウンメニューからテナント名を選択してください。
-
プルダウンメニューからバケットを選択してください。
-
「選択して有効にする」を選択します。
-
-
* 保存 * を選択します。
ログは、お客様が指定したテナントとバケットに保存されます。ログのオブジェクトキー名は、次の形式です：
system-logs/{node_hostname}/{absolute_path_to_log_file_on_node}--{last_modified_time}.gz次に例を示します。
system-logs/DC1-SN1/var/local/log/localaudit.log--2025-05-12_13:41:44.gz