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

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

アラートを入念に設定しておけば、システムの健全性を確認できるので、顧客に被害が及ぶ前にパフォーマンス問題に対処できます。

前提条件

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

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を使用します:

質問 メトリックスとKPI
ビジネスに利用できますか? New Relic BrowserNew Relic APM は、サイト可用性に対するアラートに利用できます
基礎となるインフラストラクチャはどのようなものですか? 主要ハードウェア、ネットワーク、ストレージコンポーネントに対するKPIを設定します。
アプリケーションの正常性はどうですか? JVMのパフォーマンス、キューイング、キャッシング、同様の依存関係に対するメトリックスを追跡します。
アプリケーション全体の品質はどうですか? Apdexのスコアを使用してアプリケーション品質に迅速にアクセスします。
お客様はどうですか? 実際のエンドユーザーメトリックス(BrowserAPM)、合成ユーザー(Synthetics)、Apdexスコアを検討します。
全体のビジネスはどうですか? アプリケーション内のキートランザクションに注目し、アプリケーションとビジネスパフォーマンス間の相関関係を説明するために期待するビジネスの成果と結びつけます。

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

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

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

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

devops向けのプロアクティブなベースラインアラート
alerts.newrelic.com > (アラートポリシーを選択) > (アラート条件を選択) > Define thresholds

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

プロアクティブなベースラインアラート - Browserの閾値
alerts.newrelic.com > (アラートポリシーを選択) > (アラート条件を選択) > Define thresholds

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

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

outlier-alert.png
alerts.newrelic.com > (アラートポリシーを選択) > (アラート条件を選択) > Define thresholds

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

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

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

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

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

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

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

4. アラートと閾値の微調整

New Relicを使用してアプリケーションとインフラストラクチャのパフォーマンスを最適化し、パフォーマンスの向上に合わせてNew Relic Alertsのポリシー条件を厳しくしていくことができます。

新しいコードや、一定期間にわたってパフォーマンスに悪影響を与える可能性のある変更を展開する際には、これらの短期的な変更ができるように閾値の条件を緩和してください。一例として、当社では、事前に確立したベースラインと閾値を使用して、年次イベントや主要な発表など影響の大きな期間中に効率を高めることを推奨しています。微調整により、ニーズに柔軟に対応して効率を高め、通知チャネルを拡大できます。

以前お知らせしたように、当社では、通知を最初に確立する際にまずグループチャットを行うことを推奨しています。統合するその他のツールを特定した後、通知チャネルを設定しそのまま続けます。xMattersやPagerDutyのようなツールは一般的なインテグレーションを提供しますが、Webhookなどの簡単な方法も忘れないでください。アラートのスキームを継続的に改善することが目標です。

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

事前のベースラインアラート - ダッシュボード
insights.newrelic.com > All dashboards > (選択したダッシュボード)の順に移動します

New Relicクエリ言語InsightsクエリAPIを使用して、ダッシュボードを作成します。詳細な説明については、アラートデータの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

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

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

結論

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

その他のヘルプ

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

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