Мониторинг и уведомления

Мониторинг и уведомления

Мониторинг — это система наблюдения за инфраструктурой. Его задача не в том, чтобы показывать красивые графики, а в том, чтобы вовремя отвечать на главный вопрос: всё работает нормально или уже требуется внимание?

В домашней инфраструктуре мониторинг особенно важен. Сервисы могут работать на собственных узлах, зависеть от локальной сети, DNS, reverse proxy, хранилища, резервных копий и внешнего доступа. Если один из этих слоёв ломается, пользователь часто видит только общий симптом: “ничего не открывается”.

Хороший мониторинг помогает не гадать, а быстро понять, где именно возникла проблема.

Главная идея

Главная идея мониторинга простая:

инфраструктура должна сама показывать своё состояние.

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

Для обычного пользователя мониторинг отвечает на понятные вопросы:

• работает ли сайт;
• доступно ли домашнее облако;
• хватает ли места на диске;
• выполняются ли резервные копии;
• не сломался ли внешний доступ;
• не появились ли повторяющиеся ошибки.

Для специалиста это уже набор технических задач: uptime checks, health-checks, метрики, логи, алерты, статусы сервисов, latency, TLS-проверки, DNS-проверки и контроль backend-сервисов.

Мониторинг — это не только графики

Многие воспринимают мониторинг как панель с графиками процессора, памяти и дисков. Это полезно, но этого недостаточно.

Настоящий мониторинг должен отвечать не только на вопрос “сколько ресурсов используется”, но и на вопрос “может ли пользователь выполнить нужное действие”.

Например, сервер может быть включён, процесс может быть запущен, контейнер может отображаться как active, но сам web-сервис при этом может не открываться. Поэтому важно проверять не только состояние процесса, но и реальную доступность сервиса.

Что проверяем	Почему это важно
Доступность страницы	показывает, открывается ли сервис для пользователя
Ответ backend-сервиса	помогает понять, работает ли приложение внутри
DNS-имя	показывает, правильно ли находится адрес сервиса
HTTPS	проверяет безопасное соединение и сертификат
Reverse proxy	показывает, работает ли входной слой
Свободное место	предупреждает о риске остановки сервисов
Backup	показывает, выполняются ли резервные копии
Логи	помогают понять причину ошибок

Хороший мониторинг смотрит на систему с разных сторон.

Что нужно мониторить

В небольшой инфраструктуре не нужно сразу строить сложную систему наблюдения. Достаточно начать с базовых проверок, которые дают практическую пользу.

Минимальный набор:

• доступность главного сайта;
• доступность внутренних web-сервисов;
• состояние reverse proxy;
• корректность HTTPS;
• доступность DNS-имени;
• состояние облачного сервиса;
• свободное место на дисках;
• возраст последней резервной копии;
• ошибки в журналах;
• доступность ключевых узлов;
• состояние контейнеров или системных сервисов.

Главное — мониторить не всё подряд, а то, от чего реально зависит работа инфраструктуры.

Проверка доступности

Самая простая проверка — открыть сервис и посмотреть, отвечает ли он.

Но даже здесь есть разные уровни.

Первый уровень: сервер отвечает на ping.
Второй уровень: порт открыт.
Третий уровень: web-сервис возвращает страницу.
Четвёртый уровень: страница возвращает правильный код ответа.
Пятый уровень: сервис не просто открыт, а действительно работает.

Например, домашнее облако может открывать страницу входа, но при этом не иметь доступа к хранилищу. Поэтому для важных сервисов полезно проверять не только факт открытия страницы, но и более глубокие признаки работоспособности.

Health-check

Health-check — это специальная проверка состояния сервиса.

Простыми словами, это вопрос к сервису: “ты живой и готов работать?”

Health-check может проверять:

• запущено ли приложение;
• доступна ли база данных;
• есть ли доступ к хранилищу;
• отвечает ли API;
• нет ли критической внутренней ошибки;
• не находится ли сервис в режиме обслуживания.

Для обычного пользователя это незаметно. Но для инфраструктуры health-check помогает отличить ситуацию “сервис включён” от ситуации “сервис реально работает”.

Уровни важности

Не каждое событие должно быть тревогой. Это очень важный принцип.

Если система отправляет уведомления на каждую мелочь, владелец быстро перестаёт на них реагировать. Поэтому события нужно делить по уровню важности.

Уровень	Значение	Пример
Info	обычное информационное событие	сервис обновлён, проверка прошла успешно
Notice	событие стоит зафиксировать	сервис был перезапущен
Warning	есть отклонение, но аварии ещё нет	диск заполнен на 80%
Critical	сервис недоступен или есть серьёзный сбой	облако не отвечает
Security	есть подозрительное поведение	частые обращения к закрытым путям
Recovery	проблема ушла	сервис снова доступен

Такая шкала помогает не смешивать обычные события и настоящие проблемы.

Уведомления

Уведомления нужны для того, чтобы владелец быстро узнал о важном событии. Но уведомления должны быть полезными.

Плохое уведомление выглядит так:

“Ошибка”.

Хорошее уведомление объясняет:

• какой сервис затронут;
• что именно произошло;
• когда это началось;
• какой уровень важности;
• что уже проверено;
• где вероятная причина;
• что нужно сделать дальше.

Например:

“Домашнее облако недоступно. DNS отвечает, HTTPS доступен, reverse proxy работает, backend не отвечает. Проверь контейнер или приложение.”

Такое сообщение экономит время, потому что сразу показывает направление диагностики.

Как избежать шума

Одна из главных проблем мониторинга — лишний шум.

Если уведомлений слишком много, они перестают быть полезными. Поэтому нужно вводить простые правила.

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

Хороший мониторинг должен помогать, а не нервировать.

Мониторинг сайта

Для публичного сайта важны несколько проверок.

Нужно понимать:

• открывается ли главная страница;
• возвращается ли правильный HTTP-код;
• работает ли HTTPS;
• не истёк ли сертификат;
• не сломалась ли сборка;
• отвечает ли сервер достаточно быстро;
• доступна ли документация;
• нет ли ошибок reverse proxy.

Если сайт статический, как в FASTRAID LAB, это снижает риски. Нет базы данных, нет динамической админки, нет сложного backend. Но всё равно нужно контролировать доступность, HTTPS, DNS и web-сервер.

Мониторинг домашнего облака

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

Для него важно проверять:

• доступность web-интерфейса;
• корректность HTTPS;
• доступность backend-сервиса;
• свободное место на диске;
• состояние хранилища;
• успешность резервного копирования;
• ошибки синхронизации;
• состояние фоновых задач;
• доступность через внешний адрес.

Если облако недоступно, проблема может быть не только в самом приложении. Причина может быть в DNS, reverse proxy, сертификате, контейнере, базе данных, диске или сетевом маршруте.

Мониторинг DNS

DNS — один из самых важных, но часто незаметных элементов.

Если DNS работает неправильно, сервис может быть исправен, но пользователь всё равно не сможет его открыть.

Полезно проверять:

• отвечает ли нужное DNS-имя;
• возвращается ли правильный адрес;
• не изменилась ли внешняя точка доступа;
• работают ли внутренние имена;
• не используют ли устройства обходной DNS;
• нет ли повторяющихся ошибок разрешения имён.

DNS-проверки особенно важны для сервисов, которые должны быть доступны по стабильному имени.

Мониторинг reverse proxy

Reverse proxy — это входная дверь для web-сервисов. Если он работает неправильно, могут стать недоступны сразу несколько сервисов.

Для reverse proxy полезно проверять:

• запущен ли сервис proxy;
• принимает ли он HTTPS;
• корректно ли маршрутизирует домены;
• отвечает ли backend;
• нет ли ошибок 502, 503, 504;
• обновляются ли сертификаты;
• нет ли неизвестных host-запросов;
• не выросло ли количество отказов.

Ошибки reverse proxy особенно полезно фиксировать в журналах, потому что они часто показывают, где именно разорвалась цепочка запроса.

Мониторинг резервных копий

Backup нельзя считать рабочим только потому, что когда-то была настроена задача копирования.

Нужно регулярно проверять:

• когда была последняя успешная копия;
• завершилась ли задача без ошибок;
• какой объём данных был сохранён;
• доступно ли хранилище backup;
• хватает ли места для новых копий;
• не слишком ли старая последняя копия;
• можно ли восстановить данные.

Очень важный принцип:

резервная копия имеет смысл только тогда, когда восстановление реально проверялось.

Мониторинг backup должен сообщать не только о полном падении, но и о подозрительном отсутствии свежих копий.

Журналы и мониторинг

Мониторинг и журналы — это разные вещи, но они должны работать вместе.

Мониторинг отвечает на вопрос: “есть ли проблема сейчас?”
Журналы отвечают на вопрос: “что происходило до проблемы?”

Например, мониторинг говорит: “сервис недоступен”.
Журнал помогает понять: “перед этим backend начал возвращать ошибки, потом proxy получил 502, потом контейнер перезапустился”.

Без журналов мониторинг показывает симптом, но не всегда показывает причину.

Диагностика по слоям

Когда приходит уведомление, важно не бросаться сразу перезапускать всё подряд. Лучше идти по слоям.

Для web-сервиса цепочка может быть такой:

1. DNS-имя отвечает;
2. HTTPS работает;
3. reverse proxy доступен;
4. маршрут настроен правильно;
5. backend-сервис отвечает;
6. приложение не возвращает ошибку;
7. хранилище доступно;
8. в журналах нет критических ошибок.

Такой подход помогает быстро отделить сетевую проблему от ошибки приложения, а проблему proxy от сбоя backend.

Что не нужно мониторить в начале

В начале не стоит пытаться мониторить абсолютно всё.

Лишние проверки усложняют систему и создают шум. Лучше сначала закрыть важные вещи:

• доступность ключевых сервисов;
• место на дисках;
• backup;
• DNS;
• HTTPS;
• reverse proxy;
• ошибки в журналах;
• состояние основных узлов.

Когда базовый мониторинг уже работает, можно добавлять более глубокие метрики.

Практический результат

Хороший мониторинг даёт несколько преимуществ.

Во-первых, владелец узнаёт о проблеме раньше.

Во-вторых, уведомление сразу показывает направление диагностики.

В-третьих, меньше времени уходит на гадание.

В-четвёртых, инфраструктура становится спокойнее в обслуживании.

В-пятых, появляется история событий: что ломалось, когда восстановилось и какие проблемы повторяются.

Итог

Мониторинг — это не украшение инфраструктуры, а её система наблюдения.

Он показывает состояние сервисов.
Уведомления сообщают о важных событиях.
Журналы помогают искать причины.
Health-checks показывают реальную работоспособность.
Уровни важности защищают от информационного шума.
Диагностика по слоям помогает быстрее находить проблему.

Главная цель мониторинга — сделать инфраструктуру понятной и наблюдаемой.

Хорошая система не должна молча ломаться. Она должна уметь показать, что произошло, где искать причину и когда работа восстановилась.