Что такое uptime и observability — простыми словами

Uptime-мониторинг отвечает на вопрос «сайт работает?». Observability — на «почему сайт ведёт себя именно так?». Первое нужно всем, у кого есть сайт. Второе — командам с десятками сервисов и отдельным инженером по надёжности. Разбираем разницу простыми словами.

Что такое uptime?

Uptime — это процент времени, в течение которого сайт доступен пользователям. Если сайт работал 30 дней подряд без единого сбоя, его uptime за этот период — 100%. Если за месяц был час недоступности, uptime получается примерно 99,86%. Метрика бинарная: в каждый конкретный момент сайт либо отвечает корректно, либо не отвечает.

Uptime-мониторинг устроен снаружи. Специальный сервис каждые 30 секунд или каждую минуту открывает ваш адрес и проверяет результат:

• HTTP-код ответа: 200 — хорошо, 500 или 502 — плохо.
• Время отклика: миллисекунды до первого байта.
• Содержимое: соответствует ли ожидаемому (например, на странице есть слово «Главная»).
• SSL-сертификат: действителен ли, до какого числа.
• Доступность из разных географических точек.

На основе этих данных сервис считает процент uptime, рисует график доступности и при сбое присылает алерт — в Telegram, на email, через webhook в ваш Slack. Это короткий и понятный ответ на главный вопрос владельца сайта: «всё ли в порядке прямо сейчас?».

Типичный пример: интернет-магазин подключает облачный мониторинг Tracker.ru, настраивает проверки из нескольких регионов — Москва, Франкфурт, Алматы — и получает алерт в Telegram через 30 секунд после того, как сайт перестанет отвечать. Дальше владелец открывает уведомление, видит, в каком регионе проблема, и идёт разбираться.

Что такое observability?

Observability (буквально — «наблюдаемость») — это способность понять, что и почему происходит внутри системы, по её внешнему поведению. Термин пришёл из теории управления: можно ли по выходным сигналам объекта восстановить его внутреннее состояние? В IT слово прижилось примерно с 2018 года и описывает класс инструментов, которые собирают данные изнутри приложения и помогают разобраться в причинах его поведения.

В observability принято выделять три источника данных — их называют «тремя столпами» или three pillars:

• Логи (logs) — текстовые записи о том, что произошло. «Пользователь 42 нажал кнопку «Купить», получил ошибку платежа от Stripe».
• Метрики (metrics) — числовые показатели во времени. «Запросов в секунду на /checkout: 120 → 80 → 30 за последние 5 минут».
• Трейсы (traces) — путь одного запроса через все сервисы. «Запрос /checkout зашёл в API gateway, оттуда в auth-service за 12 мс, дальше в order-service за 340 мс, оттуда в платёжный шлюз — и завис на 8 секунд, пока не отвалился по таймауту».

В отличие от uptime-мониторинга, observability ставится изнутри приложения. В код добавляется инструментирование: библиотеки логирования, замеры метрик через Prometheus или OpenTelemetry, передача trace-id через все сервисы. Эти данные собираются в центральное хранилище — Datadog, New Relic, Grafana Cloud, Better Stack, Honeycomb, Loki — и там же ищутся, фильтруются и строятся дашборды.

Observability отвечает не на вопрос «работает ли», а на вопрос «почему именно так работает». Например: «оплата проходит у 99,2% пользователей, но в Казахстане — у 84%, причём только при оплате картами одного конкретного банка через одного конкретного провайдера, и только в часы пик». Такой ответ невозможно получить uptime-мониторингом — в нём нет инструментов для подобного среза.

Чем отличаются uptime-мониторинг и observability?

Если объяснять одной фразой: uptime-мониторинг отвечает «работает или не работает», observability — «почему ведёт себя именно так».

Если разложить по практическим различиям, получится примерно такая таблица.

Это не «один лучше другого» — это разные инструменты для разных задач. Uptime-мониторинг хорошо отвечает на свой вопрос, observability — на свой. Большинству сайтов нужно только первое. Распределённым системам с десятками микросервисов нужно и то, и другое: uptime-мониторинг для внешнего контроля доступности и observability для внутренней диагностики.

Что выбрать для small business?

Для малого и среднего бизнеса в подавляющем большинстве случаев достаточно uptime-мониторинга. Это касается сайтов-визиток, лендингов, корпоративных порталов, блогов, интернет-магазинов средней руки и небольших SaaS.

Признаки, что вам хватит uptime-мониторинга:

• Один сайт или несколько сайтов на привычном стеке (PHP, Python, Node.js — без микросервисов).
• Команды разработки нет или она маленькая (1–5 человек).
• Бюджет на мониторинг — сотни рублей в месяц, не десятки тысяч.
• Главные вопросы: «не упал ли сайт?», «не истекает ли SSL?», «не стал ли сайт грузиться медленнее?».
• Уведомления нужно получать в Telegram, на email, в свой чат.

Признаки, что вам действительно нужна полноценная observability:

• Распределённая система из десятков сервисов.
• В команде есть SRE или DevOps-инженер с отдельной зоной ответственности за надёжность.
• Бизнес-логика проходит через несколько внутренних API, очередей сообщений, баз данных.
• Регулярные инциденты вида «оплата у 0,1% пользователей не проходит, но мы не понимаем, почему».
• Бюджет на наблюдаемость — от тысяч рублей в месяц до десятков и сотен тысяч.

Между этими полюсами есть промежуточная категория — стартапы и SaaS среднего размера. Им часто полезен uptime-мониторинг плюс пара точечных наблюдательных инструментов: например, отдельный сервис ошибок (Sentry), отдельная агрегация логов и uptime отдельно. Полностью платить за единый observability-стек уровня Datadog или observability-стек BetterStack для такой команды обычно дорого и избыточно.

Краткое практическое правило: пока вы можете в голове представить устройство своего проекта целиком, вам хватит uptime-мониторинга. Как только вы перестали умещать схему сервисов в голове и без логов уже не понимаете, что произошло — пора смотреть в сторону observability.

Использует ли Tracker.ru observability?

Tracker.ru — это сервис uptime-мониторинга, и это его главный фокус. При этом у него есть несколько возможностей, которые выходят за рамки чистого «работает / не работает» и приближают его к лёгкой форме наблюдательности — пользователь видит больше, чем просто бинарный статус.

Что Tracker.ru умеет сверх классического uptime:

• Проверки из нескольких регионов. Сайт опрашивается одновременно из Москвы, Франкфурта и Алматы. Если упал только один регион — это, скорее всего, локальная сетевая проблема, а не падение сайта. Подробнее о мульти-региональных проверках.
• Скриншоты сайта после восстановления. Когда сайт возвращается онлайн после инцидента, Tracker.ru делает серию скриншотов — через 1, 6, 12 и 24 часа — и складывает их в историю. Это помогает поймать визуальные регрессии: вместо нормальной страницы стала отдаваться заглушка от хостера или белый экран от ошибки в JavaScript.
• Apdex и время отклика. Кроме факта доступности, сервис считает Apdex — числовую оценку, насколько комфортно пользователю работать с сайтом по скорости отклика.
• Мониторинг SSL-сертификатов. Алерт за 30, 14 и 7 дней до истечения сертификата — отдельная задача, которую часто забывают, пока сайт не сломается с ошибкой «небезопасное соединение».
• Heartbeat-мониторинг для cron-задач. Скрипт или планировщик пингует Tracker.ru, и если пинг не пришёл вовремя — приходит алерт. Это уже про внутренние процессы, а не про публичный URL.
• История проверок и инцидентов. Можно посмотреть, как менялась доступность за месяц или год, какие были инциденты, сколько они длились.

Это ощутимо больше, чем «дашборд с зелёной точкой», но всё ещё не полноценный observability-стек уровня Datadog или Grafana Cloud. У Tracker.ru нет приёма логов из вашего приложения, нет распределённого трейсинга запросов через микросервисы, нет агента, который ставится на сервер и снимает метрики ОС. Это сознательное решение: для большинства сайтов это и не нужно, а кому нужно — у тех есть свой выбор инструментов.

Если вкратце: Tracker.ru — это «расширенный uptime», достаточный для лендингов, корпоративных сайтов, интернет-магазинов и небольших SaaS. Если у вас инфраструктура уровня сотен микросервисов и есть команда SRE — для диагностики вам понадобится отдельный observability-стек. А Tracker.ru при этом всё равно может стоять рядом и отвечать на свой простой вопрос: доступен ли наш публичный сайт прямо сейчас и из всех ли стран, где живут пользователи.

Если хочется попробовать на своих сайтах — заведите бесплатный аккаунт, добавьте URL и подключите Telegram-уведомления. Тарифы и лимиты — на странице тарифы Tracker.ru.

См. также

• Сравнение Tracker.ru с observability-стеком BetterStack — что входит в полноценную платформу с логами и on-call, и кому это реально нужно.
• Мониторинг из нескольких регионов — как настроить проверки из России, Европы и Казахстана и зачем это бизнесу.
• Heartbeat-мониторинг для cron-задач — что делать, когда нужно следить не за публичным URL, а за фоновыми процессами.
• Тарифы Tracker.ru — сколько стоит uptime-мониторинг для одного сайта и для парка из десятков.