Метрики, логи, алерты – три кита наблюдаемости

К этому моменту сервер настроен, приложение задеплоено, пайплайн катит новые версии. Остался вопрос, с которого в продакшене начинается каждый день: а оно вообще работает? Причем не «сейчас, когда я зашел проверить», а постоянно, включая три часа ночи.

Способность понять, что происходит с системой, не залезая в нее руками, называется наблюдаемостью. Без нее любая жалоба «сайт тормозит» превращается в блуждание вслепую: на каком из серверов проблема, что именно тормозит, с какого момента началось, становится ли хуже. Чтобы на эти вопросы был ответ, наблюдаемость собирают из трех частей, и у каждой своя роль.

Метрики, числа во времени

Метрика, это число, которое измеряется регулярно: загрузка процессора, занятая память, количество запросов в секунду, время ответа, доля ошибок. Одно измерение само по себе мало что значит. Сила метрик в том, что они снимаются постоянно, раз в несколько секунд, и складываются в историю.

Из истории получается график, а на графике видно главное, динамику.

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

При этом у метрик есть граница возможностей. Они отвечают на вопрос «что происходит и насколько плохо», но не «почему». График покажет, что ошибки выросли в десять раз, а вот из-за чего, уже не его работа.

Логи, текст о событиях

Лог, это текстовая запись о событии: что случилось, когда, с какими подробностями. С логами вы уже работали в модуле про Linux, когда грепали файлы в /var/log, выглядят они так:

2026-06-05 14:12:03 INFO  GET /api/orders 200 35ms
2026-06-05 14:12:04 INFO  GET /api/orders 200 41ms
2026-06-05 14:12:05 ERROR connection to db timeout after 5000ms
2026-06-05 14:12:05 ERROR GET /api/orders 500 5002ms

У записей есть уровни важности: DEBUG для отладочных мелочей, INFO для обычных событий, WARNING для подозрительного, ERROR для ошибок. И логи отвечают ровно на тот вопрос, на который не отвечают метрики, на «почему». Метрика сказала «ошибки выросли», лог говорит «таймаут соединения с базой данных», вот и причина, с точностью до строки.

Сложность логов в масштабе. Когда серверов пятьдесят, а поды в кластере еще и переезжают с узла на узел, ходить по машинам с grep физически невозможно, да и логи умершего пода умирают вместе с ним. Поэтому в реальных системах логи со всех машин и контейнеров стекаются в одно центральное хранилище, где по ним можно искать как в поисковике. Инструменты этого слоя, стек ELK (Elasticsearch, Logstash, Kibana) и Grafana Loki; запоминать их пока не нужно, достаточно знать, что слова «централизованные логи» означают «все логи в одном месте с поиском».

Алерты, «проснись, что-то сломалось»

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

Обратите внимание на «в течение N минут» в каждом правиле. Это защита от ложных тревог: секундный пик нагрузки, нормальная жизнь системы, и будить из-за него человека не нужно. Алерт срабатывает на устойчивую проблему, а не на короткий всплеск.

Куда приходят алерты, вопрос настройки: Telegram, мессенджер команды, SMS, для самого критичного, телефонный звонок дежурному. И здесь же главное правило хорошего алертинга: алерт должен требовать действия. Если завести оповещения на все подряд, наступает alert fatigue, усталость от алертов, когда канал с ними мьютят и настоящая авария тонет в шуме. Лучше три алерта, на которые реагируют, чем тридцать, которые игнорируют.

Стек, кто собирает, рисует и будит

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

Prometheus собирает и хранит метрики. Работает он по pull-модели: сам обходит свои цели раз в несколько секунд и забирает у каждой свежие числа со специальной страницы /metrics. Чтобы сервер или база умели отдавать метрики, рядом с ними ставят экспортер, маленькую программу-переводчик; например, node_exporter отдает метрики железа: процессор, память, диск. Для вопросов к накопленным данным у Prometheus есть свой язык запросов PromQL, учить его сейчас не нужно, просто узнавайте слово.

Grafana превращает данные в дашборды, экраны из графиков, те самые, ради которых снято видео. Один взгляд на дашборд отвечает на вопрос «как себя чувствует система»: нагрузка, ошибки, время ответа, состояние серверов. Дашборды собираются из запросов к Prometheus, причем рисовать с нуля чаще всего не приходится: под типовые задачи есть готовые дашборды, которые импортируются в пару кликов. И да, тот «утренний график», по которому инженер из модуля про Kubernetes узнал о ночном падении пода, это график в Grafana.

Alertmanager принимает сработавшие правила от Prometheus и доводит их до людей с умом: группирует связанное (упал узел, приходит одно сообщение, а не пятьдесят, по числу подов на нем), маршрутизирует по важности (критичное звонком дежурному, остальное в чат) и глушит повторы, пока проблему чинят.

Один инцидент, три кита

Соберем все в историю. 14, в Telegram приходит сообщение от Alertmanager: время ответа API превышает две секунды уже пять минут. Вы открываете дашборд Grafana: время ответа действительно растет, процессор и память в норме, зато график ошибок обращений к базе данных встал свечкой ровно в 14. Идете в централизованные логи, фильтруете по ERROR за последние десять минут, и вот оно: connection to db timeout. Дальше разбираться уже с базой, но диагноз поставлен: от алерта до причины прошло несколько минут.

Роли распределились в точности по китам: алерт разбудил, метрики показали, где и с какого момента, логи объяснили почему. А теперь представьте тот же инцидент без наблюдаемости: пользователи пишут в поддержку, поддержка через час пишет вам, вы по очереди заходите на серверы и гадаете, куда смотреть. Разница измеряется часами простоя.

Замыкание конвейера

Мониторинг, последний пункт карты технологий из первого модуля, и он замыкает весь конвейер в петлю: пайплайн выкатил новую версию, дашборд показывает, как она себя ведет, и если метрики после релиза поползли, версия откатывается. Решения о выкатах и откатах принимаются не на ощущениях, а по графикам.

Настраивается все это, как вы уже догадываетесь, кодом: конфиги Prometheus, правила алертов и дашборды лежат в Git, проходят ревью и едут на серверы тем же Ansible. К этому моменту все модули сцепились друг с другом, это и есть нормально устроенный DevOps.

Словарик