Принципы 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 — как базовые ресурсы
Поскольку это длинный и сложный набор статей, несомненно, существуют разные точки зрения и опыт, поэтому мы приветствуем обратную связь и другие идеи. Очень ждем их в комментариях.
От редакции
Слёрм запускает поток SRE: data-driven подход к управлению надёжностью систем.
Благодаря внедрению Sre-подхода можно снизить процент отказов сервиса, повысить скорости реагирования на отказы, снизить риски при выкате новых фич и увеличить скорости разработки.
Если вы думаете стать SRE-инженером или подготовить команду в своей компании, то на интенсиве вы сможете получить представление, чем занимается SRE в реальности и примерите эти практики на себя и компанию, чтобы в последствии внедрить в работу.
Оставить заявку на участие: https://slurm.club/3QKKaqd
