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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первый шаг к тому, чтобы вы могли реагировать на проблемы в своих системах, - это знать, когда они возникают. В нашем руководстве по поиску метрик из вашей инфраструктуры и приложений https://www.digitalocean.com/community/tutorials/gathering-metrics-from-your-infrastructure-and-applications мы представили четыре золотых индикатора мониторинга сигналов. определены командой Google SRE как наиболее важные для отслеживания. Четыре сигнала:

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

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

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

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

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

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

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

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

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

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