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

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

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

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

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

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

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

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

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

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

http://www.brendangregg.com [Брендан Грегг], влиятельный инженер по производительности, обрисовывает в общих чертах много способов получения основных метрик из систем Linux для удовлетворения потребностей инфраструктуры, которую он называет http://www.brendangregg.com/usemethod .html [ИСПОЛЬЗОВАТЬ метод для анализа производительности] ( u умножение, s атурация и e ошибки). Поскольку существует существенное совпадение между методом USE и четырьмя золотыми сигналами, мы можем использовать некоторые из его рекомендаций в качестве отправной точки для определения того, какие данные собирать с серверных компонентов.

Для измерения * CPU * могут подойти следующие измерения:

Для * memory * сигналы могут выглядеть следующим образом:

Для * запоминающих устройств *:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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