この Blog Post は Best Practices for Getting Started With New Relic Alert Conditions の意訳です。
成功したDevOpsチームにとって、アラートは不可欠なプラクティスです。アプリケーションのすべてのサービスを毎日1秒おきに見ることはできませんが、サービスに障害が発生した場合は、すぐにアクションを起こす準備ができている必要があります。New Relic Alertsは、あなたのチームの適切なメンバーが、可能な限り迅速に必要な警告を得ることを確実に実現できます。監視対象のアプリケーション、ホスト、またはその他のエンティティが事前定義されたアラート条件をトリガーした場合、New Relic Alertsは自動的に通知します。
ただし同時に、チームは「アラート疲れ（Six Steps to Combat Alert Fatigue）」を最小限に抑える必要があります。アラート疲れによりインシデント対応プロセスでケアレスミスやコミュニケーションミスにつながりやすくなります。New Relic Alertsを使用すると、主要なメトリックに焦点を合わせたアラートポリシーと条件を簡単に管理しながら、予想される振る舞いを除外できます。
簡単に始めるために、New Relic BrowserとNew Relic APMでインストゥルメントされたアプリ、およびNew Relic Infrastructureで監視されているホストのアラート条件を設定するための、実地でのベストプラクティスに基づいた提案のリストを作成しました。これらの提案は、New Relic Alertsの使用を開始したいチームや、ワークフローを改善したいチームにとって最適な出発点となります。
注：この投稿はアラート条件のみを対象としています。組織の構造とインシデント対応ワークフローに基づいてアラートポリシーを作成する必要があります。場合によっては、New Relicアカウント全体に及ぶ条件を含むアラートポリシーが存在する場合があります。他の状況では、1つ以上のアプリまたはホストに条件をスコープする必要があります。同様に、成熟したDevOpsチームの場合、ブラウザー、APM、およびインフラストラクチャの条件を同じポリシーにグループ化し、アプリまたは製品ごとにセグメント化できます。より伝統的な構造のチームは、インフラストラクチャ、APM、およびブラウザの条件を異なるポリシーに分離したい場合があります。
New Relic Alertsにまだ慣れていない場合は、始める前に以下を確認してください。
- アラートのドキュメント（NRQLクエリ用のアラート条件を作成する、ベースラインアラート条件の作成、および外れ値検出を含む）
- Getting Started with New Relic Alerts: Best Practices That Set You Up for Success
また、次の2つの用語に精通している必要があります。
- しきい値：これらは、違反と見なされるものを定義するアラート条件設定です。しきい値には、違反をトリガーするためにデータソースが渡す必要がある値と、違反を定義する時間関連の設定が含まれます。例えば：
- アプリケーションの平均Web応答時間が、15分間で5秒を超えている。
- アプリケーションの1分あたりのエラー率が、少なくとも1時間に1回は10％以上に達する。
- アプリケーションのAJAX応答時間が、予想されるベースライン動作から一定量逸脱する。
詳細については、アラート条件のための閾値の設定に関するNew Relicのドキュメントを参照してください。
- ベースライン：ベースラインアラート条件を使用して、データの動作に合わせてしきい値を定義できます。ベースラインは、次のアラート条件を作成するのに役立ちます。
- データが異常に振る舞っている場合にのみ通知します。
- 毎日または毎週のトレンドを含む、変化するデータとトレンドに合わせて動的に調整します。
- 未知の振る舞いを持った新しいアプリケーションのためにすぐに使用できます。
詳細については、ベースラインアラート条件の作成に関するNew Relicのドキュメントを参照してください。
ブラウザアプリケーションのアラート条件の構成
New Relic Browserで監視しているフロントエンドアプリケーションのアラート条件を開始するためのベストプラクティスとして、次の例を使用してください。
| 条件 | 使用法 |
|---|---|
| 条件ページビューの読み込み時間のしきい値条件 | 使用法ページの読み込み時間が許容されるしきい値を超えた場合にアラートをトリガーします。 |
| 条件ページビュースループットのベースライン条件 | 使用法突然のトラフィックのドロップまたはスパイクに対してのみアラートをトリガーします。（ベースライン条件により、予想されるトラフィックの変動を考慮してノイズを減らします。） |
| 条件JavaScriptエラーのしきい値条件 | 使用法ブラウザアプリケーションにJavaScriptエラーが表示されたときにアラートをトリガーします。 |
| 条件AJAXリクエストの応答時間に関するベースラインスループット条件 | 使用法バックエンドサービスにアクセスするAJAXリクエストがネットワーク遅延に影響する場合にアラートをトリガーします。 |
| 条件主要なページアクション（ボタンクリックなど）のベースラインスループット条件 | 使用法他のアラートを発生させないユーザー動作の変更に対してアラートをトリガーします。たとえば、CSSの変更により「チェックアウト」ボタンが表示可能な画面から移動した場合、エラーや応答時間が急増することはありませんが、カスタマーエクスペリエンスに影響します。 |
APMアプリケーションのアラート条件の構成
New Relic APMでインスツルメントしたアプリケーションのアラート条件を開始するためのベストプラクティスとして、以下の例を使用してください。
| 条件 | 使用法 |
|---|---|
| 条件Webトランザクション時間とApdexのしきい値条件 | 使用法アプリケーションがWebトランザクション時間またはApdexのしきい値を満たしていない場合にアラートをトリガーします。 |
| 条件トランザクションスループットのベースライン条件 | 使用法突然のトラフィックのドロップまたはスパイクに対してのみアラートをトリガーします。（ベースライン条件は、予想されるトラフィックの変動を考慮してノイズを減らします。） |
| 条件エラー率のしきい値条件 | 使用法アプリケーションのエラー率の増加についてアラートをトリガーします。APMアプリケーションの場合、このしきい値は0でなければなりません。 |
| 条件主要な外部リクエストのベースライン応答時間とスループットアラート | 使用法アップストリームサービスプロバイダー（支払いゲートウェイなど）が遅延を引き起こしている場合にアラートをトリガーします。 |
| 条件負荷分散アプリケーションの場合、スループット、応答時間、およびエラー率に関する外れ値検知は、ホストによってファセットされます | 使用法単一のホストにローカライズされたアプリケーションの問題に関するアラートをトリガーします。ホスト固有の条件は、根本原因分析のトラブルシューティングに役立ちます。たとえば、クラスター内のノードがトラフィックの受信を停止した場合、他のすべてのノードには影響しませんが、トラブルシューティングを行う必要があります。 |
| 条件個々の高価値トランザクションのベースラインスループットと応答時間の条件 | 使用法チェックアウトやログインなど、価値の高いトランザクションの変動に関するアラートをトリガーします。これらは、トランザクション全体のごく一部を表すことがよくあります。 |
インフラストラクチャホストのアラート条件の構成
New Relic Infrastructureで監視しているホストのアラート条件を開始するためのベストプラクティスとして、次の例を使用してください。
| 条件 | 使用法 |
|---|---|
| 条件各ホストのCPU、メモリ、I / O、およびストレージのしきい値条件。 | 使用法ホストの全体的なヘルスのこれらの基本的なメトリックのいずれかが、許容されるしきい値を超えた場合にアラートをトリガーします。 |
| 条件各ホストの「ホストが報告していない」状態 | 使用法ホストが突然クラッシュしたり、意図せずにシャットダウンした場合にアラートをトリガーします。 |
| 条件必要なキャパシティで実行されていることを確認するための主要プロセスのしきい値条件（Java仮想マシン、ログウォッチャーなど） | 使用法JVMなどのプロセスが受け入れられたしきい値を超えると、アラートをトリガーします。これらは、スループットの異常値などの他のアラートと連動してトリガーされ、根本原因分析に役立ちます。 |
次のステップ：アラート戦略は、効果的に実装されると、DevOpsチームの成功にとって最も重要な部分の1つになります。以下を学習するには、Effective Alerting in Practiceを確認してください。
- 最新の技術スタックの変化がアラート戦略の変化にどのようにつながっているか
- 動的な環境およびスケーリングされた環境向けのアラートのベストプラクティス
- 組織およびチームに役立つアラートシステムを設計および保守する方法
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
