Web サイトのモニタを設定するときに監視または無視する詳細レベルは多数あります。
まず、Web サイトが監視できるほど重要な Web ページを決定する必要があります。 通常、ユーザーはホーム ページ、ポータル ログイン、ダッシュボードやショッピング カートのチェックアウトなどの主要な内部機能を選択します。 次に、これらのページが組織の健全性にとってどれほど重要であるかを判断します。 たとえば、SaaS Web アプリケーションが唯一の製品である場合があるため、1 分ごとにダウンする大きな問題になります。 ダウンタイムがビジネスに与える影響を知ることで、Web サイトや Web アプリケーションを監視する頻度を判断できます。 情報マーケティング サイトの所有者は、Web サイトが 1 日に数回オンラインであることを知って満足している場合がありますが、オンライン ショッピング カートの管理者は、できるだけ早く問題があるかどうかを知る必要があります。
ダウンタイムのコストがビジネスに与えられる可能性を大まかに考えたら、監視の価格に対してそれを重み付けする必要があります。 より頻繁な監視は、監視データの帯域幅とストレージスペースのコストのためにサービスの価格を上昇させる予定です。 Dotcom-Monitor は、スクリーンショットや監視結果のビデオキャプチャなどの貴重なトラブルシューティングツールを提供しますが、追加のストレージ容量が必要なため、それらを少し高いコストで保存できます。 監視するページに加えて、Web サイトに最適な監視の種類を知る必要があります。
ウェブサイトのモニタータイプを選択する
まず、Web サイトに必要な監視の種類を特定します。 以下に、最も単純なものから最も複雑なものまで、いくつかのオプションを用意しています。
- ping -サーバービューの ping
サーバーが起動しているかどうかを知りたい場合は、ping モニタが最適な場合があります。
- トレースルート (各場所からホストに到達するパスを識別します) -サーバービュートレースルート
- ポートの可用性 -サーバービューの Telnet ポート
- HTML ロード (サーバーからの 200 応答を確認します) -サーバービュー http/s
ServerView http/s モニターは、web サーバーに照会して、html ファイルと 200 OK 応答を送信するかどうか確認できます。
- 完全ページのダウンロード (3rd パーティ 要素を含むすべての要素をダウンロード) -サーバービュー http/s フルページダウンロード
ServerView http/sフルページダウンロードモニターは、ページ上のすべてのコンテンツをダウンロードし、400または500サーバーエラーがないことを確認します。
- 特定のブラウザーでページ全体をダウンロードしてレンダリングする -BrowserView
ブラウザまたはモバイル デバイスを使用してブラウザビューを設定し、ユーザーが自分のブラウザで表示されるように、単一の Web ページのパフォーマンスを監視します。
- レンダリングなしのマルチステップダウンロード -ServerView EveryStepで記録された複数のタスク
EveryStep で記録された ServerView http/s スクリプトは、セキュアログインの背後にあるページを監視したり、レンダリングせずに一連のページを監視したりできます。
- 実際のブラウザでのマルチステップダウンロード、レンダリング、対話 – ユーザービューがEveryStepで記録
ブラウザーを選択し、 スクリプトを記録して、 エンドユーザーの視点から Web サイトの実際のパフォーマンスを監視します。 完全なブラウザスクリプトは、データ入力やボタンクリックを含むウェブサイトをナビゲートして使用するときに実行するすべてのアクションを記録します。 最も完全で徹底的な監視オプションは、ユーザーが実際にウェブサイト上の複数のページと対話する方法をキャプチャするために、EveryStepスクリプトレコーダーでユーザーセッションを記録することです。 また、ユーザービューの監視は、複雑なリッチ インターネット アプリケーション (RIA) と対話して、フラッシュや Silverlight などを記録することもできます。
重要でない要素を除外する
監視する内容を記録または特定したら、いくつかのテストを実行してベースラインパフォーマンスを確立し、スクリプトまたは Web ページに存在する可能性のある問題のある要素を特定する必要があります。 監視に問題が発生する要素がある場合は、コンテンツを除外する特定のドメインを含めるか、除外するかを選択できます。
たとえば、ウェブサイトのフッターに、FacebookやTwitterなどのソーシャルメディアプラットフォームへのリンクを含むアイコンが含まれている場合があります。 一部のウェブサイトでは、アイコンやリンクが欠落している場合、Webサイト管理者は直ちに通知を受け取り、他のWebサイト管理者は全く気にしない場合があります。 BrowserView と UserView モニターを使用すると、エラーの原因とアラートの送信から特定のドメインから個々の要素またはコンテンツをフィルター処理できます。 スケジュールを設定して、ウェブページ全体がダウンした場合は午前2時に警告を受けることができますが、Twitterのフォローボタンがダウンしている場合は、午前6時まで通知を送信しないようにスケジュールを設定できます。
スクリプトを数日間実行して Web サイトのベースライン パフォーマンスを確立した後、ページの読み込みプロセスに不可欠ではない要素をページ上で除外するように監視スクリプトを調整できます。 スクリプトを編集する 1 つの方法は、”拒否および許可” フィルターを使用することです。 ドメインでホストされているコンテンツだけを気にする場合は、* (ワイルドカード) を拒否し、許可 http://www.yourdomain.com/* コマンドを使用してドメインコンテンツのみを許可できます。 それ以外の場合、気にしない要素やサードパーティのホストがいくつかある場合は、各要素で deny コマンドを使用するか、deny http://www.example.com* を使用してドメイン全体を拒否できます。
監視スクリプトのもう 1 つの重要な部分は、アクション間の時間を計測することです。 ネットワークタイムウォッチャーを使用すると、タイムアウトフィルタを設定して、ボタンの押下やナビゲーションなどのアクションとその後の結果の間にかかる時間を測定できます。 タイムウォッチャーを有効にすると、モニターが何か時間がかかり過ぎていることを検出したときにアラートを設定できます。
ウェブサイトの監視に関する決定
各ページで使用するページ数と、使用する監視の種類を決定することが重要です。 ウェブサイト上のすべてのページを監視するのは良いことですが、それほど費用対効果が高くない可能性があります。 多くのドットコムモニターのお客様は、モニターの組み合わせを利用して監視ニーズを満たします。 サーバービューは、稼働時間を検出するために最適です。 BrowserView は、単一ページのコンテンツを検証するために適しており、ユーザー ビューが移動し、複雑なプロセスが動作していることを確認します。
キャッシュされた詩のキャッシュされていないウェブサイトの監視
次に、各モニタリングセッションでウェブサイトがどのように表示されるのかを決定する必要があります。 たとえば、監視対象のセッションは、手付かずの Web ブラウザで新しいユーザーを表していますか? ユーザーがドメインを訪問したことがない場合は、最初の訪問に関連する DNS クエリと、サイト上の多くのサードパーティ要素の DNS ルックアップが行われます。 また、新しいユーザーは、キャッシュされたものがないため、すべてのファイル、スクリプト、画像をダウンロードする必要がありますが、定期的な訪問者はサイト上の静的コンテンツの多くが既にキャッシュされている可能性があります。 毎回新しいユーザーであるかのようにウェブサイトを監視すると、すべてのDNSレコードが正常であり、すべてのファイルがすべての監視セッションでアクセス可能であることを確認できるため、ウェブサイトの健全性を最も深く把握できます。
さらに、JQuery、JavaScript ライブラリ、ソーシャルメディアアイコンなどの一般的な要素を持つ他の Web サイトにユーザーが最近アクセスした場合、ユーザーはローカル マシン上に既にキャッシュされているコンテンツを Web サイトで使用している可能性があります。 サイトの平均的なユーザー エクスペリエンスをシミュレートすることに関心がある場合は、多くの DNS レコードとサイト コンテンツが既にキャッシュされている可能性があります。 この場合、キャッシュされたコンテンツを持つユーザーを返す場合をシミュレートできます。 これを行うには、ブラウザー ビューまたはユーザー ビュータスクの戻り値の訪問フラグを選択できます。
ウェブサイトの監視のための DNS 解決
次に、DNS 解決を処理する方法を決定することができます- Dotcom-Monitor は、さまざまな DNS セットアップを模倣するいくつかのオプションを提供します。
- デバイスキャッシュ
デバイスキャッシュは、DNS レコードが現在の監視セッション内で解決されているかどうかを確認し、そのレコードを使用しているかどうかを確認します。
- キャッシュなし
キャッシュに入れ子でない場合、すべての要素のルート DNS サーバーから DNS 解決を検索するタスクが強制されます。 これは、ブラウザビューまたはユーザービュータスクでは現実的ではないので、サーバービュータスクのオプションに過ぎません。
- TTL キャッシュ
TTL キャッシュは、最後の検索以降、存続する時間が経過するまで DNS が検索されない実際のユーザーを模倣する最良のオプションです。
- 外部 DNS サーバー
外部 DNS サーバーでは、ルート サーバーにアクセスするのではなく、DNS 解決のルックアップを使用してクエリを実行するサーバーを指定できます。
さまざまな DNS オプションの詳細については、「 ドットコム モニタのナレッジ ベース」を参照してください。
監視場所の選択
モニターの数と位置を変更したり、制限したりすることによって、モニター結果が大きく影響を受ける可能性があります。 通常はトラフィックを受信しないリモート ロケーションからの監視は、負荷の高い時間により結果がずれ出す可能性があります。 また、中国政府は中国に出入りするすべてのトラフィックを厳格に管理しており、コンテンツフィルターにより監視結果が遅くなったり壊れたりする可能性があるため、中国のグレートファイアウォールの背後にある場所からの監視は平均応答時間を大幅に変更する可能性があります。 中国のファイアウォール テスト を実行して、中国のグレートファイアウォールの背後からWebサイトと要素がどのように読み込まれるかを確認します。 中国のグレートファイアウォールについてもっと読む。
ラウンドロビンモニタリング
監視する場所の数は、各場所から受信した監視結果の頻度にも影響します。 ドットコムモニターは、ラウンドロビンアルゴリズムを使用して監視データを収集します。 つまり、選択した周波数について、一度に 1 つの場所から監視します。 たとえば、3 つの場所を選択し、1 分間の監視を行った場合、次の結果が表示されます。 12:00 PM – カリフォルニア州, 12:01 PM コロラド, 12:02 午後ニューヨーク, 12:03 午後カリフォルニア, 12:04 PM コロラドなど. ご覧のように、選択する場所が多いほど、監視場所のキューが元の場所に戻る前の場所が長くなります。
極端なケースは、24 のロケーションを選択し、3 時間の監視の頻度を持っている場合です。 1 つの場所はラウンド ロビン方式で 3 時間に 1 回監視するため、最初の場所が 2 回目にチェックされるまで 72 時間かかる可能性があります。 このため、遠隔地から一部の場所を削除することをお勧めします。 または、複数の監視デバイスを設定して、同じ Web ページを監視し、異なる場所から監視することもできます。 理論的には、複数の場所から 1 分間の周波数で一度に監視できますが、コストは高くなります。
ウェブサイトの監視の設定に関するヘルプ
一日の終わりには、あなたのニーズに応じて、非常に具体的かつターゲットを絞った方法でウェブページを監視するのに役立つさまざまなオプションがあります。 お客様のニーズに合った最適な監視ソリューションを決定するその他のヘルプについては 、Dotcom-Monitor サポート にお問い合わせください。
