よくある質問

[編集] の一覧でターゲット デバイスを開きます。 ブラウザのアドレスバーには、次のようなものが表示されます。

https://user.dotcom-monitor.com/ClientID/DeviceEdit?pid=dc7f4ff2ca944dekjh1078b96707002& deviceId=63698 & taskId=132834 

デバイス ID=63698はデバイス ID です。
タスク Id=132834はタスク ID です。

使用可能なアカウントの一覧の [ アカウントの選択] ページで指定されたアカウント ID。

ログインしたら、左側のサイドバーの [アカウント ]メニューをポイントしてアカウントIDを見つけます。

部門 ID

マスターアカウントにログインすると、アカウントアカウント設定部門の下にあなたの部門ID > > を見つけることができます。

LoadView の各テストには一意の ID があります。 テスト ID を使用すると、LoadView 統合の構成中に特定のシナリオを呼び出すことができます (Jenkins や CircleCl ビルドなど)。

テスト ID は、テスト ページにあります。

このアプローチでは、Dotcom-Monitor が応答を「アップ」または「ダウン」応答として解釈する方法を慎重に定義する機能が提供されます。 これは、フィルターを使用して実行されます。

フィルタ処理では、次の調整可能な条件を使用して、アップ/ダウン 状態を定義します。

• 指定した時間分のエラーが報告される
• 指定した数のエージェントによってエラーが確認される
• 指定された数のタスクでエラーが検出されました。

すべてのフィルタとその設定は、フィルタの構成で使用できます > 。 フィルターがデバイスに適用されると、デバイスのすべての通知はフィルターの条件に基づきます。 「デフォルトフィルタ」は、すべての新しいデバイスに割り当てられます。 デフォルトのフィルタはバランスの取れた設定で、ほとんどの監視デバイスに適しています。

稼働時間/ダウンタイム計算

ダウンタイム計算の計算式は次のとおりです。

1. ダウンタイム期間 は、フィルタ内の設定に直接関連付けられています。

• ダウンタイム期間は、フィルタの条件が満たされたときに開始されます。 たとえば、エラーを報告するエージェントの数がフィルタで指定されたエージェントの数と等しく、指定された条件も分数とタスク数で満たされると、ダウンタイムアラートが送信されます。
• 稼働時間は、フィルターの条件が満たされなくなった時点で開始されます。 具体的には、 アップ時間 は、エージェント、分、またはタスクの数が「アップ」成功を報告し、もはやフィルター処理された「ダウン」条件に必要な条件を満たしていないときに開始します。 たとえば、エージェントが受信したエラー(「ダウン」)応答の数が、フィルターで設定されているように、エージェントが必要とするエラー(「ダウン」)応答の数より少なくなると、「上」状態が示されます。

2. 「未定義」状態の期間。 監視に関与する各エージェントのステータスが Undefined になったときに 、未定義状態を設定できます。 エージェントが一定時間内に応答 (エラーまたは成功) を提供しない場合、エージェントのステータスは 未定義 と見なされます。

応答時間の待機時間 = (エージェント全体の数 +1) × 監視頻度 + 15 分

たとえば、3つの監視エージェントと5分の監視頻度を使用します。 各エージェントは 、応答待機時間 = (3+1) ×5+15 分 = 35 分の応答を待機します。 時間が経過し、応答が受信されないと、エージェントは 未定義と報告します。

3. 「延期」状態の期間。 デバイスをいつでも延期すると、再び有効になるまで監視アクティビティが停止します。

4. 期間はスケジュールによって除外されます。アップタイム/ダウンタイム計算に大きな影響を与えるもう 1 つのエンティティは、 スケジュールです。 これは、定期的な保守の間にモニターを管理するためのオプションです。 監視は、特定の曜日に対して、また 1 日の特定の時間と分に対して延期できます。 スケジュールを設定するには、 指示に従います。

LoadView は、アマゾンウェブ サービス (AWS) と Azureクラウドサービスのロード インジェクタ サーバーを使用します。 Dotcom-Monitor には 17 の地理的領域が含まれています ロード インジェクター サーバーを述べることができ、負荷を生成できます。 各リージョンで、約 500 個のロード インジェクタをインスタンス化できます。

容量制限は、テスト実行アルゴリズムの違いにより、監視プラットフォームの種類によって異なります。

• HTTP (S) テストの場合、各ロード インジェクタは、最大で最大 1000人の同時 HTTP ユーザーを処理できます。
• Web ページまたは Webアプリケーション テストでは、各ロード インジェクタは、最大25人の同時ユーザーを処理できます。

特定のロード テストの種類の制限は、次の式を使用して計算されます。

500 x 16 x 負荷インジェクタあたりの同時ユーザー数 = 最大 ユーザ負荷

以下の結果として得られる負荷容量の制限を見つけます。

「上海」(中国)監視エージェントは、中国政府によって直接管理されている 中国の大ファイアウォールの背後に位置しています。 中国政府は、すべてのインターネットトラフィックに対してフィルタリングルールを設けており、公開されていません。 これらのフィルタリングルールは頻繁に変更され、上海、中国エージェントの監視結果に影響します。

https://youtu.be/4py8zE5EtFc?si=LnpflrvFK1ESWYWQ

[デバイスマネージャ(Device Manager

)] 画面で、複数のデバイスのモニタリングエージェントの場所を一度に編集できます。

1. 左側のサイドバーで [デバイス ]をクリックします。
2. デバイスマネージャから、各デバイスの横にあるチェックボックスをオンにして、更新するデバイスを選択します。
3. グループ アクション ツールバーの [場所] ボタンをクリックします。
4. [ Monitoring Agents] ウィンドウで、場所を追加または削除します。
5. 変更を保存します。

要するに、UserViewとBrowserViewプラットフォームのタスクは 、実際 のブラウザでWebページをロードし、すべてのページコンポーネントを実行し、HTTP(S)タスクはエミュレートされた「合成」ブラウザを使用し、レンダリングなしで要求されたページ要素のみをダウンロードします。

詳細については 、「HTTP(S)によるモニタリングとブラウザビュー/ユーザービューによる監視 と HTTP(S)とブラウザビュー/ユーザービュータスク間の時間測定の違い」を参照してください。

デフォルトでは、Exchange サーバーは、電子メール アドレスがローカルかどうかを認識します。 この場合、サーバーはパブリック インターネット経由で電子メールを送信しません。 これは、ほとんどの電子メール サーバーの既定値です。

パブリックインターネット経由で送受信をテストする場合は、往復メールモニター+Gmail^{などのサードパーティの} メールアカウントを使用することをお勧めします。

私たちのラウンドトリップメールの監視は、あなたの場所または3^rd パーティ(Gmail)のいずれかでPOP3またはIMAPプロトコルの使用が必要です。

ラウンドトリップでこれをテストするには、次の3つの方法があります。

テストアウトバウンド

1. SMTP サーバーアドレスを入力して、外部監視場所から SMTP サーバー経由で電子メールを送信するように SMTP を設定します。 (SMTP サーバーが動作していることをテストします)
2. 電子メールの送信先の電子メール アドレスを入力します (gmail.com など)。
3. 監視場所が SMTP サーバーから電子メールを取得できるように、Gmail POP3/IMAP サーバー アドレスを入力します。

受信テスト

1. Gmail SMTP サーバーアドレスを入力して、Gmail SMTP サーバー経由で外部の監視場所からメールを送信するように SMTP を設定します。
2. 電子メールを送信する電子メール アドレス (システムのアカウント) を入力してください。
3. 監視場所が SMTP サーバーから電子メールを取得できるように、POP3/IMAP サーバーアドレスを入力します。

送信と受信のテスト

1. SMTP サーバーアドレスを入力して、外部監視場所から SMTP サーバー経由で電子メールを送信するように SMTP を設定します。
2. 電子メールの送信先の電子メール アドレスを入力します (gmail.com など)。
3. サーバー上の POP3/IMAP メール アカウントに自動的に転送するように Gmail アカウントを設定します。
4. 監視場所がサーバーから電子メールを取得できるように、POP3/IMAP サーバーアドレスを入力します。

アクティブシンクのテスト

ActiveSync プロトコルは、ラウンド トリップも実行します。 アクティブシンクは、リモートデバイス(監視場所)からメールを送信し、そのリモートデバイスでサーバーから電子メールを取得する機能をテストします。 しかし、送信側と受信側のアカウントが同じサーバー上の同じアカウントであるため、アクティブな同期サーバーから別のサーバーに電子メールを送信しないため、ローカル アドレスへの最短ルートは、リモート デバイス (監視場所) からメッセージが取得されるまでパブリック インターネットにメッセージを送信する必要はありません。

ラウンドトリップとActiveSyncの違いは次のとおりです- Gmail などのサードパーティ製の電子メールプロバイダを使用して複数のサーバー間で電子メールが移動し、電子メールは activesync を使用して 1 台のサーバーに存在します。

サード パーティのラウンド トリップ電子メール パス

1. ドットコムモニター「電子メールクライアント」は、パブリックインターネット経由でメッセージを送信します
2. お客様の SMTP サーバーがパブリック インターネット上のサード^パーティ アカウントにメッセージを転送する
3. 第 3^部 (Gmail) メール サーバー メッセージを受信します。
4. ^{3 番目の}部分 (gmail) 自動転送は、パブリック インターネット経由で顧客の電子メール サーバーに
5. Dotcom モニター 「電子メール クライアント」は、パブリック インターネット経由で顧客 POP3 または IMAP サーバーからの電子メールを要求します (または、自動転送しない場合は、直接、3^rd パーティの Gmail から)

アクティブシンクメールパス

1. ドットコムモニター「電子メールクライアント」は、パブリックインターネット経由でメッセージを送信します
2. お客様の ActiveSync Server がメッセージを転送し、アカウントがローカルであることを検出して、パブリック インターネットに送信せず、アカウントに直接送信します。
3. ドットコムモニター「電子メールクライアント」は、パブリックインターネット経由で顧客ActiveSyncサーバーからの電子メールを要求します

APIはIPアドレスによってロックダウンされ、許可されたユーザーのみがアクセスできるようにします。 Web API 統合 ( > 統合の管理 > 新しい統合) を構成する場合は、Web API を介して Dotcom-Monitor アカウント以外のデータへのアクセスを有効にする必要があります。 詳細については、「 Web API アクセスの IP をホワイトリストに登録する方法 」を参照してください。

API の使用方法の詳細については、 API の概要ページを参照してください。

ドットコムモニターは、次のスケジュールに従ってシステムから自動的にデータをパージします。

有効なアカウントの場合:

• CSV や PDF ドキュメントなどの生成されたレポートファイルは、生成日から 3 年間保持されます。
• すべてのタスクの応答時間データは 6 か月間保持されます。 DNS、最初のパケット応答時間、個々の要素の読み込み時間などの詳細なウォーターフォールチャートに含まれるすべての応答時間データは、6ヶ月間の保持期間に含まれます。
• 集計データは 3 年間保持されます。 たとえば、HTTP ページ読み込みタスクの要素レベルの詳細は 1 年後には使用できなくなりますが、ページを読み込む集計時間は 3 年間保持されます。 これには、計算された稼働時間やダウンタイム期間など、計算された集計データが含まれます。 したがって、指定したクエリの期間が、保存された集計データよりも短い場合、1 年前の期間に対して実行されたグラフまたはレポートがデータを返さない可能性があります。
• ビデオ録画は 6 日後に消去されます。 ビデオ録画の動作の詳細については、 ビデオ録画の記事を参照してください。

この保持ポリシーは、すべてのタスクの種類に適用されます。

試用アカウントのデータはこのスケジュールに従って保持されず、試用期間が終了した後はいつでも削除される可能性があります。

アカウントの最後のユーザー ログインから 60 日以内に、閉じられたアカウント データがシステムから削除される場合があります。

警告を設定してタスクを開始すると、複数のアラートが表示されることがありますが、サービスや Web サイトをチェックすると、すべてが正常に表示されます。 エラーの原因を把握するためには、アラートの内容に注意を払うことが重要です。 一部のエラーにはカスタム の Dotcom-Monitor エラー コードが含まれている場合もあれば、エラーの原因を解読するのに役立つ http ステータス コード が含まれているものもあります。

Dotcom-Monitor 監視機能の詳細な性質により、アラート、レポート、または記録されたスクリプトを調整して、特定の要素やエラーを除外して誤検知を排除することができます。 これらの理由の一部は次のとおりです。

• 残りの場所が成功している間、1 つ以上の監視場所がタイムアウトしています。
• サイトに変更が加えられたので、予期されていた特定の要素が見つかりません。
• あなたのウェブサイト上の何かが遅く反応し、システムがもはや存在しないと思う
• ネットワーク トラフィックが原因で、サイトの速度が低下し、タイムアウト制限を超えています。
• インターネット経由または 1 つの監視場所からのネットワーク トラフィックの "しゃっくり"
• サードパーティの要素の読み込みが遅くなり、タイムアウトしています。
• サードパーティの要素への URL が変更されました。

これらの誤検出を調整するには 、フィルタ を作成し、問題のあるデバイスのアラートとレポートにフィルタを適用 します。

デバイスで 誤検知チェック を有効にすることもできます。 これにより、監視エラーが検出された場所から、デバイスが複数回エラーを発生していることを確認するために、一度のチェックが発生します。

ドットコムモニターシステムで多数のオブジェクト項目(デバイス/タスク/フィルタ/スケジュール/など)を作成する最も簡単な方法は、 サポートチケットを開いてサポート チームに支援を依頼することです。

作成するすべてのオブジェクトのリストを含むスプレッドシートを提供する準備をしてください。 必要に応じて、スプレッドシートをサポートチケットに添付して、サポートが必要な変更を行えるようにする必要があります。

デバイス マネージャから、デバイスマネージャから最大 24 時間、デバイスの横にあるアクションをクリックし、[ 警告を消す] を選択し、必要な期間のサイレンシングを実行することで、個々のデバイス アラートを最大 24 時間消音できます。

複数のデバイスを一度に消音するには、消音する各デバイスの横にあるチェックボックスをクリックし、リストの上部にある[アラートの無音化]ボタンをクリックして、目的の期間を選択します。

また、API を使用して、24 時間以上のアラートを無音にすることができます。 この方法については、チェックアウト API: デバイスのアラートを無効にするを参照してください。

Dotcom-Monitor システムは、監視対象ごとに必要なパフォーマンスレベルを検出するために慎重に調整する必要がある、堅牢な監視ツールセットを提供します。 アラートの数とさまざまな要因により、誤検知を排除するために、モニタの設定の一部を調整する必要があります。

受信する警告が有効かどうかを確認するには、この記事で 誤検出を特定する方法を確認してください。

現在の構成方法でアラートを受信したくない場合は、アラートを受信した時間に対してデバイス マネージャから オンライン レポート を実行すると、アラートのトリガーとなるものについて詳しく知らされます。

最大期限切れ時間

オンライン レポートのエラーに "(300) タスクの最大タイムアウトが切れました" と表示される場合、タスクの完了に時間がかかったのは、タスクに指定された最大タイムアウトよりも長くかかったことを意味します。 これは正当な問題を指しているかもしれませんが、アラートを受信する必要がある時点を決定するのはユーザーの必要です。 アラートの受信数が多すぎると思う場合は、タスクを編集して、最大タイムアウト制限値を増やすことができます。

場所固有のエラー

複数の場所から監視を行っているのに、1 つの場所からのみ問題が発生している場合は、いくつかの確認が可能です。

IP 制限付きアクセス

サーバーのアクセスが IP アドレスによって制限されている場合は、 すべての監視場所の IP アドレス を IP アドレス アクセス リストに追加していることを確認してください。

必要なセキュリティ証明書

サーバーがコンテンツにアクセスするために証明書を必要とする場合は、 サポート チケットを開いて 、各監視場所に証明書をアップロードする必要があります。

中国のグレートファイアウォール

中国の場所で問題が発生している場合は、「中国の大ファイアウォール」の結果が表示される可能性があります。 中国政府が国内からアクセス可能なコンテンツを厳しく管理しているので、コンテンツがアクセス不能として除外されたり、特定のサイトへの帯域幅が制限されてサイトの要素がタイムアウトになることがあります。 これらのケースでは、中国政府がネットワークを制御しているので、あなたができることはほとんどありません。

サポートへのお問い合わせ

特定の場所から問題が発生した場合は、 サポート チケットを開 いて、サポート チームが協力して他の可能性のある問題を特定します。 DNS サーバーのルーティングが正しくない、DNS の逆引き参照、または監視場所に固有の問題が発生する場合があります。

ユーザービューのタイムアウト

UserView スクリプトを実行している場合は、サイトにすべての要素を正しく読み込む時間を増やすために、スクリプトに 遅延 を追加する必要があります。 また、遅延を追加した後に href をクリックするなど、この手順を繰り返すことができます。

アラート メッセージを送信するかどうか、および送信先を決定する要素は多数あります。

フィルター

デバイスを作成すると、既定のフィルタがすべてのデバイスに自動的に適用されます。 既定のフィルターでは、アラートがトリガーされる前に、複数の場所 (1 つの場所だけを選択しない場合を除く) がエラーを受信する必要があります。 これは、1 つの場所が小さなネットワークの問題に苦しんでいる場合に、誤検知の警告を排除するために行われます。 複数の場所を必要としないフィルタを作成できますが、インターネット上のトラフィックの制御されていない性質のために、多くの誤検知アラートが届く可能性があることに注意してください。

スケジュール

スケジュールをデバイスに適用した場合、スケジュールされていない期間中はデバイスが監視されないので、アラートを設定するデータは記録されません。 24 時間おきにアラートを受信したくない場合でも、システムが 24 時間監視されるように、デバイスにスケジュールを直接適用しないことをお勧めします。 スケジュールを異なるアラート グループに適用して、たとえば、異なるグループが勤務シフト中にのみアラートを受信するようにすることができます。

エスカレーション期間

グループアラートを設定する際に、エラーが検出されたときにグループが直ちに通知を受け取るかどうか、またはエラーが最初に検出された時点からエラーが送信されるまでの遅延を指定できます。 たとえば、第 1 層のサポートがアラートを受信してから 30 分経過してもエラーが発生し続ける場合にのみ通知される第 2 層サポート グループがあるとします。

誤検知チェック

既定では、誤検出チェックはオンになっています。 つまり、監視場所でエラーが発生した場合、エラー メッセージを送信する前にエラーを再作成しようとします。 誤検知の警告を受け取るリスクが高まるため、これを無効にすることはお勧めしませんが、タスクが 1 回の反復処理を完了するまでに特に長い時間がかかる場合は、最初のエラーが検出されてから 10 分 (最初のタスクを完了するまで 5 分) を受け取る代わりに、すぐにエラーが発生するように誤検出チェックをオフにすることをお勧めします。、エラーが検出されると、さらに5分でエラーを確認します)

アラート グループ

アラート グループは、複数のデバイスに対して設定および使用できます。 だれかが警告を受信していない場合は、その連絡先情報が必要なすべてのグループに存在することを確認してください。 グループは追加のデバイスに使用される可能性があるため、グループの編集や削除には注意が必要です。

Web サイトが部分的または完全にアクセス可能な場合に発生する可能性のあるエラーは多数あります。 ウェブサイトが利用可能に見える間に発生する可能性のある最も一般的なエラーには、次のようなものがあります。

• タイムアウトを超えました

タイムアウトが発生したことをエラーで示している場合は、監視タスクの詳細を編集し、最大タイムアウト値を探します。 タイムアウト エラーが多い場合は、タイムアウトの最大値を増やすか、またはタイムアウト値を完全に削除することを検討してください。 また、サイトの更新を実行して、読み込み速度を向上させるか、コンテンツ配信ネットワーク (CDN) で個々の要素をホストすることもできます。 [最大タイムアウト] の値を指定していない場合、タスクのデフォルトのタイムアウトは 120 秒です。

• 検証中のテキストまたはイメージが見つからない

特定のキーワードまたはイメージの検証が含まれているタスクがページ上で見つかった場合、残りのコンテンツは、予期される要素が欠落している間も正しく読み込まれる可能性があります。

• ページ上の要素の読み込みが遅く、スクリプトが失敗する

要素が完全に読み込まれる前にタスクが要素を検索すると、一部の検証が失敗することがあります。 タスクが UserView スクリプトの場合は、この特定の要素を検証する前に時間の遅延を追加する必要があります。

• DNS サーバーのサブセットに対して DNS 解決が失敗する可能性があります。

インターネットやローカル サービス プロバイダ間でさまざまなネットワークの問題が発生するため、指定された DNS サーバーまたは最上位の DNS サーバーのいずれかが、サイトに対する DNS 解決を完全に修飾できないことがあります。 この場合、ほとんどのブラウザは次に利用可能な DNS サーバーに対してクエリを実行し、解決を完了しますが、監視の設定によってはアラートが表示されることがあります。 DNS エラーのトラブルシューティング方法の詳細については、サポート技術情報の記事を 参照してください。

オンライン レポートの詳細で、個々の監視セッションを展開してステップの詳細を表示すると、エラーが発生しても全体的な監視タスクが成功するのはなぜですか。

監視対象のサーバーに対する個々の要素または呼び出しによってフラグが設定された応答やエラー応答が発生する場合が数多くあります。 このような応答は、通常、赤い感嘆符で示され、テキストはわずかに灰色表示されることがあります。

1. このタイプのフラグ付きイベントの原因の 1 つとして、監視対象の Web サイトに 基本認証が必要であることが考えられます。 この場合、サーバーは、基本認証が必要であることをブラウザーに知らせる 401 応答を返すため、URL の最初の要求はエラーとしてフラグが付きます。 次の要求は、正常な応答を返す基本認証資格情報を含むモニターから送信されるため、技術的にはタスクが正常に完了します。
2. もう 1 つの原因として、要求された要素が監視スクリプトの以前の要求から既に読み込まれ、その要求が取り消されると、タスク全体が正常に完了した可能性があります。
3. このような異常に関するさらなる洞察については、 サポートチケットを開いてサポートにお問い合わせください。