Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

ログ管理を構成する

共同作成者 netapp-lhalbert netapp-perveilerk netapp-pcarriga
PDF

必要に応じて、監査レベル、プロトコル ヘッダー、監査メッセージとログの場所を構成します。

すべてのStorageGRIDノードは、システム アクティビティとイベントを追跡するために監査メッセージとログを生成します。監査メッセージとログは、監視とトラブルシューティングに不可欠なツールです。

オプションとして、"外部syslogサーバーを設定する"監査情報をリモートで保存します。外部サーバーを使用すると、監査データの完全性を低下させることなく、監査メッセージのログ記録によるパフォーマンスへの影響を最小限に抑えることができます。外部 syslog サーバーは、大規模なグリッドがある場合、複数の種類の S3 アプリケーションを使用する場合、またはすべての監査データを保持する場合に特に便利です。

開始する前に

監査メッセージレベルの変更

監査ログでは、次のカテゴリのメッセージごとに異なる監査レベルを設定できます。

監査カテゴリ デフォルト設定 詳細情報

システム

標準

"システム監査メッセージ"

ストレージ

エラー

"オブジェクトストレージ監査メッセージ"

管理

標準

"管理監査メッセージ"

クライアント読み取り

標準

"クライアント読み取り監査メッセージ"

クライアントからの書き込み

標準

"クライアント書き込み監査メッセージ"

ILM

標準

"ILM監査メッセージ"

グリッド間レプリケーション

エラー

"CGRR：クロスグリッドレプリケーション要求"
メモ アップグレード中は、監査レベルの構成はすぐには有効になりません。
手順

  1. 構成 > 監視 > *ログ管理*を選択します。

  2. 監査メッセージのカテゴリごとに、ドロップダウンリストから監査レベルを選択します。

    監査レベル 製品説明

    オフ

    このカテゴリの監査メッセージはログに記録されません。

    エラー

    エラー メッセージ (結果コードが「成功」(SUCS) ではなかった監査メッセージ) のみがログに記録されます。

    標準

    標準のトランザクション・メッセージはログに記録されますこのメッセージは ' カテゴリに関する次の手順に記載されています

    デバッグ

    非推奨です。このレベルの動作は Normal 監査レベルと同じです。

    特定のレベルに含まれるメッセージには、上位レベルでロギングされるメッセージも含まれます。たとえば、 Normal レベルには Error レベルのメッセージがすべて含まれます。

    メモ S3 アプリケーションのクライアント読み取り操作の詳細な記録が必要ない場合は、オプションで クライアント読み取り 設定を エラー に変更して、監査ログに記録される監査メッセージの数を減らします。

  3. [ 保存（ Save ） ] を選択します。

HTTP要求ヘッダーの定義

オプションで、クライアントの読み取りおよび書き込み監査メッセージに含める HTTP 要求ヘッダーを定義できます。

手順

  1. [Audit protocol headers]セクションで、クライアントの読み取り/書き込み監査メッセージに含めるHTTP要求ヘッダーを定義します。

    0 個以上の文字に一致させるには、ワイルドカードとしてアスタリスク（ \* ）を使用します。リテラルアスタリスクに一致させるには、エスケープシーケンス（ \ * ）を使用します。

  2. 必要に応じて、「 * 別のヘッダーを追加」を選択して追加のヘッダーを作成します。

    要求に HTTP ヘッダーが含まれている場合、 HTTP ヘッダーは HTRH フィールドの下の監査メッセージに含まれます。

    メモ 監査プロトコル要求ヘッダーは、*クライアント読み取り*または*クライアント書き込み*の監査レベルが*オフ*でない場合にのみログに記録されます。

  3. [ 保存（ Save ） ] を選択します

ログの場所を設定する

デフォルトでは、監査メッセージとログは、生成されたノードに保存されます。ディスク領域を過剰に消費しないように、定期的にローテーションされ、最終的には削除されます。監査メッセージとログのサブセットを外部に保存する場合は、外部のsyslogサーバーを使用する 。

ログ ファイルを内部に保存する場合は、ログ ストレージ用のテナントとバケットを選択し、ログ アーカイブを有効にします。

[use-external-syslog-server]]外部syslogサーバを使用する

必要に応じて、監査ログ、アプリケーションログ、およびセキュリティイベントログをグリッドの外部の場所に保存するように外部のsyslogサーバを設定できます。

メモ 外部のSyslogサーバーを使用しない場合は、この手順をスキップして、ログの場所を選択 。
ヒント この手順で使用できる構成オプションが要件を満たすほど柔軟性がない場合は、のプライベートAPIセクションにあるエンドポイントを使用して追加の構成オプションを適用できます audit-destinations。"Grid 管理 API"たとえば、ノードのグループごとに異なるsyslogサーバを使用する場合は、APIを使用できます。

syslog情報の入力

外部syslogサーバの設定ウィザードにアクセスし、StorageGRIDが外部syslogサーバにアクセスするために必要な情報を入力します。

手順

  1. [ローカル ノードと外部サーバー] タブから、[外部 Syslog サーバーの構成] を選択します。または、以前に外部 Syslog サーバーを設定している場合は、[外部 Syslog サーバーの編集] を選択します。

    Configure external syslog serverウィザードが表示されます。

  2. ウィザードの* syslog情報の入力*ステップで、* Host *フィールドに外部syslogサーバの有効な完全修飾ドメイン名またはIPv4またはIPv6アドレスを入力します。

  3. 外部 syslog サーバのデスティネーションポートを入力します（ 1~65535 の整数で指定する必要があります）。デフォルトのポートは514です。

  4. 外部 syslog サーバへの監査情報の送信に使用するプロトコルを選択します。

    TLS または RELP/TLS *を使用することを推奨します。これらのいずれかのオプションを使用するには、サーバ証明書をアップロードする必要があります。証明書を使用して、グリッドと外部 syslog サーバの間の接続を保護できます。詳細については、を参照してください "セキュリティ証明書を管理する"。

    すべてのプロトコルオプションで、外部 syslog サーバによるサポートおよび設定が必要です。外部 syslog サーバと互換性のあるオプションを選択する必要があります。

    メモ Reliable Event Logging Protocol (RELP) は、 syslog プロトコルの機能を拡張し、信頼性の高いイベントメッセージ配信を実現します。RELP を使用すると、外部 syslog サーバを再起動する必要がある場合に監査情報が失われないようにすることができます。

  5. 「 * Continue * 」を選択します。

  6. [[attach-certificate]* TLS または RELP/TLS *を選択した場合は、サーバCA証明書、クライアント証明書、およびクライアント秘密鍵をアップロードします。

    1. 使用する証明書またはキーの [* 参照 ] を選択します。

    2. 証明書またはキーファイルを選択します。

    3. ファイルをアップロードするには、 * 開く * を選択します。

      証明書またはキーファイル名の横に緑のチェックマークが表示され、正常にアップロードされたことを通知します。

  7. 「 * Continue * 」を選択します。

syslog の内容を管理します

外部syslogサーバに送信する情報を選択できます。

手順

  1. ウィザードの* syslogコンテンツの管理*ステップで、外部syslogサーバに送信する監査情報の種類をそれぞれ選択します。

    • 監査ログの送信：StorageGRID イベントとシステムアクティビティを送信します

    • セキュリティイベントの送信:許可されていないユーザーがサインインしようとしたときや、ユーザーがrootとしてサインインしようとしたときなど、セキュリティイベントを送信します

    • アプリケーションログを送信：次のようなトラブルシューティングに役立つ情報を送信します"StorageGRIDソフトウェアのログファイル"。

      • bycast-err.log

      • bycast.log

      • jaeger.log

      • nms.log（管理ノードのみ）

      • prometheus.log

      • raft.log

      • hagroups.log

    • アクセスログを送信：外部要求に対するHTTPアクセスログをGrid Manager、Tenant Manger、設定されているロードバランサエンドポイント、およびリモートシステムからのグリッドフェデレーション要求に送信します。

  2. ドロップダウンメニューを使用して、送信する監査情報のカテゴリごとに重大度とファシリティ（メッセージのタイプ）を選択します。

    重大度とファシリティの値を設定すると、ログをカスタマイズ可能な方法で集約して分析を容易にすることができます。

    1. では、[Passthrough]*を選択するか、重大度値を0~7で選択します。

      値を選択すると、選択した値がこのタイプのすべてのメッセージに適用されます。固定値で重大度を上書きすると、異なる重大度に関する情報が失われます。

      重大度 製品説明

      パススルー

      外部syslogに送信される各メッセージの重大度は、ノードにローカルにログインしたときと同じになります。

      • 監査ログの場合、重大度は「info」です。

      • セキュリティイベントの場合、重大度の値はノード上のLinuxディストリビューションによって生成されます。

      • アプリケーションログの重大度は、問題の内容に応じて「info」と「notice」の間で異なります。たとえば、NTPサーバを追加してHAグループを設定すると値が「info」になり、SSMサービスまたはRSMサービスを意図的に停止すると値が「notice」になります。

      • アクセスログの場合、重大度は「info」です。

      0

      EMERGENCY ：システムが使用できない

      1

      ALERT ：早急に対処が必要です

      2

      Critical ：クリティカルな状態です

      3

      Error ：エラー状態

      4

      Warning ：警告状態です

      5

      通知：通常の状態だが重要な状態

      6

      INFORMATIONAL ：情報メッセージです

      7

      DEBUG ：デバッグレベルのメッセージ

    2. *Facilty*では、*Passthrough*を選択するか、0～23のファシリティ値を選択します。

      値を選択すると、このタイプのすべてのメッセージに適用されます。固定値でファシリティを上書きすると、さまざまなファシリティに関する情報が失われます。

    ファシリティ 製品説明

    パススルー

    外部syslogに送信される各メッセージのファシリティ値は、ノードにローカルにログインしたときと同じです。

    • 監査ログの場合、外部syslogサーバに送信されるファシリティは「local7」です。

    • セキュリティイベントの場合、ファシリティ値はノード上のLinuxディストリビューションによって生成されます。

    • アプリケーションログの場合、外部syslogサーバに送信されるアプリケーションログのファシリティ値は次のとおりです。

      • bycast.log:ユーザーまたはデーモン

      • bycast-err.log：user、daemon、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

    News （ネットワークニュースサブシステム）

    8

    UUCP

    9

    cron クロックデーモン

    10

    セキュリティ（セキュリティ / 認可メッセージ）

    11

    FTP

    12

    NTP

    13

    logaudit （ログ監査）

    14

    logalert （ログアラート）

    15

    clock （ clock デーモン）

    16

    ローカル0

    17

    local1

    18

    local2

    19

    local3

    20

    local4

    21

    local5

    22

    local6

    23

    local7

  3. 「 * Continue * 」を選択します。

テストメッセージを送信します

外部 syslog サーバの使用を開始する前に、グリッド内のすべてのノードが外部 syslog サーバにテストメッセージを送信するように要求する必要があります。外部 syslog サーバへのデータ送信にコミットする前に、これらのテストメッセージを使用してログ収集インフラ全体を検証する必要があります。

注意 外部syslogサーバがグリッド内の各ノードからテストメッセージを受信し、メッセージが想定どおりに処理されたことを確認するまでは、外部syslogサーバの設定を使用しないでください。
手順

  1. 外部syslogサーバが適切に設定され、グリッド内のすべてのノードから監査情報を受信できることが確実であるためにテストメッセージを送信しない場合は、*[スキップして終了]*を選択します。

    緑色のバナーは、設定が保存されたことを示します。

  2. それ以外の場合は、テストメッセージを送信（推奨）を選択します。

    テスト結果は、テストを停止するまでページに継続的に表示されます。テストの実行中も、以前に設定した送信先に監査メッセージが引き続き送信されます。

  3. Syslog サーバーの構成中または実行時にエラーが発生した場合は、エラーを修正して、テスト メッセージの送信 を再度選択してください。

    エラーの解決方法については、を参照してください"外部 syslog サーバのトラブルシューティングを行います"。

  4. すべてのノードがテストに合格したことを示す緑のバナーが表示されるまで待ちます。

  5. syslog サーバを調べて、テストメッセージが正常に受信および処理されているかどうかを確認します。

    メモ UDP を使用している場合は、ログ収集インフラストラクチャ全体を確認してください。 UDP プロトコルでは、他のプロトコルほど厳密なエラー検出はできません。

  6. 「 * ストップ & フィニッシュ * 」を選択します。

    監査および syslog サーバ * ページに戻ります。緑色のバナーは、syslogサーバの設定が保存されたことを示します。

    メモ 外部 Syslog サーバを含む宛先を選択するまで、 StorageGRID監査情報は外部 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サーバを設定した場合にのみ使用できます。
手順

  1. ログの場所 > *ローカルノードと外部サーバー*を選択します。

  2. ログ タイプに応じてログの場所を変更するには、別のオプションを選択します。

    ヒント *ローカルノードのみ*および*外部syslogサーバ*の方が一般的にパフォーマンスが向上します。
    オプション 製品説明

    ローカルノードのみ（デフォルト）

    監査メッセージ、セキュリティ イベント ログ、アプリケーション ログは管理ノードに送信されません。代わりに、それらはそれを生成したノード (「ローカル ノード」) にのみ保存されます。各ローカルノードで生成された監査情報は、 /var/local/log/localaudit.log 。

    注: StorageGRID は、スペースを解放するために、定期的にローカル ログをローテーションで削除します。ノードのログ ファイルが 1 GB に達すると、既存のファイルが保存され、新しいログ ファイルが開始されます。ログのローテーション制限は 21 ファイルです。ログ ファイルの 22 番目のバージョンが作成されると、最も古いログ ファイルが削除されます。平均して、各ノードには約 20 GB のログ データが保存されます。ログを長期間保存するには、ログ保存にテナントとバケットを使用する 。

    管理ノード/ローカルノード

    監査メッセージは管理ノード上の監査ログに送信され、セキュリティイベントログとアプリケーションログはそれらを生成したノードに格納されます。監査情報は次のファイルに格納されます。

    • 管理ノード (プライマリおよび非プライマリ): /var/local/audit/export/audit.log

    • All nodes（すべてのノード）： `/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サーバーを設定しました 。

  3. [ 保存（ Save ） ] を選択します。

    警告メッセージが表示されます。

  4. [OK]*を選択して、監査情報の保存先を変更することを確認します。

    選択した送信先に新しいログが送信されます。既存のログは現在の場所に残ります。

バケットを使用する

ログは定期的にローテーションされます。同じグリッド内の S3 バケットを使用して、ログを長期間保存します。

  1. ログの場所 > *バケットの使用*を選択します。

  2. アーカイブ ログを有効にする チェックボックスを選択します。

  3. リストされているテナントとバケットが使用したいものでない場合は、[テナントとバケットの変更] を選択し、[テナントとバケットの作成] または [テナントとバケットの選択] を選択します。

    テナントとバケットを作成する

    1. 新しいテナント名を入力します。

    2. 新しいテナントのパスワードを入力して確認します。

    3. 新しいバケット名を入力します。

    4. *作成して有効化*を選択します。

    テナントとバケットを選択します

    1. プルダウンからテナント名を選択します。

    2. プルダウンからバケットを選択します。

    3. *選択して有効にする*を選択します。

  4. [ 保存（ Save ） ] を選択します。

    ログは指定したテナントとバケットに保存されます。ログのオブジェクト キー名は次の形式になります。

    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