外形監視を正しく行う方法：ノイズではなくシグナルを伝えるスマートアラート

このシリーズのベストプラクティスを実践していれば、ブラウザ外形テストは今、よく調整された機械のように順調に稼働しているはずです。すぐに使えるダッシュボードは確実に情報を伝え、デジタルエクスペリエンスのパッシブ監視は安定して動作し、すべてがうまく機能しています。

どこかですでに申し上げたかもしれませんが、オブザーバビリティチームのリーダーである私は、外形テストで問題が検出されたら行動を起こせばよいことがわかっているので、夜はぐっすり眠れます。それだけ、チームが設定した外形テストは信頼性が高く、有意義で、実用的なのです。

この自信は根拠のないものではありません。重要な問題が発生したときにのみアラートを生成するよう、しきい値とディテクターを適切に設計する、スマートアラートのアプローチから生まれたものです。

この記事では、「外形監視を正しく行う方法」シリーズのベストプラクティス3「スマートアラート」についてご説明します。このシリーズを初めてお読みになる場合は、まず「はじめに」の記事で、これらのベストプラクティスを組み合わせてブラウザ外形テストの信頼性と実用性を高める方法の概要をご確認ください。

スマートアラートとは

スマートアラートは、ブラウザ外形テストを、単純な稼働状況チェックから、信頼できる実用的なシグナルへと変えます。そのために大切なのが、アラートの対象を調整し、不要な通知を除外し、重要なシグナルをチームの対応プロセスと関連付けることです。

以下のセクションでは、これらの設定を確実に行うための手順をご紹介します。適切なしきい値の設定、誤検知の削減、計画的メンテナンスへの対応、外形監視アラートとSplunk Observability Cloudの他のオブザーバビリティデータとの統合について説明します。

これらの技法を組み合わせれば、外形監視によって問題を早期に検出し、情報を正確に伝えて、適切に対応することで、プロアクティブなオブザーバビリティプラクティスを促進できます。

メリット

スマートアラートでは、コンテキストが提供されます。想定される動作、場所の違い、さらには既知のメンテナンス期間にも適応するため、チームは本当に重要な情報を把握できます。スマートアラートには以下のメリットがあります。

• ユーザーに影響を及ぼす本当に重要な問題を捕捉して、チームのアラート疲れを防ぐことができます。
• 外形監視アラートを行動開始のシグナルに位置付けて、問題があることを認識するだけの段階から、問題の発生場所、影響、詳細な関連インサイトを把握する段階にすばやく移行できます。
• すべての外形監視アラートが実用的で調査に値するものであるという確信を対応担当者に与えることができます。

目標は、アラート数を減らすだけでなく、アラートの品質を向上させることです。外形テストを適切に設計すれば、そのアラートをノイズの新たな発生源ではなく、信頼できるシグナルとして活用できます。

実践：スマートアラートの設定方法

スマートアラートを実装するには、以下の手順に従います。

1. 基本的な指標から始める：静的しきい値、ステータスコード、コア検証

Splunk Observability Cloudでは、外形テストを実行するたびに50以上のメトリクスが収集されます。DOMの読み込み時間からリソースのサイズまで、あらゆる指標が対象になります。データが非常に多いため、すべてのメトリクスからアラートを生成するのは得策ではありません。

可用性と応答時間のメトリクスはディテクターで重点的に使用し、ウェブバイタルやオブジェクト数など、その他のメトリクスはトリアージや分析で使用することをお勧めします。これにより、アラートでは信頼性に重点を置き、最適化に必要なメトリクスはノイズとして排除できます。

高度なしきい値の調整を始める前に、基本をしっかりと理解しておきましょう。

静的しきい値は、問題を検出するための最もシンプルで直接的な方法です。テストでサーバーに接続できない場合や、応答時間またはステータスコードが既知の制限を超えた場合は、ただちにアラートを生成する必要があります。このような、2つの状態を基準に判定するチェックは、アラートの信頼性のベースラインになります。

Splunk Observability Cloudでは、テストの全体的な健全性がダウンタイムメトリクスによって表されます。このメトリクスでは、選択した期間内におけるすべての実行の平均スコアが記録されます。実行失敗時のスコアは100、成功時は0で、結果の平均は、その期間内にテストがどの程度一貫して合格または不合格になったかを示します。

ダウンタイムには、テストで評価されるすべての項目(接続、HTTP応答コード、アサーション、TLS/SSL検証)が反映されます。ダウンタイムの増加は、監視対象のワークフロー内の重要なステップが期待どおりに動作しなかったことを意味します。

ダウンタイムの計算方法について詳しくは、Splunk Synthetic Monitoringのドキュメント「Browser test metrics (ブラウザテストのメトリクス)」を参照してください。

Splunk Observability Cloudで利用できるしきい値

Splunk Observability Cloudの外形監視ディテクターは、テスト、ページ、またはトランザクションの3つのレベルで設定できます。そのため、重視する項目に合わせてしきい値を調整できます。

Splunk Observability Cloudでは、ほとんどの外形監視ニーズに対応する基本的なしきい値タイプがサポートされます。静的しきい値では、明確な障害を検出できます。

突然の変化(Sudden Change)、外れ値の検出(Outlier Detection)、過去の異常(Historical Anomaly)など、より高度なオプションを設定すれば、急激な逸脱を検出したり、特定の実行環境に固有の異常を切り分けたり、長期的なパフォーマンスの劣化を特定したりできます。

外形テスト失敗の一般的な原因

これらはそれぞれ、ダウンタイムメトリクスに加算され、最終的にアップタイムメトリクスに反映されます。アップタイムメトリクスは、サービスの可用性やテストの成功率を時系列で把握するための概要レベルの指標です。

本稼働前のアラートのプレビュー

Splunk Observability Cloudでは、ディテクターの設定を本番環境への導入前にプレビューできます。アラートのプレビュー機能では、選択した期間内にアラートがトリガーされるはずのタイミングが表示されるため、設定が期待どおりに動作するかどうかを検証できます。

プレビューの結果に基づいて、本稼働前にアラートのしきい値レベルを微調整したり、ディメンションをフィルタリングしたり、ロジックを調整したりできます。プレビュー機能を使えば、外形監視アラートが必要なときに生成され、不要なときは生成されないことをすばやく確認できます。

詳細：Observability Cloudのディテクターアラートのプレビュー

2. 高度な機能を利用してノイズを低減する

静的しきい値とコア検証の設定が完了したら、次に、シグナルの品質を向上させるための設定を行います。テストの失敗が必ずしも実際のユーザーの問題を示すとは限りません。ネットワークの一時的なタイムアウト、サードパーティの動的なコンテンツ、読み込みに時間のかかるステップなどにより、不要なノイズが発生することがあります。

Splunk Observability Cloudには、ブラウザ外形テストのレジリエンスと信頼性を高め、本当に重要な問題に重点を置くために役立つ機能がいくつか用意されています。

自動再試行

外形テストは、ネットワークの一時的な中断、タイムアウト、サードパーティサービスでの短時間の問題によって失敗することがあります。自動再試行では、ダウンタイムイベントを記録する前に、失敗したテストを自動的に再実行し、こうした一時的な中断を除外することで、誤検知を減らすことができます。

自動再試行は常に有効にしておくことをお勧めします。この機能では、障害に関するデータの忠実性を維持しながら、偶発的なノイズを除去できます。再試行では追加のテストクレジットは消費されず、完了した最終結果のみがサブスクリプションの使用量にカウントされます。

除外ファイル

読み込みに時間のかかるサードパーティリソースや予測できないサードパーティリソース(分析タグ、広告サービス、埋め込みウィジェットなど)が原因で、ブラウザテストが意図せず失敗することがあります。

このノイズを排除するために、除外ファイルのルールを設定して、特定のパターンやドメインに一致するすべてのHTTPリクエストをスキップできます。この除外ルールは以下のために役立ちます。

• 分析やマーケティングのためのスクリプトによる意図しないアラートを防止する
• 特定のリソースを含む場合と含まない場合のパフォーマンスをテストする
• サードパーティの不要なポップアップや挿入コンテンツをブロックする
• 失敗や遅延を繰り返し引き起こすことがわかっているファイルを無視する

カスタム待機時間

読み込みに時間がかかるアプリケーションでは、外形テストが早い段階で失敗して終了することがあります。カスタム待機時間を設定すれば、テストで特定のステップが完了するまで待つ時間を調整できます。この機能は、読み込みに時間がかかるページや複数段階の認証を含むワークフローで特に役立ちます。

待機ステップを追加すると、テスト結果の精度が向上します。ページが一部表示されていない場合や、リソースがまだ読み込み中の場合に、テストが意図せず失敗するのを防ぐことができます。待機時間を使用するときのベストプラクティスは以下のとおりです。

• 検索、決済、レポート生成など、読み込みに時間がかかることがわかっているアクションの間に待機ステップを追加します。
• テスト全体の実行時間が妥当な範囲に収まるようにします。
• ステップごとの最大カスタム待機時間は200秒、アサーションステップの場合は90秒です。

自動再試行、除外ファイル、カスタム待機時間を組み合わせれば、誤検知を減らし、ブラウザ外形テストでより有意義な結果を得ることができます。しきい値に達する前にノイズを排除することで、真のカスタマーエクスペリエンスを反映する、より正確なシグナルと信頼性の高いアラートを生成できます。

3. オブザーバビリティを統合してコンテキストを強化し、行動につなげる

スマートアラートの価値を引き出すには、行動につながる情報を提供することが大切です。そのためには、外形テストが失敗した時点でのコンテキスト(影響範囲、影響を受けるユーザー、トラブルシューティングの出発点など)が必要です。

Splunk Observability Cloudでは、Synthetic Monitoring、RUM、APM、ITSIの関連データにアクセスできるため、問題が発生したことだけでなく、その原因もすばやく把握できます。

Splunk RUMとの統合

ブラウザ外形テストをSplunk Real User Monitoring (RUM)とリンクさせることで、テスト実行時のウェブバイタルメトリクスを自動的に収集できます。これにより、外形テストのパフォーマンスと実際のユーザーエクスペリエンスを比較して、問題が内部にとどまっているのか、顧客にまで影響が及んでいるのかをすばやく判断できます。

外形テストとAPMスパンのリンク

APMとの統合により、外形テストのスパンをバックエンドのトレースと直接リンクさせることができます。これにより、フロントエンドでのブラウザ操作からバックエンドサービスの動作まで、エンドツーエンドで可視化して、問題の原因になっているコンポーネントをすばやく特定できます。

詳細：

• 外形テストのスパンとAPMのスパンのリンク
• 実行結果とSplunk RUMのウェブバイタルの比較

アラートと包括的なITコンテキストの相関付け

Splunk Observability CloudのアラートをSplunk IT Service Intelligence (ITSI)に統合することで、外形監視イベントを、シスコのネットワークオブザーバビリティソリューションで収集されたネットワークテレメトリなど、他のシステムのアラートと相関付けることができます。これにより、ビジネスコンテキストを付加して対応ワークフローを強化し、重複を排除して、根本原因分析を迅速化できます。

詳細：ITSI上でのObservability Cloudのアラートの相関付け

これらの統合により、外形監視アラートの精度だけでなく実用性も高めることができます。エンドツーエンドの可視化は、一刻を争う問題対応でチームが自信を持って行動できるようにするために役立ちます。

スマートアラートでノイズを排除して外形監視の信頼性を高める

スマートアラートを設定するかどうかは、外形監視の自信を高めるかノイズ率を高めるかの分かれ目になります。

有意義なしきい値に重点を置き、Splunkの内蔵機能を活用して誤検知を減らし、ダウンタイムに効果的に対処し、オブザーバビリティスタックの他のツールと統合すれば、外形テストのレジリエンスと信頼性を向上させることができます。

その成果として、信頼できるシグナル、つまり、本当に重要な問題のみを警告し、他のオブザーバビリティプラクティスとシームレスにつながるシグナルを構築できます。

外形監視ディテクターの現在の設定を確認して、そのしきい値やダウンタイム設定がリリースプロセスと整合しているかどうかを検証し、RUM、APM、ITSIとの統合によってインシデント対応ワークフローをどのように強化できるかを探りましょう。

無料トライアル版で、Splunk Observability Cloudをぜひ実際にお試しください。

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。