Повідомлення електронної пошти за три секунди після відключення сайту та більше ніколи за п'ять годин простоїв

До і після кожної історії моніторингу є межа, яка завжди одна й та ж: відключення, яке тривало занадто довго, тому що ніхто не стежив. До моніторингу проблеми з серверами виявляються випадково. Колега згадує, що сайт здається повільним. Клієнт надсилає розлючену електронну пошту. Розробник намагається розгорнути оновлення та виявляє, що сервер недоступний протягом годин. Шаблон послідовно повторюється в організаціях будь-якого розміру. Після моніторингу та сама проблема з сервером створює принципово інший досвід. Сервер відключається. За три секунди приходить електронна пошта. Хтось розслідує протягом хвилини. Виправлення розгортається до того, як більшість користувачів навіть помітять, що щось не так. Різниця між цими двома сценаріями - не щастя чи рівні персоналу. Це наявність або відсутність автоматизованої системи, яка постійно стежить і говорить в момент, коли щось йде не так.

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

Те, що робить uptime.yeb.to, просто за концепцією та ретельне у виконанні. Кожна контрольована кінцева точка перевіряється з регулярними інтервалами на чотирьох різних вимірах: базова досяжність мережі через ping, завершення повного запиту HTTPS, дійсність сертифіката SSL та часова шкала закінчення терміну дії, а також вимірювання часу відповіді. Кожен вимір ловить іншу категорію невдач, і разом вони дають комплексну картину того, чи служба не просто в мережі, але насправді здорова і добре функціонує. Сервер, який реагує на ping, але не пройде перевірки HTTPS, має проблему з веб-сервером. Сервер, який проходить усі перевірки, але показує постійне збільшення часу відповіді, наближається до краху. Сервер з дійсним сертифікатом SSL, який закінчується за три дні, ось-ось запустить попередження браузера, які відганяють відвідувачів. Кожен з цих сценаріїв вимагає іншої реакції, і кожен із них невидимий без активного моніторингу.

Що фактично перевіряє монітор і чому кожен рівень важливий

Моніторинг Ping - це найбільш базовий рівень, і також найчастіше неправильно розумівся. Успішна відповідь ping означає, що операційна система на сервері працює, а мережевий шлях між зондом моніторингу та сервером чистий. Це не означає, що веб-сервер працює. Це не означає, що програма функціонує. Це не означає, що користувачі насправді можуть завантажити сторінку. Ping - це основа, мінімально можливий знак життя, і все інше будується поверх нього. Коли перевірка ping не вдається, проблема серйозна: або сервер повністю відключений, або існує фундаментальна проблема з мережею, яка запобігає будь-якому трафіку на машину. Це відключення, які впливають на все, не лише на веб-трафік, але також на SSH доступ, підключення до бази даних, доставку електронної пошти та кожну іншу службу, що працює на цій машині.

Моніторинг HTTPS додає критичний рівень, який ping пропускає. Перевірка HTTPS виконує повний веб-запит, такий же вид запиту, який браузер робить, коли користувач відвідує веб-сайт. Перевірка перевіряє, що веб-сервер приймає з'єднання, що рукостискання SSL успішно завершується, що сервер повертає дійсну відповідь HTTP, і що весь процес завершується розумним часовим рамкам. Це ловить широку категорію проблем, які ping не може виявити: аварійні процеси веб-сервера, неправильно налаштовані сертифікати SSL, помилки програми, які повертають коди стану HTTP 500, та деградація продуктивності, яка робить сайт практично непридатним, хоча технічно він "онлайн". Розрізнення між сервером, який досяжний, та веб-сайтом, який придатний для використання, - це точно прогалина, яку заповнює моніторинг HTTPS.

Моніторинг сертифіката SSL вирішує проблему, яка вкусила майже кожного оператора веб-сайту принаймні один раз. Сертифікати закінчуються. Безплатні сертифікати від Let's Encrypt тривають 90 днів. Платні сертифікати зазвичай тривають один рік. У обох випадках дата закінчення наступає абсолютною впевненістю, і все ж поновлення сертифіката все ще пропускаються з дивовижною частотою. Причина проста: немає вбудованої системи нагадування. Органи видачі сертифіката не завжди надсилають повідомлення про поновлення. Скрипти автоматичного поновлення іноді виходять з ладу мовчки. А наслідки закінченого сертифіката негайні та жорсткі. Браузери відображають сповіщення про безпеку сторінки. Пошукові системи позначають сайт. Користувачі, які бачать ці попередження, рідко продовжують, і вони часто не повертаються навіть після поновлення сертифіката. Моніторинг дати закінчення сертифіката та сповіщення задовго до крайнього терміну усуває цю цілу категорію запобіжних інцидентів.

Моніторинг часу відповіді - це система раннього попередження для проблем, які ще не стали відключеннями, але рухаються в цьому напрямку. Здоровий веб-сервер реагує за 100 до 300 мілісекунд. Коли час відповіді починає зростати до 500, потім 800, потім 1500 мілісекунд, щось не так. Запити до бази даних можуть працювати повільно через зростаючі розміри таблиці. Пам'ять може споживатися витоком процесу. Дисковий введення-виведення може бути насичене реєстрацією або операціями резервного копіювання. Ці проблеми не спричинюють збої ping або помилки HTTPS, але вони погіршують досвід користувача способами, які безпосередньо впливають на показники відскоку, показники конверсії та рейтинги пошукових систем. Відстежуючи час відповіді протягом днів і тижнів, тенденції стають видимими задовго до того, як вони переростають у повні відключення.

Система сповіщень і чому три секунди змінюють все

Швидкість виявлення - єдина найважливіша змінна для мінімізації впливу простоїв. Математика прямолінійна: загальна шкода дорівнює впливу за хвилину помноженої на кількість хвилин. Скорочення часу виявлення з п'яти годин до трьох секунд не змінює вплив за хвилину, але це драматично скорочує кількість хвилин. Сервер, який відключається і виправляється протягом десяти хвилин, має приблизно 0,002% простоїв на день. Той самий сервер, який відключається і виявляється через п'ять годин, має 0,35% простоїв, навіть якщо виправлення займає ті ж десять хвилин. Протягом місяця ці цифри складаються в різницю між "чотирма дев'ятками" надійності та сором'язливим відсотком безперервної роботи, який ніхто клієнт не хоче бачити на сторінці статусу.

Механізм доставки сповіщень має таке ж значення, як швидкість виявлення. Сповіщення, яке приходить на інформаційну панель, яку ніхто не стежить, еквівалентне відсутності сповіщення взагалі. Електронна пошта залишається найнадійнішим каналом повідомлення для більшості операторів, тому що електронна пошта завжди ввімкнена, завжди доступна з будь-якого пристрою, і не вимагає встановлення ще однієї програми або перевірки ще одного інтерфейсу. Коли uptime.yeb.to виявляє збій, повідомлення електронної пошти миттєво розподіляється з усіма відповідними контекстом: яка кінцева точка не вдалася, який тип перевірки виявив проблему, точна мітка часу та отримана відповідь (або помилка, яка сталася). Це означає, що одержувач може почати діагностику проблеми з самої електронної пошти, не потребуючи спочатку входити на інформаційну панель моніторингу.

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

Щоденні дайджести, тижневі звіти та довгий погляд

Сповіщення в режимі реального часу обробляють терміново проблеми. Дайджести обробляють все інше. Щоденна дайджест електронної пошти приходить кожен ранок з повним підсумком попередніх 24 годин: відсотки безперервної роботи для кожної контрольованої кінцевої точки, середній та пік часу відповіді, будь-які інциденти, які відбулися, та їх тривалість, та статус закінчення сертифіката SSL для всіх кінцевих точок HTTPS. Цю електронну пошту займає приблизно 30 секунд для сканування та надає негайну відповідь на питання "все здорово?" без необхідності входу до будь-якої інформаційної панелі або ручної перевірки будь-якого виду.

Тижневі дайджести збільшуються, розкриваючи тенденції, які невидимі на щоденному рівні. Сервер, який підтримував 100% безперервної роботи кожен день тижня, але показав час відповіді, збільшує на 50 мілісекунд кожного дня, має розвивається проблема, яку щоденна дайджест може не зробити очевидною, але тижневий графік тренду робить невомовним. Аналогічно, сервер, який мав два коротких відключення в різні дні тижня, може розкрити шаблон, коли переглядається разом: обидва відключення сталися о 3 ранку під час автоматизованого вікна резервного копіювання, пропонуючи, що процес резервного копіювання споживає занадто багато ресурсів і потребує оптимізації або перепланування. Ці шаблони з'являються лише коли дані агрегуються протягом часу, і тижневий дайджест розроблений для виявлення саме цих розуміння.

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

Мультирегіональні зонди та сліпі точки однолокаційного моніторингу

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

Однолокаційний моніторинг сліпий до всіх цих сценаріїв. Якщо зонд моніторингу знаходиться в тому ж регіоні центру даних, що й сервер, це буде звітувати 100% безперервної роботи, хоча половина глобальної користувацької бази не може отримати доступ до сайту. Мультирегіональний моніторинг з шести географічно розподілених місць ловить ці розбіжності за дизайном. Коли перевірка не вдається з одного регіону, але проходить з інших, сповіщення включає географічний контекст, який негайно звужує проблему до регіональної маршрутизації або помилки, а не до серверної помилки. Це розрізнення величезно матеріально для діагностики та відповіді: проблема на стороні сервера вимагає перезапуску служб або контакту з постачальником хостингу, хоча проблема з регіональною маршрутизацією вимагає розслідування DNS, конфігурації CDN або проблем на рівні ISP.

Шість місцеположень моніторингу вибираються для охоплення основних центрів населення та трафіку в світі. Це означає, що веб-сайт, що обслуговує клієнтів в Північній Америці, Європі та Азії, має зонди в чи поблизу кожного з цих регіонів, забезпечуючи справжнє покриття, а не ілюзію моніторингу, яку один зонд створює. Для бізнесу, який залежить від глобальної доступності, цей мультирегіональний підхід не є опціональним поліпшенням. Це мінімально можливий конфігурація моніторингу, яка може точно представляти досвід географічно розподіленої користувацької бази. Будівництво uptime.yeb.to з можливістю мультирегіону з самого початку забезпечує, що моніторинг такий же всеохопний, як трафік, який він захищає.