Sign in Subscribe
it

Как мониторить золотые сигналы SRE

Sergey Golubev

• 6 min read

Вольный перевод серии статей How to Monitor the SRE Golden Signals

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

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

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

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

Во-первых, что такое сигналы SRE?

Есть три общих списка или методологии:

  • Из книги Google SRE: задержка (Latency), трафик (Traffic), ошибки (Errors) и насыщенность (Saturation)
  • Метод USE (от Брендана Грегга): использование (Utilization), насыщенность (Saturation) и ошибки (Errors)
  • RED метод (от Тома Уилки): частота (Rate), ошибки (Errors) и продолжительность (Duration)

Возможно увидеть совпадение, и, как отмечает барон Шварц в своем блоге «Мониторинг и наблюдение с блогами USE и RED», каждый метод имеет разную направленность. Он предполагает, что USE - это ресурсы с внутренним представлением, а RED - с запросами, реальной работой и, следовательно, внешним представлением (с точки зрения потребителя услуг). Они, очевидно, связаны, а также являются дополнительными, так как каждая служба потребляет ресурсы для выполнения работы.

Для наших целей мы сосредоточимся на простом наборе из пяти сигналов:

  • Rate (Rate) - частота запросов, в запросах / сек
  • Ошибки (Errors) - частота ошибок, в ошибках / сек
  • Задержка (Latency) - время ответа, включая время ожидания в очереди, в миллисекундах.
  • Насыщенность (Saturation) - насколько перегружено что-то, что связано с использованием, но более непосредственно измеряется такими вещами, как глубина очереди (или иногда параллелизм). В качестве измерения очереди оно становится ненулевым, когда насыщено, часто не намного раньше. Обычно счетчик.
  • Использование (Utilization) - насколько занят ресурс или система. Обычно выражается 0–100% и наиболее полезно для прогнозов (поскольку насыщение, вероятно, более полезно). Обратите внимание, что не используется Использование, чтобы получить это (~ Rate x Время обслуживания / Количество воркеров), но вместо этого ищутся более знакомые прямые измерения.

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

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

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

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

Теперь у нас есть наши сигналы, что с ними делать?

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

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

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

Собираются золотые сигналы по нескольким причинам:

  • Оповещение - сигналы сообщают, когда что-то не так
  • Устранение неполадок - сигналы помогают найти и устранить проблему
  • Настройка и планирование мощностей - сигналы помогают улучшить ситуацию с течением времени

Наше внимание сосредоточено на оповещениях и способах оповещения, основываясь на этих сигналах. Все, что необходимо сделать дальше, зависит от ситуации.

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

Если это необходимо, то следует начать со статических порогов, основываясь на своем опыте и лучших практиках. Они часто работают лучше всего, когда установлены уровни, на которых есть уверенность, что что-то не так или, по крайней мере, происходит что-то необычное (например, 95% ЦП, задержка более 10 секунд, очереди небольшого размера, частота ошибок выше нескольких в секунду и т.д.).

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

Измеряем среднее или процентиль?

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

У средних есть другие проблемы, как указывает Optimizely в своем блоге. Тем не менее, средние / медианы легко понятны, доступны и весьма полезны в качестве сигнала, если у вас короткое окно измерения (например, 1–5 минут).

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

Тем не менее, процентили более сложны, чем кажутся, и, конечно, у Vivid Cortex есть блог на эту тему: Почему процентили не работают так, как вы думаете, где, например, он предупреждает, что система действительно делает процентиль среднего в течение времени измерения (например, 1 или 5 минут). Но это все еще полезно для оповещения, и следует попробовать их, если это возможно.

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

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

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

К счастью, новые решения для мониторинга SaaS / Cloud, такие как DataDog, SignalFX и т.д., могут сделать это, как и новые локальные системы, такие как Prometheus или InfluxDB.

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

Возможно ли отобразить?

В дополнение к предупреждения, также следует визуализировать эти сигналы. Weave Works имеет хороший формат, с двумя графическими столбцами, а Splunk имеет хороший вид. Слева - составной график коэффициентов запросов и ошибок, а справа - графики задержек. Также возможно добавить 3-й смешанный график насыщенности / использования.

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

Исправления

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

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

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

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

Вот и все. Получайте удовольствие от ваших сигналов, поскольку их сложно и интересно находить, отслеживать и оповещать.

Получение данных от каждого сервиса

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

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

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

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

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

Sign up for more like this.

Enter your email
Subscribe