Сървърът ми падна и открих го пет часа по-късно случайно

Известието не дойде от услуга за мониторинг. Не дойде от автоматизиран алърт или webhook, който се изпраща в Slack. Дойде от най-примитивната система за мониторинг, която съществува: отваряне на браузър, въвеждане на URL адреса и гледане на празна страница. Беше петък. Сайтът е бил събран от около девет часа сутринта и вече беше далеч след два часа следобед. Пет часа абсолютна тишина от уеб приложение, което обикновено служеше хиляди заявки на ден. Пет часа, през които всеки посетител видя страница с грешка, всеки API повик върна нищо и всяка планирана задача се провали тихо на фона. Сървърът не падна драматично. Нямаше kernel panic, нямаше дефект на диска, нямаше вектор на атака, който остави криминалистически доказателства. VPS-ът на Contabo просто спря да отговаря на HTTP заявки, седейки там с валиден IP адрес и пулс на мрежевия слой, но отказвайки да служи какъвто и да е уеб трафик.

Откритието се случи защото беше напълно несвързана задача. Имаше необходимост да се провери конкретен макет на страница за промяна на дизайна, така че браузърът отиде на URL адреса и върна нищо. Първият инстинкт беше да обвини местната мрежа. Обновена страница. Все още нищо. Опитах различен браузър. Все още нищо. Отворил терминала и ping на сървъра. Пакетите се върнаха нормално. SSH връзка? Работеща. Статус на Apache? Мъртвец. Процесът на уеб сървъра е разбил някъде по време на ранните сутрешни часове и никога не е рестартиран, защото нямаше супервизор на процеса, конфигуриран да обработи този точен режим на отказ. Поправката отнесе тридесет секунди. Осъзнаването, че това може да се случи отново и вероятно се е случило преди без да го забележи никой, отнесе значително по-дълго време.

Всеки разработчик, който е управлявал производствени услуги на VPS, има версия на тази история. Може би не беше пет часа. Може би беше два, или осем, или цял уикенд. Спецификите варират, но моделът е идентичен. Сървърът падна, никой не забележи и откритието беше случайно. Коренният проблем не е надеждност на сървъра. Сървърите отказват, процесите се разбиват, дисковете се запълват, памет изтичане натрупава. Това е природата на управление на софтуер на физически хардуер. Коренният проблем е отсъствието на мониторинг и по-специално пропастта между знаенето, че сървърът е онлайн и знаенето, че приложението действително работи.

Разликата между мониторинг на наличност и знаенето, че вашият сайт действително работи

Традиционните монитори за наличност правят едно нещо добре. Те изпращат HTTP заявка до URL адрес на редовни интервали и проверяват дали кодът на отговор е 200. Ако кодът е нещо друго или ако заявката време изтече, алърт се активира. Това хвата най-катастрофалните откази: сървърът е напълно недостъпен, домейнът е изтекъл, SSL сертификатът е невалиден. Но пропуска огромна категория проблеми, които са твърдо по-често срещани и по-вредни.

Разгледайте сценарий, в който сървърът връща код 200 статус, но страницата е счупена. Връзката към база данни е неудачна, така че областта със съдържание показва съобщение за грешка вместо очаквания списък на продукти. CSS файлът е неудачен да се зареди, така че страницата се показва като немодерна HTML. Грешка на JavaScript предотвратява инициализирането на главното приложение, оставляйки потребителя гледащ спинер за зареждане, който никога не се разрешава. Джаджа на трета страна инжектира оверлей, който покрива цялото съдържание на страницата. Във всички тези случаи монитор за наличност докладва всичко като здраво, защото е получил отговор с код 200. Сървърът е горе. Сайтът е счупен. Никой не знае.

Тази пропаст между "сървърът отговаря" и "сайтът работи" е където скрийншот мониторинг става съществен. Планираният скрийншот улавя как страницата действително изглежда на редовни интервали. Ако страницата внезапно покажет съобщение за грешка, счупен макет или празен екран, скрийншотът прави това веднага видимо. Комбинирайте планирани скрийншотове с сравнение на пиксели, и системата може автоматично да открие когато страница е променена по неочаквани начини. Няколко пиксела се преместват поради актуализация на съдържание е нормално. Цялата страница се превръща в бяла или показва трейс на грешка не е и алгоритъма за разлики може да прави разлика между двата с конфигурируема чувствителност прагове.

След петчасовата прекъсване, първото нещо, което се настрои, беше монитор за наличност за всяка критична услуга. Но по-интересното добавяне беше планиран скрийншот мониторинг, който улавя действителното визуално състояние на ключови страници всеки петнадесет минути. Монитор за наличност улавя очевидните разбивки. Скрийншот монитор улавя всичко останало: фин откази, които връщат код 200 статус, докато показват счупена страница, скриптове на трета страна, които инжектират неочакваното съдържание, грешки на база данни, които се повтарят само при специфични условия.

Изграждане на тръбопровода за алърти, която трябваше да е съществувала от първия ден

Архитектурата на правилна система за мониторинг не е сложна в теория. Планировщик задейства проверка на определени интервали. Проверката улавя текущото състояние на целевата. Състоянието се сравнява с очакваното базово. Ако сравнението превиши праг, алърт се активира. Предизвикателството не е в архитектурата, а в надеждността на всеки компонент. Система за мониторинг, която сама падне, е по-лоша от отсъствието на мониторинг, защото създава фалшива чувство на сигурност.

Тръбопровода за скрийншот мониторинг работи на етапи. Планировщик разпраща задача за улавяне на конфигурирания интервал, обикновено всеки пет, десет или петнадесет минути в зависимост от критичност на страницата. Задачата за улавяне стартира екземпляр на безглав Chromium, който зарежда страницата, чака за рендериране да е завършено и спасява получения скрийншот. Новия скрийншот се сравнява с предишния улов с помощта на алгоритъм на пиксели разлики, който определя променени области и изчислява общия процент на промяна. Ако промяната превиши конфигурирания праг, известие се разпраща чрез конфигурирани канали: имейл, webhook, Slack или всяка пользовател крайна точка.

Сравнението разлики е където нещата стават наистина интересни от технически гледна точка. Наивен пиксели сравнение би отбелязал всеки скрийншот като променен, защото динамично съдържание като времеви печати, реклами или анимирани елементи. Разлика двигателя отчита това чрез подпора на исключение зони, правоъгълни региони на страница, които са маскирани преди сравнение. Времевия печат в заглавие, ротираща банер реклама, живо чат джаджа в ъгъл: всички те могат да бъдат изключени, така че само смислени промени спусък алърти. Какво остава след исключение е стабилно съдържание област, и всяка промяна там е почти сигурно достойна разследване.

Петчасовата прекъсване щяло да бъде уловено в рамките на минути при този система. Първия планиран скрийншот след сървърът падна щяло да върне или празна образ или грешка страница, всички които щяло да различае драматично от базово. Разлика процент щяло да бъде близо 100%, далеч над всяка разумна праг и алърт щяло да се активира веднага. Пет часа прекъсване щяло да бъде пет минути, и тези пет минути щяло да бъде мониторинг интервал себе си, не време, което е отнесло на човек да случайно натъкне на проблема.

Какво пет часа невидимо прекъсване наистина струва

Преки цена на пет часа прекъсване е лесно да се изчисли, когато цифрите са налични. За сайт, който се занимава хиляди дневни заявки, пет часа представлява значителен резен дневна трафик. Всеки заявка, което върна грешка беше потребител, който не получи какво дойде за. Някои от тези потребители бяха нови посетители, които никога не щяло да се върнат. Някои бяха съществуващи потребители, които щяло да загубят малко доверие. Някои бяха API потребители, чиито собствени приложения е неудачна поради зависимост. Преки приходи влияние зависи от природата на сайта, но дори за малък SaaS приложение, пет часа прекъсване по време на работно време може лесно да представлява стотици долари в загубени преобразувания.

Скритото цена е трудно да се количествено но твърдо по-голямо. Търсещи машини, които раздраскаха сайта по време на тези пет часа получи грешка отговори, и докато кратко прекъсване е общо толерирано от Google разпръскане инфраструктура, разширени прекъсване може да доведе до временно деindexing затронутите страниците. Имейл кампании, които са работили по време на прекъсване диск трафик към мъртвец крайна точка, без отпадане цяла кампания разход. Планирани задачи, които зависят на уеб приложение, неща като webhook доставки, доклад генериране и партида обработка, всички неудачна мълчаливо и трябваше да се определи и повторни ръчно след сървър беше възстановена.

Най-коварен цена е репутационна един. Потребители, които се сблъсква събор сайта обикновено не типично изпращане имейл казване "вашия сайт е събрал." Те просто отиват и може или не може да се върнат. Има никакви обратна връзка механизъм за прекъсване поради обратна връзка механизъм себе си е събрал. Петчасовия прозорец беше дълъг достатъчно, че някои потребители почти сигурно опита сайта, намери го счупена, и преместена на конкурент без никога генериране един данни точка, което щяло да посочи какво се случи. Те са просто отишли, и има никакви начин да знам колко много или кой те бяха.

От реактивна към проактивна и никога не открива по случай отново

Урок от това петък следобед не беше, че сървърите срив. Което беше вече известни. Урок беше, че всеки минута между отказ и си открито е минута на съсредоточен вред и един единствен начин да минимизира това прозорец е да се автоматизира откритието. Човек мониторинг прави не мащаб. Проверка сайта ръчно един път ден означава средния откритие време за прекъсване е дванадесет часа. Проверка го един път час доведе до тридесет минути, но никой човек може реалистично проверка всеки страница на всеки приложение един път час около часовника.

Комбинация на мониторинг за наличност и визуален скрийншот мониторинг покрива и слоеве на проблема. Мониторинг за наличност улавя сървър отива полностью в интернет. Скрийншот мониторинг улавя приложение счупена докато сървър остава горе. Заедно щяло да намалее откритието прозорец от "едва ли някой случайно забележи" на мониторинг интервал себе си, които може да бъде като кратко един минута за критични услуги. Алърт активира, известие пристигнува и поправка начина в рамките на минути вместо часа.

Сървърът е отишъл събор два пъти повече от този оригинален инцидент. И двата пъти алърт пристигнува в рамките на три минути. И двата пъти поправка беше приложена преди всяка значителна трафик беше загубена. Мониторинг инфраструктура плащане за себе си с един първи инцидент това уловена и всичко след, че е бил чист нагоре. Епохата на откритие за прекъсване по случай е над, и оглед обратно, един единствен наистина въпрос е защо отнесе пет часа прекъсване да прави инвестиция очевидна.