New Relic Infrastructureで何が出来るのか ~アラート編~

New Relic Infrastructureとは

New Relic Infrastructure はパブリッククラウド, コンテナ, OS,ミドルウェア, Network, OSS等の情報を収集することができるNew Relic のサービスです。

 

インフラ監視の基礎

インフラ監視ツールでは以下の4要素が共通する要素として存在します。

リソース監視、プロセス監視、機器監視、アプリケーション監視、ログ監視など世の中でシステム監視と呼ばれるものには複数の意味がありますが
システム監視を行う目的はシステムの安定稼働およびシステム稼働効率の最適化を行うことです。

今回はNew Relic Infrastructureでの「通知」について解説します。

通知を考慮する

通知設定において重要なことは全て通知することではなく、対応する必要がある内容を通知することです。
通知しても読まれないメール、届いても何も作業を行う事が無い通知などが多くなれば本当に必要な通知が埋もれ
通知の見落としにも繋がってしまいます。

重要なのはその後の対処に繋がる通知を行う事です。
これはメールによる人への通知だけではなく、システムに対して行う連携通知も同様です。

New Relicの通知設定

New Relicの通知はAlerts メニューに集約されています。
これは、今回ご紹介しているNew Relic Infrastructureだけではなく、New Relic APM やNew Relic One といった他のServiceでも同様で
通知設定は同一のAlerts 画面に集約されます。

New Relic Infrastructure 画面

 

New Relic APM画面

 

New Relic One画面

New Relic Infrastructureで何が出来るのか ~閾値編~で紹介した閾値設定もNew Relc Alerts の中に設定されます。

 

New Relc Alerts の構成

New Relic Alerts の設定は「ポリシー(判定条件および通知先設定の集合)」「コンディション(判定条件)」「Notification channel(通知先)」から構成されます。
New Relic Alertsのワークフロー図

また、ポリシーには通知動作の条件として「By policy」,「By condition」 ,「By condition and entity」が存在します。

 

By policy
  • アラートポリシー毎に1つの通知を作成します。
  • ポリシーの中に複数のコンディションが登録されている場合、障害発生中に別の閾値越えが発生した場合はインシデントの追加情報として処理され
    新たなインシデントは生成されません。
By condition
  • ポリシーの中で設定した個別の条件(condition)毎にインシデントを生成します。
  • 障害発生中に別の閾値越えが発生した場合には新たなインシデントが生成されます。
  • コンディション設定の中で複数のアプリケーション(エンティティ)が登録されている場合、
    障害発生中に別のエンティティで同様の閾値越えがが発生した場合は
    追加情報となり、新たなインシデントは生成されません。
By condition and entity
  • アラートポリシーの中に含まれる、全てのコンディション、全てのエンティティ毎に、インシデントが生成されます。

 

アラートポリシーの中には複数のコンディションを登録することができます。

このコンディション設定の中で判定条件として閾値を設定する要素がコンディションになります。
APMのメトリクスやInfrastructureなどがコンディションとなります。

 

そして、評価対象となる個々のアプリケーションやサーバーなどがエンティティとなります。

ポリシーの動作条件の設定によりアラートポリシーの意味合いがことなります。

アラートポリシーのインシデントプリファレンス

アラートポリシーの動作条件をNew Relicではインシデントプリファレンスと呼びます。

インシデントプリファレンスによってアラートポリシーが持つ意味合いが変化します。

 

By policy
  • アラートポリシー自体が1つのインシデントチケットになります。
  • 個々のコンディション設定は同時に発生した付加情報として見えます。
  • 障害対応チームが全体を見渡して、障害対応を行うような設定に向いています。
By condition
  • トラフィック増大やレスポンス劣化など事象毎にインシデントチケットが生成されます。
  • 複数のアプリに渡った同一事象は付加情報として見えます。
  • 複数のアプリに跨がる対策を立案するような管理者や専門家を通知先とするような設定に向いています。
By condition and entity
  • 全ての条件毎に別々のインシデントのチケットが生成されます。
  • アラートポリシーは個々の障害を表すのではなく、通知先をグルーピングしたHUBのような位置づけとなります。
  • インシデントチケット管理システム等と連携して1つの通知設定で多くの通知を行いたいような場合に向いています。

 

New Relic Alarts の通知先

New Relic Alertで利用する通知先はNotification channelに登録を行います。
Notification channelではEmailの他サードパティーのチケット管理ツールやチャットサービスと連携が可能です。

さらにwebhookに対応しているので、独自の管理システムとも連携を行う事ができます。

Slack連携

Slackと連携を行う場合にはSlackAppとしてNew Relic Alertがリリースされています。


SlackのAppディレクトリからNew Relicを検索して導入を行ってください。

導入を行ったSlack AppでWebhook URLが表示されます。

ここで表示されたURLをNew Relic Notification channel設定に設定を行います。

 

Slackではリソースグラフ付きでAlertが表示されます。
また、View IncidentボタンをクリックすればAlertの詳細ページへ、Application Overview ボタンをクリックすればNew Relic APMページへとジャンプすることができます。

Slack通知であれば、作り込む事無くそのままチャットから概要確認やオペレーションを開始することができます。

Amazon EventBridge連携

2020年2月時点ではLimited Releaseのため、フォームからの申込みが必要ですがWebhookを利用して Amazon EventBridgeと連携を行う事ができます。

Basic Authに入力するためのUserName/パスワードが フォームからの申請後、New Relicから通知されます。

Amazon EventBridge 連携により、New Relicでの障害検知からAWS Lambdaの起動への繋ぐ事ができるようになりますので、
対応自動化などの作業がより設計しやすくなります。

New Relic Infrastructure のAlert設定

New Relicであれば、Infrastructureだけではなく、APMやSynseticsなど複数のサービスを組み合わせて通知を行う事ができます。
これにより、複合的な情報の見方を行いながら効率良く障害対応を行う事ができます。

また、利用できる情報が多いからこそ、対応が不要なAlertを設定しない
とりあえず通知しておくといった運用を行わないことが重要となります。

 


無料トライアル

New Relic株式会社 シニアテクニカルサポートエンジニア OSSの運用監視ソフトウェアの日本におけるテクニカルサポート、テクニカルトレーニングの立ち上げを行い、VMwareベースのクラウドサービス開発、AWSテクニカルサポート、クラウドアーキテクトを経て現職。 テクニカルサポート、テクニカルトレーニング、運用コンサルを専門領域としてお客様の運用負荷軽減を目指す。得意分野は運用設計、クラウド設計、OSSソフトウェア。 View posts by .