LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@yukitkns

OCI カスタム・ログを使用してシステムログを監視する

Posted at

今回やりたいこと

1. OCI上でコンピュート・インスタンスを作成
・Oracle Cloud Infrastructure（以下OCI）で仮想マシンを提供する「コンピュート」サービスを利用し、インスタンス（VM）を作成します。
・このインスタンスには、任意のOS（Linuxなど）が予めインストールされています。
2.コンピュートのOSの/var/log/messagesを収集
・作成したコンピュート・インスタンス上で動作するOSのシステムログファイルである/var/log/messagesを収集します。
3.ロギング上で表示
・収集した/var/log/messagesのログデータを、OCIの「ロギング」サービスに送信します。
・ロギングサービスを使うことで、ログデータを可視化可能になります。
4.サービス・コネクタ・ハブでerrorの文字だけをフィルタリング
・「サービス・コネクタ・ハブ」を利用して、ログデータをフィルタリングします。
・具体的には、ログ内でerrorという文字列が含まれるエントリだけを抽出します。
・抽出したログデータを「モニタリング」サービスに送信します。
5.モニタリングで設定したルールに基づいて検知
・フィルタリングされたログデータをOCIの「モニタリング」サービスで監視します。
・ルールを設定し、例えば「errorが一定回数以上検出された場合にアクションをトリガーする」などの条件を指定します。
6.通知サービスで電子メールにアラートを送信
・モニタリングサービスが設定したルールに基づき異常を検知した場合、OCIの「通知」サービスを利用してアラートを発行します。
・通知サービスは、事前設定された電子メール宛にアラートメールを送信します。
・これにより、システム管理者が問題を即座に認識し、対応できるようになります。

image.png

手順

以下の手順で、ログ監視の仕組みを構築します。
1. 動的グループおよびIAMポリシーの作成
2. カスタム・ログの作成
3. サービス・コネクタ・ハブの作成
4. モニタリング設定の構築
5. アラートメールの送信

なお、事前準備として通知サービスのトピックは既に作成済みです。
トピックの作成手順については以下のドキュメントをご参照ください。
トピックの作成

実行環境

実行環境は以下の通りです。

[opc@cl ~]$ cat /etc/oracle-release
Oracle Linux Server release 9.5

動的グループおよびIAMポリシーの作成

それでは「手順」で示した流れに従い、設定を進めていきます。

まずは動的グループを作成します。
「動的グループの作成」画面で、以下の情報を入力します。

  • 動的グループ名：任意の名前（例：CL-DG）
  • 説明：（例：カスタム・ログ用動的グループ）

次に、以下の一致ルールを定義して、「作成」を選択します。

instance.compartment.id = '<コンピュートが置かれているコンパートメントのOCID>'

1.png

動的グループが作成されます。
2.png

次に、IAMポリシーを作成します。
「ポリシーの作成」画面で、以下の情報を入力します。

  • ポリシー名：任意の名前（例：CL-Policy）
  • 説明：ポリシーの目的を説明（例：カスタム・ログ用IAMポリシー）

次に、以下のステートメントを定義、「作成」を選択します。

Allow dynamic-group 'Default'/'CL-DG' to use log-content in tenancy

2.png

これでIAMポリシーが作成されます。
3.png

カスタム・ログの作成

動的グループとIAMポリシーの作成後、カスタム・ログの作成を行います。

ログ・グループの作成

最初にカスタム・ログ用のログ・グループを作成します。
OCIコンソールで「監視および管理」→「ログ・グループ」を選択します。
4.png

「ログ・グループの作成」を選択します。
5.png

以下の情報を入力、「作成」を選択します。

  • 名前：任意（例：CL-LG）
  • 説明：任意（例：カスタム・ログ用ログ・グループ）
    6.png

ログ・グループが作成されます。
7.png

カスタム・ログの作成

ログ・グループの作成後、カスタム・ログの作成を行います。
「フィルタ」から作成したログ・グループに変更、「カスタム・ログの作成」を選択します。
8.png

以下の情報を入力、「追加オプションの表示」を選択します。

  • 名前：任意（例：CL）
  • ログ・グループ：作成済みのログ・グループを選択
    9.png

必要に応じてログの保持期間を設定します（デフォルトは1ヶ月、最大6ヶ月まで設定可能）。
ここではデフォルト値の1ヶ月に、「カスタム・ログの作成」を選択します。
10.png

エージェント構成の作成

カスタム・ログの作成後、ログ収集用のエージェント構成も設定します。
以下の情報を入力、「エージェント構成の作成」を選択します。

  • 構成名：任意（例：CL-AG）
  • 説明：任意（例：Configuration agent for custom logs）
  • ホスト・グループ
    • グループ・タイプ：動的グループ
    • グループ：作成した動的グループを選択
  • エージェント構成
    • 入力タイプ：ログ・パス
    • 名前の入力：任意（例：messages）
    • ファイル・パス：任意（例：/var/log/messages）
      13.png
      12.png

ステータスが「作成中」から「アクティブ」に変わると、エージェント構成の設定が完了です。
14.png
15.png

カスタム・ログ作成後、約5分程度で対象ログ（ここでは/var/log/messages）が収集され、OCIコンソール上で確認できるようになります。

なお、カスタム・ログを作成する際には、作成時点のログが収集対象となります。
作成以前のログは収集されないため、この点にご注意ください。

16.png

カスタム・ログが収集されない場合

上記手順を実施してもカスタム・ログが収集されない場合があります。
この場合、OS側のカスタム・ログ用構成自動アップデータ・サービスが更新されていない可能性があるため、手動で更新を行う必要があります。

コンピュート・インスタンスのOSにログインし、以下のコマンドを実行して構成自動アップデータ・サービスのログを確認します。

journalctl -u unified-monitoring-agent_config_downloader.service

以下のようなログが出力されている場合、更新がまだ行われていません。

 ====================

=====================

構成自動アップデータを手動で更新するには、以下のコマンドを実行します。

sudo systemctl start unified-monitoring-agent_config_downloader.service

更新完了までに最大30秒以上かかる場合があります。

更新完了後、再度以下のコマンドを実行してログを確認します。

journalctl -u unified-monitoring-agent_config_downloader.service

以下のログがそれぞれ表示されていれば、アップデータの更新は完了しています。
これによりカスタム・ログが正常に収集され、OCIコンソール上で確認できるようになります。

====================
     <source>
         @type tail
         tag ocid1unifiedagentconfigurationoc1ap-tokyo-1amaaaaaa7swuj4yaimk6g7enlsrginqjxblgwugt2af7za637b5ruoxv2>
         path  /var/log/messages
         pos_file  /etc/unifiedmonitoringagent/pos/ocid1unifiedagentconfigurationoc1ap-tokyo-1amaaaaaa7swuj4yaimk>
         path_key  tailed_path
        <parse>
            @type none
         </parse>
     </source>
     <match ocid1unifiedagentconfigurationoc1ap-tokyo-1amaaaaaa7swuj4yaimk6g7enlsrginqjxblgwugt2af7za637b5ruoxv2j>
        @type oci_logging
        log_object_id  ocid1.log.oc1.ap-tokyo-1.amaaaaaa7swuj4yal6be3ityzhmj2bcer3bvkv3v3bkxkssiglqixrexj6na
         <buffer tag>
            @type file
            retry_timeout  3h
            path  /opt/unifiedmonitoringagent/run/buffer/ocid1unifiedagentconfigurationoc1ap-tokyo-1amaaaaaa7swu>
            disable_chunk_backup  true
            chunk_limit_size  5MB
            flush_interval  180s
            total_limit_size  1GB
            overflow_action  throw_exception
            retry_type  exponential_backoff
        </buffer>
     </match>
 
=====================

                               =========beginning of fluentd output=========
                  true
                               =========end of fluentd output=========

trueではなくfalseと表示される場合は、エージェント構成の設定が間違っている可能性が高く、再度構成の見直しを推奨します。

サービス・コネクタ・ハブの作成

ここでは、サービス・コネクタ・ハブを使用して特定のログのみをフィルタリング、モニタリング・サービスに連携する手順を記載します。

OCIコンソールで「監視および管理」→「コネクタ」を選択します。
15.png

「サービス・コネクタの作成」を選択します。
16.png

以下の情報を入力、「ディメンションの追加」を選択します。

  • コネクタ名：任意（例：CL-SCH）
  • 説明：任意（例：カスタム・ログ用コネクタ）
  • コネクタの構成
    • ソース：ロギング
    • ターゲット：モニタリング
  • ソースの構成
    • ログ・グループ：「カスタム・ログの作成」で作成したグループ
    • ログ：「カスタム・ログの作成」で作成したログ
    • ログ・フィルタ・タスク
      • data.message = cl（コンピュート・インスタンス名）
      • data.message = error
  • ターゲットの構成
    • メトリック・ネームスペース：任意（例：custom_logs）
    • メトリック：任意（例：Messages）

ターゲットの構成値は手動で入力します。

17.png
18.png
19.png

検知するのログのパスや文字列をアラートメールに表示したい場合、「パスの編集」で以下の内容を入力後、「変更の保存」を選択します。
※他の項目は空白でも問題ありません。

  • ログ・パス
    • ディメンション名：subject
    • 値：logContent.subject
  • 文字列
    • ディメンション名：message
    • 値：logContent.data.message
      20.png

尚、作成時に以下の画面が表示された場合、サービス・コネクタ・ハブがモニタリングへの書き込み権限を持っていないことを意味します。
この場合、モニタリングへの書き込みを許可するIAMポリシーを作成する必要があります。
デフォルトでは「ConnectorPolicy_monitoring_YYYY-MM-DDThh:mm：ssZ」という名前で作成され、このIAMポリシー名で問題なければ「作成」を選択します。
21.png

IAMポリシーが作成されると、以下のステートメントが定義されます。

allow any-user to use metrics in compartment id <コンパートメントのOCID> where all {request.principal.type='serviceconnector', target.metrics.namespace='<メトリック・ネームスペース>', request.principal.compartment.id='<コンパートメントのOCID>'}

全ての項目を作成後、「作成」を選択します。
22.png

「ACTIVE」の状態でサービス・コネクタ・ハブが作成されます。
23.png

モニタリング設定の構築

サービス・コネクタ・ハブの構築後、モニタリングの設定を実施します。
事前準備として、筆者調べでは直近1時間以内に任意の文字列（ここではerror）が収集されていない場合、メトリック・ネームスペースとメトリックを選択することができません。
そのため、以下のコマンドを使用して、任意のパス（ここでは/var/log/messages）に任意の文字列を出力します。

logger "error"

出力後、OCIコンソールで「監視および管理」→「アラーム定義」を選択します。
21.png

「Create Alarm」を選択、以下の情報を入力します。
22.png

アラーム基本情報の設定

  • Alarm name（アラーム名）：任意（例：CL-AL）
  • Alarm summary（アラーム・サマリー）：任意（ここでは空白）
  • Metric description（メトリック詳細）
    • Metric namespace（メトリック・ネームスペース）：任意（例：custom_logs）
    • Metric name（メトリック名）：任意（例：Messages）
    • Interval（間隔）：任意（例：1 minutes）
    • Statistic（統計）：任意（例：Mean）
      ※ Countは指定した間隔で受信された観測の数を返します。
      詳細は以下のOCI公式ドキュメントをご覧ください。
      問合せの統計の選択
  • Metric dimensions（メトリック・ディメンション）
    • Dimension name：任意（例：connectorName）
    • Dimension value：任意（例：CL-SCH）
      23.png

トリガー・ルールの設定

  • Trigger rule（トリガー・ルール）
    • Operator（演算子）：任意（例：greater than or equal to（次より大きいか等しい））
    • value（値）：任意（例：1）
    • Trigger delay minutes（トリガー遅延分数）：任意（例：1分）
      ※ 条件が維持される必要がある時間です。詳細は以下をご覧ください。
      アラームへのトリガー・ルールの追加
    • Alarm Severity（アラーム重大度）：任意（例：Critical）
      ※ Critical,Error,Warning,Infoから選択可能です。
    • Alarm Body（アラーム本体）：任意（例：下記サーバからイベントが到着しました。通知内容：ステータス：{{status}} 発生日時：{{timestamp}} 重大度：{{severity}} オブジェクト名：{{title}} ログ・パス：{{Dimensions.subject}} 文字列： {{Dimensions.message}}）
      24.png

この箇所で使用する変数は「動的変数」と呼ばれ、発報時に内容が自動的に置き換わります。
ただし、改行は使用不可で1行のみ表示されます。

通知設定

  • Destination（宛先）
    • Destination Service（宛先サービス）：任意（例：Notifications）
      ※アラートメールで通知する場合は「Notifications」を選択します。
    • Topic（トピック）：任意（例：CL-TP）
  • Message Grouping（メッセージのグループ化）：任意（例：Group notifications across metric streams
    ※ 上記を選択した場合、すべてのメトリック・ストリームが1つのアラートメール内に統合されます。
    OCI Alarm通知のメトリック値の発表
  • Message Format（メッセージのフォーマット）：任意（例：Send formatted messages）
    ※上記を選択した場合、見やすい形式のアラートメールが作成されます。
  • Repeat notification? （通知の繰り返し）：無効
    ※ 有効時には間隔を分単位で設定可能です。
  • Suppress notifications：無効
    ※ 有効時には指定期間モニタリングが非アクティブになります。
    25.png

以上の手順でモニタリングのアラームが作成されます。
26.png

アラートメールの送信

モニタリングの設定後、任意の文字列（ここではerror）を出力し、アラートを発報してアラートメールを送信する流れを確認します。

アラートが発報されると、モニタリングのステータスはFiringとなります。
27.png

作成したモニタリングの設定に基づき送信されたアラートメールの例を以下に示します。
（設定時に複数回文字列を出力させ、Metric values~の箇所に複数件が表示されますが、これは仕様でありバグではありません。）
28.jpg

デフォルトでは、指定の文字列が13分以内に再度収集されない場合、ステータスはRESETに変更され、解除用のアラートメールが送信されます。
注意点として、動的変数に使用可能なデータが存在しない場合、該当する変数は未解決のままコード化されて表示されます。
以下の例では、{{Dimensions.subject}}と{{Dimensions.message}}がコード化されています。
29.png

解除用アラートメールの送信後、モニタリング画面に戻るとステータスはOKに復帰します。
30.png

補足として、モニタリング作成時にはName、Alarm Summary、およびAlarm Bodyの項目を日本語で設定することも可能です。
28.png

OCI上でのログ監視設定の手順については以上となります。

参考記事

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?