DNS
DNS DNS - система доменних імен (domain name system), слугує для визначення розташування сайтів.

DNS - система доменних імен (domain name system). Ця система допомагає знайти фізичний сервер за допомогою віртуального імені сайту. Вона реалізована на базі ієрархічної структури DNS серверів, кожен з яких містить інформацію про певні домени та може делегувати таку ж роль нижчим за рангом серверам. Для прикладу, візьмемо сайт www.host-tracker.com. Доменне ім'я найвищого рівня - .com, таким чином звернення йде до серверу, відповідального за всі .com сайти. Він знає, де розташований кожен з цих сайтів, або ж щонайменше адресу іншого сервера, який вже знає напевно. Якщо ж Ви бачите повідомлення "Сервер не знайдено", це означає, що DNS сервер не містить записів про сайти з ім'ям, яке Ви ввели.

Кожного разу, коли Ви набираєте адресу в браузері - генерується запит DNS, з метою визначення фізичного розташування сайту. Для того, щоб пришвидшити цей процес, дані DNS можуть бути збережені у кеші. Якщо ж Ви є власником сайту і вирішили з якоїсь причини змінити його назву, або ж якщо Ви щойно створили новий сайт - слід мати на увазі, що для глобального оновлення кешу DNS потрібен деякий час. Зазвичай, це відбувається в межах пари годин, проте взагалі може зайняти аж до 48 годин. Саме тому іноді новостворені сайті можуть бути недоступними протягом певного часу.

  • CM.Glossary.WebsiteMonitoring
  • CM.Glossary.Uptime
  • CM.Glossary.WebHosting
більше глосарій
Як перевірити доступність сайту?

Базова функція сервісу ХостТрекер -  регулярна перевірка сайтів з інтервалом моніторингу від 1 хвилини. Більш того, перевірка здійснюється за допомогою розподіленої мережі моніторингу, яка, на даний момент, налічує  понад 140 серверів по всьому світу. Які ж перевірки доступності сайту бувають? Як заміряти час відгуку сторінки і швидкість її завантаження.

Базова функція сервісу ХостТрекер -  регулярна перевірка сайтів з інтервалом моніторингу від 1 хвилини. Більш того, перевірка здійснюється за допомогою розподіленої мережі моніторингу, яка, на даний момент, налічує  понад 140 серверів по всьому світу.

Кожна перевірка симулює візит реального користувача. Якщо цей уявний відвідувач зміг успішно зайти на сторінку - все добре, якщо ж ні - за певним алгоритмом відбувається повторна перевірка (для надійності), далі фіксується помилка і надсилається повідомлення про недоступність сайту. Але це найбазовіший спосіб, здатний виявити і зафіксувати більшість помилок. Втім, для кращої діагностики і передбачення цікавіших сценаріїв існує багато додаткових інструментів.

Які ж перевірки доступності сайту бувають?

Коротко зупинимося на найбільш популярних з них. Слід зауважити, всі ці перевірки використовують різні протоколи. Наприклад:

  • HTTP – по суті є звичайним запитом, що надсилається з браузера користувача;
  • Ping - це перевірка сайту або сервера на доступність з мережі загалом по протоколу ІСМР.
  • TCP-порт - перевірка можливості приєднання до певного додатку та доступності з мережі певного порта;
  • Перевірка баз даних - дозволяє побачити, чи є база, з якою працює сайт, доступною, чи є в ній необхідні дані, а також дозволяє контролювати певні показники в ній. Є можливість перевіряти дані і на самій сторінці завдяки функції перевірки контенту. У цьому випадку віртуальний клієнт не просто заходить на сторінку, але й додатково шукає на ній присутність або ж відсутність певних слів і виразів. Це дозволяє бути в курсі, коли щось важливе зникає зі сторінки, або ж навпаки: відстежити певну помилку в момент її появи.
  • Також можна заміряти час відгуку сторінки і швидкість її завантаження. Ця інформація зберігається в логах перевірок.

Поєднучи всі ці показники, ви маєте можливість зібрати багато цінної інформації про стан сайту. І дізнаватися не тільки про те, що сайт перестав працювати, а й чому так сталося (відвалилася мережа, або впав сервер, або проблема з самим сайтом тощо). Більш того - навіть якщо сайт працює, моніторинг дозволяє помітити коли він став повільно завантажуватися, а, отже, клієнтам стало незручно ним користуватися. Або якісь дані регулярно не завантажуються з бази. Тобто, час на діагностику скорочується і все можна полагодити ще швидше. А отже, і час простою скорочується.

Цікавий факт: майже всім клієнтам сервісу ХостТрекер вдається досягти показників аптайму >=99%. До речі, дані з сервісу ХостТрекер є базою для хорошої аргументації в суперечках з хостингом. Чимало клієнтів ХостТрекера знайшли для себе оптимальний хостинг або ж змусили існуючий дотримуватися умов договору.

Цікавою також є функція моніторингу термінів закінчення реєстрації доменів і сертифікатів. Здавалося б, все просто: реєстратор сам надсилає листи з нагадуваннями. Але є випадки, коли навіть такі компанії, як Microsoft не оминає ця біда.

Ще однією корисною функцією є перевірка на потрапляння у всілякі списки блокування, відомі як DSNBL. Суть їх у тому, що вони, володіючи певною репутацією, за своїми критеріями аналізують IP адреси і домени, намагаючись виявити джерела розповсюдження спаму, зафіксувати участь у ботнетах, зараженні і поширенні шкідливих програм тощо. Якщо вони вирішують, що хтось грішить – цей хтось блокується і нове ім’я з’являється у списку.

Проблема в тому, що ці списки є загальнодоступними, щоб інші люди могли по ним налаштовувати фільтри. І ось тут дуже неприємний момент: до них можна потрапити цілком випадково і навіть не знати про це. Здогадатися можна лише за рядом неприємних ознак, таких як: падіння рейтингів в пошукових системах, зменшення відвідуваності, зниження ефективності розсилок тощо. А потрапити туди можна навіть без очевидних підстав, просто тому, що ваш хостер ділить вашу IP адресу з кимось менш «чистим на руку» або більш легковажним в плані безпеки. Моніторинг цих списків дозволяє вчасно дізнатися про «новий» статус і, відповідно, вчасно відреагувати. Необхідні в цьому разі заходи полягають, як правило, лише в написанні листа з проханням видалити зі списку, або ж навіть в проходженні якоїсь автоматичної процедури на визначення що ви не робот.

Налаштування сервісу

Всі описані вище перевірки мають ряд цікавих налаштувань:

  • Планування технічних робіт - не фіксувати помилки, якщо, наприклад, запланований апгрейд сервера.
  • Перевірки з певного регіону - як зазначалося вище, в наявності широка мережа, і є можливість вибирати тільки регіони світу з потенційною клієнтурою.

  • Сповіщення з затримкою - якщо є необхідність відправляти повідомлення  лише в разі тривалих збоїв.

Детальніше про самі сповіщення:

У клієнтів є безліч варіантів бути інформованими. Звичайно ж, серед них є електронна пошта і СМС, а також популярні меседжери - Skype, Viber, Hangouts, Telegram, голосовий дзвінок. З цікавого - POST запит, тобто можливість надсилати запит на певний веб-сервер, запускаючи при цьому на ньому якийсь сценарій, наприклад, автоматичне перезавантаження сайту.

Сервіс має API, який дозволяє інтегрувати його з різними додатками і використовувати в найрізноманітніших цілях.

Ще одним важливим плюсом сервісу є те, що він не вимагає встановлення будь-якого програмного забезпечення на сервери клієнтів. Майже всі функції працюють в хмарі і налаштовуються через сайт сервісу ХостТрекер за пару хвилин.

Додамо, що сервіс постійно розвивається: розширюється мережа моніторингу, з'являються нові функції тощо. Останні, до речі, поповнюються, в першу чергу, завдяки запитам клієнтів. Тому якщо у Вас є цікаві пропозиції та ідеї, не зволікайте, сміливо пишіть команді ХостТрекера! Можливо, саме Ви станете тією «рушійною силою» для нового та корисного інструментарію.

 

більше блог
Благодарим за внимание к нашему сервису!
 
Вхід
Вхід
Зареєструватись
Ціни та пакети
Наша мережа моніторингу
Home > Blog
Host-Tracker under Windows Azure (English)

Those, who actively involved with the Web, should know HostTracker, a company from Ukraine, which has been supporting one of the leading global web monitoring services since 2004. Its goal is to monitor site health and accessibility in near-real-time access. Using alert message system, HostTracker allows to reduce downtimes, to improve quality of service for users, to quickly localize troubles...

​Those, who actively involved with the Web, should know HostTracker, a company from Ukraine, which has been supporting one of the leading global web monitoring services since 2004. Its goal is to monitor site health and accessibility in near-real-time access. Using alert message system, HostTracker allows to reduce downtimes, to improve quality of service for users, to quickly localize troubles, and etc.

Architecturally, HostTracker includes a server-based hub, acting both as a data collector and control center, and a series of software agents, launched in various regions – typically using the equipment operated by major providers, hosters and affiliates. The geographically distributed architecture provides common system reliability and also allows collecting data in terms of access speed, bandwidth and other key performance characteristics on regional level – a critically important feature for the international business.

The first version of HostTracker, which is still functioning and providing services for tens of thousands of customers, was Linux based. Today, it is supported by nine control servers, located and organized in two DPCs on collocation principle, and few dozens of agents. Considering that the final objective of web monitoring is focused on increasing the uptime of client-based web resources – whereas 95% of HostTracker customers were able to increase it up to 99% – then, performance and accessibility of the service itself are not just critical, but rather fundamental parameters that influence the whole business. Theoretically, HostTracker should demonstrate accessibility close to 100%. However, an extensive growth of the service made this task hard to solve.

HostTracker was facing constantly increasing network traffic – a problem for seamless operation of the service. Inability to add new control servers on-the-fly, difficulties when maintaining not uniform and multiple-aged hardware was another limiting factor. Moreover, the desire to develop the service through wider protocol and network service support was meeting certain obstacles. “Unfortunately, for Linux there was a limited choice of ready-to-use solutions and libraries, while inventing something completely new was difficult”, says Artem Prisyazhnyuk, HostTracker director. “We had an idea of reviewing the stack of technologies we used for a more sophisticated one and after taking a closer look at the .NET platform, its potential in terms of scalability and network support, I realized that was exactly the thing we had been looking for.”

It was sure that migrating to a completely different platform should be a complex task – the project extended over three years. However, it was like blessing in disguise: during this period, the world has seen the cloud computing that seemed an ideal tool for solving both the scalability problem and putting aside one’s own whole infrastructure. Besides, the PaaS model allowed to remove most of the effort in terms of administering the solution and to control the application as a self-contained entity, to the extent of complete automation, and thus, Windows Azure had in fact no alternatives.

As a result, the second version of HostTracker, commercial operation of which started in May 2012, is already functioning under Windows Azure. Its central ingredient is realized as Web Role and associated with SQL Azure Database – it provides external portal, analytics and report generation, control of monitoring applications. The latter are ensured with instances of Worker Role, which also use SQL Azure Database to store their data and to provide the service scalability depending on the network loading. Agents are functioning as they did before, with the viability of their transfer to Windows Azure being considered.
Now, HostTracker uses HTTP/HTTPS and ICMP protocols to monitor specific ports, including various methods (HEAD/POST/GET), and etc.
 

HostTracker instant check



Alarm reporting is available via email, SMS and instant messages. The customer can receive reports with statistics about resources being controlled and their performances. You can spend only 6 minutes to make monitoring settings for five sites, while the average response time in case of failure is limited by a couple of minutes, and it takes 1-3 minutes more to inform the customer about the problem. Using this service, anyone can check any site, including access from various regions.

 As a result, if on the one side the transfer to the .NET platform itself gave us the potential to modernize HostTracker, to optimize the application architecture and realize new internal functions, then, on the other side, the migration to the cloud allowed to refuse from less important, though time consuming activities such as administering the solution, and, first of all, to reach necessary performance indicators. Microsoft, for all basic Windows Azure services, declares 99,9% accessibility and guarantees monthly refunds, should this indicator be lower. This creates a firm ground for operating such services like HostTracker, as the accessibility is the most critical parameter for these applications. Using the cloud infrastructure also provides a better protection for the service: unauthorized access to the application and many types of attacks are effectively excluded, while the data safety is ensured by triple reservation.

HostTracker received another advantage from abandoning its own infrastructure. The service’s performance characteristics are also rather critical, for they directly affect the failure reporting system operation. In this respect, Windows Azure is virtually a drainless source of computing power. This means that by timely starting additional monitoring instances you can support HostTracker functioning parameters on the necessary level. Moreover, the cloud environment is exactly what you need in order to make this process almost fully automatic, excluding further need for direct control.

більше
Host Tracker: оповещение о падении сайта только по делу (Русский)

Ни один человек не способен круглосуточно осуществлять мониторинг работоспособности сайта. Более того, ресурс может быть недоступным в другом регионе, и это руководитель никак не отследит.
И именно для решения этих задач предназначен сервис ХостТрекер, который мониторит доступность сайта. Он фиксирует «падение» сайта, анализирует проблему и отправляет тревожный сигнал администратору или руководству ресурса...

Разумеется, одной из первоочередных задач для любого руководителя сайта является обеспечение бесперебойной работы ресурса. Однако периодические «падения» сайта неизбежны, и главное тут — вовремя отследить и решить проблему.
Очевидно, что ни один человек не способен круглосуточно осуществлять мониторинг работоспособности сайта. Более того, ресурс может быть недоступным в другом регионе, и это руководитель никак не отследит.
И именно для решения этих задач предназначен сервис ХостТрекер, который мониторит доступность сайта. Он фиксирует «падение» сайта, анализирует проблему и отправляет тревожный сигнал администратору или руководству ресурса.
При этом очевидно, что ложная тревога никому не нужна, и принцип «лучше перебдеть, чем недобдеть» — не лучшая стратегия в данном случае. Поэтому в работе сервиса необходима исключительная точность и адекватность в оценке проблем.

Таким образом, перед ХостТрекером стоит ряд важнейших задач: отследить возникновение проблемы и вовремя уведомить об этом клиента, при этом исключив ложную тревогу, и рассчитать uptime, исходя из наилучшего и наихудшего варианта развития событий.

Каким же образом регистрируется непосредственно «падение» ресурса?

Как только клиент добавляет свой сайт, с заданным интервалом в диапазоне от минуты до часа система посылает ему запрос. При этом такая проверка совершается с независимых серверов, разнесенных по всему миру, для осуществления географически распределенного мониторинга. На данный момент таких серверов более пятидесяти. Случайным образом выбирается конкретный агент.
 

моментальная проверка


В случае возврата ошибки при проверке, перепроверка запускается для еще пяти-семи независимых агентов. Если в большинстве случаев наличие проблемы подтверждается, ресурс считается «упавшим». Если же остальные агенты не зафиксировали неполадок, считается, что локальная проблема возникла на конкретном агенте.
В случае необходимости определить, «поднялся» ли сайт, действует тот же алгоритм. Он практически исключает возможность ложной тревоги, таким образом, оберегая покой клиентов сервиса. Недоступность ресурса устанавливается лишь после многократных проверок с определенным интервалом.

Конечно, гарантировать на сто процентов, в каком именно состоянии сайт был между проверками, невозможно. Однако, все же с наибольшей вероятностью в промежутке между выдававшими ошибку проверками сайт «лежит». Правда, если после ошибки начинается восстановление, между проверками ресурс может и работать. Собственно, данный сценарий ложится в основу расчета оптимистичного uptime. Вариант же «лежания» сайта между проверками становится отправной точкой для расчета пессимистичного сценария.
Оптимистичный вариант берется в расчет при статистических исследованиях, а вот при уведомлении клиентов данные указываются по пессимистичному.
Таким образом, благодаря расчету всех вариантов и тщательному всестороннему мониторингу, клиент получает своевременные уведомления только в случае настоящих проблем и может получить полную и достоверную картину происходящего.

більше
Поширити:
Send to Twitter Send to Facebook Send to LinkedIn
Блоги:
HostTracker blog HostTracker page on Facebook
Безготівковий
розрахунок