プロアクティブアラートの設定：パフォーマンス問題を理解し対応

「アラート」という用語は、しばしば否定的な意味を有しています。多くの開発者にとって、アラートはエラーやミス、進行中の問題と密接に関連しています。ただし、アラートについて事前対策を講じる開発者は、効果的なアラートがチェックインのタイミングを示すため、ダッシュボードを1日中眺めている必要はありません。

アラートを入念に設定しておけば、システムの健全性を確認できるので、顧客に被害が及ぶ前にパフォーマンス問題に対処できます。アラートの量に圧倒される可能性があるため、アラートを調整し、AIを活用することで、重要な内容についてのみアラートを受け取ります。

前提条件

このチュートリアルでは、次のことを行っていると仮定しています：

• New Relicでアプリケーションのインストゥルメントを行っている。
• これを開始する前に、チュートリアル目的とベースラインを定めるを見直してください。
• オプション：追加されたカスタムアトリビュートとイベント。

1. サービスレベル目標に基づき、必要なアラートポリシーを定義する

サービスレベル目標（SLO）は、サービスのパフォーマンスを測定する、合意された手段です。SLOでは、指定された量的指標の目標値が規定されます。この目標値はサービスレベルインジケーター（SLI）と呼ばれます。サービスレベルインジケーターの例としては、平均応答時間やレスポンスタイムパーセンタイル、アプリケーションの可用性があります。SLOでは、次のようなSLIのターゲット値を明確にします：

• 平均応答時間は200ミリ秒未満であるべきです。
• 要求の95%は、250ミリ秒以内に完了させる必要があります。
• サービスの可用性は、99.99％である必要があります。

このSLOを論理的にグループ化し、サービスが期待を満たしているかどうかについての全体的なbooleanインジケーターを提供できます（例：「リクエストの95%が250ミリ秒以内に完了し、かつ可用性が99.99%」）。これは、アラートで有用です。

このSLIを主要パフォーマンスインジケーター（KPI）として使用することで、チームと組織はサービスを測定し、顧客の期待を満たしていることを確認できます。サービスで必要な定量的なパフォーマンスメトリックスを分析することで、どのような種類のアラートをそれぞれについて設定すべきかを特定できます。たとえば、ウェブのトランザクションタイムが0.5ミリ秒を超える、またはエラー率が0.20%を超える場合に通知するアラートを設定できます。

ただし、SLOを全てアラートにする必要はありません。堅固なアラート戦略では、SLOをシンプルなセットにして、アクションに結びつくアラートにします。New Relicは多くの場合、最も成熟したDevOps顧客は一般に設定しているアラートが少なく、アラートでは自らの顧客の体験でいつ本当に問題が生じているかを示す中心となる一連のメトリックスに重点を置いていることを把握しています。その結果、New Relic DevOps顧客は多くの場合、アラート戦略の一環としてApdexを使用し、アラートをユーザー満足度の低下の兆候に関連付けます。

アラート戦略を設計する際は、次の質問を念頭に置いてください：「顧客に影響がない場合、アラートを行うことに意味があるか?」

アラートを設定する分野の簡単なフレームワークについては、次の質問と、提案されたメトリックスおよびKPIを使用します：

2. パフォーマンス、正確性、スループット、可用性、および依存関係に固有のアラートの設定

New Relicを使用して、インストゥルメントされたアプリケーションやエンドユーザー体験、インフラストラクチャ、データベースなどで、アラートを設定できます。New Relicは、サイトの可用性が低下、またはエラー発生率がSLOで定義の許容水準を上回った場合、アラートを行います。警告閾値を設定し、深刻度が危険に近づいているがまだ通知を発信する段階にない問題を監視します。

いつアラートでチームに通知を行うかの閾値の設定は困難な場合があります。閾値が厳しすぎるとアラート慣れが生じ、緩すぎると顧客の満足度が低下します。

ベースラインアラートヲ使用して、過去のパフォーマンスに基づきアラートの閾値を動的に設定できます。ベースラインを使用して、アラートを適切な閾値に微調整します。たとえば、APMのアラートでは、ウェブのトランザクションタイムが、割り当てられた長さの時間について過去の実績から乖離すると、インシデント対応チームにアラートを通知できます。

これと同じ種類のアラートをBrowserで設定し、パフォーマンスを次善に最適化できます。次の例では、スループットの警告と違反の両方を設定しています：

使用期間の短いアーキテクチャで実行する小さな独立したサービスを開発する際には、環境はより複雑なものとなります。外れ値の可視化は、発生する可能性の高いパフォーマンス問題の理解で重要なツールとなります。外れ値がある場合に自動的に警告を行うようアラートを設定してください。これにより、ホストやロードバランサー、アプリの動作の異常を示すことができます。

たとえば、ロードバランサーは、5つの異なるサーバー間のウェブトラフィックをほぼ均等に分割します。あるサーバーのトラフィックが他のサーバーより大幅に増加または減少したら通知を送信するよう、NRQLクエリに基づきアラートを設定できます。グラフは次のとおりです：

NRQLクエリのサンプルは次のとおりです：

SELECT average(cpuPercent) FROM SystemSample WHERE apmApplicationNames = 'MY-APP-NAME' FACET hostname

静的なベースラインアラートと外れ値のアラートを設定しました。これにより、エコシステムを包括的に認識できます。

アラートの最適化の詳細については、New Relic Alertsドキュメントを参照してください。

3. アラート対象グループを特定し、伝達方法を設定

適切なブロードキャスト方法を使用しないでアラートを送信すると、脆弱性は改善されません。アラート戦略には、アプリケーションまたはアーキテクチャで問題が発生した場合に適切なチームに通知されるように通知チャネルを含める必要があります。New Relicには多くの通知インテグレーションがありますが、最初は単純なものを使用し、後で複雑なものを追加するようにしてください

アラートは最初にグループチャットチャネルに（一例としてSlackを使用して）送信することをお勧めします。アラートをリアルタイムで数週間にわたり評価して、どのアラートが重要または問題のある問題を示しているかを理解します。こうしたアラートは、誰かを目覚めさせる根拠となる種類のものです。

4. AIを活用してアラートを微調整し、異常を探す

通知をオフにしたり無視したりするようにチームをトレーニングしていないことを確認するには、アラートを有効で最新の状態に保ちます。New Relicを使用してアプリケーションとインフラストラクチャのパフォーマンスを最適化し、パフォーマンスの向上に合わせてNew Relic Alertsのポリシー条件を厳しくしていくことができます。アラートを最小限に抑えるには、Incident Intelligence{などのNew Relic Applied Intelligence機能を活用します。この機能は、関連するアラートを機械学習と手動入力を組み合わせた1つの解決可能な問題に関連付けます。アラートが正しく相関していることを確認し、最も正確なインシデント相関を取得するようにシステムをトレーニングします。

これ以外にも、アラートノイズを低減する方法には、フラップの検出と抑制があります。問題が「フラップ」している場合、問題はオープン状態と解決済み状態の間を循環し、循環するたびに新しいアラートが作成されます。これらを効果的に処理することで、チームに送信されるアラートの総数を減らすことができます。最後に、メンテナンスをスケジュールする場合は、アラートミュートルールを利用して、不要なアラートを抑制します。

アラートを有効な通知に調整したので、異常を事前に追跡して、問題がインシデントになる前に修正することができます。異常のプロアクティブ検知を有効にし、それらに一定レベルの通知を設定します。

5. アラートダッシュボードの作成

必ずアラートをチェックし、定期的にアラートが行われており、顧客満足のメトリックスと現在も関連していることを確認してください。New Relicプラットフォームを使用して、最も一般的なポリシー条件や違反について、アラートやインシデント中心のダッシュボードを作成します。

NRQLを使用してダッシュボードを作成します。詳細な手順については、Insightsへのアラートデータの送信をご覧ください（Insightsはクエリインターフェイスではなくなりましたが、同じコンセプトが適用されます）。

上記のダッシュボードは、次のNRQLクエリを使用して作成されました。アラートダッシュボードについて、必要に応じて再度作成することが推奨されます。

• 条件別のインシデント:

  SELECT count(*) FROM ALERT_NAME WHERE current_state = 'open' FACET condition_name SINCE 1 week ago

  コピー

• ポリシー別のインシデント:

  SELECT count(*) FROM ALERT_NAME where current_state = 'open' FACET policy_name SINCE 60 MINUTES AGO TIMESERIES

  コピー

• 期間中のアラートの傾向:

  SELECT count(*) FROM ALERT_NAME WHERE current_state IS NOT NULL FACET policy_name SINCE 1 week ago TIMESERIES

  コピー

• インシデントの詳細:

  SELECT timestamp, incident_id, policy_name, condition_name, details, severity FROM ALERT_NAME SINCE 1 week ago LIMIT 40

  コピー

このデータを可視化することで、使用しているアラートと閾値を絞り込むために他のユーザーと共有できるリソースが得られます。

通知チャネルについての広範な議論については、インシデントのオーケストレーションのチュートリアルを参照してください。

結論

特化型のアラートポリシーを用意しておけば、アプリケーションやインフラストラクチャのパフォーマンスに影響を与えるおそれのある劣化を、どんなものでも突き止めてくれます。プロアクティブなアラートによりユーザーが報告するインシデントが減少し、チームが問題解決に費やす時間が減り、より多くの時間を製品への重要な変更のディプロイに費やすことができるようになります。

その他のヘルプ

アラートのヒントとベストプラクティスの詳細については、次のドキュメントをご覧ください。

• New Relic Alertsでの動的ターゲティングによるアプリケーション監視の管理
• アラートポリシーのベストプラクティス
• New Relic Infrastructure監視のベストプラクティスガイド
• Infrastructureアラートの例

さらに支援が必要な場合は、これらのサポートと学習リソースを確認してください：

• Explorers Hubを参照して、コミュニティから支援を受け、ディスカッションに参加してください。
• 当社のサイトで回答を見つけ、サポートポータルの使用方法について学びます。
• Linux、Windows、およびmacOSのトラブルシューティングツールであるNew Relic Diagnosticsを実行します。
• New Relicのデータセキュリティとライセンスドキュメントを見直してください。