Функциональность мониторинга DNS и обновления функций
Система Domain Name Server (DNS) является одним из наиболее важных строительных блоков Интернета, и тем не менее, она часто неправильно понимается и считается как должное. Система DNS, как фундамент дома в основном скрыты, игнорируются, и не обсуждается.
Однако, как дом с проблемами фундамента, если Есть DNS проблема все на вершине, или зависит от системы DNS — сети, подключение, пользовательский опыт — влияет. Поэтому мы считаем, что процесс DNS является неотъемлемой частью мониторинга. Потому что, если процесс DNS не удается, то большинство пользователей не могут получить доступ к онлайн-ресурсов потребляется.
По умолчанию Dotcom-Monitor разрешает имена хостов, начиная с корневых серверов. Разрешение имен хостов с корневых серверов гарантирует, что цепочка DNS не будет нарушена, а имена хостов могут быть решены на их соответствующий IP-адрес во время проверки. При разрешении имени хоста с корневого сервера обеспечивается наиболее полная проверка, для некоторых клиентов и при определенных обстоятельствах это может вызвать проблемы.
Проблемы с мониторингом из-за разрешения имени хоста с корневого сервера
- Увеличение общего времени для мониторинга — Общее время для выполнения проверки мониторинга увеличивается, поскольку разрешение DNS может занять несколько секунд. В некоторых случаях, когда экземпляр мониторинга особенно быстр (т.е. загрузка пикселей HTTP), разрешение DNS может составляют большую часть общего времени для выполнения мониторинга. Таким образом, мониторинг не будет отражать опыт среднего пользователя веб-сайта или интернет-ресурса. Поэтому, если клиент больше заинтересован в мониторинге опыта повторного посетителя веб-сайта, то мониторинг распространения DNS с корневого сервера не подходит.
- Разрешение DNS не может контролироваться, поэтому проблемы DNS не имеют значения — В некоторых случаях процесс разрешения DNS не находится под контролем клиента, поэтому они предпочитают игнорировать проблемы DNS и простои. Хотя важно знать о проблемах разрешения DNS, поскольку это запрещает доступ конечного пользователя к службам, клиенту не полезно получать оповещения о мониторинге и отчеты о проблемах DNS, которые они не могут контролировать.
Контроль проверки производительности разрешения DNS
Пользователи Dotcom-Monitor имеют обширный контроль над тем, как dns разрешение выполняется для их задач мониторинга. На основе обширной обратной связи с пользователями для задач мониторинга доступны четыре различных варианта DNS для решения имен хостов:
1. Устройство кэшировано (опция по умолчанию) — Когда эта опция установлена, Dotcom-Monitor будет решать имя хоста один раз в экземпляре проверки. Таким образом, если в одном или нескольких задачах в одном и том же устройстве есть ссылки на одно и то же имя хоста, то поиск DNS будет происходить один раз, а затем будет кэширован на время проверки на этом устройстве.
Большинство проверок довольно быстро и выполняется менее чем за одну минуту, так что определили, что нет никаких оснований для решения одного и того же хозяина каждые несколько секунд. Недостатком этой опции является то, что данные о производительности могут варьироваться в зависимости от задачи в одном устройстве. Таким образом, если вы контролируете два URL-адреса в одном устройстве, которые находятся на том же хосте, первый URL всегда будет медленнее, потому что он будет включать время поиска DNS, в то время как второй URL будет использовать кэшированный IP-адрес DNS и разрешение DNS будет очень быстрым.
2. Не кэшированный — Когда эта опция установлена, каждая проверка разрешает имя хоста, распространяемое с корневых серверов. Это полезно для обеспечения равномерного времени, так как поиск DNS будет выполняться каждый раз. Однако опция не кэша может значительно увеличить нагрузку на DNS-серверы, а также увеличить время отклика для выполнения задач мониторинга.
Эта опция недоступна для браузерных платформ мониторинга BrowserView или UserView, так как нецелесообразно разрешать одно и то же имя хоста сотни раз в течение нескольких секунд после проверки. Например, подумайте о веб-странице, которая имеет много элементов на одном сервере, имеющих отдельные разрешения DNS от корневого сервера. В этом типе сценария достаточно решить один раз за проверку.
3. TTL Live — Этот вариант лучше всего имитирует опыт реального пользователя. Dotcom-Monitor один раз разрешает имя хоста и кэшит его для значения Time-to-Live (TTL) в месте мониторинга. Значение TTL может варьироваться от нескольких секунд до нескольких недель. TTL контролируется DNS-сервером, принимающим имя.
Важно отметить, что если опция TTL Live установлена и DNS-сервер выходит из строя, то Dotcom-Monitor может не обнаружить сбой до истечения срока действия TTL (что может занять несколько дней или недель). Этот вариант рекомендуется только в том случае, если мониторинг для правильного разрешения DNS не является приоритетом.
4. Конкретный DNS-сервер — Эта опция будет запрашивать указанный DNS-сервер для решения хоста на IP-адрес. Это полезно в определенных ситуациях, например, если вы знаете, что большинство ваших клиентов используют общедоступную службу кэширования, например, Google 8.8.8.8, или 8.8.4.4. В этом случае можно настроить DNS Server на один из IPs Google. До тех пор, пока указанный Google DNS предоставляет действительный ответ Dotcom-Monitor не обнаружит ошибку DNS, даже если DNS-сервер, ответственный за домен, не работает должным образом.
Другая ситуация связана, если вы знаете серверы, ответственные за разрешение имен и не заботитесь о всем разрешении цепочки DNS. В этом случае можно указать DNS-сервер для использования для разрешения DNS. Эта опция может обеспечить лучшее время разрешения DNS, так как Dotcom-Monitor не должен распространять поиск с корневого сервера и может перейти непосредственно к надлежащему DNS-серверу. Однако эта опция может не обнаружить все проблемы, связанные с DNS.
[divider top=»no»]Использование опций разрешения DNS для решения конкретных проблем
Как отмечалось выше, каждый вариант разрешения DNS имеет свои плюсы и минусы. Возможность настройки процесса разрешения DNS обеспечивает гибкость, которая наилучшим образом служит конкретной ситуации и необходимости. Как правило, чаще всего рекомендуется опция по умолчанию , Device Cached. Однако при определенных обстоятельствах другие варианты разрешения DNS могут быть ценным решением для решения конкретных вопросов.
