Synthetic モニタリングのトラブルシューティング

概要

Datadog Synthetic モニタリングのセットアップや構成で問題が発生した場合は、こちらのページを参考にしてトラブルシューティングをお試しください。問題が解決されない場合は、Datadog サポートまでお問い合わせください。

API テスト

ネットワークのタイミングが一様ではない

API テストの時間メトリクスに急激な上昇や全体的な増加がある場合、リクエストにボトルネックまたは遅延があることを示しています。詳しくは、API テストの時間とバリエーションのガイドを参照してください。

ブラウザテスト

記録

ウェブサイトが iframe で読み込まれない

Datadog 拡張機能をダウンロードすると、ブラウザテストのレコーダーの右側にある iframe で Web サイトを確認できなくなり、Your website does not support being loaded through an iframe. (この Web サイトは iframe 経由の読み込みをサポートしていません) と表示されます。この場合、アプリケーションの設定で iframe での表示が抑制されている場合があります。

あるいは、iframe レコーダーで記録しているときに Web サイトにログインできない場合、アプリケーションのリクエストがブロックされている可能性があります。

Open in Popup をクリックして Web サイトをポップアップウィンドウで開き、ユーザージャーニーを記録してみてください。

一部のアプリケーションは iframe に読み込まれるが、読み込まれないものがある

これは、アプリケーションと環境によって制限が異なることを意味します。そのため、一部は iframe で視覚化されますが、表示されないものもあります。

iframe の上部に「We’ve detected HTTP requests that are not supported inside the iframe, you may need to record in a popup (iframe 内でサポートされていない HTTP リクエストを検知したため、ポップアップで記録を行う必要があります)」と表示される

これは http ページでステップを記録しようとしている場合に主に発生します。iframe レコーダーでは https のみサポートされています。ページをポップアップとして開くか、URL を https に変更してページの記録を開始してください。

HTTP を iframe で開いた場合

iframe で Web サイトが読み込まれず、Web サイトをポップアップで開いてもステップを記録できない

Datadog 拡張機能をダウンロードすると、ブラウザテストのレコーダーの右側にある iframe でウェブサイトを確認できなくなります。さらに、ウェブサイトを iframe とポップアップのどちらで開いても、ステップを記録できなくなります。

このような場合は、On specific sites セクションでウェブサイトを指定するか、On all sites にトグルボタンを変更して、意図したウェブサイトのデータの読み取りおよび変更の許可を Datadog 拡張機能に付与してください。

アプリケーションで手順を記録することができません

Chrome ブラウザに、拡張機能が正常に記録できないようにするポリシーがある可能性があります。

確認するには、chrome://policy へ移動して ExtensionSettings のような拡張機能に関する設定を探します。

レコーダーにログインページが表示されない

デフォルトでは、レコーダーの iframe/ポップアップは、ユーザーが使用しているブラウザを使用します。したがって、すでにアプリケーションにログインしている場合、iframe/ポップアップがログイン後のページを直接表示し、先にログアウトしないとログイン手順を記録できない可能性があります。

アプリケーションからログアウトせずに手順を記録できるようにするには、レコーダーのシークレットモードを利用します。

シークレットモードでポップアップウィンドウを開くと、使用中のブラウザのメインセッションとユーザーデータから完全に分離されたセッションとして、テストコンフィギュレーションで設定した開始 URL からテストの記録を開始できます。

このシークレットポップアップウィンドウは、以前のブラウザ履歴 (Cookie やローカルデータなど) を無視します。アカウントから自動的にログアウトされ、初めて Web サイトにアクセスした場合と同じようにログイン手順の記録を開始できます。

テスト結果

Mobile Small またはタブレットブラウザテストの結果が失敗し続けます

ウェブサイトにレスポンシブ技術を使用している場合、その DOM はテストを実行するデバイスにより大きく異なります。Laptop Large から実行するときは特定の DOM を使用し、Tablet または Mobile Small から実行する場合は別のアーキテクチャになります。

つまり、Laptop Large のビューポートから記録されたステップは Mobile Small からアクセスされた同じウェブサイトには適用されず、Mobile Small のテスト結果が失敗となることがあります。

モバイルタブレットデバイスの失敗

このような場合のため、Datadog では、ランタイムでテストが設定されたビューポートと記録されたステップが一致する、Mobile Small または Tablet に特定の別々のテストを作成することをおすすめしています。

Mobile Small または Tablet ビューポートでステップを記録するには、Start Recording ボタンを押す前にレコーダーのドロップダウンで Mobile Small または Tablet を選択します。

モバイルタブレットでの記録ステップ

さらに、Datadog のテストブラウザはヘッドレスで実行されるため、ブラウザテストがサポートしない機能があります。たとえば、ブラウザテストは touch をサポートしないため、ウェブサイトがモバイルデザインで表示されるべきかを touch で検出することはできません。

ブラウザテストで None or multiple elements detected というステップの警告が表示される

ブラウザテストのステップに None or multiple elements detected のステップ警告が表示されています。

ユーザーのロケーターのステップ警告

これは、このステップに定義されたユーザーロケーターが、複数の要素を対象としているか、いずれの要素も対象としていないため、ブラウザテストで対応する必要のある要素が不明であるという意味です。

この問題を修正するには、問題のあるステップの詳細オプションを開き、テストするステップのページで Test をクリックします。これにより、要素がハイライトされるかエラーメッセージが印刷されます。次に、ページの単一要素に一致するようユーザーロケーターを修正できます。

CSS のポインタープロパティで問題が発生している

自動化されたブラウザは、CSS の pointer メディア機能をエミュレートすることをサポートしていません。ブラウザテストでは、すべてのテストとデバイス (ラップトップ、タブレット、モバイル) で pointer: none が使用されます。

API およびブラウザのテスト

不正なエラー

Synthetics テストの 1 つが 401 をスローしている場合は、エンドポイントで認証できないことを意味している可能性が高いです。そのエンドポイント (Datadog 外) での認証に使用するメソッドを使用し、Synthetic テストを構成するときにそれを複製する必要があります。

  • エンドポイントはヘッダーベース認証を使用していますか？

    • 基本の認証情報: HTTP またはブラウザテストの高度なオプションに、関連する認証情報を指定します。
    • トークンベース認証: 最初の HTTP テストでトークンを抽出し、その最初のテストの応答をパースしてグローバル変数を作成し、その変数を認証トークンを必要とする 2 回目の HTTP またはブラウザテストに再挿入します。
    • セッションベース認証: HTTP またはブラウザテストの高度なオプションに必要なヘッダーまたはクッキーを追加します。

  • このエンドポイントは認証用のクエリパラメーターを使用していますか (たとえば、URL パラメーターに特定の API キーを追加する必要がありますか)？

  • このエンドポイントは IP ベース認証を使用していますか？その場合は、Synthetics テストの元となる IP の一部またはすべてを許可する必要があります。

Forbidden エラー

Synthetic テストによって返された 403 Forbidden エラーが確認された場合は、Sec-Datadog ヘッダーを含むリクエストを Web サーバーがブロックまたはフィルタリングした結果である可能性があります。このヘッダーは、Datadog が開始する各 Synthetic リクエストに追加され、トラフィックのソースを識別し、Datadog サポートが特定のテスト実行を識別するのを支援します。

さらに、Datadog Synthetics のモニタリング IP 範囲がファイアウォールによってトラフィックソースとして許可されていることを確認する必要がある場合もあります。

通知の欠落

デフォルト設定では、Synthetic テストは 再通知しません。これは、トランジション（たとえば、テストがアラート状態になる、または直近のアラートから回復するなど）が生成された後に通知ハンドル（メールアドレスや Slack ハンドルなど）を追加しても、そのトランジションの通知は送信されないことを意味します。次のトランジションから通知が送信されます。

プライベートロケーション

    ブラウザテストの結果で、Page crashed エラーが表示されることがあります

    これにより、プライベートロケーションワーカーのリソース消費の問題が明らかになることがあります。プライベートロケーションワーカーが、十分なメモリリソースでプロビジョニングされていることを確認してください。

    テストの実行が通常より遅くなることがあります

    これにより、プライベートロケーションワーカーのリソース消費の問題が明らかになることがあります。プライベートロケーションワーカーが、十分な CPU リソースでプロビジョニングされていることを確認してください。

    ブラウザテストの実行に時間がかかりすぎる

    プライベートロケーションのデプロイメントで、メモリ不足の問題が発生していないことを確認します。ディメンショニングガイドラインに従ってワーカーインスタンスのスケーリングを既に試した場合は、Datadog サポートに連絡してください。

    プライベートロケーションから実行される API テストに TIMEOUT エラーが表示される

    API テストの実行が設定されているエンドポイントに、プライベートロケーションが到達できていない可能性があります。テストするエンドポイントと同じネットワークにプライベートロケーションがインストールされていることを確認してください。別のエンドポイントでテストを実行し、同じ TIMEOUT エラーが表示されるかどうか試してみることも可能です。

    プライベートロケーションがタイムアウトした API テスト

    時々、プライベートロケーションのコンテナが、強制終了された OOM を取得する

    強制終了された Out Of Memory を取得するプライベートロケーションのコンテナは、通常、プライベートロケーションワーカーのリソース消費の問題を明らかにします。プライベートロケーションのコンテナが、十分なメモリリソースでプロビジョニングされていることを確認してください。

    プライベートロケーションのテストを実行しようとすると、invalid mount config for type "bind": source path must be a directory というエラーが表示される

    これは、Windows ベースのコンテナで単一ファイルをマウントしようとした場合に発生し、これはサポートされていません。詳しくは、Docker マウントボリュームのドキュメントをご参照ください。バインドマウントのソースがローカルディレクトリであることをご確認ください。

    再起動せずに Synthetics Private Location Worker サービスを再起動する

    まず、インストール時に指定した構成でプライベートロケーションをインストールしたことを確認します。サービスを再起動するには、GUI を使用するか、Windows PowerShell を使用します。

    GUI

    1. MSI インストーラーを開き、Start メニューで Services を検索します。
    2. 任意のユーザーアカウントで Services を起動します。
    3. Services (Local) をクリックし、Datadog Synthetics Private Location というサービスを探します。
    4. ステップ 2 で見つかったサービスを右クリックし、Restart を選択します。

    Synthetics Private Location Worker は Local Service アカウントで実行されるようになりました。これを確認するには、タスクマネージャーを起動し、Details タブで synthetics-pl-worker プロセスを探します。

    PowerShell

    1. PowerShell スクリプトの実行権限を持つ任意の Windows アカウントで Windows PowerShell を起動します。
    2. コマンド Restart-Service -Name “Datadog Synthetics Private Location” を実行します。

    Synthetics Private Location Worker の実行を維持する

    まず、Synthetics Private Location Windows Service がインストールされているマシンにログインし、そのマシンでスケジュールタスクを作成する権限を持っていることを確認してください。

    Synthetics Private Location Worker がクラッシュした場合、Windows に PowerShell スクリプトを実行するスケジュールタスクを追加し、アプリケーションの実行が停止した場合に再起動するようにします。これにより、クラッシュ後にプライベートロケーションが確実に再起動されます。

    アプリケーションのインストール時にコンフィギュレーションファイルを提供した場合、インストール後に Datadog Synthetics Private Location という名前の Windows サービスが自動的に開始されます。これを確認するには、Services ツールでサービスが実行されていることを確認します。この Windows サービスは、プライベートロケーションを自動的に再起動します。

    sudo のパスワードを要求される/dog ユーザーのパスワードを要求される

    Private Location ユーザー (dog) は、さまざまな理由で sudo を必要とします。通常、このユーザーには、コンテナ上で Private Location を起動する過程で sudo アクセスを許可する特定の権限が付与されます。ポリシーで dog ユーザーの sudo 権限を制限しているか、dog ユーザー (UID 501) としてコンテナを起動できないようにしているか確認してください。

    さらに、Private Location のバージョン >v1.27 では、Datadog は clone3 システムコールの使用に依存しています。古いバージョンのコンテナランタイム環境 (Docker バージョン <20.10.10 など) では、clone3 はデフォルトの seccomp ポリシーではサポートされていません。コンテナランタイム環境の seccomp ポリシーに clone3 が含まれていることを確認してください。これは、使用中のランタイムのバージョンを更新したり、seccomp ポリシーに clone3 を手動で追加したり、または unconfined seccomp ポリシーを使用することで実現できます。詳細については、Docker の seccomp ドキュメントを参照してください。

    その他の参考資料

    お役に立つドキュメント、リンクや記事:

    Synthetic テストの管理ドキュメント more more ブラウザテストの構成ドキュメント more more API テストの構成ドキュメント more more タイムボードドキュメント more more