Когда сервис падает ночью, а ты узнаёшь об этом утром от разгневанных пользователей, приходит понимание: без наблюдения за инфраструктурой дальше жить нельзя. Логи и метрики — это два разных, но одинаково важных источника информации о здоровье системы. Логи рассказывают, что именно произошло, а метрики показывают, как быстро и насколько сильно всё ухудшилось. Начать строить систему мониторинга проще, чем кажется, если сразу разложить процесс на понятные этапы и не пытаться объять необъятное в первый же день.
Первым делом стоит определиться с инструментами, которые будут собирать и показывать данные. Многие команды выбирают платформу для мониторинга приложений, потому что она объединяет работу с логами, метриками и алертами в одном окне, избавляя от необходимости склеивать зоопарк разрозненных утилит. Дальше важно не распыляться: начните с двух-трёх ключевых сервисов, настройте для них базовые дашборды и только потом расширяйте покрытие на остальные части инфраструктуры.
Частая ошибка новичков — попытка сразу собирать всё: каждый системный лог, каждую метрику ядра, каждый запрос к базе. Это приводит к перегрузке хранилища, шуму в алертах и быстрому выгоранию команды. Гораздо эффективнее идти от бизнес-задач: что должно работать всегда, какое ухудшение критично для пользователей, какие сбои стоят денег. Ответы на эти вопросы и определят, какие именно логи и метрики собирать в первую очередь.
Логи и метрики: в чём разница и зачем нужны оба
Логи — это текстовые записи о событиях. Они отвечают на вопросы «почему упало» и «кто виноват». Метрики — это числовые ряды во времени: загрузка CPU, количество запросов в секунду, latency, объём свободного места на диске. Они отвечают на вопросы «насколько всё плохо» и «когда началось». Без логов вы не поймёте причину инцидента, без метрик — не заметите, что инцидент вообще происходит.
Хорошая система мониторинга умеет связывать эти два мира. Например, график latency резко пополз вверх в 14:32 — вы смотрите метрику, видите аномалию, а затем по таймстемпу переходите к логам приложения за тот же период и находите stacktrace. Если данные разрознены по разным системам, такой переход занимает минуты, а в инциденте каждая минута — это потерянные пользователи и деньги.
Практический совет: начните с четырёх базовых типов метрик для каждого сервиса:
- Количество запросов или операций в единицу времени.
- Процент ошибок от общего числа запросов.
- Время ответа: среднее, медианное и перцентили 95 и 99.
- Потребление ресурсов: CPU, память, диск, сеть.
Эти четыре группы покрывают 80 процентов типовых проблем и дают отличную базу для первых алертов. Логи же стоит собирать структурированно, с обязательными полями timestamp, уровень, сервис и trace id, если он есть.
С чего начать: минимальный жизнеспособный мониторинг
Не нужно разворачивать сложный стек из десятка компонентов. Минимальный жизнеспособный мониторинг состоит из трёх слоёв: агенты сбора данных, центральное хранилище и интерфейс визуализации с алертами. Агенты ставятся на серверы или встраиваются в приложения, отправляют логи и метрики в хранилище, а дашборды и уведомления строятся поверх этого хранилища.
Начните с одного пилотного сервиса. Пусть это будет то, что уже доставляет боль: падает чаще всего, тормозит под нагрузкой или теряет данные. Для него настройте сбор логов с уровня INFO и выше, а также перечисленные выше четыре группы метрик. Создайте один дашборд, на котором видно: общее состояние сервиса, график запросов, график ошибок, график latency и топ-10 самых частых ошибок из логов. Уже этого хватит, чтобы через неделю вы начали видеть закономерности, которых раньше не замечали.
Параллельно продумайте retention — сколько хранить данные. Горячие данные за последние сутки или неделю нужны для оперативного разбора, холодные за месяц или квартал — для анализа трендов и планирования ёмкости. Хранить все логи вечно дорого и бессмысленно: через полгода детальный debug-лог вчерашнего запроса вряд ли кому-то понадобится. Настройте ротацию и tiers хранения с первого дня, иначе через пару месяцев столкнётесь с раздутым диском и неработающими запросами.
Алерты: как не утонуть в уведомлениях
Алерты — самая опасная часть мониторинга. Слишком много уведомлений — и команда перестаёт на них реагировать, слишком мало — и инциденты пропускаются. Золотое правило: алерт должен требовать действия. Если уведомление приходит, но делать с ним ничего не нужно, это не алерт, а шум. Удаляйте такой алерт или понижайте его до информационного уровня.
Настройте алерты на основе симптомов, а не причин. Плохой алерт: «CPU сервера номер 7 выше 90 процентов». Хороший алерт: «Процент ошибок сервиса оплаты превысил 5 процентов за последние 5 минут». Первый заставляет гадать, второй сразу указывает на бизнес-проблему. Причинный алерт можно оставить как дополнительную подсказку, но основным триггером должен быть именно симптом.
Каналы доставки тоже имеют значение. Для критичных инцидентов используйте то, что реально будит ночью: звонок, push с громким звуком, SMS. Email подходит только для дайджестов и некритичных событий. Обязательно настройте дедупликацию и группировку: если упали сразу десять серверов, вы должны получить одно уведомление с перечнем, а не десять одинаковых сообщений.
Вот минимальный набор алертов, с которого можно начать:
- Процент ошибок сервиса выше порога в течение нескольких минут.
- Latency 99-го перцентиля выше порога в течение нескольких минут.
- Свободное место на диске ниже критической отметки.
- Сервис не отвечает на health-check дольше заданного времени.
- Резкий рост или падение трафика относительно обычного уровня.
Каждый из этих алертов напрямую влияет на пользовательский опыт или на стабильность системы. Если какой-то из них срабатывает слишком часто, не отключайте его сразу — разберитесь, почему порог подобран неверно, и скорректируйте значение.
Культура и процессы: мониторинг без людей не работает
Самая продвинутая платформа бесполезна, если команда не смотрит на дашборды и не разбирает инциденты. Мониторинг — это не только инструменты, но и привычки. Введите короткий ритуал: в начале рабочего дня или на дейли стендапе просматривайте главный дашборд, отмечайте аномалии, назначайте ответственных за разбор. Пять минут в день экономят часы при расследовании инцидентов.
После каждого серьёзного сбоя проводите blameless постмортем. Не ищите виноватого, а выясняйте, почему система позволила сбою случиться и как мониторинг мог бы заметить проблему раньше. Возможно, не хватало метрики, алерт был настроен с неправильным порогом или уведомление ушло не тому человеку. Каждый такой разбор должен заканчиваться конкретным действием: добавить метрику, поправить порог, изменить маршрутизацию алерта.
Постепенно расширяйте покрытие. Когда пилотный сервис мониторится стабильно и алерты не вызывают раздражения, подключайте следующий сервис. Через несколько месяцев вы получите систему, которая видит всю инфраструктуру целиком, а не отдельные её куски. Именно в этот момент мониторинг перестаёт быть обузой и становится инструментом, который реально помогает спать спокойно и быстрее чинить то, что сломалось.
Не гонитесь за идеалом с первого дня. Начните с малого, настройте базовые дашборды и алерты, приучите команду смотреть на данные. Остальное придёт с опытом, а первые победы над инцидентами, пойманными до того, как о них узнали пользователи, станут лучшей мотивацией продолжать.
Последние обсуждения