本番環境でのアプリケーションのエラーの調査と追跡に、いつもぎりぎりまで時間をかけすぎていませんか?そうであれば、そのエラーが致命的な危機へ発展する前に、積極的に検出し修正するためにはどうすればいいのかを悩んでいるかもしれません。おそらく、優れたコードを本番環境に確実に実装するため、すでにE2Eテストや継続的インテグレーション、その他のベストプラクティスは活用しているでしょう。しかし、たとえそうだとしても、特にアプリケーションが大規模で複雑になっている環境では、いまだにストレスの多いエラーに遭遇するはずです。
だからこそ、顧客に影響を与える重大なエラーを、チケットが切られる前に追跡できるシステムを整備しておくことが重要なのです。そうしなければ、開発者たちは、エラーの特定と選別を行う際の面倒とその付随コストに対処しなければならなくなります。このプロセスを効率化し、開発者の作業負担を軽減するため、New RelicはErrors Inboxを提供しています。そこで全てのエラー通知を1カ所で能動的に受け取り、それらのエラーに関するチーム間のコミュニケーションを容易にします。
受動的アプローチから積極的アプローチへ
多くのチームは、エラー率からエラーを追跡し、事前に定義された閾値を超えた場合にのみアラートを受け取ります。さらに悪いのは、顧客やその他のエンドユーザーがエラーを発見し、チケットを切る場合です。顧客に影響するエラーを、それが起こってしまってから知るというのは、ありがちな問題です。
エラー追跡のソリューションは、開発者が重大なエラーに対してより積極的に対応できるようにするために導入されました。エラー追跡のソリューションでは、類似したエラーをまとめ、どのアプリケーションやサービスが問題になっているのかを特定することができます。また、エラーグループの選別が容易になり、重要なエラーを適切なチームにアサインし、重要でないエラーは無視したり優先度を下げたりすることができます。
フルスタックのエラーを1つの画面で追跡
New Relicは、常に開発者のことを念頭に置いてソフトウェアを開発しています。Futurestack 2021で発表したNew Relic Errors Inboxも、そのあらわれです。Errors Inboxは、New RelicのFull-Stack Observabilityライセンスに含まれるエラー追跡ツールです。
Errors Inboxは、スタック全体にわたるあらゆるエラーの対応を集約するワンストップ・ショップとなるべく開発されました。これには、New RelicのAPM、RUM(Browser)、Mobile、そしてServerless(AWS Lambda Function)モニター別に特定されたエラーが含まれます。今後は、根本原因の迅速な特定に必要なコンテキストを提供する豊富な相関データをもとに、単一の画面で能動的にエラーを検出、選別することができます。
チームや時間をまたぐコラボレーションを可能に
分散システムにおけるエラーのトラブルシューティングは、調査に時間がかかったり、誰にエラー修正の責任があるかの論争になりがちです。ノイズを低減するため、New Relic Errors Inboxは関連するエラーをエラーグループにまとめ、全チームに同じビューを提供します。アカウントやスタックトレース、属性などの詳細情報をもとに、何が問題でどのチームに責任があるのかをより簡単に判断できます。共有されたコメントは全チームに表示され、いろいろなチームが問題について発言しやすくなります。
また、エラーデータは存続します。エラー解決後も、全てのコメントやリンク、コンテキストが保存されます。のちに問題が再発した際に、以前の詳細やこの問題解決に誰が携わったかをすぐに確認できます。
Slackでの通知の受け取り
もし、すでにSlackなどのコミュニケーションツールでの協働業務に慣れている場合、Errors InboxにはSlackへのインテグレーションが組み込まれているため、送られてきたエラーの詳細を能動的に適切なチャネルに通知することができます。設定は簡単です。
1. 特定のErrors Inbox画面の右上にあるInbox Settingsアイコンを選択し、ワークスペースとチャネルを選択します。
2. 通知を送りたいSlackのWorkspaceとChannelを選択します。Testをクリックして、テストメッセージをチャネルに送信します。正しく動作していることを確認したら、Saveをクリックします。
3.設定完了です!以降、選択したSlackチャネルにエラー通知が流れてくるようになります。
本番環境に影響する前にエラーを捉える
それぞれのInboxは、New Relicのワークロードに紐づけられています。ワークロードでは、ターゲットのモニタリングを行うために特定のアプリケーションやサービスをグループ化できます。Errors Inboxを使用する際のベストプラクティスは、本番環境、開発環境に合わせ、別々のワークロードを作成することです。そうすることで、開発環境での新たなエラーが通知され、開発プロセスで発生した問題を先取りすることができます。
ワークロードの設定
これまでワークロードを設定したことがない場合、以下の手順で迅速に作成できます。
- New Relic OneのWorkload viewsに移動します。
- 右上のCreate a workloadをクリックします。
- 名前を入力し、検索バーを使用してアプリケーションやサービスを名前、タグ、またはエンティティタイプ(Lambda関数やMobile Appsなど)で検索します。
- 追加したいエンティティ、タグ、グループの横にある+Addをクリックします。個別のエンティティではなくタグやグループを追加するメリットは、タグやグループの更新が自動的にErrors Inboxに反映されることです。
- 追加後、右下のCreate a workloadをクリックします。
ワークロード作成の詳細はこちらでご覧いただけます。
今すぐErrors Inboxを使いはじめる
ワークロードの設定ができたら、Errors Inboxの設定は簡単です。
1. Errors Inboxタブに移動します。左上のドロップダウンメニューからWorkloadを選択します。
2. 各行でエラーグループが示されます。右側で、ユーザーを選択し、その人をエラーグループにアサインできます。
3. エラーグループをクリックすると、アカウント、スタックトレース、属性などの詳細が表示されます。データの種類により、表示される詳細の内容は異なります。
4. Commentsタブで、エラーについてのコメントを入力したり、他のユーザーのコメントを確認できます。
これで完了です。たった数分の設定で、スタック全体にわたるあらゆるエラーを1カ所で追跡し、その問題が顧客に影響する前に、選別と修正を容易に行えるようになります。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。