DNS 監視の権利の実行: AT&T DNS の停止
2012年8月15日のAT&Tドメインネームサーバー(DNS)の停止は、ミッションクリティカルなウェブサイトにとってウェブサイトを監視するための「非キャッシュベース」の方法が重要である理由を例示しています。 まず、少しレビュー。 最も一般的な基本的な Web サイトの監視 は、HTTP 要求プロセスを介してターゲット サーバーに接続する合成ブラウザー (実際のブラウザーではない) を使用して行われます。 対象サーバーの可用性、Web サイトの HTML ファイルをサーバーから読み込む時間、HTML ファイル内のキーワードを検出する機能など、サーバーに焦点を当てたプロセスの多くは、HTTP 要求プロセスを使用して合成ブラウザーを使用してチェックされます。
キャッシュするかキャッシュしないか、それが問題です
しかし、基本的な合成HTTP監視方法論について一般的に知られていないのは、ウェブサイトの監視会社が「キャッシュ」または「非キャッシュ」の方法論を使用する選択肢を持っていることです。 モニタリングサービスによる方法論の選択 2012 年 8 月 15 日に発生した AT&T DNS 停止など、セカンダリ DNS サーバーの問題を検出する機能に直接影響します。一方で、キャッシュベースの方法は、監視業務が実装する方がはるかに簡単で、設定と管理にかかるコストが少なくなります。 実際、低コストの「基本的な」アップタイム監視サービスのほとんどは、「キャッシュ方式」を使用しています。
私は非キャッシュ、おかげで取ります
しかし、ダーティ・リトル・シークレットは、監視のキャッシュ方法が、キャッシュ以外のソリューションほど正確ではなく(また、長期的には費用対効果の高い)である。 なぜでしょうか。 単純な理由は、キャッシュベースのメソッドはセカンダリ DNS の問題を検出しないからだ。
もう少し複雑な理由は長くなりますが、ダウンタイムを避けて、良い監視が何であるかの肉に実際に取り入れられます。
具体的には、非キャッシュがより費用対効果が高い理由は、AT&T DNS停止のような問題が常に発生する場合、Webサイトのエラー状態が発生した場合と同様に、コスト効率が高いからです。 ダウンタイムによる損失を決定する合計修復時間(TTR)です。 つまり、エラーの検出、診断、 修復 に要する合計 TIME (1) は、エラーの影響が悪化します。 逆に、監視ソリューションが速くTTRをスピードアップするほど、損失が減少します(または完全に回避されます)。
次の AT&T DNS 停止状況を効果的に監視する方法
AT&T DNS の停止問題の場合、修復までの時間を決定するいくつかの重要な要因があります。
エラー検出方法: 非キャッシュ方式を使用する監視ソリューションを使用して、各監視インスタンスを持つルートネームサーバーまで DNS クエリを伝達します。 キャッシュ方式サービスは DNS をキャッシュするため、セカンダリ DNS の問題をまったく検出しないか、問題を検出するのに数日から数週間かかる場合があります。
-監視の頻度: 1 分ごと 1 時間ごと、1 時間に 1 回など、非キャッシュ監視の頻度を速く使用します。 非キャッシュ監視ソリューションが、障害が発生した DNS サービスを使用して影響を受ける Web サイトの管理者を高速に検出して警告する速度で、DNS フェールオーバー プロバイダーに対して迅速に切り替えを行うことができます。
– 存続時間 (TTL) 設定の頻度: DNS 管理者が DNS キャッシュをプライマリ権限のあるネームサーバーからドメイン名のセカンダリ DNS サーバーに設定するために使用する、存続時間 (TTL) の頻度設定の値が小さくなります。 障害復旧計画では、通常、86,400 秒 (1 日) 以上に設定すると、TTL は 300 秒に 1 回の低い値に設定できますが、設定値が低いほど、権限のあるドメイン ネーム サーバーの負荷が高くなります。
-診断 (検出された DNS 問題の時点での自動トレースルートなど) は、監視ソリューションによって提供されます (ほとんどの基本的な監視サービスは、診断情報を提供しません)
-Repair: エラー状態の間にソリューションを監視し続け、問題をさらに特定します。 監視対象の結果を DNS プロバイダーに送信します。 また、 ここで 無料の手動 DNS トレース ルートを実行して (トレース スタイル “DNS” を選択) して、必要に応じて問題を確認することもできます。
-防止: DNS 検索の詳細を表示できる監視ソリューションを使用する 実際のブラウザ監視)スローダウントレンドや断続的な問題などの「ソフトエラー」を確認するため、「ソフトエラー」が「ハードエラー」になる前に、ダウンタイムに直面しているお客様のような「ハードエラー」に対処できます。
(1)TRAC Researchに参加した組織によると、2011年9月の調査では、パフォーマンスの問題のトラブルシューティングに費やされた時間が「平均して、毎月戦争室の状況で費やされる全労働時間(46.2時間)にわたって」の最大の課題であると特定しました。
