Сбор метрик инфраструктуры и приложений

VPS | Amber | Комментировать запись

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

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

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

Четыре сигнала мониторинга

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

Задержка

Задержка – это время, необходимое для завершения действия. Специфика измерения этой метрики зависит от компонента, ее общие аналоги – время обработки, время отклика или время в пути.

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

Трафик

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

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

Ошибки

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

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

Насыщение

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

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

Измерение важных данных среды

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

Мы рассмотрим различные уровни сложности, присутствующие в распространенных средах распределенных приложений:

• Отдельные серверные компоненты
• Приложения и сервисы
• Группы серверов
• Зависимости среды
• Комплексный опыт

Приведенный выше порядок расширяет объем и уровень абстракции с каждым последующим слоем.

Метрики отдельных компонентов сервера

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

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

Брендан Грегг (Brendan Gregg) предлагает множество способов получения основных сетрик систем Linux. Его метод анализа производительности называется USE (utilization, saturation, errors – использование, насыщение и ошибки). Как видите, метод USE и четыре золотых сигнала сильно совпадают, потому вы можете использовать некоторые из его рекомендаций, чтобы выяснить, какие данные собирать с серверных компонентов.

Для CPU нужно определить:

• Задержка: средняя или максимальная задержка в планировщике CPU
• Трафик: загрузка процессора
• Ошибки: ошибки конкретного процессора, неисправные процессоры
• Насыщение: длина очереди выполнения

Для измерения памяти сигналы могут выглядеть так:

• Задержка: нет рекомендаций – трудно найти хороший метод измерения
• Трафик: количество используемой памяти
• Ошибки: ошибки в памяти
• Насыщение: события OOM, использование своп-пространства

Для устройства хранения:

• Задержка: среднее время ожидания для операций чтения и записи
• Трафик: чтение и запись уровней ввода/вывода
• Ошибки: ошибки файловой системы, ошибки диска в /sys/devices
• Насыщение: глубина очереди ввода-вывода

Сигналы сети могут выглядеть так:

• Задержка: очередь сетевого драйвера
• Трафик: входящие и исходящие байты или пакеты в секунду
• Ошибки: ошибки сетевого устройства, сброшенные пакеты
• Насыщение: сброшенные пакеты, повторные передачи сегментов, перегрузка

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

Метрики приложений и сервисов

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

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

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

Приложения, обслуживающие клиентов, отслеживают по таким сигналам:

• Задержка: время выполнения запросов
• Трафик: количество запросов в секунду
• Ошибки: ошибки приложения, возникающие при обработке клиентских запросов или доступе к ресурсам
• Насыщение: процент или количество ресурсов, используемых в настоящее время

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

Четыре золотых сигнала были разработаны в основном для распределенных микросервисов, поэтому они предполагают архитектуру клиент-сервер. Для приложений, которые не используют архитектуру клиент-сервер, все те же сигналы по-прежнему важны, но сигнал «трафик», возможно, нужно немного пересмотреть. Этот сигнал в основном отображает уровень занятости, поэтому тут нужно найти метрику, которая адекватно отражает занятость вашего приложения. Специфика будет зависеть от того, что делает конкретная программа, обычно трафик на этом уровне определяется количеством операций или данных, обрабатываемых в секунду.

Метрики групп серверов и их взаимодействий

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

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

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

• Задержка: время ответа пула на запросы, время для координации или синхронизации с одноранговыми серверами
• Трафик: количество запросов, обрабатываемых пулом в секунду
• Ошибки: ошибки приложения, возникающие при обработке клиентских запросов, доступе к ресурсам или синхронизации с одноранговыми серверами
• Насыщение: количество используемых в настоящее время ресурсов, количество запущенных серверов, количество доступных серверов.

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

Метрики внешних зависимостей и среды развертывания

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

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

Сигналы для мониторинга внешних зависимостей:

• Задержка: время, необходимое для получения ответа от сервиса или предоставления новых ресурсов провайдера
• Трафик: количество операций, передаваемых внешнему сервису, количество запросов, поступающих во внешний API
• Ошибки: коэффициенты ошибок для запросов на обслуживание
• Насыщение: количество используемых ресурсов, зависящих от учетной записи (экземпляры, запросы API и т.п.).

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

Метрики общей функциональности и комплексного опыта

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

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

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

• Задержка: время для выполнения пользовательских запросов
• Трафик: количество запросов пользователей в секунду
• Ошибки: ошибки, возникающие при обработке клиентских запросов или доступе к ресурсам
• Насыщение: процент или количество используемых ресурсов

Значения, которые выходят за пределы допустимых диапазонов для этих метрик, вероятно, указывают на непосредственное воздействие пользователей. Задержка, не соответствующая клиентским или внутренним SLA (service level agreements), и трафик, который показывает серьезный скачок, увеличивают частоту ошибок. Точные метрики на этом уровне могут многое сказать о доступности, производительности и надежности вашего приложения.

Заключение

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

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