Начать с решений, а не графиков
Полезный сигнал — тот, после которого понятно следующее действие. Если график интересно разглядывать, но по нему нельзя решить, кого будить и что проверять, это пока декорация.
Для небольшого веб-сервиса я начинаю с четырёх вопросов: отвечает ли он, сколько длится ответ, сколько запросов завершается ошибкой и хватает ли места на диске. Этого достаточно, чтобы заметить большинство бытовых проблем.
Практическое правило
У каждого оповещения должны быть порог, окно наблюдения и первая команда для проверки. Без последнего пункта сигнал быстро превращается в шум.
Журнал событий — это интерфейс
Строка журнала должна помогать восстановить ход запроса: время, уровень, компонент, идентификатор операции и короткое описание результата. Секреты и полные тела запросов туда не попадают.
Структурированный формат удобен для машин, но дисциплина важнее формата. Даже обычный текст работает, если поля остаются одинаковыми, а часы на сервере синхронизированы.
Проверять путь пользователя
Процесс может быть запущен, а сервис — уже бесполезен. Поэтому внешняя проверка должна проходить по тому же маршруту, что и обычный запрос: DNS, соединение, TLS и ответ приложения.
Для статичного сайта достаточно получить главную страницу, проверить код ответа и разумный предел времени. Для приложения лучше выбрать небольшой безопасный сценарий без изменения данных.
Оставить место для роста
Минимальная схема не обязана быть вечной. Когда появляются несколько серверов, разные команды или строгие требования к времени восстановления, централизованные метрики и трассировка начинают окупаться. До этого момента простая система выигрывает тем, что её действительно проверяют.