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

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

  • 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
Escalations. Typical scenarios (English)

As many people know, HostTracker is a sites efficiency monitoring system. One of its main functions is to notify the user of any problems promptly. The efficiency of the notifications and the acceptable level of “detalization” are important. If you send alerts at each “sneeze”, the person will not find the important information in this flow...

I was woken up by an SMS at three a.m.
My site dropped for three minutes, and it raised back itself.
But I could not go back to sleep.

True-life story

As many people know, HostTracker is a sites efficiency monitoring system. One of its main functions is to notify the user of any problems promptly. The efficiency of the notifications and the acceptable level of “detalization” are important. If you send alerts at each “sneeze”, the person will not find the important information in this flow.

We have provided several mechanisms that will help the right people to get the necessary notifications:

  • Separation of the notifications into several groups according to their criticality;
  • No notifications at short-term failures;
  • Report the problem to the manager promptly;
  • Report a prolonged failure to the administration;
  • Use the free alerts first – email, gtalk, and then the paid ones – SMS or phone call;
  • At the contact level – set the working time when this contact should receive the alerts.

There are three types of notifications:

  • The website has “dropped”;
  • The website is still “down”;
  • The website “rose

The “dropped” and “rose” are clear. The notifications “site is still down” are sent at each test fail, but only at the confirmed drops. The fails confirmation algorithm was described in the article “False alerts exclusion”

For each site-contact pair you may enable or disable the appropriate notification type. The setting can be located in the contact properties as well as in the general “matrix” at the “Notifications subscribtion” page.

Escalation and the notifications detalization level.

Suppose, two people are responsible for the site:

  • Administrator
  • Manager

Let's try to implement the following scenario:

  • In the event of a “drop” we want to send an email message to the administrator immediately;
  • If the site does not rise within 15 minutes, we send an SMS to the administrator;
  • If the site is “down” for more than an hour, then we send an SMS to the manager.

Adding the contacts for the users. While adding, draw attention to the “Notification Delay” window.

We appear to have three contacts with the following delays:

  • Administrator (email) – no delay;
  • Administrator (SMS) – 15 minutes delay;
  • Manager (SMS) – 1 hour delay.

According to this configuration the administrator will get all the failures notifications to the email, but SMS notifications will be sent only if the site is “down” for more then 15 minutes. The manager will receive only SMS about major failures lasting more than an hour. Setting up the contact working schedule

Suppose that one administrator can not cope, and we hired one more administrator. The first one works during the first half of the week, the second one works during the second half. Accordingly the notifications should be sent to the administrator “on duty” To set this scenario the window “Set the contact working hours” is used in the contact settings.

In this case the first administrator will receive the SMS notifications from Monday to Thursday inclusive. Additionally, you may divide the notification for different employees according to the time of day, for example appointing day and night administrators.

Conclusions: with the help of relatively simple mechanisms we may cover most notifications fine-tune user scenarios.

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