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

Розподілений моніторинг - це один з видів моніторингу веб сайтів, коли перевірка відбувається одразу з кількох географічних точок. Основною метою цього методу є виключення помилок перевіряючих серверів (які завжди можливі) зі статистики сайту і, таким чином, забезпечити більш точний результат. Зазвичай він реалізується через мережу незалежних серверів, які перевіряють сайти по черзі або ж одночасно. Переваги такої перевірки наведено нижче:

Моніторинг створює запити з різних місць - так само, як і справжні клієнти сайту.

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

Можливість порівняння доступу та швидкості завантаження сторінки з різних країн та міст.

Можливість детектування помилок, пов'язаних з мережею або DNS: сайт може відкриватись з Вашого комп'ютера, та чи впевнені Ви, що він працюватиме звідусіль?

  • CM.Glossary.WebsiteMonitoring
  • CM.Glossary.Availability
більше глосарій
Як і що можна перевіряти за допомогою хмарних сервісів? Огляд сервісу ХостТрекер. Частина 2

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

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

 Дійсно вся справа в наборі функцій?

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

Приємні дрібнички

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

Іншою цікавою функцією є перевірка доменів в чорних списках DNSBL. Ці списки є незалежними і формуються кожен за власним алгоритмом.  Вони створені, головним чином, для фільтрації підозрілих речей. Кожен адміністратор може налаштувати свій веб-сервер так, щоб, наприклад, не отримувати листи від серверів, які наявні в певному списку. Це допомагає боротися зі спамом, поширенням шкідливого ПЗ, DDoS-атаками та іншими проблемами. Але всі ці списки мають свої власні алгоритми, і немає гарантії, що ваш сайт не опиниться в цих списках випадково. Більш того, статистика показує, що таке регулярно відбувається навіть з найбільш безневинними сайтами. Наприклад, ніхто не дасть гарантію, що на сусідній з вами IP-адресі не пропишеться місцевий Король спаму, внаслідок чого весь діапазон буде занесений до неблагонадійного. До яких наслідків це все може призвести? Листи від вас перестануть надходити клієнтам, сайт стане гірше відображатися в пошукових системах тощо. Однак ви про це дізнаєтеся не відразу, а тоді, коли зміни стануть критичними, а часом, і незворотними. Тому функція контролю та сповіщення про потрапляння в найбільш популярні чорні списки також є досить актуальною.

Перевірка контенту

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

Підлаштовуючись під різних клієнтів, ця функція стала максимально універсальною: може шукати відразу одне або кілька слів зі списку. Або навпаки - реагувати на появу певних фраз. Також може видавати в помилку рядок, в якому міститься ключове слово. Наприклад, багато хто робить сторінку статусів: «Server 1 OK» тощо. Якщо він раптом стане «Error», тоді в повідомленні прийде «Server 1 Error» - вся діагностика вже проведена, можна відразу приступати до усунення.

А якщо так трапиться, що сервер ПОВИНЕН «прилягти»?

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

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

Звичайно, це все трохи нагадує шахрайство, але запланований простій, тим більше, в неробочий для цільової аудиторії час - цілком може бути виправданий, з нашої точки зору. Проте, під час технічних робіт перевірки так само виконуються і справно записуються в лог, тому можуть бути корисними для вебмайстрів та адміністраторів: лог дозволяє визначити, скільки саме тривало оновлення або перезавантаження; які помилки при цьому видавалися (тобто простежується весь процес: сервер деякий час недоступний, потім повертає помилку додатка, потім іншу помилку і т.д.); що при цьому «гальмувало» найбільше, тощо.

Технічні роботи можна запланувати проводити на регулярній та одноразовій основі. Наприклад, якщо щоночі робиться бекап, або щочетверга - новий реліз. Єдина умова - розклад технічних робіт повинен бути узгоджений та затверджений не пізніше, ніж за 12 годин до найближчої зупинки роботи сайту/сервера. Це зроблено для того, щоб в разі виникнення несподіваних проблем, їх виникнення не пов’язували з проведенням технічних робіт, і статистика ХостТрекеру при цьому залишалася достовірною.

Замість епілогу

Нам часто задають питання - а для чого ви це все робите? Це ж можливо робити і самостійно. Відповідаємо: так, можливо. Особливо, якщо потрібно щось одне. Але справа в тому, що, грубо кажучи, весь бізнес побудований на людській ліні. Більш того, якого ресурсу нам завжди не вистачає? Правильно, часу. Отже, вирішуючи ряд рутинних завдань, ми максимізуємо корисність часу наших клієнтів, по суті, економимо його. Цим ми даруємо додаткові години для вирішення більш суттєвих проблем. Ну і не варто забувати, що не кожен здатний особисто зібрати для себе автомобіль або виростити хліб. Загалом, ми щиро поважаємо людей, які здатні самостійно зробити собі щось хороше в нашій сфері, але практика показує, що далеко не всі готові витрачати на це свій особистий час.

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

більше блог
Благодарим за внимание к нашему сервису!
 
Вхід
Зареєструватись
Ціни та пакети
Наша мережа моніторингу
Home > FAQ
Ключевые советы для поддержания работы сайта (Русский)
  • Оптимизируйте контент сайта. Максимально возможное сжатие изображений, до последнего килобайта, позволяющее сохранить качество изображения.
  • Используйте Minify (приложение PHP5) для CSS и JavaScript для сжатия веб-данных, и размещайте JavaScript в конце документа, если это возможно.
  • Добавьте заголовки «expires» для контента, чтобы избежать постоянной загрузки браузерами одних и тех же файлов при просмотре вашего веб-сайта пользователем.
  • Убедитесь, что ваш веб-сервер обеспечивает предоставление контента в сжатом состоянии - например, mod_deflate для Apache. Очевидно, что это правило не касается таких файлов, как изображения, которые уже сжаты, поэтому убедитесь, что вы задали все настройки правильно.
  • Уменьшите количество HTTP-запросов для попадания на ваш Веб-сайт. Совместите CSS в одном файле. Совместите JavaScripts в одном файле, где это возможно. Включайте эти файлы только в страницы, где они действительно необходимы.
  • Оптимизируйте систему управления контентом. Например, уменьшите количество обращений к базе данных, необходимое для каждого запроса страницы. В Drupal этого можно достичь всего лишь отключив ненужные модули. Кроме того, увеличьте эффективность всех пользовательских кодов, где это только возможно. Изменение на одной десятую долю секунды в алгоритме, который используется тысячи раз, будет заметным.
  • Поддерживайте кэширование часто используемых данных. Используйте Memcache или нечто подобное. Многие пакеты CMS поддерживают эту возможность, но будьте осторожны с динамическими характеристиками.
  • Уравняйте нагрузки веб-сервера.
  • Разделите базы данных для чтения/записи, так что обеспечит иерархическую структуру баз данных, делая их благодаря этому размерно варьируемыми.
  • При возможности, разделите базу данных вертикально или горизонтально (или совместите эти направления, если эта модель подходит для структуры вашей базы данных) для нескольких серверов. Хотя это может подходить не для всех случаев.
Поделиться:
Send to Twitter Send to Facebook Send to LinkedIn Share on Google+
Блоги:
HostTracker blog HostTracker page on Facebook
Безготівковий
розрахунок