В 2013 году Amazon потерял $66,240 в секунду во время 30-минутного outage. В 2024 году CrowdStrike update обрушил 8.5 миллионов Windows-машин по всему миру. Между этими инцидентами — тысячи менее публичных историй: SaaS-сервис, который потерял enterprise-клиента из-за 4-часового простоя; стартап, чей payment API молча ломался каждую ночь; e-commerce, который узнавал о downtime из жалоб в Twitter.
Uptime monitoring — система раннего предупреждения. Она не предотвращает downtime (это задача reliability engineering), но она сокращает время между "сервис упал" и "команда узнала" с часов до секунд. А это время — самое дорогое: пока вы не знаете о проблеме, вы не можете её чинить.
Что такое uptime monitoring
Uptime monitoring — это непрерывная автоматическая проверка доступности вашего сервиса из внешних точек. Ключевое слово — внешних. Внутренний мониторинг (Prometheus scraping metrics из подов, Grafana dashboards) полезен, но он работает внутри вашей инфраструктуры. Если упадёт сеть между вашим датацентром и пользователями — внутренний мониторинг покажет "всё зелёное", а пользователи увидят таймаут.
Внешний мониторинг эмулирует пользователя: отправляет HTTP-запрос из Франкфурта, Парижа, Хельсинки — из тех же точек, откуда заходят реальные пользователи. Если запрос не прошёл — вы знаете, что пользователи тоже не могут зайти.
Как работает проверка
Каждые N секунд (30, 60, 300 — зависит от настроек) агент мониторинга выполняет цикл:
1. DNS Resolution. Резолвит доменное имя в IP-адрес. Если DNS не отвечает — проверка уже провалена.
2. TCP Connection. Устанавливает TCP-соединение с сервером. Измеряет время connect (TCP handshake).
3. TLS Handshake. Для HTTPS — устанавливает шифрованное соединение. Проверяет валидность сертификата.
4. HTTP Request. Отправляет запрос (GET, POST, HEAD). Начинает таймер TTFB.
5. Response. Получает ответ: status code, headers, body. Записывает TTFB и total response time.
6. Validation. Сравнивает результат с ожиданиями: правильный status code? Содержит ли body нужный keyword? Response time в пределах порога?
Результат каждой проверки: UP (всё ок) или DOWN (что-то не так) с причиной: timeout, wrong status code, keyword not found, TLS error. Результаты от всех агентов агрегируются на control plane, который решает — открывать инцидент или нет.
Типы мониторинга
"Uptime monitoring" — зонтичный термин. Под ним — десяток типов проверок, каждый для своего сценария. Ни один тип не заменяет остальные; сильная мониторинговая конфигурация комбинирует несколько.
HTTP/HTTPS Monitoring
Самый распространённый тип. Отправляет HTTP-запрос на URL, проверяет ответ. Подходит для веб-сайтов, API, health check endpoints. HTTP-мониторинг — основа, с которой начинают все.
Что можно проверить: status code (200, 201, 204...), response time и TTFB, содержимое ответа (keyword, JSON path), headers (Content-Type, Cache-Control, CORS), размер ответа, redirect chain.
Когда использовать: для любого HTTP/HTTPS endpoint. Главная страница, API health, login page, checkout — всё это HTTP-проверки. Для API monitoring добавляйте JSON path assertions и custom headers (Bearer token, API key).
TCP/Port Monitoring
Проверяет, что порт на сервере открыт и принимает TCP-соединения. Не отправляет HTTP-запросов — просто TCP handshake. Port monitoring используется для сервисов, которые не работают по HTTP: базы данных (PostgreSQL:5432, MySQL:3306), почтовые серверы (SMTP:25/587), кастомные TCP-протоколы (game servers, IoT gateways).
ICMP/Ping Monitoring
Отправляет ICMP echo request (ping). Проверяет, доступен ли хост на сетевом уровне. Ping monitoring — самый низкоуровневый тип: если ping не проходит, хост либо выключен, либо сеть между вами разорвана. Используется для серверов, роутеров, network appliances.
Ограничение: многие cloud-серверы блокируют ICMP. Если ping не проходит, а HTTP работает — проблема в firewall, а не в сервере. Ping дополняет HTTP-мониторинг, но не заменяет его.
DNS Monitoring
Проверяет, что DNS-записи вашего домена верны: A-запись указывает на правильный IP, MX-записи корректны для почты, TXT-записи (SPF, DKIM) на месте. DNS monitoring ловит проблемы, которые HTTP check обнаружит с задержкой — потому что если DNS не резолвит, HTTP-запрос даже не начнётся.
Типичные сценарии: истёкший домен, случайно удалённая A-запись, миграция DNS-провайдера с потерянными записями, DNS hijacking. Подробнее — в полном гайде по DNS monitoring.
SSL/TLS Monitoring
Проверяет валидность SSL/TLS-сертификата: дату истечения, полноту certificate chain, hostname match, версию TLS-протокола. TLS monitoring отправляет алерт за 30 дней до истечения — достаточно времени, чтобы починить auto-renewal, если он сломался.
Expired SSL = полный отказ для пользователей, API-клиентов и мобильных приложений. Это один из немногих типов downtime, который предотвратим на 100% с правильным мониторингом.
Keyword Monitoring
HTTP-проверка + валидация содержимого ответа. Keyword check ищет (или подтверждает отсутствие) определённый текст в ответе. Ловит тихие сбои: сервер вернул 200 OK, но вместо контента — пустая страница, HTML-ошибка nginx, или "Database connection failed" внутри JSON.
Heartbeat / Cron Job Monitoring
Инвертированный мониторинг: не система проверяет ваш сервис, а ваш сервис пингует систему. Heartbeat monitoring (он же "dead man's switch") используется для cron jobs, scheduled tasks, background workers — процессов, которые не имеют HTTP-endpoint для проверки. Если ping не пришёл вовремя — алерт.
Подробная инструкция: Cron Job Monitoring Guide.
Page Speed Monitoring
Загружает страницу в headless-браузере и измеряет Core Web Vitals: LCP (Largest Contentful Paint), FID (First Input Delay), CLS (Cumulative Layout Shift). Это ближе к synthetic monitoring пользовательского опыта, чем к классическому uptime check.
Multi-region мониторинг: почему одной точки недостаточно
Мониторинг из одной точки — как камера наблюдения с одного ракурса. Она видит, что дверь закрыта, но не видит, что окно разбито. Один агент в одном датацентре подвержен локальным сетевым проблемам: BGP routing issues, DNS cache, провайдерский maintenance. Любая из этих проблем выглядит как "ваш сайт упал", хотя он работает для 99.99% пользователей.
Multi-region мониторинг решает это фундаментально:
Отсеивание false positives. Один агент видит DOWN, остальные 10 видят UP? Локальная сетевая проблема — не ваш сервер. Без multi-region вы бы получили ложный алерт в 3 часа ночи.
Реальная картина latency. Response time из Франкфурта — 80ms. Из Хельсинки — 200ms. Из Лиссабона — 350ms. Вы видите, где пользователям медленно, и можете оптимизировать CDN или добавить edge сервер.
Обнаружение региональных проблем. CDN edge в одном регионе может кэшировать устаревшие данные или возвращать ошибки, в то время как остальные регионы работают нормально. Single-probe мониторинг этого не увидит — или увидит, или нет, в зависимости от того, в каком регионе стоит probe.
Quorum confirmation: консенсус вместо retry
Классический подход к борьбе с false positives — retry: проверь 3 раза, алертни если все 3 раза DOWN. Проблема: retry увеличивает задержку обнаружения. При интервале 60 секунд и 3 retry — вы узнаёте о проблеме через 3 минуты минимум.
Quorum confirmation — другой подход: вместо повторных проверок из одной точки, спроси все точки одновременно. Если 8 из 11 агентов говорят DOWN — это реальный инцидент, подтверждённый за один цикл (30 секунд), а не за 3 retry (3 минуты). Если 2 из 11 говорят DOWN — у этих двух агентов локальная проблема, результат подавляется.
Результат: false positive rate падает с типичных 5-15% до менее 0.1%, при этом скорость обнаружения не страдает. Подробнее о механизме — в статье о false positive алертах.
Incident detection: от "проверка упала" до "инцидент открыт"
Не каждая проваленная проверка — инцидент. Одиночный таймаут из одного региона — транзиентная ошибка. Три последовательных провала из восьми регионов — паттерн, требующий внимания. Incident detection — алгоритм, который отличает шум от сигнала.
Двухуровневая система: soft и hard incidents
Soft incident. Одна или несколько проверок вернули DOWN в одном цикле. Система фиксирует: "что-то произошло" — и начинает наблюдать внимательнее. Алерт не отправляется. Если в следующем цикле всё вернулось в норму — soft incident закрывается тихо. Это был jitter.
Hard incident. N регионов подтверждают DOWN в течение M последовательных циклов. По умолчанию: 3 региона, 3 цикла. Это подтверждённая проблема. Алерт отправляется в Slack, Telegram, email, webhook — куда настроено.
Recovery. Для закрытия инцидента требуется R успешных циклов подряд (по умолчанию: 2). Это hysteresis — защита от flapping: сервис дёргается между UP и DOWN, и вы получаете 10 "resolved" и 10 "opened" за 5 минут. Recovery cycles предотвращают это.
Все параметры (регионы, циклы, recovery) настраиваются для каждого target отдельно через AlertPolicy. Критичный payment API: hard_cycles=1, мгновенный алерт. Staging-среда: hard_cycles=5, алерт только при устойчивой проблеме.
Batch anomaly detection
Отдельный слой фильтрации. Если один агент теряет сеть полностью, все его проверки возвращают DOWN — 50, 100, 200 targets одновременно. Без batch anomaly detection вы получите 200 алертов. С ним — система обнаружит: "Agent-X сообщает DOWN для 80% своих targets, другие агенты сообщают UP → проблема в Agent-X, а не в targets". Все результаты Agent-X подавляются до восстановления.
Response time: не только "работает", но "насколько быстро"
Availability monitoring отвечает "работает или нет". Response time monitoring отвечает "насколько хорошо работает". Оба параметра критичны: сайт с uptime 99.99%, но response time 5 секунд — технически доступен, но функционально бесполезен.
Ключевые метрики response time:
TTFB (Time to First Byte). Время от отправки запроса до первого байта ответа. Изолирует серверную производительность от скорости передачи. TTFB > 500ms — сигнал исследовать бэкенд.
Total Response Time. Полное время от запроса до получения последнего байта. Для маленьких JSON-ответов ≈ TTFB. Для тяжёлых страниц может значительно отличаться.
Percentiles (p50, p95, p99). Среднее время ответа обманчиво — оно маскирует хвост распределения. Мониторьте p95 и p99: они показывают опыт 5% и 1% самых "несчастливых" пользователей.
Alerting: как не утонуть в уведомлениях
Мониторинг без alerting — бесполезный дашборд, на который никто не смотрит. Alerting без правильных порогов — генератор шума, который все игнорируют. Цель — алерты, которым доверяют: каждое уведомление = реальная проблема, требующая действия.
Каналы оповещений
Не все каналы одинаково надёжны. Email — задержка доставки. Slack — тонет в потоке сообщений. SMS — дорого, но надёжно. Оптимальная стратегия: primary канал (Slack/Telegram) для оперативной команды + fallback (email/SMS) для критичных инцидентов, которые не были acknowledged за 15 минут.
Эскалация
Если on-call инженер не отреагировал за N минут — уведомление должно эскалироваться: следующему в ротации, тимлиду, CTO. Без эскалации критичный инцидент может висеть часами, потому что единственный получатель алерта спит с телефоном на беззвучном.
Mute и maintenance windows
Перед плановым deployment или maintenance — замьютьте target. Это не маскировка проблем, это гигиена: деплой вызовет кратковременный downtime (перезапуск контейнеров), и алерт в этот момент — шум, а не сигнал.
SLA, SLO, SLI: связь с мониторингом
Мониторинг — это механизм сбора данных для SLI (Service Level Indicators). SLI — метрика (availability 99.95%, p95 latency 200ms). SLO — внутренняя цель (мы стремимся к 99.95%). SLA — контракт с клиентом (мы гарантируем 99.9%, иначе компенсация).
Без мониторинга у вас нет SLI. Без SLI нет SLO. Без SLO нет SLA. Мониторинг — фундамент всей пирамиды reliability.
Uptime calculator поможет перевести процент uptime в конкретные минуты downtime: 99.9% = 43.8 минут простоя в месяц. 99.95% = 21.9 минут. 99.99% = 4.38 минут.
Status pages: коммуникация с пользователями
Мониторинг обнаруживает проблему. Status page сообщает о ней пользователям. Это два звена одной цепи: инцидент автоматически создаётся при обнаружении проблемы, status page обновляется, пользователи видят текущий статус.
Хорошая status page: компоненты по пользовательским сценариям, отдельная инфраструктура (доступна когда основной сервис лежит), подписка на обновления, история инцидентов за 90 дней. Подробнее: Status Page Best Practices и 15 лучших примеров.
Стоимость downtime: зачем всё это
Мониторинг — инвестиция. Чтобы обосновать её, нужно знать стоимость downtime. Для SMB: ~$427/минута (Gartner). Для mid-market SaaS: ~$5,600/минута (ITIC). Для enterprise e-commerce: $11,000+/минута.
Но прямые потери — только часть. Скрытые расходы: инженерные часы на диагностику, SLA-кредиты, потеря позиций в Google (поисковик понижает ненадёжные сайты), churn клиентов, которые потеряли доверие. Реальная стоимость часового outage — в 1.5-2x больше прямых потерь.
Мониторинг не предотвращает downtime. Но он сокращает MTTR (Mean Time to Resolution). Разница между обнаружением через 30 секунд и через 2 часа — разница между 5-минутным инцидентом и 2.5-часовым.
Настройка: пошаговый чеклист
Минимальная конфигурация для production-сервиса, которая покрывает 95% потребностей:
1. HTTP-мониторинг основных endpoints. Главная страница, API health (/health/ready), login, ключевой user flow (checkout, dashboard). Интервал: 1 минута. Регионы: 3+. Keyword check на каждый — чтобы ловить тихие сбои (200 OK с пустым телом).
2. DNS-мониторинг. Проверка A-записи основного домена. Проверка MX-записей, если email критичен. Интервал: 5 минут. Ловит проблемы на уровне DNS до HTTP-failures.
3. SSL-мониторинг. TLS-проверка для каждого HTTPS-домена. Порог алерта: 30 дней до истечения. Занимает 30 секунд на настройку, предотвращает один из самых обидных типов downtime.
4. Heartbeat для cron jobs. Бэкапы, scheduled sync, cleanup tasks — добавьте curl на heartbeat URL в конец каждого скрипта. Если задача не отработала — алерт.
5. Alerting. Подключите минимум 2 канала: primary (Slack/Telegram для оперативной реакции) + fallback (email для полноты). Настройте hard incident thresholds: 2-3 цикла для подтверждения.
6. Status page. Создайте публичную status page с компонентами по пользовательским сценариям. Подключите кастомный домен (status.yourdomain.com). Настройте автоматическое обновление при инцидентах.
7. Response time пороги. Для каждого HTTP-монитора установите warning (2x baseline) и critical (5x baseline) thresholds. Рост response time — ранний предвестник outage.
Продвинутые техники
JSON Path Assertions
Для API-endpoints: проверяйте не просто status code, а конкретные поля в JSON-ответе. $.status = "ok", $.data.length > 0, $.version содержит "2.". Ловит сценарии, когда API отвечает 200, но данные неправильные.
Multi-step transactions
Реальное использование сервиса — цепочка запросов. Login → получить token → запросить данные → обновить запись. Мониторинг отдельных endpoints может показать "всё зелёное", но цепочка ломается из-за проблемы между шагами. Multi-step мониторинг проверяет весь flow.
Custom headers и аутентификация
Мониторинг protected endpoints требует авторизации. Создайте dedicated monitoring user с минимальными правами. Используйте long-lived API key или service token (не личные credentials). Добавьте Bearer token или API key в custom headers HTTP-проверки.
Мониторинг из-за CDN
CDN кэширует ответы и может маскировать проблемы origin-сервера. Для полноценного мониторинга: проверяйте и cached version (через CDN) и origin напрямую (по IP или через bypass header). Так вы узнаете, если CDN работает, но origin упал — и наоборот.
Типичные ошибки
Мониторинг только homepage. Главная страница часто на CDN и работает при мёртвом бэкенде. Мониторьте API endpoints, login, checkout — всё, что зависит от вашего кода и базы данных.
Один регион мониторинга. Один probe = ложные алерты при сетевых проблемах probe. Минимум 3 региона для quorum.
Только status code, без валидации body. 200 OK + пустое тело = тихий сбой. Добавьте keyword check.
Слишком агрессивные алерты. Алерт на каждый единичный таймаут → alert fatigue за неделю → команда игнорирует все алерты, включая реальные. Используйте hard incident thresholds.
Забытый SSL-мониторинг. "У нас Let's Encrypt с auto-renewal" → auto-renewal ломается тихо → через 60 дней сертификат истекает → полный outage в субботу ночью.
Нет мониторинга cron jobs. Бэкап не работает 3 недели, но вы узнаёте только когда нужно восстановиться. Heartbeat monitoring занимает одну строку curl и спасает от катастрофы.
FAQ
What is uptime monitoring?
Uptime monitoring is the practice of continuously checking whether your website, API, or online service is accessible to users. External monitoring agents send requests to your endpoints at regular intervals (every 30 seconds to 5 minutes) from multiple geographic locations. If the endpoint doesn't respond correctly, the system creates an incident and sends alerts via email, Slack, Telegram, or other channels.
How does uptime monitoring work?
A monitoring service runs agents in multiple locations (datacenters, cloud regions). Each agent periodically sends an HTTP request (or TCP, ICMP, DNS query) to your endpoint. The agent records the response: status code, response time, TLS validity, response body. Results are sent to a central control plane that evaluates them against your thresholds. If multiple agents confirm a failure, an incident is created and you get notified.
What's the difference between uptime monitoring and APM?
Uptime monitoring checks your service from outside — like a user would. It answers 'is it up and fast?' APM (Application Performance Monitoring) instruments your code from inside — it answers 'which function is slow and why?' You need both: uptime monitoring for instant outage detection, APM for root cause analysis.
How often should I check my website?
For production services: every 30-60 seconds. For staging or internal tools: every 5 minutes. The right frequency depends on your SLA — if you promise 99.9% uptime, a 5-minute check interval means you could miss up to 5 minutes of downtime. At 30-second intervals, you detect issues within 1 minute.
Is uptime monitoring necessary if I use a cloud provider?
Yes. Cloud providers (AWS, GCP, Azure) guarantee infrastructure uptime, not your application uptime. Your code can crash, your database can fill up, your DNS can misconfigure — all while the cloud VM runs perfectly. Uptime monitoring checks your actual service, not the infrastructure underneath it.
What is a good uptime percentage?
99.9% (three nines) is the standard for most production SaaS services — that's about 8.7 hours of allowed downtime per year. 99.95% is common for payment systems and auth services. 99.99% (four nines) is enterprise-grade and requires significant infrastructure investment. Anything below 99.5% usually signals reliability problems.
How many monitoring regions do I need?
Minimum 3 for basic quorum (2-of-3 agreement prevents false positives). 5-7 for solid coverage of a single continent. 10+ for global services or when you need high-confidence incident detection. More regions = fewer false alerts and faster, more accurate detection.
Can uptime monitoring detect slow performance, not just outages?
Yes. Modern uptime monitors track response time (TTFB and total) alongside availability. You can set thresholds: alert if response time exceeds 500ms for 3 consecutive checks. This catches performance degradation before it becomes a full outage — the 'site is slow' stage before the 'site is down' stage.