合成モニタリングは、グローバルなロケーションネットワークからスケジュールされたスクリプトチェックを実行してユーザーの旅やAPI呼び出しをシミュレートするプロアクティブな監視手法です。ウェブサイト、アプリケーション、APIに対して制御されたテストを実行することで、可用性、パフォーマンス、機能的正確性を検証し、ライブユーザートラフィックに依存しないシステムの健康状態の一貫した信号を提供します。ユーザーが問題を報告するのを待つのではなく、チームは自動化されたテストを使用して、ページロード、ログイン、検索、フォーム送信、チェックアウトフローなどの重要なリクエストやユーザーの旅をシミュレートします。
これらのチェックはスケジュールに従って実行されるため、合成モニタリングはトラフィックが少ない場合や存在しない場合でも問題を検出できます。これは、顧客の苦情を通じて可視化される前に、障害、レイテンシの回帰、壊れたページ要素、失敗したトランザクション、地域的なルーティングの問題、SSLの問題、APIエラーを特定するために一般的に使用されます。
合成モニタリングは、重要なユーザーの旅をプロアクティブに検証し、外部のロケーションからの可用性を測定し、トラフィックが少ない場合でも回帰を検出する必要があるときに最も役立ちます。これは、ユーザーがインフラストラクチャの外部から体験するものを測定する制御された再現可能なチェックを提供することで、RUM、APM、ログ、インフラストラクチャの監視を補完します。
合成モニタリングの仕組みは？
合成モニタリングは、重要なチェックを定義し、選択したロケーションから実行し、各結果を測定し、閾値または機能条件が違反されたときにアラートを送信することで機能します。
1. 重要なエンドポイントと旅を特定する
ユーザーやビジネスにとって最も重要なフローから始めます。ほとんどの環境では、ホームページの可用性、ログイン、検索、チェックアウト、アカウントアクセス、主要な公開APIが含まれます。
最初のチェックは、顧客への影響に直接結びついているものが最適です。失敗がサポートの急増、収益の損失、または目に見えるサービスの中断を引き起こす場合、それは監視リストの上位に近いべきです。
2. 正しいタイプの合成テストを構築する
異なるユースケースには異なるテストタイプが必要です。
- 軽量の可用性チェックは、基本的な到達可能性と応答性を検証します。
- ブラウザベースのチェックは、リアルブラウザでのレンダリング、インタラクティビティ、ワークフロービヘイビアを検証します。
- APIチェックは、エンドポイントの動作、レイテンシ、ペイロード、ヘッダー、認証、および応答ロジックを検証します。
- トランザクションチェックは、マルチステップのビジネスプロセスをエンドツーエンドで検証します。
Dotcom-Monitorは、稼働時間の監視、リアルブラウザのウェブアプリケーションの監視、ウェブトランザクションの監視、およびAPIの監視を使用して、この層状のアプローチをサポートします。EveryStepレコーダーは、クリック、フォーム入力、ナビゲーション、認証などのリアルなブラウザのインタラクションをキャプチャするように設計されており、グローバルなロケーションからスケジュールに従ってこれらのスクリプトを実行します。
3. 選択したロケーションからスケジュールに従ってテストを実行する
監視プラットフォームは、構成されたチェックポイントから定義された間隔でテストを実行します。Dotcom-Monitorは、30以上のグローバルロケーションからチェックを実行しており、これによりチームは地域間のパフォーマンスを比較し、ローカライズされた障害を特定できます。
実用的な開始モデルは次のようになります：
- 軽量の稼働時間または可用性チェック：1〜5分ごと
- 重要なエンドポイントの公開APIチェック：1〜5分ごと
- 高価値のユーザーの旅のためのブラウザおよびトランザクションチェック：5〜15分ごと
- より重いまたはリスクの低いワークフロー：影響と運用価値に基づいて、より少ない頻度で
Dotcom-MonitorのEveryStep構成は、1〜60分のチェック頻度をサポートしており、チームが重要なパスのために迅速なチェックを調整し、より高価なブラウザフローのために遅いリズムを設定する余地を提供します。
4. 技術的および機能的な結果を測定する
各テスト実行は、可用性ステータス、HTTPステータス、TTFB、ページロード時間、DOMタイミング、ステップの持続時間、APIのレイテンシ、アサーション結果、トランザクションの成功または失敗、SSLの有効性、およびサポート診断などのデータを生成できます。
有用な合成プログラムは、リクエストが応答を返したことを確認するだけではありません。応答が正しいかどうかも検証します。たとえば、成功したAPIチェックは、期待されるステータスコード、有効な認証結果、特定の応答フィールド、正しいヘッダー、一致するコンテンツアサーション、または依存リクエストの成功したシーケンスを必要とする場合があります。Dotcom-MonitorのAPIおよびブラウザ監視ガイダンスは、稼働時間だけでなく、アサーション、コンテンツ検証、ワークフローの成功を強調しています。
5. 意味のある失敗にアラートを送信する
テストが失敗した場合、閾値を超えた場合、またはアサーションが違反した場合、プラットフォームはアラートを送信し、対応者が調査できるようにします。
良いルールは、ユーザーに影響を与え、持続的であることが確認された問題に対してのみページを送信することです。たとえば、チェックが3回連続して失敗した後、または少なくとも2つの異なる監視ロケーションから確認された場合にのみ、高優先度のアラートをトリガーするように構成します。ハードな失敗の閾値を超えない地域的な遅延のような劣化については、自動的に調査のために低優先度のチケットを開きます。
アラートに値する条件には、次のようなものがよく含まれます：
- 複数の実行での繰り返しの失敗
- 複数のロケーションから確認された失敗
- ログイン、チェックアウト、アカウントアクセス、または主要なAPIでのハードな失敗
- 期限切れに近いSSL証明書の有効性の問題
- 高優先度のエンドポイントでの大きなレイテンシの回帰
- ビジネスアクションを完了できない完全なトランザクションの失敗
チケットに値する条件には、次のようなものがよく含まれます：
- 中程度だが持続的なパフォーマンスの回帰
- 非クリティカルな地域的な遅延
- 予算よりも遅いが成功するトランザクションステップ
- 顧客向けのインシデントを反映しないスクリプトのメンテナンスの問題
- テストの更新が必要なコンテンツ、セレクタ、またはアサーションの変更
一般的な合成テストの4つのタイプ
1. 稼働時間と可用性の監視
稼働時間の監視は、サービスが到達可能で期待通りに応答していることを確認するために軽量のテストを使用します。実際には、これは通常、URL、ホスト、またはエンドポイントが閾値内で応答し、期待されるステータスまたはコンテンツを返すかどうかを確認することを意味します。
このタイプの監視は基本的な可用性を確認するのに役立ちますが、完全なユーザーワークフローが健康であることを証明するものではありません。ホームページが200 OKを返す一方で、ログイン、チェックアウト、または下流のAPIが壊れている可能性があります。これを解決するために、チームはトランザクション監視を使用して、ユーザーの旅全体を検証します。基本的な稼働時間チェックは到達可能性を確認しますが、トランザクション監視は、チェックアウトのようなマルチステッププロセスがエンドツーエンドで機能的に正しいことを確認します。
2. ブラウザ監視
合成ブラウザ監視は、制御されたブラウザ環境内でスクリプト化されたアクションを実行して、ウェブアプリケーションがリアルなユーザーインタラクション中にどのように動作するかをテストします。これは、レンダリング、クリック、ナビゲーション、動的コンテンツ、フォーム送信、およびエンドツーエンドのページ動作を検証するために使用されます。たとえば、ログインページのリアルブラウザテスト：
- アサーション：成功したログインと正しいページリダイレクションを確認します。
- 失敗：ログインが失敗するか、ページが5秒以内に読み込まれない場合は、高優先度のアラートを作成します。
Dotcom-Monitorは、特に動的アプリケーションやトランザクションが多いサイトの正確なレンダリングとワークフローの検証のために、リアルブラウザの監視を強調しています。
3. トランザクション監視
トランザクション監視は、ログイン、検索、アカウントアクセス、予約、またはチェックアウトなどのマルチステップのビジネスワークフローを検証します。これは、最初のページリクエストが成功した後に多くのユーザーが目に見える失敗が発生するため、重要です。Dotcom-Monitorのトランザクション監視は、ユーザーが実際にリアルブラウザのワークフローで重要なアクションを完了できるかどうかに焦点を当てており、トランザクションが壊れた場所を示すためにビデオキャプチャやウォーターフォール分析などの診断を含みます。重要なアサーションの例：
- カートに追加されたアイテムが表示され、チェックアウトページが正しい価格で読み込まれることを確認します。
- 支払い確認が成功し、ユーザーが確認ページに到達することを確認します。
4. API監視
API合成監視は、アプリケーションプログラミングインターフェースが利用可能で、十分に速く、期待される出力を返しているかどうかを検証します。強力なAPI監視は、稼働時間だけでなく、より多くのことをチェックします。必要に応じて、ステータスコード、ペイロード構造、ヘッダー、トークン、認証動作、およびチェーンリクエストロジックを検証します。たとえば、製品検索のためのREST APIを監視する場合：
- アサーション：200 OKの応答が、すべての期待される製品フィールド（名前、価格、可用性）を含む有効なJSONペイロードで返されることを確認します。
Dotcom-Monitorは、稼働時間、パフォーマンス、トランザクションレベルの診断、認証された監視、アサーションベースの検証の観点からAPI監視を説明しています。
合成モニタリングと稼働時間モニタリングの違い
稼働時間の監視は、合成モニタリングのサブセットです。これは、ページ、ホスト、またはエンドポイントが利用可能で、許容される閾値内で応答しているかどうかなど、基本的な到達可能性と応答の検証に焦点を当てています。
合成モニタリングはより広範です。稼働時間チェックを含みますが、ブラウザテスト、APIアサーション、およびマルチステップのトランザクション監視もカバーします。言い換えれば、稼働時間の監視は、サービスが稼働しているかどうかを教えてくれます。合成モニタリングは、重要なユーザーの旅やAPIワークフローが実際に機能しているかどうかを教えてくれます。
この区別は、プロダクションで重要です。サイトが到達可能である一方で、ログインが失敗したり、チェックアウトが壊れたり、APIが無効なデータを返したりすることがあります。だからこそ、多くのチームは迅速な検出のために稼働時間の監視を使用し、より深い検証のためにブラウザまたはトランザクションチェックを使用します。
合成モニタリングとリアルユーザーモニタリングの違い
合成モニタリングとリアルユーザーモニタリングは異なる質問に答えます。
合成モニタリングは、事前定義されたユーザーの旅やエンドポイントが現在、制御されたテスト条件下で正しく機能しているかどうかを尋ねます。これはアクティブで、スケジュールされており、再現可能です。ライブトラフィックがないときでも機能します。
リアルユーザーモニタリングは、実際の訪問者がプロダクションで体験するものを測定します。これは、実際のブラウザ、デバイス、ネットワーク、およびユーザーの行動を反映しますが、ユーザーが積極的にトラフィックを生成しているときだけです。
2つを分ける簡単な方法は次のとおりです：
- 合成モニタリングは、「ユーザーは今すぐこの重要な旅を完了できますか？」と答えます。
- リアルユーザーモニタリングは、「実際のユーザーは時間の経過とともにアプリケーションをどのように体験していますか？」と答えます。
プロダクションチームにとって、合成モニタリングは、リリースや依存関係の変更後に回帰を検出する最初のシステムであることが多いです。なぜなら、問題を露呈させるためにオーガニックトラフィックを待つ必要がないからです。
合成モニタリングとAPMおよび可観測性の違い
アプリケーションパフォーマンス監視およびより広範な可観測性ツールは、チームがアプリケーションとそのインフラストラクチャ内で何が起こっているかを理解するのに役立ちます。これらは、リクエストのトレース、ログの分析、サービスのレイテンシの測定、インシデント中のバックエンドの動作の相関に役立ちます。
合成モニタリングは異なる質問に答えます。これは、ユーザーまたはAPI消費者がシステムの外部からフローに成功裏にアクセスし、完了できるかどうかを示します。
実際には、これらのツールは一緒に最もよく機能します：
- 合成モニタリングは、外部の視点からユーザーに見える失敗を検出します。
- APMは、遅いサービス、失敗した依存関係、またはコードレベルのボトルネックを特定するのに役立ちます。
- ログは、調査中の詳細なイベントコンテキストを提供します。
- メトリクスとトレースは、失敗が発生した理由とその広がりを説明するのに役立ちます。
合成モニタリングは、ユーザーに見える問題を検出する最も迅速な方法であることが多いです。可観測性ツールは、それを説明する最も迅速な方法であることが多いです。
外部からの監視とは何ですか？
外部からの監視とは、アプリケーションスタックの内部からだけでなく、外部のユーザー、ブラウザ、またはAPI消費者の視点からデジタルサービスをテストすることを意味します。
これは重要です。なぜなら、内部のテレメトリはインフラストラクチャが健康であることを示すことができる一方で、ユーザーは依然として失敗を経験する可能性があるからです。認証リダイレクトが壊れる、CDNアセットが読み込まれない、DNSプロバイダーが1つの地域で失敗する、またはサードパーティAPIがタイムアウトすることがあります。これらはすべて、内部の健康チェックだけでは見逃されるユーザーに見える問題です。
Dotcom-Monitorは、ウェブサイト、アプリケーション、API全体で外部からの監視を使用して、グローバルチェックポイントから実際の可用性とトランザクションの動作を検証します。
追跡すべき主要な合成モニタリング指標は何ですか？
最も有用な合成指標はチェックのタイプによって異なりますが、技術チームは一般的に次のものを追跡します：
- 可用性と成功率
- HTTPステータスとエラー頻度
- TTFBと総応答時間
- ページロード時間とDOMタイミング
- ステップレベルのトランザクション持続時間
- APIのレイテンシ
- アサーションの合格または失敗率
- SSL証明書の有効性と期限切れのウィンドウ
- 地域のパフォーマンスの変動
- トランザクション完了率
これらの指標は、特定のユーザーの旅やビジネスへの影響に結びついているときに最も有用です。一般的な応答時間の傾向は、デプロイ後にある地域でのログイン成功率が低下したことを知るよりも行動可能性が低いです。
なぜチームは合成モニタリングを使用するのか？
チームは、ユーザーがそれに気づく前に、障害、レイテンシの回帰、壊れたワークフローをキャッチするために合成モニタリングを使用します。これは、認証、検索、チェックアウト、アカウントアクセス、公開APIなどの重要なパスに特に価値があります。
実際には、エンジニアリングチームは合成モニタリングを使用して：
- リリース後に重要なユーザーの旅を検証する
- サポートのボリュームが増加する前にサードパーティの失敗を検出する
- 顧客向けのSLAおよびSLOが外部の視点から満たされていることを確認する
- トラフィックが少ない期間中にプロダクションの回帰をキャッチする
- 修正が実際にユーザーに見えるインシデントを解決したことを確認する
たとえば、デプロイ後、チームは外部のチェックポイントからログイン、検索、チェックアウトに対してブラウザベースのチェックを実行して、リリースが顧客向けのフローを壊していないことを確認することがあります。内部のインフラストラクチャメトリクスは健康に見えるかもしれませんが、外部からのトランザクションがJavaScriptエラー、古いCDNアセット、壊れたリダイレクト、認証の問題、またはサードパーティの依存関係の失敗のために失敗することがあります。
エンタープライズチームによる実際のユースケース
SREおよびプラットフォームチーム
SREおよびプラットフォームチームは、合成モニタリングを使用してユーザーに見えるSLIを検証し、外部の失敗を迅速に検出し、緩和策やロールバックがサービスを復元したことを確認します。
アプリケーションエンジニアリングチーム
アプリケーションチームは、リリースがログイン、検索、チェックアウト、またはアカウント管理フローを壊していないことを確認し、内部サービスメトリクスでは表面化しないフロントエンドの回帰を検出するために使用します。
APIおよびバックエンドチーム
APIチームは、公開エンドポイント、認証、ペイロードの整合性、依存関係の健康を外部の視点から検証するために使用します。
eコマースおよびデジタルエクスペリエンステーム
これらのチームは、コンバージョンパスを保護し、チェックアウトフローを検証し、収益に影響を与える前にサードパーティのスクリプトや支払いの問題を検出するために使用します。
合成モニタリングは本番環境で何をキャッチするのか？
合成モニタリングは、失敗が外部から見えるが、スタック内部からは見逃されやすいときに最も役立ちます。
特に次のようなものをキャッチするのが得意です：
- 期限切れまたは誤設定されたSSL証明書
- DNSの失敗およびドメイン解決の問題
- ページやボタンの機能を妨げる壊れたJavaScript
- 認証やリダイレクトエラーによるログインの失敗
- チェックアウトやフォーム送信の失敗
- 劣化または失敗しているサードパーティのスクリプトやAPI
- 地域特有のレイテンシやルーティングの問題
- コンテンツの不一致や不正確なAPI応答ロジック
- リリース後の遅いページレンダリングやステップレベルの回帰
Dotcom-Monitorの公開資料は、SSL監視、複数のロケーションチェック、リアルブラウザの実行、アサーションベースのAPI検証、スクリーンショット、ビデオ、ウォーターフォールチャートなどの診断を通じて、これらの外部からの失敗モードを強調しています。
一般的な合成モニタリングの課題とアラートノイズを減らす方法は？
強力な合成モニタリングプログラムでさえ、メンテナンスと運用の規律が必要です。
スクリプトのメンテナンス
ユーザーインターフェースは変化します。セレクタが壊れます。認証フローが進化します。サードパーティのコンテンツが動作を変更します。アプリケーションが変化するにつれて、合成スクリプトも更新する必要があります。そうしないと、実際のワークフローを反映し続けることができません。
アラートノイズとフラッピング
適切に調整されていない監視戦略は、一時的なネットワーク条件、脆弱なスクリプト、または攻撃的すぎる閾値からノイズの多いアラートを生成する可能性があります。良好な再試行ロジック、合理的なアラートポリシー、慎重なスクリプト設計が偽陽性を減らします。
カバレッジのギャップ
合成モニタリングは、テストすることを選択したものだけを検証します。重要なビジネスパスが監視セットから欠落している場合、そのパスの失敗は見逃される可能性があります。
スケールと所有権
チームがより多くの地域、API、ユーザーの旅、環境を追加するにつれて、監視は管理が難しくなることがあります。標準的な命名、所有権、エスカレーションポリシー、およびダッシュボードの規律が、カバレッジが増えるにつれて重要になります。
実際にアラートノイズを減らすためには：
- 小さく、高価値のチェックセットから始める
- ページングの前に繰り返しの失敗を要求する
- ユーザーに影響を与えるアラートのために複数のロケーション確認を使用する
- ページング条件からチケット条件を分ける
- 理想的なベンチマークではなく、ビジネスへの影響に基づいて閾値を調整する
- UI、認証、または依存関係の変更後にスクリプトをレビューする
合成モニタリングのベストプラクティス
小さく、高価値のチェックセットから始める
ホームページの可用性、ログイン、検索、チェックアウト、および最も重要な公開APIなど、3〜5のビジネスクリティカルなチェックから始めます。
層状の監視を使用する
単一のチェックタイプに依存しないでください。軽量の稼働時間監視を到達可能性のために、ブラウザおよびトランザクションチェックを実際の機能のために、さらにAPI監視をバックエンドの正確性のために組み合わせます。
応答だけでなくビジネスの成果を検証する
サービスが応答することは、サービスが正しく機能することとは異なります。可能な限りアサーションとコンテンツ検証を使用して、テストが期待される動作を検証するようにします。単に返されたステータスコードではなく。
ユーザーが気にするロケーションから監視する
地域テストは、ユーザーベースに一致する場合に最も重要です。グローバルな監視は、チェックポイントの選択が実際にビジネスに影響を与える地理を反映しているときに最も有用です。
意図的に間隔と閾値を設定する
迅速で高影響のチェックは、通常、より厳しい間隔と明確なページング閾値に値します。より重い、リスクの低いトランザクションは、しばしば、より攻撃的でないスケジュールとより多くの診断コンテキストでうまく機能します。
合成の失敗を内部のテレメトリと相関させる
合成チェックが失敗した場合、対応者はその失敗をログ、トレース、メトリクス、デプロイイベント、依存関係のダッシュボードと比較する必要があります。合成モニタリングは、ユーザーが外部から影響を受けていることを教えてくれます。内部のテレメトリは、なぜそうなったのかを説明するのに役立ちます。
スクリプトを保守可能に保つ
高価値のフローの少数から始めます。1つのスクリプトでUIのすべての詳細をテストすることは避けてください。重要な完了ポイントを検証し、UIや認証の変更後にスクリプトをレビューし、ページングの前に複数のロケーション確認を使用します。
Dotcom-Monitorの合成モニタリング機能
Dotcom-Monitorは、ウェブサイト、ウェブアプリケーション、API、およびマルチステップのユーザーの旅に対して、リアルブラウザテストとグローバルな監視ネットワークを使用した合成モニタリングを提供します。その公開された機能には：
- 可用性と応答の検証のための稼働時間の監視
- 動的アプリケーションのためのリアルブラウザの監視
- ログイン、フォーム、チェックアウトフローのためのウェブトランザクションの監視
- 認証されたリクエストとアサーションを伴うAPIの監視
- 30以上のグローバルロケーションからの監視
- ウォーターフォール分析、スクリーンショット、ビデオキャプチャ、レポートなどの診断
- SSL証明書の監視とSLAレポート
技術チームにとって、価値はサービスが到達可能であるかどうかを知ることだけではありません。それは、外部から見て使用可能で、パフォーマンスが良く、機能的に正しいかどうかを知ることです。