ログ監視のアラート通知にログメッセージを出力させる方法をご紹介します。本内容はよく質問をいただきますが、実現する機能として Enrichment を利用する方法をご案内しています。
本ポストでは、ログ収集から通知までの一連の流れ (Infrastructure Agent を用いたログ情報の収集、アラートコンディションの設定、Workflow での通知設定) と簡単な注意点を踏まえご紹介いたします。すでにログ収集をされている場合やアラートコンディションまで完了されている場合は、後半からご参照ください。
また、Enrichment の結果をテキスト展開する動作は、一部アカウントでは有効になっていない場合があります。本方法でうまくいかない場合は、サポートケースにてご連絡ください。
ログを New Relic に転送する
New Relic にログを転送する方法には複数の選択肢があります。
ここでは Linux OS (RHEL9) でオリジナルなログファイルの出力をインフラストラクチャエージェントのログ転送機能を用いて収集します。
他の方法は ドキュメント New Relicへのログ転送 や ブログポスト ファーストステップガイド NewRelic Logs セットアップの流れ を参照ください。
インフラストラクチャエージェントを利用したログ収集は、基本的にはガイドインストールだけで、自動でログ転送もセットアップされます。
(自動設定セットアップの対象 OS は ドキュメント インフラストラクチャエージェントを使用してログを転送する > システム要求 を参照ください。)
まずは、プラットフォーム UI の Add Data から Guided install を選択し、Infrastructure Agent のガイドインストールを行います。
(ガイドインストールによる Infrastructure Agent のインストールの詳細はブログポスト ファーストステップガイド Infrastructure 導入 をご参照ください。)
RHEL9 の場合、デフォルトのインストール操作にて Logs Integration も行われます。
上記のインストール作業で /etc/newrelic-infra/logging.d/logging.yml が作成され、/var/log/messages などの log 転送が開始されます。
(UI から Infrastructure > Hosts > 対象ホスト > Logs などにて、収集されたログを確認することができます。)
$ cat /etc/newrelic-infra/logging.d/logging.yml
logs:
- name: cloud-init.log
file: /var/log/cloud-init.log
attributes:
logtype: linux_cloud-init
- name: messages
file: /var/log/messages
attributes:
logtype: linux_messages
- name: secure
file: /var/log/secure
attributes:
logtype: linux_secure
- name: newrelic-cli.log
file: /root/.newrelic/newrelic-cli.log
attributes:
newrelic-cli: true
logtype: newrelic-cliここでは、自分で指定するログファイルに関して転送を行うので、上記の設定ファイル倣って、新規のログ転送用の設定ファイルを作成します。
シンプルに name と file パスを記載します。yaml ファイルなので、インデントのスペースの数には注意ください。
$ cat /etc/newrelic-infra/logging.d/mylog.yml
logs:
- name: log-test-with-notification
file: /var/log/myTest.logまた、設定ファイルは作成すると infrastructure agent が自動で読み込みを行うので、file に指定した対象ファイルに出力があれば、New Relic にその内容が転送されます。
簡易的に下記のように対象ファイルに出力させて、転送確認を行います。
$ echo "test TEST テスト" | sudo tee -a /var/log/myTest.log
test TEST テストUI では、Logs > All logs や Query Your Data などから該当ログを確認することができます。
logs UI では、該当メッセージをクリックすると紐づいた様々な情報を確認することができます。
infrastructure agent 経由であれば、自動で情報の紐付けが行われます。
また、ログ転送用の yaml ファイルで attribute を追加で設定している場合は、その情報も紐づきます。
これらの情報は Query Your Data や アラートコンディションの NRQL 条件に利用することが可能です。
Query Your Data での表示
アラート発報テストのために crontab などで対象ログファイルに出力が発生するようにしておきます。
$ sudo tail -n 1 /etc/crontab
* * * * * root echo "ERROR: log-test at `date '+\%Y-\%m-\%d \%H:\%M:\%S'`" >> /var/log/myTest.logまた、ログ転送において、日本語版 Windows のような SHIFT-JIS 系のシステムからログを送られる場合、文字化けすることがあります。
その場合は、ブログポスト fluentd を用いた Windows イベントログ連携 などでご紹介している方法をお試しください。
ログ監視用のアラートコンディションの例
一般的なログ監視では、非定期的な出力で、何かの異常が発生した際に出力されるログを検出することが多いのではないかと思います。
ここでは指定したキーワード (error) を含むメッセージが出力されたら、インシデントが作成されるようにアラートコンディションを作成します。
Alerts & AI > Alert Conditions より New alert condition (新規アラートコンディション作成) で Write your own query にて作成します。
アラート用の NRQL として、count() 関数 を利用して、アラート対象のログ出力数を集計します。
必要に応じて、WHERE 条件を追加します。
# アラート用の NRQL の設定例
SELECT count(*) FROM Log
WHERE message LIKE '%error%' AND hostname = 'ip-172-31-39-240.ap-northeast-1.compute.internal' AND filePath = '/var/log/myTest.log'その他の設定は下記です。
ここでは、Streming Method として、Event Timer を利用し、対象のログが 1回以上が出力されたら、インシデント作成。信号喪失設定を用いて10分以上出力されなくなったらインシデントをクローズするようにします。
また、閾値の設定値は、例となりますので監視要件に合わせて調整ください。
検知したログを確認後、手動で issue をクローズされたいという場合は、信号喪失の閾値などは不要です。
また、20分以上の期間で 2回以上出力されたら違反とするような場合などは、Event Timer のタイマー上限制約で、Cadence 方式の方が良い場合などがあります。
新規ポリシー作成時の workflow 編集では Enrichment が設定できないため、設定は飛ばしてしまって構いません。コンディション作成後に改めて workflow を作成し、Enrichment も設定を行います。また、コンディションが有効だと先にインシデントが作成されてしまう場合があるため、コンディションは無効で作成し、workflow の設定後にコンディションを有効にする方がスムーズかと思います。
また、Workflow 通知をカスタマイズするため、ログ監視用のポリシー、またはコンディションごとにポリシーを作成する方がよいかと思います。
Workflow の設定 ~ Enrichment ~
Enrichment は、アラート通知の実行時に任意のクエリ結果を追加できる機能です。Enrichクリエとして、ログメッセージを取得するクエリを登録することで、通知にログメッセージを追加することができます。
※ 本ブログ執筆時では、Enrichment は Free プランではご利用できません。
新規の workflow を作成し、Filter data で先のポリシーを設定します。
次に、Additional settings > Enrich your data から Enrichment を作成します。
ログメッセージを出力するクエリを作成します。
アラートコンディションの NRQL クエリと同一の WHERE 条件を記載し、SELECT で message を出力するようにします。
また、このあと利用するので命名したクエリ名をメモしておきます。
SELECT message FROM Log
WHERE message LIKE '%error%' AND hostname = 'ip-172-31-39-240.ap-northeast-1.compute.internal' AND filePath = '/var/log/myTest.log'Enrich クエリは アラート用 NRQL ではないため、通常の NRQL で利用する LIMIT や SINCE なども記載可能です。SINCE は未指定の場合 60 minutes ago, LIMIT は 10件となります。デフォルトのクエリで問題がある場合は、追加ください。
ここまでの設定で、メール通知の場合は Enrich の結果が画像データとして、通知に追加されます。
ただ画像データであるため、メッセージをコピーできなかったり、メッセージが長い場合は途中で切れてしまっていたりということがあります。
下記は実際のメール通知での Enrich (画像) の通知例です。
Workflow の設定 ~ Notify when .. ~
メール通知の通知タイミングのデフォルトは、Activated, Acknowledged, Closed となります。
同一の issue に 複数の incident が追加されるような場合でも、通知を受け取りたい場合は、other update にもチェックを入れる必要があります。
不要な場合はデフォルト設定、または不要なタイミングがある場合はチェックを外し調整します。
通知タイミングに関するより詳細な内容はブログポスト アラート通知タイミングの有効・無効の変更方法 を参照ください。
また、Enrichment はあくまで 通知に任意の情報を追加する機能であるため、アラートコンディションと関係がある情報に自動で制限されたり、過去に通知されたメッセージを除外するようなことはされません。また、クエリは Workflow が動作した際の結果となります。
Workflow の設定 ~ Custom Details ~
メール通知や Slack 通知の場合は、Custom Details に Enrich 変数を記載することで、Enrich クエリの結果をテキストで出力することができます。
※ 一部アカウントでは、テキスト展開が有効になっていない場合があります。本方法にてうまくいかない場合は、サポートケースにてご連絡ください。
Custom Details の入力画面にて、波括弧を連続入力する {{ ことで、入力補助ダイアログが表示されます。
さきほど作成した Enrich 名が表示されるので、選択します。
作成した Enrich 名にスペースが含まれる場合は 大括弧を利用します。 {{ [EnrichLogMessage] }}
この設定で、実際にログアラートが通知されると、下記のような json 形式で Enrich の結果が記載され、通知されます。
Send test notification や Test workflow による通知テストの場合、利用されるデータが実際のデータとは異なるため、上手くいかない場合があります。
通知を確認されたい場合は、実際にアラートを発生させた方が確実です。
先の通知結果のように json 型データの場合、読みにくいという場合は、ヘルパー関数を利用して、出力データの加工を行うことができます。
ヘルパーの詳細はドキュメント 通知メッセージテンプレート > ヘルパー機能 をご参照ください。
## タイムスタンプを Asia/Tokyo に変換した場合の記載例
{{#each EnrichLogMessage}}{{#timezone this.timestamp 'Asia/Tokyo'}}{{/timezone}}, {{this.message}}{{#unless @last}},
{{/unless}}{{/each}}
## タイムスタンプは表示せず、メッセージのみを表示させた場合の記載例
{{#each EnrichLogMessage}}{{this.message}}{{#unless @last}},
{{/unless}}{{/each}}
Webhook 利用の場合、任意の json データを受け付けない場合などは、上記のように json 形式からテキストに変換することで回避できる場合があります。
下記は、Webhook (Slack) でメッセージのみを記載した通知例です。
また、Enrich クエリ結果のデータ構造は、FACET や変数の利用の有無で、変化する場合があります。メッセージテンプレートの出力調整をされる場合は、まずは Custom Details で全文を出力させて、構造をご確認の上、メッセージの整形をされることを推奨します。
具体的なデバッグ方法などはブログポスト Handlebars playgroundを使った、Workflowのカスタムメッセージのテンプレートのデバッグ方法 をご参照ください。
最後に
ログ監視のアラート通知文面にログメッセージを追加する方法をご紹介しました。
通知内容にログメッセージを含めたいというご要望は、アラートを受け取った際に New Relic にログインできない場合や簡易的に確認いただく場合などで有用かと思います。
一方で、アラート受信時に New Relic にアクセスできる環境である場合は、ログ監視用の Dashboard を別途作成し、アラートコンディションの RUNBOOK にその URL を設定するという方法などもございます。メール文面にログ内容を掲載できない場合やアクセス時点の状況を確認されたい場合などは、より有効かと思います。
後続の対応や管理なども含めて、通知方法や内容のカスタマイズを実施いただければと思います。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
