トップ > New Relic > New Relicのアラート通知を柔軟に制御するワークフロー設定

New Relicのアラート通知を柔軟に制御するワークフロー設定

New Relic Alert Wokflow Incident notification
記事タイトルとURLをコピーする

みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。

New Relicなどの監視システムを使っていて、障害が検知された際にそのまま検知されたアラートのインシデント通知を行っていると思いますが、もう少しだけこんなこといいな～、できたらいいな～なんて思うことはないでしょうか。今回はインシデント通知の制御をおこなうNew RelicのWorkflowについているフィルタ機能ついてのお話になります。

目次

想定読者

  • New Relicを使って障害通知をおこなっている人
  • アラートの条件を細かく設定したい人

1. はじめに

近年のモダンなシステムの運用ではアラート管理は非常に重要な要素となっています。しかしシステムの規模が大きくなるにつれて、アラートの数が増加するため重要な通知を見逃すリスクがとても高くなっています。New RelicのWorkflowに含まれるフィルタリング機能は、このような課題を解決するための強力なツールになります。適切なフィルタリングを設定することで、必要な情報を必要なチームに、適切なタイミングで届けることが可能になるでしょう。

本記事では、New RelicのWorkflowに含まれるフィルタリング機能について、ご紹介していきます。なお、公式ドキュメントは下記のものになります。

docs.newrelic.com

2. New RelicのWorkflowのフィルタリング機能とは

フィルタリングの基本概念

New RelicのWorkflowのフィルタリング機能は、発生したインシデントやイベントに対して、特定の条件に基づいて通知先を制御する機能です。フィルタリングを適切に設定することで、以下のような効果を期待することができます。

  • 重要なアラートの見逃し防止
  • チーム別の通知制御
  • 環境別の通知管理
  • 優先度に応じた通知先の振り分け

フィルタリングができる項目一覧

New RelicのWorkflowのフィルタリング機能で指定できる主な項目は以下の通りです。

  • インシデントの優先度（CRITICAL/WARNING）
  • エンティティ情報（アプリケーション名、ホスト名など）
  • タグ情報（チームタグ、環境タグなど）
  • アラート条件（条件名、ポリシー名）
  • カスタム属性

フィルタリングの制限事項

New RelicのWorkflowのフィルタリング機能を使用する際は、以下の制限事項に注意が必要です。

  • フィルターサイズは4096文字まで
  • アカウントごとに最大1000のワークフロー作成が可能

3. フィルタリング条件の種類と活用方法

インシデント属性によるフィルタリング

インシデントの属性を使用したフィルタリングでは、以下のような項目の指定が可能です。

  • 優先度（Priority）
  • 重大度（Severity）
  • インシデントのタイトル
  • インシデントID
  • インシデントのステータス

これらの属性を組み合わせることで、より細かな制御が可能になるでしょう。

エンティティ情報によるフィルタリング

エンティティ情報を使用したフィルタリングでは、主要な項目として以下の項目の指定が指定できます。

  • アプリケーション名
  • ホスト名
  • サービス名
  • コンテナID
  • Syntheticsモニタ名
  • 各種リソース名

その他、All entitiesに含まれる情報などを使用することができます。

アラート条件に基づくフィルタリング

アラート条件に基づくフィルタリングでは、以下ような項目の指定が可能です。

  • アラートポリシー名
  • コンディション名
  • コンディションのカスタムディスクリプション

上記以外に、コンディションやエンティティに付与されたタグによるフィルタリングを使用することもできます。

  • 環境名（Production、Staging、Development等）
  • AWSのアカウントID
  • リージョン情報
  • リソースのNameタグ名
  • その他何かの条件を示すタグ（例えば特定のチームに対してのみ送信するなど）

※チームタグの詳細は次の項4でご紹介します。

4. チームタグを活用したフィルタリング戦略

チームタグとは

チームタグは、監視対象のリソースに対して担当チームを示すタグを事前に付与しておくことで、特定のチームに対してのアラート通知を制御する方法です。

例えば、以下のような形式で設定します。

team: frontend
team: backend
team: infrastructure

チームタグを使用した効果的なフィルタリング例

チームタグを活用した効果的なフィルタリングの例として、以下のようなパターンが考えられそうです。

  • フロントエンドチーム向けの通知設定
  • バックエンドチーム向けの通知設定
  • インフラチーム向けの通知設定
  • オンコールチーム向けの通知設定
  • 複数チームへのクロスファンクショナルな通知設定

これらは一般的な運用監視においてよくある通知パターンですが、こうした通知パターンはNew Relicではタグやエンティティなど情報をうまく組み合わせて条件を作ることで実現することが可能です。

5. フィルタリングのベストプラクティス

推奨されるフィルタリング設計

一般的な話として効果的にフィルタリングする場合の条件を決めるポイントとして、以下のポイントを検討した上で条件を決めるとよさそうです。

  1. 階層的なフィルタリング

    1. 優先度によるフィルター
    2. チームタグによるフィルター
    3. 環境によるフィルター

  2. 命名規則の統一

    • チームタグの命名規則
    • 環境タグの命名規則
    • アラート条件の命名規則

上記を考慮した上での通知ルールの文書化と関係者間の認識共有

  • フィルタリングルールの文書化
  • チーム間での共有
  • 定期的な見直しと更新

アンチパターン

避けるべきパターンとして、以下のようなポイントがあります。

  • 過度に複雑なフィルター条件
  • 重複するフィルター設定
  • メンテナンス性の低い設定
  • ドキュメント化されていない特殊なフィルター

6. 実際の設定

それでは、実際にどのような設定をおこなうか見ていきましょう。まずはタグ設定から説明します。

  1. リソースにタグを付与する場合、All entitiesから対象のリソースのサマリー画面を開き、Tagsのボタンをクリックしてタグ設定画面を開きます。

  2. テキストエリアに key: value形式で入力し、エンターキーを押して確定します。これでタグの登録は完了です。

次に通知設定を見てみましょう。

  1. Alerts から Workflowを開きます。

  2. 既存のWorkflowの編集画面を開くか、Add a workflowのボタンをクリックします。

  3. Filter dataの右にあるAdvancedをクリックします。

  4. Select or enter attributeをクリックし、設定対象の属性を選択または入力します。

  5. 選択した属性に対する条件を設定します。

あとは設定を保存すると、設定したフィルタ条件でインシデントの通知をフィルタリングすることができます。

まとめ

New RelicのWorkflowのフィルタリング機能を使用すると、かなり柔軟な通知制御をおこなうことができ、特定のタグが付いている条件を指定することで特定のチームのみにインシデントを通知したり、ログ監視など復旧通知をしてほしくない時に復旧通知だけ送らないような制御をしたりと、設定次第で細やかな制御をすることができます。ぜひWorkflowのフィルタリング機能を活用してみてください。

宣伝

弊社では、お客様環境のオブザーバビリティを加速するためにNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。

◆　塩野　正人
◆　マネージドサービス部　所属
◆　X（Twitter）：@shioccii
◆　過去記事はこちら

前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。