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

Мониторинг — это автоматизированный сбор данных из ваших систем, который передает ваши SLI (индикаторы уровня обслуживания) и сообщает вам, выполняются ли ваши SLO (цели уровня обслуживания). На самом деле, SRE рекомендует базовый набор показателей для мониторинга, называемый четырьмя золотыми сигналами:

  • Задержка,
  • Трафик,
  • Ошибки и
  • Насыщенность.

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

Задержка

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

Трафик

Трафик — это величина нагрузки, на которую реагирует ваша система. Это может быть размер очереди сообщений для системы обработки заданий или количество HTTP-запросов в секунду для веб-сайта или REST API. Трафик говорит вам, насколько усердно работает ваша система.

Ошибки

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

Насыщенность

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

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

Давайте рассмотрим пример задержки для веб-приложения. У вас может быть SLO, ориентированный на пользователя, в котором говорится, что домашняя страница должна возвращаться менее чем за полсекунды для 95% запросов. И есть много разных способов, которыми вы можете построить SLI, чтобы дать вам время, необходимое серверу для генерации и возврата ответа. Но это не тот период времени, который видит пользователь, потому что будут балансировщики нагрузки, CDN и весь Интернет, прежде чем они получат ответ от сервера.

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

В этом случае единственный способ получить истинное представление о времени задержки конечного пользователя — включить мониторинг во время отклика записи JavaScript и времени рендеринга. Для этого могут потребоваться специальные инженерные усилия, или вы можете получить то, что вам нужно, от службы, такой как Google Analytics, которая записывает задержку страницы вместе с трафиком.

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

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

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

Появляются стандарты того, как должны быть представлены метрики, но наиболее распространенным форматом является проект Prometheus с открытым исходным кодом, который занимается сбором и хранением данных. Книги Google SRE используют Prometheus для своих примеров, и это довольно большой проект. Это часть Cloud Native Computing Foundation, которая является той же основой, которая управляет средой выполнения контейнеров Kubernetes и Docker.

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

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

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

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

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

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

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