7
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

New Relic クロスアカウントアラートで実現!チーム別アラート管理の始め方

Last updated at Posted at 2025-06-19

 New Relic に新しく加わった「クロスアカウントアラート機能」を使って、アプリケーションやインフラなどチーム間の責任範囲を明確化し、アラート運用を最適化する方法をご紹介します。

 システム運用でアラートが多すぎたり、誰が対応すべきか曖昧になったりしていませんか?あるいは、アラート設定が複雑になりすぎて、特定の担当者しか変更できない状態に悩んでいませんか?

 この記事では、New Relic のクロスアカウントアラート機能を活用し、これらの課題を解決する具体的な方法を解説します。特に、複数チームでNew Relicを利用しているケースで、各チームが自律的にアラートを設定・管理できるようになるための、詳細な設定手順に焦点を当ててご紹介します。

はじめに

 システム運用において、アプリケーションやインフラの監視は不可欠です。しかし、システムが複雑化し、関わるチームが増えるにつれて、アラート管理にはさまざまな課題が生まれています。

最新のアップデートの詳細はこちら
New Relic アップデート一覧

無料のアカウントで試してみよう!
New Relic フリープランで始めるオブザーバビリティ!

システム運用におけるアラート管理の課題

 多くの組織では、以下のような問題に直面しているのではないでしょうか。

アラートの多さとノイズ:
 監視項目が増えるほどアラートの数も増え、本当に対応が必要な重要なアラートが、他のアラートに埋もれて見過ごされてしまう「アラート疲れ」が発生しやすくなります。

責任範囲の不明確さ:
 アプリケーションとインフラ、あるいは複数のサービスが密接に連携している環境では、アラートが発生した際に「これはアプリの問題なのか、それともインフラの障害なのか?」と、対応すべきチームの判断に時間がかかったり、責任の所在が曖昧になったりすることがあります。

通知のサイロ化と重複:
 各チームが個別に監視ツールや通知チャネルを設定していると、同じ事象に対して複数のアラートが異なる場所から届いたり、逆に必要なチームに通知が届かなかったりする「通知のサイロ化」や「重複」が発生しがちです。

アラート設定の複雑化と属人化:
 一つのアカウント内で全てのアラート設定を行っていると、アラートポリシーが肥大化し、誰が何を設定したのか、どの設定が現在有効なのかが把握しにくくなります。その結果、特定の人しかアラート設定を変更できない「属人化」が進むこともあります。

New Relic クロスアカウントアラートが解決する問題

 New Relic のクロスアカウントアラート機能は、これらの課題に対する強力な解決策を提供します。この機能を使うことで、異なる New Relic アカウント間で監視データを共有し、それぞれのアカウント内で独立してアラート条件を設定・管理できるようになります。

 これにより、例えばインフラチームが提供する共通のインフラ基盤(例: Kubernetesクラスター、DBインスタンス)の稼働状況メトリクスを、各アプリケーションチームのアカウントから参照し、それぞれのアプリケーションの特性に応じた閾値でアラートを自律的に設定するといった運用が実現できます。キャッシュヒット率のアラートは、インフラチームのキャッシュデータを利用しつつ、アプリのパフォーマンスに直結するヒット率低下を検知するために設定します。

概要図.png

 具体的の例としては、インフラチームが管理するキャッシュインスタンスのデータを活用し、アプリチームがキャッシュヒット率の低下を検知するアラートを設定できます。これは、インフラ稼働に問題がなくても、アプリのパフォーマンスに直結するヒット率低下を早期に把握するために有効です。

今回のポイント

この記事で紹介しているポイントは、次の3つです。

  1. New Relic クロスアカウントアラートの基礎知識を学ぶ
     New Relic の異なるアカウント間で監視データを共有し、アラートを設定するクロスアカウントアラート機能の基本的な概念、目的について解説します。
  2. クロスアカウントアラートの具体的な設定手順を理解する
     データ共有の有効化から、NRQLを用いたアラート条件の作成、さらにはチームごとの通知(ワークフローとDestinationの設定)まで、実践的な設定方法をステップバイステップで解説します。

 これにより、各チームが自身の担当領域に集中し、効率的かつ効果的にシステムの状態を監視し、迅速な問題解決へと繋げられるようになることを目指します。

New Relic クロスアカウントアラートの基礎知識を学ぶ

 New Relic のクロスアカウントアラート機能がどのようなものか、なぜそれが重要なのかを解説していきます。

機能概要と目的

 New Relic のクロスアカウントアラートとは、一言でいうと「ある New Relic アカウントに転送されたテレメトリデータ(メトリクス、イベント、ログなど)を、別の New Relic アカウントで参照し、そのデータに基づいてアラートを設定できる機能」です。

なぜこのような機能が必要なのでしょうか?主な目的は以下の通りです。

  • アラート管理の明確化:
     システム全体を複数のチーム(例:アプリケーションチーム、インフラチーム、データ基盤チームなど)が分担して管理している場合、それぞれが自身の責任範囲でアラートを設定・管理できるようにします。これにより「このアラートはどのチームが設定したの?」「このアラートは誰が対応するの?」といった曖昧さを解消できます。

  • 権限の最小化:
     アカウントへのアクセス権限を活用して各チームが必要な機能・データのみにアクセスできるよう権限を細かく制御できます。これにより、誤った設定変更のリスクを防ぎつつ、本番環境の重要なアラート設定を安全に運用することが可能です。

  • 設定の整理と複雑性の軽減:
     すべてのアラート設定を単一のアカウントで行うと、アラートポリシーや条件が膨大になり、管理が複雑化します。クロスアカウントアラートを利用することで、アラート設定をチームや用途に応じて別のアカウントに分離し、見通しを良くすることができます。

  • 自律的な運用:
     データを共有された側のアカウント(アラート設定アカウント)では、自身の業務やアプリケーションの特性に合わせて、自由にアラートの閾値や通知方法を設定できます。データ提供元に設定変更を依頼する手間が省け、より自律的な運用が可能になります。

データ共有の仕組み

 クロスアカウントアラートは、New Relic の「組織(Organization)」の中で管理されているアカウントに利用できる機能です。組織内の特定のアカウント間で、監視データを共有する設定を行うことで、この機能が利用可能になります。

 データ共有の際、アカウントは、主に以下の2つの役割を持ちます。

  • データソースアカウント:
     実際にアプリケーションやインフラからメトリクス、イベント、ログなどの監視データを収集し、保有している New Relic アカウントです。このアカウントのデータを、他のアカウントがアラート条件の設定に利用できるようになります。
  • アラート設定アカウント:
     データソースアカウントから共有されたデータを参照し、そのデータを使ってアラート条件やポリシーを設定する New Relic アカウントです。このアカウントは、自身の責任でアラートを管理します。

データ共有の有効化は、データソースアカウント側で設定しますが共有するかどうかのみ設定できます。どのアカウントにデータを共有するかを個別に設定することはできません。

クロスアカウントアラートの具体的な設定手順を理解する

 ここでは、実際に New Relic のクロスアカウントアラートを設定するための具体的な手順を解説します。大きく分けて「データ共有の有効化」「アラート条件の作成」の2つのステップで進めていきます。

ステップ1: データ共有の有効化

 クロスアカウントアラートを利用するための最初のステップであり、最も重要な設定です。これにより、データソースアカウントの監視データを、アラート設定を行うアカウントで参照できるようになります。

1. データ共有設定画面へのアクセス:
 New Relic の UI 上で、組織の管理者権限を持つユーザー(Organization Managerロールが必要)でログインし、左側のメニューから Alerts > General へと進みます。

2. データ共有の有効化:
 Generalの設定画面には、Cross-account alerts が表示されています。ここで、データを共有したいアカウント(データソースアカウント) を右上のアカウント選択ドロップダウンから選びます。
 次に、[Allow other accounts to create alert conditions from this account's data] のチェックボックスにチェックを入れ、Save ボタンをクリックすると有効化は完了です。

crossAccountAlerts.png

補足: データ共有の設定は Organization Manager ロールでのみ実行可能です。また、データソースアカウント側でデータ共有を有効に設定すると、組織内の他のアカウントからそのデータを参照できるようになります。

ステップ2: アラート条件の作成

 データ共有が有効になったら、次はいよいよアラート設定アカウント側でアラート条件を作成します。ここでポイントとなるのが、NRQL (New Relic Query Language) で共有されたデータを参照する方法です。

1. アラート設定アカウントへの切り替え:
 アラート条件を作成したい New Relic アカウント(アラート設定アカウント)にログインしていることを確認します。

クロスアカウントアラートの設定にはデータソースアカウントへの参照(view)権限が必要です。

2. アラート条件の作成:
 Alerts > Alert conditions へと進み、「New alert condition」 を選択します。アラート条件のタイプとして 「Write your own query」 を選びましょう。

3. NRQL でのクロスアカウントアラートの設定方法:
 データ共有が有効になっていると、クエリビルダーの左上にアカウント選択ドロップダウンが表示されます。

初期表示.png

 「Contdition owner」 に表示されているのが Alert condition の所有アカウント(アラート設定アカウント)です。通常、アラート条件で参照するデータとアラート設定アカウントは同じになりますが、クロスアカウントアラートでは異なります。

 クロスアカウントアラートを設定するには、クエリビルダーの左上のアカウント選択ドロップダウンで データソースアカウント(画像では application ) を選択します。

ドロップダウン.png

 選択後、データソースアカウントに対してクエリを実行し、データが取得できることを確認してください。

クエリ.png

 データ取得が確認できたら、後は通常のアラート設定と同じ手順で閾値などを設定するだけです。

まとめ

 New Relic のクロスアカウントアラートは、単にアラートを設定するだけでなく、チーム間の責任を明確にし、複雑化しがちな監視運用をシンプルにするための強力なツールです。この機能を活用することで、以下のような未来を築くことができるでしょう。

  • アラート対応の迅速化と効率化: 各チームが自身の責任範囲でアラートを受け取ることで、誤った通知や責任のたらい回しが減り、問題解決までの時間を短縮できます
  • 権限管理の強化と運用の安全性向上: 最小権限の原則に基づき、各チームが必要なデータにのみアクセスできるよう制御することで、誤操作のリスクを低減し、本番環境の安定稼働に貢献します
  • 柔軟なアラート設計: チームのニーズやアプリケーションの特性に合わせた、きめ細やかなアラート設定が容易になります

 ぜひ本記事で学んだ設定手順を参考に、New Relic 環境でクロスアカウントアラートを導入してみてください。チーム間の連携をスムーズにし、よりスマートで効率的なアラート運用を実現するための第一歩となります。

New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています!
無料でアカウント作成も可能なのでぜひお試しください!

New Relic株式会社のX(旧Twitter)Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。

無料のアカウントで試してみよう!
New Relic フリープランで始めるオブザーバビリティ!

image.png

7
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?