Мониторинг: Часть 1 — Зачем он нужен и что измерять

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

Зачем нужен мониторинг

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

Виды мониторинга

• Системный — загрузка процессора, память, диски, сеть, время работы серверов и виртуальных машин.
• Сетевой — состояние маршрутизаторов и коммутаторов, потери пакетов, задержки, загрузка каналов.
• Мониторинг приложений (APM) — время ответа, запросы к базе данных, исключения внутри кода.
• Мониторинг со стороны пользователя — реальные действия посетителей (RUM) и синтетические проверки, когда внешний сервис регулярно открывает сайт из разных регионов и измеряет доступность и скорость.

Что измерять: три проверенных подхода

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

Четыре золотых сигнала. Инженеры Google в книге о SRE выделяют четыре показателя для сервисов, с которыми работают пользователи:

• задержка — время обработки запроса, причём успешные и ошибочные запросы нужно считать отдельно: быстрый ответ с ошибкой не должен улучшать среднее значение;
• трафик — нагрузка на систему, например число HTTP-запросов в секунду;
• ошибки — доля неудачных запросов: явных (код 500), неявных (код 200 с неверным содержимым) и нарушающих правила (ответ дольше установленного порога);
• насыщение — насколько система «заполнена», в первую очередь по самому ограниченному ресурсу.

Метод USE (Брендан Грегг) применяется к ресурсам — процессору, памяти, дискам, сети. Для каждого ресурса проверяют три вещи: использование (какую долю времени ресурс был занят), насыщение (сколько работы ждёт в очереди) и ошибки. По оценке автора, такая проверка находит большую часть проблем на серверах при небольших затратах времени.

Метод RED (Том Уилки, 2015) — для сервисов, которые обрабатывают запросы: частота запросов, ошибки и длительность обработки. Если строить панели по RED для каждого сервиса, все они выглядят одинаково, и дежурный разбирается даже в сервисе, который писал не он.

На практике USE описывает серверы, а RED и золотые сигналы — сервисы на них.

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

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

• Каждое оповещение должно требовать действия. В рекомендациях Google SRE сказано: если на оповещение можно ответить механически, оно не должно будить человека. Такие случаи автоматизируют или переводят в отчёты.
• Оповещать о симптомах, а не о причинах. Пользователю важно, что сайт отвечает ошибкой или медленно, а не то, что процессор загружен на 90 %. Высокая загрузка без влияния на сервис — повод посмотреть на график, но не поднимать дежурного ночью.
• Добавлять задержку срабатывания. Условие должно держаться несколько минут, прежде чем придёт оповещение: кратковременные всплески не должны вызывать тревогу.
• Разделять уровни важности. Критические оповещения — в мессенджер или по телефону круглосуточно, предупреждения — в рабочий чат или отчёт.
• Группировать. Если упал коммутатор, не нужно двадцать сообщений о каждом сервере за ним — достаточно одного.
• Пересматривать правила. Оповещение, которое за месяц ни разу не привело к действию, стоит отключить или переделать.

Большинство систем мониторинга отправляют оповещения в Telegram, на почту, по SMS и в сервисы дежурств.

Инструменты цикла

• Munin — простая система с готовыми графиками для нескольких серверов.
• Prometheus, Node Exporter и Grafana — сбор метрик по запросу, гибкий язык запросов и оповещения через Alertmanager.
• Zabbix — система «всё в одном»: агенты, шаблоны, оповещения и веб-интерфейс в одном продукте.
• VictoriaMetrics — экономичное хранилище метрик, совместимое с Prometheus, для долгого хранения и больших объёмов.

Пример того, как мониторинг выглядит на большом парке, — в статье о том, как автоматизировать управление 366 серверами.