Project Flash. Использование Azure Работоспособность ресурсов для мониторинга доступности виртуальных машин Azure

Статья
02/12/2024

Azure Работоспособность ресурсов — это одно решение, предлагаемое Flash. Flash — это внутреннее имя проекта, выделенного для создания надежного, надежного и быстрого механизма для мониторинга работоспособности виртуальных машин(виртуальных машин).

В этой статье описывается использование Azure Работоспособность ресурсов для мониторинга доступности виртуальных машин Azure. Общие сведения о решениях Flash см. в обзоре Flash.

Для документации, конкретной для других решений, предлагаемых Flash, выберите в следующих статьях:

Служба работоспособности ресурса Azure

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

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

Первопричины проблем с виртуальными машинами в Azure Работоспособность ресурсов

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

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

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

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

Хотя начальная функция уведомления о простое составляет несколько лет, публикация инструкции о первопричине является новым дополнением. Теперь давайте рассмотрим детали того, как мы наследуем эти первопричины.

Подсистема анализа первопричин

Давайте рассмотрим предыдущий пример и рассмотрим подробные сведения о том, как работает двигатель RCA и технология, лежащая в ее основе. В основе ядра RCA для виртуальных машин лежит azure Data Обозреватель (ADX), служба больших данных, оптимизированная для аналитики телеметрии журналов больших объемов. Azure Data Обозреватель позволяет легко анализировать терабайты телеметрии журналов с устройств и служб, составляющих платформу Azure, объединять их вместе и интерпретировать коррелированные потоки информации, чтобы получить первопричину различных сценариев сбоя. В конечном итоге это процесс разработки многоэтапных данных:

Этап 1. Обнаружение простоя

Первый этап анализа первопричин заключается в определении триггера, в котором выполняется анализ. Для Виртуальные машины мы хотим определить первопричины при неожиданной перезагрузке виртуальной машины, поэтому триггер — это виртуальная машина, переходя из состояния вверх в состояние вниз. Определение этих переходов из телеметрии платформы является простым в большинстве сценариев, но более сложно вокруг определенных типов сбоев инфраструктуры, когда данные телеметрии платформы могут быть потеряны из-за сбоя устройства или потери питания. Для обработки этих классов сбоев требуются другие методы, например отслеживание потери данных в качестве возможного указания на переход доступности виртуальной машины. Azure Data Обозреватель excels in this time of series analysis, и более подробный обзор методов этого процесса можно найти в Microsoft Tech Community: вычисление простоя с помощью функций окон и функций временных рядов в Azure Data Обозреватель.

Этап 2. Анализ корреляции

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

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

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

Этап 3. Назначение первопричин

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

Этап 4. Публикация RCA

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

Дальнейшие действия

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

Следующие шаги

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

Общие сведения о мониторинге Виртуальные машины Azure см. в справочнике по мониторингу виртуальных машин Azure и мониторингу виртуальных машин Azure.

Поделиться через