Relic Solution: アラートワークフローの実装パターン

この記事は「Relic Solution: Patterns for Implementing Alerts Workflows」の抄訳となります。

今回は、ワークフローとデスティネーションを使ってアラート通知を設定するための様々な実装パターンを紹介します。ワークフローは非常に柔軟で高度に設定可能です。様々な運用モデルやアカウントサイズに対応するために、様々な方法で設定することができます。そのため要件に応じてさまざまな実装パターンを使用できます。この記事では考えられるいくつかの実装パターンについて説明します。

まず、Alerts & AI Opsのリファレンスモデルについて簡単におさらいしておきましょう。

• 最初の構成要素は、Alert Conditionです。アラート条件は、ストリーミングされたテレメトリー信号を評価し、異常な動作を特定します。
• そのような動作が検出されると、incidentが開かれます。incidentはより大きな問題の個々の症状の詳細と状態を把握します。
• incidentが開かれると、issueが作成されます。issueは、関連する一連のincidentのためのコンテナです。issueは、根本原因を決定する必要がある、より大きな問題のすべての症状を収集し、整理します。
• Issueがアクティブになる際、お客様またはお客様の下流システムに通知するために、どの課題がどのデスティネーションを通じてルーティングされるかをWorkflow設定により定義されています。

実装パターン

パターン1：1アカウントに1つのワークフロー

シナリオ： すべてのissueは共通のスキーマを持つ1つの下流システムにルーティングされます。

ServiceNowやサードパーティのAI Opsプラットフォームなど、1つの下流システムにすべての課題を送信している場合、非常にシンプルな構成を実装できます。フィルターが定義されていない1つのワークフローがすべてのIssuesにマッチし、ServiceNowや他のシステムに接続するために設定した宛先にルーティングします。

パターン 2：担当チームごとに1つのワークフロー

ワークフローが「team」タグをフィルタリングしてチームに通知する。

シナリオ : DevOpsチームが担当チームごとのサービスのセットを管理し、そのサービス群からのすべての通知を該当チームに送信したい。

DevOpsモデルで運用する組織では、1つのチームが複数のサービスを構築・運用し、多くのエンティティを所有しています。チーム内では、誰がアラートを受け取り、インシデントに対応するかというローテーションを共有することがよくあります。このアプローチでは、まず、すべてのインシデントに「team」タグが追加されていることを確認することをお勧めします。この状態で、ワークフローに「てteam」タグにマッチするフィルターを追加し、PagerDutyやSlackなど、チームごとに希望する宛先に課題をルーティングします。

この方法は、「environment」タグのチェックや「priority」のチェックを追加するなど、さまざまな方法で拡張でき、課題をチームごとに最も適切な宛先にルーティングすることができます。これは、アラート条件をどのようにポリシーに整理するか考える際に、通知の方法を考慮せずにすむ、柔軟で効率的なパターンです。

タグは、NRQL条件のファセット属性（別名テレメトリータグ）、条件をトリガーしたエンティティのタグ、またはアラート条件に関連付けられたタグの3つの方法のいずれかでincidentに追加されます。一貫性を確保するため、すべてのコンディションに「team」タグ、またはモデルに適合する同様のタグ名を付けることを推奨します。

パターン：アラートポリシーごとに1つのワークフロー

アラートポリシーに通知チャネルがひもづいた従来の仕組みですでに通知の種類ごとにアラートポリシーを整理済みの場合。アラートポリシータグでフィルタリングし、サービスオペレータに通知するワークフロー。

シナリオ： サービスに関する全てのアラート条件はすでにアラートポリシーごとにグループ化されており、通知先はサービスやポリシーごとに異なる。

すでに特定のサービスに対するアラート条件をポリシーにまとめ、そのポリシーに基づいて通知をルーティングしている組織の場合、ワークフローのフィルタとしてポリシータグを使用することを選択することができます。これは、アラート条件をどのように整理したかに基づいて通知設定を制約する、従来のアラートモデルに最も似ています。このモデルがすでに組織でうまく機能しており、ポリシーの数がそれほど多くない場合、このモデルがうまく機能する可能性があります。

これは、レガシーアラートチャンネルをワークフローに自動的にアップグレードする際に、New Relicが使用しているパターンです。これは、すべてのNew Relicアカウントに共通するマッピングモデルであるためです。しかし、非常に多くのポリシーがあり、各ポリシーの通知が一意の宛先にルーティングされない場合は、上記のようなタグベースのパターンを使用することをお勧めします。ポリシーベースのパターンは、個々のアカウントに数百以上のポリシーがある場合、スケーリングの限界に直面する可能性があります。

これらは推奨または一般的なパターンですが、決してこれらのパターンや手法に限定されるものではありません。ワークフローフィルターは非常に柔軟であり、多くの実装モデルに適応することができます。