Пасивний Моніторинг
Пасивний Моніторинг Пасивний моніторинг - це спосіб перевірити роботу сайту за допомогою певного програмного забезпечення на стороні сервера.

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

  • CM.Glossary.WebsiteMonitoring
  • CM.Glossary.Downtime
  • CM.Glossary.DistributedMonitoring
  • CM.Glossary.ActiveMonitoring
більше глосарій
Що таке моніторинг і для чого він потрібен? Огляд сервісу ХостТрекеру. Частина 1

Чому існує така необхідність в моніторингу доступності сайтів і як він може стати у нагоді при тестуванні сайтів і серверів? Цей огляд дає вам відповіді на ці всі запитання, а також можливість переконатись, як просте бажання оптимізувати свою роботу, може перетворитися на корисний для інших продукт. Більш того, ви дізнаєтесь як не втратити дух стартаперства в сучасних умовах і завжди бути на одній хвилі зі своїми клієнтами.

Однією з лідерів на ринку серед компаній, які надають послуги моніторингу, є компанія ХостТрекер. Намагаючись йти в ногу зі всіма сучасними тенденціями і трендами, компанія володіє більшістю сучасних інструментів, які вона постійно удосконалює.

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

Вступ та історія стартапу

Кожний програміст хоч раз стикався у своїй роботі з проблемою неочікуваної відмови у роботі нібито ідеально налаштованих серверів (сайтів, баз, програм, мереж тощо). На пошук цієї проблеми може бути витрачено багато часу. Протягом цього періоду, ця проблема може з'являтися постійно, періодично або зникнути зовсім, останнє найгірше – ви не зможете передбачити, коли вона нагадає про себе знову, а якщо саме в момент передачі проекта клієнту? Для того, щоб уникнути таких моментів і з'явився ХостТрекер. Засновник проекту завжди вирізнявся прискіпливістю до деталей і намагався оптимізувати роботу об'єктів основного свого виду діяльності якнайкраще. Звичайно, якщо б на той момент (початок 2000) існували надійні моніторингові сервіси, напевно, ХостТрекер ніколи б і не з'явився. Однак, в той час була така необхідність. Спершу виникла ідея написати простенький скрипт для перевірки своїх сайтів, але в нього виникла та ж проблема, описана раніше. Частенько бувало, що він не працював взагалі або відпрацьовував некоректно. Тому було вирішено оптимізувати цей скрипт, шляхом дублювання і розподілу на декілька машин. Після ряду оптимізацій, прийшли до висновку, що це може бути корисним для інших і так ХостТрекер «вийшов з тіні». Між іншим, з появою великої кількості клієнтів, з'явилася можливість отримувати дохід від цього сервісу. Отже, як ви могли переконатись, цей проект з'явився для вирішення власних проблем, але, в кінці кінців, переріс в сервіс, який, на разі, має на меті допомагати іншим у вирішенні їхніх проблем, аналогічних до тих, які свого часу постали перед нами. Адже, дійсно, не у всіх є час написати маленький скрипт, потім його ще трішки дописати, оптимізувати і т.д.

Моніторинг та його суть

Ця частина огляду дає вам можливість познайомитися з найбільш популярною функцією – регулярною перевіркою для швидкого і своєчасного виявлення існуючих на даний момент проблем із сайтом або іншим мережевим інструментом. Ці перевірки можуть працювати згідно різних протоколів, наприклад, http(s), icmp (пінг), port (перевірка будь-якого порту по протоколу TCP) тощо. Існує два типи моніторингу: внутрішній і зовнішній. Внутрішній – це коли стан сайту оцінюється за рахунок ПЗ, яке розміщено на цьому ж сервері. До цього типу можна віднести, наприклад, Google Analytics або Яндекс.Метрику, в ній вбудований в код сторінки скрипт відсилає інформацію про клієнтів, які зайшли на сайт, і має можливість робити непрямі висновки про працездатність сайту. В свою чергу, зовнішній (юрид. «моніторинг третьою стороною») – полягає в імітації заходження на сайт користувачів з реальних адрес, і робить висновки по, відповідно, реальним відповідям серверів на відправлені запити. Далі мова йтиме про нього.

Інфраструктура або яким чином це все побудовано

Інфраструктуру можна умовно поділити на дві частини: внутрішню і зовнішню. Внутрішня розміщена в хмарі, складається з обчислювальних серверів, баз даних, файлових сховищ тощо, та належить співробітникам ХостТрекера, які здійснюють моніторинг та управління цими системами. Зовнішня – складається з нодів (агентів), які розташовані по всьому світі і здійснюють незалежну перевірку серверів, аналогічно до «таємних покупців» в магазинах. Перевірка здійснюється за рахунок створення стандартних запитів для протокола, який перевіряється. Наприклад, якщо це перевірка веб-сайту, то генеруються стандартні http запити, які нічим не відрізняються від запитів реальних користувачів. Ці сервери є повністю незалежними один від одного і від внутрішньої складової системи. Основне, що вони роблять – отримують від центрального сервера перелік сайтів для перевірки  і віддають результати цих перевірок. Частину цих серверів орендує ХостТрекер, але більшість належить партнерам, які надають їх безкоштовно або зі значною знижкою у відповідь на зворотні посилання або знижки на наші послуги, або просто по дружбі.

Такий розподіл інфраструктури обумовлено алгоритмом роботи сервісу моніторингу.

Алгоритм роботи сервісу

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

Обробка помилок та сповіщення клієнтів про них

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

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

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

більше блог
Благодарим за внимание к нашему сервису!
 
Вхід
Зареєструватись
Ціни та пакети
Наша мережа моніторингу
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 Share on Google+
Блоги:
HostTracker blog HostTracker page on Facebook
Безготівковий
розрахунок