エラーのより迅速な優先順位付けと解決

ソフトウェアの構築は困難ですが、エラーの優先順位を決定するワークフローを進めるのはさらに難しくなる場合があります。稼働時間、信頼性、最終的に潜在的な収益損失の回避となると、顧客に影響を及ぼす問題の修正は一刻を争います。 

問題を迅速に解決するためには、最もミッションクリティカルなエラーに優先順位をつけて迅速に解決するためのエラーに関連した豊富なデータが必要です。New RelicのErrors Inboxの最新のアップデートは、エラー解決の意思決定を加速させる判断材料を提供し、顧客に影響を与える問題の解決に集中することで平均復旧時間（MTTR）の削減に役立ちます。

影響を受けたユーザーとアラートによるエラーの優先順位付け

最新のErrors Inboxの強化は、さまざまなエラーグループの重要度の優先順位の決定に役立ちます。 これにより、エラーグループによって影響を受けたユーザー数を表示し、メトリクスに基づきアラートを作成できます。最高のROIでエラーに集中できます。

エラーの影響を受けるユーザー数に基づき、New Relicのアラートを生成できます。影響を受けたユーザーに基づくアラートの設定を始めるの簡単なチュートリアルを参照してください。

エラーにリンクされたトレース情報を表示し、根本原因に迅速にたどり着きます。 

最新のアプリケーションには複数のコンポーネントまたはサービスがあり、問題の根本原因の特定が困難になります。さまざまなサービスがシステム間でどのように連携するかを完全に理解していない場合は、特に難しいです。特定のエラーメッセージを解読して故障箇所を特定したり、ツールを切り替えて発生した問題がなぜアプリケーションのパフォーマンスを低下させたのかを理解したりすることになるかもしれません。

Errors Inboxから直接ディストリビューティッド（分散）トレーシング へアクセスできるようになり、単一のビューで洞察を導き出し、エラーを分析できるようになりました。

エラーを選択すると、相関するトレースが表示され、リクエスト全体の概要と、その期間、スパン数、発生したエラーの概要がわかります。

Exploreを選択すると、より詳細な情報が表示されます。

そして、トレースの詳細と記録されたすべてのスパンの視覚的な表示とともに、リクエストのより詳細なビューを開くことが可能です。この可視化を活用することで、どこで問題が発生したかをすばやく特定し、その問題をより早く解決することに集中できます。

Slackを活用した、エンティティレベルでの コンテキストに沿ったコラボレーション

Slackとのインテグレーションについてご存知でしょうか。このたび、さらに一歩進んで、コンポーネントやワークロードといったエンティティの単位でSlackを通じたコミュニケーションをサポートし、チーム内のコラボレーションを強化することができるようになりました。

この統合の強化により、サービスやアプリケーションにフォーカスしたコミュニケーションが可能です。自分やチームが所有するアプリケーションに焦点を当て、コラボレーションを行うことができるようになりました。

Errors InboxとSlackの連携の詳細については、この動画をご覧ください。

または、以下の手順に従ってください。 

1. Slackワークスペースに New Relicアプリ がインストールされていない場合は、先にインストールします。
2. New Relic Errors Inboxの1つを開き、右上隅の通知設定アイコン（ベルのアイコン）を選択します。
3. Slackボタンがオフの場合は、選択してオンに切り替えます。
4. ワークスペースがない場合は、+ボタンを選択してSlackを有効化します。
5. 認証後は、ワークスペースと、通知を送信する特定のチャネルを選択できます。
6. Test を選択し、メッセージが正しいチャネルへ送信されたことを確認します。

影響を受けたユーザーに基づくアラート設定を始める

この新機能を最大限に活用するには、まずNew Relicに 影響を受けたユーザーのデータを送信中であることを確認する必要があります。次に、以下を決定することでアラートを設定します。

• 監視およびアラートを設定するエラーが発生しているエンティティ
• ユースケースに関して最も価値が高いアラートシグナル
• 組織にとって即座に価値をもたらすのはどのような閾値か

以下は、3つの基本手順によるクイックチュートリアルです。

1. アラートサービスの entity.guidを決定します。

基本的には、任意のNRQLのクエリに基づきアラートを作成できます。このチュートリアルの場合は、顧客に影響を及ぼすエラーが発生したエンティティに関するアラートを作成します。アラートを作成するエンティティがAPMサービスの場合は、ナビゲーションでAPM & servicesを選択してから、アラートを作成するサービスを選択します。以下のスクリーンショットで示すように、See metadata and manage tags（タグのアイコン）を選択して、entity.guidを検索します。

次に、以下の例で示すように、entity.guidをコピーします。 

エラーが発生しているコンポーネントやワークロード（ただし、これらに限定されません）にはエンティティが存在します。

詳細については、エンティティとは？ および 検索方法に関するドキュメントをご覧ください。

2. 影響を受けたユーザー数を取得するクエリを作成します。

影響を受けたユーザーを返すNRQLのクエリを作成するには、まずアラートに含めるサービスを決定し、その entity.guidを取得します。

  entity.guidを決定したら、クエリビルダーへ移動し、以下のNRQLのクエリを挿入します。 

entity.guid をアラートを作成するサービスのGUIDに置き換えます。

このクエリは、提供した entity.guidのサービスによって生成された各エラーグループによって影響を受けたユニークなユーザー数を返します。次に、影響を受けたユニークなユーザー数が閾値を超えたときにトリガーするアラートを定義する必要があります。 

クエリビルダーでこのデータをグラフ作成すると、必要に応じてクエリ文字列を調整できます。

アラートを設定したいシグナルを生成する文字列ができたら、Create alertを選択します。NRQLのアラート条件を設定するウィンドウが表示されます。

3. 影響を受けたユーザーメトリックに基づきNRQLのアラート条件を作成します。

インストゥルメントされたサービスで影響を受けたユーザー数を基準としてアラートを作成するには、NRQLのアラート条件を作成する必要があります。以下がその方法です。

Edit an alert conditionのウィンドウで、条件をトリガーする閾値を定義します。条件に外れた場合はハイライト表示され、特定のユースケースの最善の閾値決定に役立ちます。理想的な閾値はユースケースによって異なりますが、好ましい開始値はアラートをトリガーしない最小の値と違反期間です。

集合ウィンドウのチューニングは、ノイズの削減や、よりアクションを起こしやすいアラートを生成する上で役立つ場合があります。

ウィンドウが短すぎる場合、小さな閾値はいくつかの一時的なエラーから誤アラートを誘発し、大きな閾値は影響を受けているユーザーの緊急ではないものの継続的な流れを見落とすことがあります。詳細については、ウィンドウ期間を参照してください。

保存する準備ができました。アラート設定セクションを折りたたんで、Save conditionを選択します。

次に、アラートポリシーが作成され、デフォルト設定で有効化されます。詳細については、ポリシードキュメントを確認してください。 

注: 使用されるNRQLのクエリはエラーグループ別でまとめられます。つまり、エラーグループが違反期間の閾値を超えると、アラートをトリガーします。お客様のユースケースでは、各エラーグループごとの影響を受けた合計ユーザー数だけでなく、全体的な影響を受けた合計ユーザー数を測定する方がより適切かもしれません。この場合は、FACET句を削除できます。以下のサンプルクエリを参照してください。

また、1つのアラート条件で使用するエンティティのタイプは同じである必要はない点に注意してください。