みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。
そろそろ夏も終わりかけて、やっとちょっとだけ秋の気配を感じれるようになりましたね。 まだ本格的な秋ではありませんが、秋といえば毎年月見バーガーを楽しみにしていて、今年も販売開始後にさっそく頂きました♪
これで今年も安心して冬を迎えられます（笑）
さて、ここから本題に入りたいと思いますが、New Relicを使っていく中で必ずおさえておかなければいけないポイントとして、PolicyやCondition、Workflowといった概念がありますが、個人的にはNew Relicを触り始めた当初は取っつきにくいといった印象を持っていました。慣れてしまえば大したことはないのかもしれませんが、ここの部分をちゃんとおさえておかないと後々の手戻りが大きいことから今回の記事として取り上げさせていただきました。
目次
アラート管理の概念
一般的なアラート管理の注意点
基本的な考え方として、発生したアラートに対してそれらをどのように管理するか、どこに通知するかという点はアラート設定の際に必ず必要となる情報かと考えています。
もう少し具体的な話をさせていただくと、例えばWebサーバの運用をおこなっており、その監視項目として、CPU使用率、メモリ使用率、ディスク使用率などを監視していた場合、CPU使用率、メモリ使用率、ディスク使用率はAさんとBさんに通知するという設定をされているでしょう。この場合に通知先をそれぞれの監視項目毎に設定されているのではないでしょうか。
この考え方は監視システムによって実装に差があるため、使う監視システムによって若干オリジナリティが出る部分ではありますが、監視システムの種類によっては上記のようにアラート条件毎に通知先を指定するケースもそれなりにあると考えています。アラート条件に対して個別に通知先を設定する場合の利点として、柔軟に通知先の設定ができる反面、個別のアラート条件毎に通知先を設定することから設定ミスを誘発しやすい部分でもあります。
New Relicの概念
New Relicの場合は、Policyという器の中にアラート条件であるConditionをまとめることができるため、ある程度の条件に応じてグルーピングを行うことができます。このPolicyという器自体は通知先自体を制御するのではなく、あくまでもアラートの条件をグルーピングするものであるという点が他の監視システムとの大きな違いとなっています。
New Relicのアラート通知：PolicyとConditionの役割について
ここでは、アラートの「発生条件」と「通知方法」を制御する、PolicyとConditionの違いについてお話したいと思います。
New Relic Alert Policyの特徴
Alert Policyの特徴
まずは公式ドキュメントを見てみると、ドキュメント上では下記のように表現をされています。
ポリシーとは、1 つ以上の条件のグループを指します。 docs.newrelic.com
端的に表現するなら「アラート条件をグルーピングする機能」と言うこともできますが、アラートポリシーの機能には単なるグルーピングの機能以外にアラートの通知頻度を制御する機能も含まれております。
つまり、Policyの主な役割は以下のようなものとなります。
- 関連するConditionをグループ化する
- アラートの通知頻度（Issue preference）を設定する
ここで、アラートの通知頻度についてもう少し深堀して見てみましょう。
New Relicでは発生したアラートの最小単位をインシデント（Incident）として管理しています。CPU使用率で閾値を超えてアラートが発報された場合も、メモリ使用率で閾値を超えてアラートが発報された場合も、ディスク使用率で閾値を超えてアラートが発報された場合も、個別のインシデントが発生したという扱いとなります。
ここまではそういうものだとご理解いただいた上で、こんなシーンを想像してみてください。
Webサーバーの場合、アプリケーションのポートに通信ができなくなった場合や、Webサーバのプロセス（nginxなど）がダウンした場合も同様にインシデントが発生してアラートが通知されます。一般的にはこのような状況に陥った場合、「アプリケーションのポートに通信ができなくなったことを通知するアラート」と「Webサーバのプロセス（nginxなど）がダウンしたことを通知するアラート」が同時に送信されます。
発生している事象としては「Webサーバのプロセス（nginxなど）がダウン」していることによる影響と推測されますが、こういった場合に通知が２通届くのって鬱陶しくないですか？
もちろんどちらかの監視に寄せてしまったり、届いたアラートをスルーするという選択肢もあるかとは思いますが、監視を一つに寄せる場合はプロセスが生きているにもかかわらずハングアップしていることによってポートダウンしているケースは検知できませんし、負荷が大きなシステムの場合でプロセスを複数動かしているケースなどもあるでしょう。こういった場合にアラート通知を抑制する機能がNew Relicに搭載されており、Policyの設定を変更するだけである程度の制御が可能となります。
Alert Policy設定の違い
New Relicのアラート通知頻度（Issue preference）の設定では以下の３つの設定値があります。それぞれ、ポリシーに１つのイシュー（Issue）、アラート通知条件（コンディション）に１つのイシュー、アラート通知条件とシグナルに対して１つのイシューの３種類の設定値があります。
- One issue per policy (default)
- One issue per condition
- One issue per condition and signal
まず設定値の詳細に入る前にイシュー（Issue）についてお話しますが、イシューとは同じ根本的な問題に関連するインシデントのグループのことを指します。
例えば、システム負荷の関係でCPU使用率アップダウンのアラート通知が大量に発生した場合は、CPU使用率のアラートが関連するインシデントとして纏めてくれると嬉しいですよね。Webサーバの例として記事に書いていますが、特定のWebサーバで特定のポート監視と特定のプロセス監視が関連している場合で両方のアラートが発生するプロセスダウン障害が発生した場合に、ポートダウンとプロセスダウンのアラートを関連付けてIssueとして管理できたらどうでしょうか。Issueとはそういった関連するインシデントをまとめて管理する機能となります。
少しだけ話が横に逸れましたが、アラート通知頻度（Issue preference）の設定項目について話を戻します。アラートポリシーの設定値について公式ドキュメントの情報を参考にしながら話を進めたいと思います。
One issue per policy
公式ドキュメント上では下記のように表現されています。
ポリシー全体を通じて、一度に 1 つの問題のみが開かれます。
つまり、デフォルトではひとつのポリシーに対して複数のインシデント（アラート）が発生した場合、その中の１つしか通知されません。
その代わりに同じポリシーで発生したインシデントは最初のイシューにまとめられて管理されます。New Relicの管理画面を見ていれば判別できるかもしれませんが、運用者側が何も考えずにアラート設定した場合に監視システムに期待している挙動は「グループにまとめているとはいえ、それぞれの監視項目毎に通知してほしい」だと思います。
そのため、公式ドキュメントにも「通知数が最も少ない」が「効果を上げるには、すぐに行動を起こして問題を解決する必要がある」と記載されています。
New Relicの管理画面に頻繁にアクセスせずインシデント（アラート）としてCPU使用率異常のアラートが最初に発報したまま放置していたら、そのあとに発生したディスク使用率アラートやプロセスダウンのインシデント（アラート）を見逃してしまったという事象がこの設定では発生してしまう恐れがあります。そうなればシステムの信頼性ってどうなの？となってしまうため、この設定を使用する場合は対象ポリシーのインシデント、イシューはなるべく早く解消することが推奨されます。
One issue per condition
公式ドキュメント上では下記のように表現されています。
ポリシー内の各条件ごとに、一度に 1 つの問題が開かれます。
こちらはかなり一般的な認識と実際の挙動が近い設定になります。端的にはアラート条件（コンディション）毎に発生したインシデント（アラート）はひとつのイシューとして纏められて通知をおこなう設定となります。それぞれ監視項目毎にアラートを通知したいという要望があった場合は、この設定を使用するとよいでしょう。
One issue per condition and signal
公式ドキュメント上では下記のように表現されています。
このオプションは、同じ条件と信号を共有するインシデントを独自の問題にグループ化します。
正直なところ、大半のケースでOne issue per conditionが設定内容を一番イメージしやすいかと思います。One issue per condition and signalを使用するケースはアラート通知自体を減らすのではなく、アラートコンディションの設定を減らすためのものと私自身は理解しています。公式ドキュメントに書かれている「最も通知が多い」ことや「インシデントを作成したエンティティに関する通知が必要な場合や、アラート通知を送信する外部システムがある場合に役立ちます」といった場合にメリットがあるとありますが、正直なところイメージし辛いのではないでしょうか。
例えば、WindowsやLinuxなどで複数のドライブを接続・マウントしている場合を想像してみてください。WindowsサーバにCドライブからFドライブに分けて構築するケースってないでしょうか。よくあるパターンとしてActiveDirectoryをインストールする際にADのデータベースをDドライブに、SysvolをEドライブに、ログをFドライブにというケースや、Windowsファイルサーバを構築する際に、ファイルサーバ領域をDドライブに構築するケースなど、ディスク枯渇によるシステム影響を減らすような構成をとるケースはそれなりにあると思います。
こういった場合に、監視設定を行うとディスク容量監視（Ｃドライブ）、ディスク容量監視（Ｄドライブ）、ディスク容量監視（Ｅドライブ）・・・とやると、設定大変ですよね？New Relicではこういった場合の監視設定をアラートコンディション１つだけで実現することができます。つまり、ひとつだけのアラート設定で複数ドライブの監視をおこなうことができるのですが、このケースの場合にOne issue per conditionで設定してしまうと必要なアラートが届かなくなる場合があるため、One issue per condition and signalで設定をおこないます。
通知設定の違い：WorkflowとDestination
ここまではポリシー設定のお話でしたが、ここからは通知設定のお話となります。 New RelicではWorkflowを用いてアラートの通知をおこないます。Workflowではアラートコンディションで発生したインシデントを細やかに制御して実際の通知先であるメールアドレスやSlackなどへ通知することができます。ここからもう少し掘り下げて通知設定を見ていきましょう。
Destination設定
Workflowの通知先となるメールアドレスやSlackチャンネルなどを設定します。WorkflowとDestinationは１：１の関係となります。
Workflow設定
Workflowでは発生したインシデントをどのように通知先に流すかといった設定をができます。
例えば、特定のポリシーに紐づくアラートコンディションと、別のポリシーの中にある一部のアラートコンディションで発生したインシデントだけを通知するような制御をおこなうことができます。もちろん、特定のNew Relicアカウントで発生したイシューをすべて同じアカウント内にあるひとつのWorkflowで通知するようなこともできます。最終的にはマルチアカウントで利用されている場合の他に、ポリシー、コンディションをどのように管理するかといった観点でWorkflowやポリシーの通知設定をご検討いただくのがいいと思います。
なお、通知条件の制御は、ポリシーID、ポリシー名やコンディションID、コンディション名以外にNRQLクエリ、タグ情報など様々な条件を指定することができます。
まとめ
New RelicのポリシーやWorkflow設定は若干取っつきにくい反面、うまく設定すればとても便利で細やかな通知制御ができます。ここまでの情報を整理してみると、ポリシーではリソース単位やサービス単位で設定を管理し、Workflowでは誰にどのような手段で通知をするという設定をおこない、その通知先グループ毎にポリシーやコンディションを整理していくといいのかもしれません。
当記事がどなたかのお役に立てれば幸いです。
参照元
宣伝
弊社では、お客様環境のオブザーバビリティを加速するための伴走型のNew Relic導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。
