[Перевод] Как мониторить золотые сигналы SRE14.09.2022 01:01

Собираем метрики из популярных сервисов

Принципы Site Reliability Engineering (SRE) в последнее время очень популярны, отчасти благодаря знаменитой книге о SRE в Google, где говорится о золотых сигналах, за которыми нужно следить, чтобы наши системы работали быстро и безотказно в любых масштабах.

Все понимают, что это важные сигналы, но не все знают, как их отслеживать. Об этом мало где пишут.

А между тем собирать эти сигналы гораздо сложнее, чем традиционные данные по ЦП и ОЗУ. У каждого сервиса и ресурса свои метрики, определения и, особенно, инструменты.

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

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

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

Что мы называем сигналами SRE?

Есть три популярных методологии:

·        Из книги о SRE в Google: задержка, трафик, ошибки, насыщение (Latency, Traffic, Errors, Saturation).

·        Метод USE (придуманный Бренданом Греггом): использование, насыщение, ошибки (Utilization, Saturation и Errors).

·        Метод RED (придуманный Томом Уилки): частота запросов, ошибки, длительность (Rate, Errors, Duration).

Как видите, некоторые метрики повторяются. Бэрон Шварц (Baron Schwartz) в статье Monitoring & Observability with USE and RED отмечает, что у каждого метода своя направленность. USE, например, — это про взгляд на ресурсы изнутри, а RED — про запросы и реальную работу, то есть взгляд снаружи, с точки зрения потребителя сервиса. Конечно, эти методологии связаны и дополняют друг друга, ведь для работы сервису нужны ресурсы.

Мы объединим все три подхода и рассмотрим пять сигналов:

• Частота — частота запросов, в запросах в секунду.

• Ошибки — частота ошибок, в ошибках в секунду.

• Задержка — время отклика, включая время в очереди/время ожидания, в мс.

• Насыщение — перегруженность ресурса; связана с использованием, но измеряется напрямую. Например, через глубину очереди (иногда через количество параллельно выполняемых операций). При измерении очереди ненулевое значение обозначает насыщение или почти насыщение. Обычно представляет собой счётчик.

• Использование — насколько загружен ресурс или система. Обычно выражается в процентах и используется в прогнозах. Мы не используем сложные формулы (частота x время обслуживания / рабочие узлы), а берём понятные прямые измерения.

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

Все эти измерения можно разделять и/или объединять по разным аспектам. Например, для HTTP можно отдельно оценивать ошибки 4xx и 5xx, а задержку и частоту можно просматривать по URL.

Можно использовать более сложные расчёты. Например, у ошибочных запросов задержка обычно ниже, чем у успешных, так что из сигнала «Задержка» их лучше по возможности исключить (хотя часто это невозможно).

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

Сигналы мы определили. Что дальше?

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

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

В теории они гораздо полезнее, чем множество косвенных метрик, связанных с ЦП, ОЗУ, сетями, задержкой репликации и т. д. и т. п., которых может набираться штук по 200 на сервер.

Зачем мы собираем золотые сигналы?

• Чтобы получать оповещения, когда что-то пошло не так.

• Чтобы находить и устранять неисправности.

• Чтобы оптимизировать конфигурации и планировать мощности.

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

Оповещения часто срабатывают при достижении статических пороговых значений, заданных в наших любимых Nagios, Zabbix, DataDog и других подобных системах. Метод неплохой, но шумный. Вы (и ваши домашние) наверняка и так это знаете

Можно начать со статических порогов, выбрав их на основе опыта и рекомендаций. Лучше всего задавать значения, которые точно указывают на проблему. Например, 95% ЦП, задержка больше 10 секунд, маленький размер очереди, больше нескольких ошибок в секунду и т. д.

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

Средние значения или перцентили?

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

У средних значений есть и другие недостатки (см. эту статью). Медианные и средние значения понятны, доступны и полезны, если речь о коротком периоде (1–5 минут).

А как насчёт перцентилей? Например, можно настроить оповещение для 95-го перцентиля задержки, и это гораздо более эффективный способ измерять проблемы.

Правда, разобраться с перцентилями не так просто. В статье о сложностях работы с перцентилями, например, сказано, что на самом деле система высчитывает перцентиль от среднего за период изменения (например, 1 или 5 минут). Это удобный показатель для настройки оповещений, и вам определённо стоит его попробовать. Возможно, вы сильно удивитесь, увидев, как плохи ваши перцентили.

Аномалия или просто странность?

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

Выявлять аномалии сложно, не каждая локальная система мониторинга с этим справится (Zabbix, например, не может). Методология довольно новая и развивающаяся, её сложно правильно настроить, особенно с учётом сезонности и трендов, характерных для золотых сигналов.

К счастью, для этой задачи подходят новые решения для мониторинга на базе SaaS или облака (DataDog, SignalFX и т. д.) и локальные системы, вроде Prometheus и InfluxDB.

Бэрон Шварц написал неплохую книгу о доступных вариантах, алгоритмах и сложностях, связанных с обнаружением аномалий: Anomaly Detection for Monitoring.

Наглядная визуализация

Для визуализации сигналов у Splunk есть удобное представление, а у Weave Works есть отличный формат с графиками в две колонки. Слева — частота запросов и ошибок, справа — задержка. Можно добавить график насыщения/использования.

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

Как реагировать на оповещения

Реагировать на золотые сигналы SRE не так-то просто, потому что они указывают только на симптомы, а не на причину проблемы.

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

Им, конечно, и раньше приходилось это делать для проблем с ЦП и ОЗУ, но золотые сигналы обычно более абстрактны и их может быть много. Например, одна проблема с высокой задержкой в низкоуровневой службе может приводить ко множеству оповещений о задержках и ошибках по всей системе.

Часто бывает, что у нас есть полезные данные всего о нескольких сервисах, поэтому когда на фронтенде возникает проблема, нам приходится долго разыскивать виновника. Золотые сигналы упрощают нам жизнь — мы собираем их с каждого сервиса, нам будет легче найти проблемный (особенно если есть информация о зависимостях).

Вот и всё. Экспериментируйте с сигналами — это сложно, но очень интересно.

Сбор данных с конкретных сервисов

Ниже приводится список ресурсов для популярных сервисов. Там много нюансов и сложностей, иногда придётся подумать. Например, посчитать дельту метрик на основе счётчиков (большинство систем делают это автоматически). 

·        Балансировщики нагрузки — AWS ALB/ELB, HAProxy

·        Веб-серверы — Apache и Nginx

·        Серверы приложений — PHP, FPM, Java, Ruby, Node, Go, Python

·        Серверы баз данных — MySQL & AWS RDS

·        Серверы баз данных — AWS Aurora

·        Серверы Linux — как базовые ресурсы

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

От редакции

© Habrahabr.ru