Сначала перечислите сбои, о которых нужно узнать раньше пользователей: сайт недоступен, база не принимает соединения, диск заполняется, очередь задач растет или копирование не завершается. Для каждого события назначьте проверку, условие тревоги и ответственного. Значение «CPU выше 80%» без периода и контекста приложения может дать много бесполезных сообщений. Нужны разные сигналы.

Разделите четыре источника наблюдения

ИсточникНа какой вопрос отвечаетПример
Проверка снаружиОткрывается ли сайт по пользовательскому путиКод ответа, TLS, ключевая страница
МетрикиКак меняются процессы и ресурсыCPU, память, свободный диск, соединения базы
ЖурналыКакое событие или ошибка произошлиОшибка подключения, рестарт, сбой платежного шлюза
Тест восстановленияВозвращаются ли данные после сбояОтдельный restore файлов и базы на тестовом узле

В обзоре Prometheus, проверенном 8 октября 2026 года, метрики описаны как числовые измерения, записанные во временной ряд. Для веб-сервера это могут быть длительность и количество запросов, для базы - активные соединения или запросы. В системе Prometheus сбор и хранение метрик отделены от маршрутизации предупреждений через Alertmanager.

Снимите обычный профиль до аварии

Запишите нагрузку в рабочие и спокойные часы. Смотрите не только на среднее, но и на короткие пики, ошибки и задержки. Для диска учитывайте свободное место и темп его заполнения; для базы - медленные запросы, активные соединения и очередь. Сопоставьте событие с журналом и последним изменением сайта.

Ubuntu в документации по observability разделяет метрики, логи и трассировки: каждая показывает отдельную сторону работы системы. В текущей документации Ubuntu старый стек LMA обозначен как переходящий на Canonical Observability Stack. Не переносите старую пошаговую конфигурацию без проверки версии и поддержки.

Оповещения без лишнего шума

Сообщение должно указывать, что проверялось, когда начался сбой и куда перейти. Разделите тревогу о доступности сайта и предупреждение о тенденции, например росте каталога журналов. Настройте подавление повторов. Одно событие не должно присылать десятки одинаковых уведомлений.

Проверьте путь доставки на тестовом событии: правило, Alertmanager и конечный канал уведомления. Успешное создание правила еще не показывает, что письмо или сообщение дошло до ответственного. Не останавливайте рабочий сервер ради проверки тревоги.

Где заканчиваются возможности мониторинга

Проверка доступности не измеряет скорость покупки и не подтверждает целостность резервной копии. Метрика за пределами нормы не называет причину автоматически. После уведомления сверяйте релиз, журналы, зависимости и реальную нагрузку.

Начните с базовых журналов и метрик на VPS, затем выбирайте стек под объем телеметрии и привычную инфраструктуру. Источники Ubuntu и Prometheus проверены 8 октября 2026 года; универсальные пороги и обещания безотказности не приводятся.