Мониторинг распределенной архитектуры и микросервисов
Мониторинг системы и инфраструктуры является основной обязанностью оперативных групп всех размеров. На сегодня существует множество стратегий и инструментов для мониторинга серверов, сбора важных данных и реагирования на ошибки и изменения условий в различных средах. Однако по мере развития программных методов и проектов инфраструктуры мониторинг должен адаптироваться для решения новых задач и освещения относительно незнакомой территории.
Ранее в этой серии мануалов мы обсудили основы мониторинга и сбора метрик, а также базовые качества хороших систем мониторинга. Также мы рассмотрели сбор метрик инфраструктуры и приложений и важные сигналы мониторинга для всей инфраструктуры.
В этом мануале речь пойдет о том, как мониторинг и коллекции метрик изменяют распределенные архитектуры и микросервисы. Растущая популярность облачных вычислений, больших кластеров данных и оркестровки заставила профессионалов переосмыслить проектирование мониторинга и найти лучшие способы и инструменты для решения новых проблем. Мы поговорим об отличительных характеристиках новых моделей развертывания и стратегиях, которые можно использовать для удовлетворения этих новых требований.
Какие проблемы создают высокораспределенные архитектуры?
Инфраструктура мониторинга всегда была в той или иной мере распределенной – это необходимо, чтобы моделировать и зеркалировать отслеживаемые системы. Однако многие современные методы разработки (в том числе конструкции на основе микросервисов или контейнеров и взаимозаменяемые, эфемерные вычислительные экземпляры) резко изменили ландшафт мониторинга. Во многих случаях основными особенностями этих улучшений являются те самые факторы, которые усложняют мониторинг. Давайте рассмотрим основные отличия этих методов от традиционных сред, чтобы лучше понять, как это влияет на мониторинг.
Отделение работы от базовых ресурсов
Самые базовые изменения в поведении многих новых систем связаны с появлением новых уровней абстракции для программного обеспечения. Контейнерная технология изменила взаимосвязь между развернутым программным обеспечением и базовой операционной системой. Приложения, развернутые в контейнерах, взаимодействуют с внешним миром, другими программами и операционной системой хоста иначе, чем приложения, развернутые с помощью обычных средств. Абстракции ядра и сети могут привести к разному восприятию операционной среды в зависимости от того, какой слой вы мониторите.
Этот уровень абстракции невероятно полезен во многих отношениях, он позволяет разработчикам создать согласованные стратегии развертывания, упростить миграцию работы между хостами и полностью контролировать среду выполнения приложений. Однако эти новые возможности возникают за счет усложнения отношений с ресурсами.
Увеличение сетевой связи
Одной из общих черт новых парадигм является увеличение зависимости от внутренней сетевой связи для координации и выполнения задач. То, что ранее было областью одного приложения, теперь может распространяться между многими компонентами, которые должны координироваться и обмениваться информацией. Это имеет несколько последствий для инфраструктуры связи и мониторинга.
Во-первых, поскольку эти модели построены на связях между небольшими дискретными сервисами, огромное значение имеет состояние сети. В традиционных, более монолитных архитектурах, координация задач, обмен информацией и систематизация результатов в значительной степени выполнялись в приложениях с обычной логикой программирования или через сравнительно небольшое количество внешних связей. Логический поток высокораспределенных приложений, напротив, использует сеть для синхронизации, проверки работоспособности соседних элементов и передачи информации. Здоровье и производительность сети напрямую влияют на функциональность (гораздо сильнее, чем раньше), а это означает, что для обеспечения правильной работы необходим более интенсивный мониторинг.
Сеть стала более важной, чем прежде, но вместе с этим эффективно мониторить ее состояние становится все сложнее (из-за большого числа участников процесса и отдельных линий связи). Вместо отслеживания взаимодействия между несколькими приложениями необходима правильная связь между десятками, сотнями или тысячами разных точек. Кроме того, растущий объем трафика также создает дополнительную нагрузку на имеющиеся сетевые ресурсы, что еще больше усугубляет необходимость надежного мониторинга.
Разделение функциональности и ответственности
Ранее мы мимоходом упомянули тенденцию современных архитектур делить работу и функциональность между множеством меньших, дискретных компонентов. Эти проекты могут оказывать непосредственное влияние на ландшафт мониторинга.
Для обеспечения хорошего рабочего процесса требуется более надежная оркестровка и инструменты. Однако, поскольку ответственность за выполнение любой задачи фрагментирована и разделена между разными рабочими элементами (потенциально – между многими разными физическими хостами), найти элемент, который вызывает проблемы производительности или ошибки, бывает очень сложно. В такой ситуации визуализация пути запроса или анализ основных причин с использованием традиционных механизмов могут оказаться нецелесообразными.
Эфемерность компонентов
Следующий этап адаптации традиционного мониторинга – разумное отслеживание короткоживущих или эфемерных элементов. Независимо от типа абстракции подобные компоненты часто нарушают некоторые основные механизмы традиционного мониторинга.
Например, чтобы различать ноду, которая прекратила работу в результате сбоя, и экземпляр, который был намеренно уничтожен во время масштабирования, система мониторинга должна иметь более глубокое понимание уровня оркестровки и управления, чем раньше. Во многих современных системах подобные события происходят гораздо чаще, поэтому ручная корректировка домена мониторинга непрактична. Среда развертывания быстрее сменяется, поэтому уровень мониторинга должен принимать новые стратегии, чтобы оставаться ценным.
Еще одни важный вопрос, с которым сталкиваются многие системы – это то, что нужно делать с данными, которые остаются от уничтоженных экземпляров. Рабочие элементы быстро оркеструются для удовлетворения меняющихся требований среды, потому необходимо принять решение о том, что делать с данными, связанными со старыми экземплярами. Данные не обязательно сразу теряют свою ценность только потому, что сгенерировавший их экземпляр больше не существует. Когда приложение меняет сотни или тысячи нод в день, бывает трудно понять, как лучше спроектировать общее работоспособное состояние системы из фрагментированных данных недолговечных экземпляров.
Какие изменения необходимы для масштабирования системы мониторинга?
Теперь, когда мы определили некоторые из важнейших задач распределенных архитектур и микросервисов, мы можем поговорить о том, как системы мониторинга могут работать в рамках этих реалий. Некоторые из решений включают в себя переоценку метрик и выделение наиболее важных их типов. Также можно использовать новые инструменты или новые способы понимания среды.
Детализация и выбор дискретных данных
Увеличение общего объема трафика, вызванное большим количеством сервисов, является одной из самых базовых проблем, о которых стоит подумать. Кроме того, что в новых архитектурах стремительно растет количество операций передачи данных, сам по себе мониторинг может начать опустошать сеть и красть ресурсы хоста. Чтобы лучше справиться с увеличением объема трафика, вы можете либо уменьшить инфраструктуру мониторинга, либо уменьшить разрешение данных, с которыми работаете. Оба подхода заслуживают внимания, но мы сосредоточимся на втором, поскольку он используется чаще.
Изменение частоты дискретизации данных может свести к минимуму количество данных, которые ваша система должна собирать с хостов. Выбор дискретных данных – обычная часть сбора метрик, которая показывает, как часто вы запрашиваете новые значения той или иной метрики. Увеличение интервала уменьшит объем обрабатываемых данных, но также уменьшит и разрешение – уровень детализации данных. Настройка частоты дискретизации данных может оказать глубокое влияние на количество клиентов мониторинга, которых сможет адекватно обслуживать система.
Чтобы снизить потерю информации при настройке более низкого разрешения, вы можете продолжить собирать данные с той же частотой, но скомпилировать их в более удобные объемы для передачи по сети. Отдельные компьютеры могут агрегировать и усреднять метрические значения и отправлять в систему мониторинга сводки. Это может снизить сетевой трафик при сохранении глубины детализации данных. Обратите внимание, это помогает снизить влияние сбора данных на сеть, но не решает проблем, связанных со сбором этих данных внутри хоста.
Принятие решений на основе данных, собранных из нескольких экземпляров
Как упоминалось выше, одним из основных отличий между традиционными системами и современными архитектурами является распределение ролей экземпляров в обработке запросов. В распределенных системах и микросервисах блок работы, вероятно, попадает в пул рабочих экземпляров через какой-то уровень планирования или арбитражный уровень. Это имеет последствия для многих автоматизированных процессов, которые вы можете использовать для мониторинга.
В средах, где используются пулы взаимозаменяемых рабочих юнитов, политики проверки работоспособности и оповещения могут иметь сложные отношения с контролируемой ими инфраструктурой. Проверка работоспособности отдельных рабочих юнитов может использоваться для автоматического вывода из эксплуатации дефектных элементов. Однако если у вас настроена автоматизация, в масштабе большого пула один вышедший из строя веб-сервер не имеет большого значения. Система будет самовосстанавливаться, чтобы поддерживать в активном пуле только здоровые юниты.
Хотя проверка работоспособности хоста позволяет выявлять дефектные элементы, проверка работоспособности всего пула больше подходит для подобной архитектуры. Способность пула обработать текущую рабочую нагрузку имеет большее влияние на пользовательский опыт, чем возможности любого отдельного рабочего элемента. Оповещения, сообщающие о количестве рабочих членов пула, задержке для совокупности пулов или о вероятности сбоя пула, своевременно уведомят операторов о проблемах, которые сложнее смягчить автоматически (такие проблемы, скорее всего, повлияют на пользовательский опыт).
Интеграция с уровнем оркестровки
В общем, уровень мониторинга в распределенных системах должен иметь более полное представление о среде развертывания и механизмах оркестровки. Автоматизированное управление жизненным циклом становится невероятно ценным из-за роста количества отдельных элементов, участвующих в этих архитектурах. Независимо от того, какими являются эти элементы (простыми контейнерами, контейнерами в рамках структуры оркестровки или вычислительными нодами в облачной среде), существует уровень управления, который предоставляет информацию о здоровье и принимает команды для масштабирования и реагирования на события.
Увеличение количества фрагментов в архитектуре увеличивает статистическую вероятность неудачи. При прочих равных условиях такая архитектура потребует большего человеческого вмешательства для реагирования и смягчения этих проблем. Поскольку система мониторинга отвечает за выявление сбоев и ухудшения обслуживания, она сможет устранить многие из этих проблем, если она сможет подключаться к интерфейсам управления платформы. Автоматические ответы программного обеспечения мониторинга помогут поддерживать работоспособность вашей системы.
Эта тесная взаимосвязь между системой мониторинга и платформой развертывания необязательно необходима в других архитектурах. Но автоматизированные распределенные системы поддерживают саморегулирование (с возможностью масштабирования и настройки на основе предварительно сконфигурированных правил и наблюдаемого статуса). Система мониторинга в этом случае играет центральную роль в контроле среды и принятии решений.
Другая причина, по которой система мониторинга должна обладать знаниями об оркестровке, заключается в устранении побочных эффектов эфемерных экземпляров. В средах с большим оборотом рабочих экземпляров система мониторинга зависит от этой информации, потому что она позволяет системе понять, когда действия были намеренными, а когда нет. Например, системы, которые могут считывать события API, могут реагировать по-разному на умышленное уничтожение сервера и на внезапный сбой в его работе. Возможность различать эти события помогает системе мониторинга оставаться полезной, точной и заслуживающей доверия в условиях, где базовая инфраструктура может часто меняться.
Распределенная трассировка
Одним из наиболее сложных аспектов высокораспределенных рабочих нагрузок является понимание взаимодействия между различными компонентами и выделение ответственности при попытке анализа основных причин. Поскольку один запрос может обрабатываться десятком небольших программ, может быть сложно определить узкие места или причины изменения производительности. Для сбора информации о задержке и потреблении ресурсов на обработку появился метод, называемый распределенной трассировкой.
Распределенная трассировка – это подход к инструментальным системам, который добавляет к каждому компоненту код для освещения обработки запроса разными сервисами. Каждому запросу присваивается уникальный идентификатор внутри инфраструктуры, который передается при обработке задачи. Затем каждый сервис использует этот идентификатор, чтобы сообщать об ошибках и метках времени, когда он впервые увидел запрос и когда он передал его на следующий этап. С помощью агрегирования отчетов компонентов с учетом идентификатора запроса в инфраструктуре можно проследить детальный путь с точными данными синхронизации.
Этот метод можно использовать для понимания того, сколько времени тратится на каждую часть процесса, и затем четко определить любые серьезные увеличения задержки. Это дополнительное средство – способ адаптации коллекции показателей к большому количеству компонентов обработки. При визуальном отображении, где время определяется по оси x, вы можете отследить взаимосвязь между различными этапами, длительность каждого процесса и зависимость между событиями, которые должны выполняться параллельно. Это может быть невероятно полезно для понимания того, как улучшить систему и как тратится время на обработку тех или иных задач.
Оптимизация работоспособности распределенных систем
Теперь вы знаете, как распределенные архитектуры могут усложнить анализ работоспособности инфраструктуры. Во многих случаях при этом следует изменить способ реагирования команды разработчиков и способы изучения проблем. Инструменты, собирающие информацию таким образом, чтобы дать вам возможность анализировать ситуацию методично, помогут вам при работе со множеством доступных уровней данных. В этом разделе мы обсудим, как вести себя при устранении неполадок в больших распределенных средах.
Настройка предупреждений для четырех золотых сигналов на каждом уровне
Первый шаг к успешному мониторингу распределенной системы – своевременное выявление проблем. В статье Сбор метрик инфраструктуры и приложений описываются четыре золотых сигнала – индикатора мониторинга, которые команда Google SRE определила как наиболее важные. Вот эти четыре сигнала:
- Задержка
- Трафик
- Коэффициент ошибок
- Насыщение
Это хорошее начало работы с инструментами системы, но количество слоев, которые необходимо отслеживать, в высокораспределенных системах обычно увеличивается. Основная инфраструктура, уровень оркестровки и рабочий уровень нуждаются в надежном мониторинге с продуманными предупреждениями, которые сообщат о важных изменениях. Условия оповещения могут варьироваться по сложности с учетом эфемерных элементов платформы.
Составление полной картины
Когда система замечает аномалию и уведомляет об этом сотрудников, команде необходимо начать сбор данных. Прежде чем действовать, они должны понимать, какие компоненты затронуты, когда начался сбой, какое условие вызвало предупреждение.
Самый надежный способ понять уровень сбоя – начать с самого высокого уровня. Начните проверку с дашбордов мониторинга и визуализации, которые собирают и обобщают информацию ваших систем. Это может помочь вам быстро выявить факторы и понять, с чем сталкивается пользователь. При этом вы должны иметь возможность сравнивать информацию разных компонентов и хостов.
Цель этого этапа – начать инвентаризацию элементов для более детальной проверки и уделить приоритетное внимание исследованию. Если вы можете идентифицировать цепочку связанных проблем, которые затрагивают разные уровни, самый низкий уровень должен иметь наивысший приоритет: исправления базовых уровней часто устраняют проблемы на более высоких уровнях. Список затронутых систем может служить неофициальным контрольным списком мест для проверки и исправления.
Устранение особых проблем
Как только вы почувствуете, что у вас есть разумное и полное представление проблемы, попробуйте собрать более подробную информацию о компонентах и системах в порядке очередности. Подробные метрики отдельных элементов помогут вам проследить маршрут сбоя. Рассматривая более мелкие экземпляры и логи, обратитесь к списку затронутых компонентов, чтобы попытаться понять, как проблема распространяется по системе. В микросервисах количество взаимозависимых компонентов таково, что проблемы чаще распространяются на другие сервисы.
На этом этапе основное внимание уделяется изоляции сервиса, компонента или системы, которая стала источником сбоя, и дальнейшему выявлению конкретной проблемы. Это может быть недавно развернутый код, неисправная физическая инфраструктура, ошибка на уровне оркестровки или изменение рабочей нагрузки, которое система не смогла обработать. Диагностика события позволяет оперативно смягчить проблему и восстановить работоспособность системы.
Смягчение проблем
Определив специфику, вы можете работать над решением или смягчением проблемы. Во многих случаях существует очевидный быстрый способ восстановления сервиса путем увеличения количества ресурсов, отката или перенаправления трафика на альтернативную реализацию. В этих сценариях разрешение будет разбито на три этапа:
- Решение проблемы и восстановление обслуживания.
- Решение основной проблемы для восстановления полной функциональности и работоспособности.
- Полная оценка причин отказа и внедрение долгосрочных исправлений, которые должны предотвратить повторение проблемы.
Во многих распределенных системах избыточность и высокодоступные компоненты гарантируют быстрое восстановление сервиса (хотя в фоновом режиме может потребоваться дополнительная работа для восстановления избыточности или смягчения проблем системы). Вы должны использовать список затронутых компонентов, чтобы определить, устраняет ли первоначальное смягчение проблемы каскад в сбое обслуживания. По мере усложнения система мониторинга также может автоматизировать некоторые из процессов восстановления, отправляя команды на уровень оркестровки, чтобы выявить новые нерабочие экземпляры или вывести их из строя.
Учитывая автоматизацию, доступную на первых двух этапах, наиболее важной задачей команды специалистов является обнаружение основной причины события. Такие знания можно использовать для разработки новых политик для прогнозирования будущих событий и дальнейшей автоматизации реакции системы. Программное обеспечение мониторинга в ответ на каждый сбой часто получает новые возможности, которые позволяют защитить систему от подобных проблем. Вы можете восстановить последовательность событий и определить, где можно улучшить программные процессы и реакцию команды.
Из-за особой сложности, присущей крупным распределенным системам, важно рассматривать процесс решения любого значимого события как возможность изучить и более точно настроить систему. Количество отдельных компонентов и путей коммуникации связано с большой зависимостью от автоматизации и инструментов, которые помогают управлять инфраструктурой. Улучшение кода механизмов реагирования и наборов правил компонентов – лучший способ сохранить контроль системы мониторинга над инфраструктурой.
Заключение
В этом мануале мы поговорили о некоторых конкретных проблемах мониторинга, которые появляются в распределенных архитектурах и микросервисах. Современные способы проектирования систем нарушают некоторые традиционные методы мониторинга, что в свою очередь требует создания новых подходов к обработке подобных конфигурационных сред. Теперь вы знаете, что нужно учитывать при переходе к инфраструктурам, которые работают в эфемерном, облачном или контейнерном режиме, и координации сети большого объема. Также вы знаете способы устранения проблем и сбоев в большой распределенной архитектуре.
