Моделирование работоспособности и наблюдаемость критически важных рабочих нагрузок в Azure

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

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

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

Важно!

Эта статья входит в серию критически важных рабочих нагрузок Azure Well-Architected . Если вы не знакомы с этой серией, рекомендуем начать с критически важной рабочей нагрузки?

Существует три main уровня операционной зрелости при стремлении к максимальной надежности.

  1. Обнаружение проблем и реагирование на них по мере их возникновения.
  2. Диагностируйте проблемы, которые возникли или уже возникли.
  3. Прогнозирование и предотвращение проблем до их возникновения.

Видео. Определение модели работоспособности для критически важной рабочей нагрузки

Работоспособности многоуровневого приложения

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

Важно!

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

Рекомендации по проектированию

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

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

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

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

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

    • Такие ошибки могут наблюдаться не сразу.

Рекомендации по проектированию

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

    • Модель работоспособности должна быть многоуровневой и отражать структуру приложения.
    • Базовый уровень должен учитывать отдельные компоненты приложения, такие как ресурсы Azure.
    • Базовые компоненты следует агрегировать вместе с ключевыми нефункциональными требованиями, чтобы создать контекстуализированный бизнес-контекст в работоспособности системных потоков.
    • Системные потоки должны агрегироваться с соответствующими весами на основе важности бизнеса, чтобы создать понятное определение общей работоспособности приложения. Следует уделить приоритетное внимание финансово значимым потокам пользователей или потокам пользователей для клиентов.
    • Каждый уровень модели работоспособности должен фиксировать то, что представляют состояния "работоспособный" и "неработоспособный".
    • Убедитесь, что модель работоспособности может различать временные и не временные неработоспособные состояния, чтобы изолировать снижение работоспособности службы от недоступности.
  • Представление состояний работоспособности с помощью детализированной оценки работоспособности для каждого отдельного компонента приложения и каждого потока пользователя путем агрегирования оценок работоспособности для сопоставленных зависимых компонентов с учетом ключевых нефункционирующих требований в качестве коэффициентов.

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

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

  • Используйте модель работоспособности в конвейерах CI/CD и циклах тестирования для проверки работоспособности приложения после обновления кода и конфигурации.

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

    • Определите процесс постоянной оценки и точной настройки точности модели и рассмотрите возможность инвестирования в модели машинного обучения для дальнейшего обучения модели.

Пример многоуровневой модели работоспособности

Это упрощенное представление многоуровневой модели работоспособности приложения для наглядности. Комплексная и контекстуализированная модель работоспособности предоставляется в эталонных реализациях Mission-Critical:

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

Критически важные примеры определений работоспособности

Это определение работоспособности впоследствии может быть представлено запросом KQL, как показано в примере запроса ниже, который объединяет InsightsMetrics (Аналитика контейнеров) и AzureMetrics (диагностика параметр для кластера AKS) и сравнивает (внутреннее соединение) с порогами работоспособности модели.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

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

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

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

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

Визуализация модели работоспособности критически важный

Демонстрационный видеоролик. Демонстрация мониторинга и моделирования работоспособности

Единый приемник данных для коррелированного анализа

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

Единый приемник данных необходим, чтобы обеспечить быстрое хранение всех операционных данных и их доступность для коррелированного анализа, чтобы создать представление работоспособности приложения в одной панели. Azure предоставляет несколько различных операционных технологий в рамках Azure Monitor, а рабочая область Log Analytics служит основным приемником данных Azure для хранения и анализа операционных данных.

Сбор критически важных данных о работоспособности

Рекомендации по проектированию

Azure Monitor

  • Azure Monitor включен по умолчанию для всех подписок Azure, но журналы Azure Monitor (рабочая область Log Analytics) и ресурсы Application Insights должны быть развернуты и настроены для включения возможностей сбора данных и запросов.

  • Azure Monitor поддерживает три типа данных наблюдаемости: журналы, метрики и распределенные трассировки.

    • Журналы хранятся в рабочих областях Log Analytics, основанных на Data Explorer Azure. Запросы к журналам хранятся в пакетах запросов, которые можно совместно использовать в разных подписках, и используются для управления компонентами наблюдаемости, такими как панели мониторинга, книги или другие средства создания отчетов и визуализации.
    • Метрики хранятся во внутренней базе данных временных рядов. Для большинства ресурсов Azure метрики автоматически собираются и хранятся в течение 93 дней. Данные метрик также можно отправлять в рабочую область Log Analytics с помощью параметра диагностики для ресурса.
  • Все ресурсы Azure предоставляют журналы и метрики, но ресурсы должны быть правильно настроены для маршрутизации диагностических данных в нужный приемник данных.

Совет

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

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

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

  • Данные можно архивировать или экспортировать из рабочих областей Log Analytics для долгосрочного хранения и (или) аудита.

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

  • Рабочие области Log Analytics развертываются в указанном регионе Azure.

  • Чтобы защититься от потери данных из-за недоступности рабочей области Log Analytics, ресурсы можно настроить с помощью нескольких параметров диагностики. Каждый параметр диагностики может отправлять метрики и журналы в отдельную рабочую область Log Analytics.

    • За данные, отправляемые в каждую дополнительную рабочую область Log Analytics, взимается дополнительная плата.
    • Избыточная рабочая область Log Analytics может быть развернута в одном регионе Azure или в отдельных регионах Azure для обеспечения дополнительной региональной избыточности.
    • Отправка журналов и метрик из ресурса Azure в рабочую область Log Analytics в другом регионе приведет к затратам на исходящий трафик данных между регионами.
    • Для некоторых ресурсов Azure требуется рабочая область Log Analytics в том же регионе, что и сам ресурс.
    • Дополнительные варианты доступности для рабочей области Log Analytics см. в статье Рекомендации по работе с журналами Azure Monitor .
  • Данные рабочей области Log Analytics можно экспортировать в службу хранилища Azure или Центры событий Azure непрерывно, по расписанию или разово.

    • Экспорт данных обеспечивает долгосрочное архивирование данных и защищает от возможной потери операционных данных из-за недоступности.
    • Доступными назначениями экспорта являются служба хранилища Azure или Центры событий Azure. Службу хранилища Azure можно настроить для различных уровней избыточности , включая зональные или региональные. Экспорт данных в службу хранилища Azure сохраняет данные в JSON-файлах.
    • Назначения экспорта данных должны находиться в том же регионе Azure, что и рабочая область Log Analytics. Назначение экспорта данных концентратора событий, которое будет находиться в том же регионе, что и рабочая область Log Analytics. Центры событий Azure геоизбыточное аварийное восстановление неприменимо для этого сценария.
    • Существует несколько ограничений на экспорт данных. Экспорт данных поддерживается только для определенных таблиц в рабочей области .
    • Архивирование можно использовать для хранения данных в рабочей области Log Analytics для долгосрочного хранения по сниженным затратам без их экспорта.
  • Журналы Azure Monitor имеют ограничения регулирования пользовательских запросов, которые могут выглядеть как снижение доступности для клиентов, например панели мониторинга наблюдаемости.

    • Пять одновременных запросов на пользователя: если пять запросов уже выполняются, дополнительные запросы помещаются в очередь параллелизма для каждого пользователя до тех пор, пока не завершится выполнение запроса.
    • Время в очереди параллелизма: если запрос находится в очереди параллелизма более трех минут, он будет завершен и возвращается код ошибки 429.
    • Ограничение глубины очереди параллелизма: очередь параллелизма ограничена 200 запросами, а дополнительные запросы будут отклонены с кодом ошибки 429.
    • Ограничение скорости запросов: для каждого пользователя существует ограничение в 200 запросов в 30 секунд во всех рабочих областях.
  • Пакеты запросов — это ресурсы Azure Resource Manager, которые можно использовать для защиты и восстановления запросов журналов, если рабочая область Log Analytics недоступна.

    • Пакеты запросов содержат запросы в формате JSON и могут храниться за пределами Azure, как и другие ресурсы инфраструктуры как кода.
      • Развертывается с помощью REST API Microsoft.Insights.
      • Если необходимо повторно создать рабочую область Log Analytics, пакет запросов можно повторно развернуть из определения, хранящегося извне.
  • Application Insights можно развернуть в модели развертывания на основе рабочей области, в основе которой лежит рабочая область Log Analytics, в которой хранятся все данные.

  • В Application Insights можно включить выборку, чтобы сократить объем отправленных данных телеметрии и оптимизировать затраты на прием данных.

  • Плата за все данные, собираемые Azure Monitor, включая Application Insights, взимается в зависимости от объема принимаемых данных и длительности хранения данных.

    • Данные, переданные в рабочую область Log Analytics, могут храниться без дополнительной платы в течение первых 31 дня (90 дней, если включена служба Sentinel).
    • Данные, передаваемые в Application Insights на основе рабочей области, хранятся в течение первых 90 дней без дополнительной платы.
  • Модель ценообразования уровня обязательств Log Analytics обеспечивает снижение затрат и прогнозируемый подход к сбору данных.

    • Плата за использование выше уровня резервирования взимается по той же цене, что и для текущего уровня.
  • Log Analytics, Application Insights и Azure Data Explorer использовать язык запросов Kusto (KQL).

  • Запросы Log Analytics сохраняются как функции в рабочей области Log Analytics (savedSearches).

Рекомендации по проектированию

  • Используйте рабочую область Log Analytics в качестве единого приемника данных для предоставления единой панели во всех рабочих наборах данных.

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

  • Используйте Application Insights в качестве согласованного средства мониторинга производительности приложений (APM) для всех компонентов приложения для сбора журналов приложений, метрик и трассировок.

    • Разверните Application Insights в конфигурации на основе рабочей области, чтобы убедиться, что каждая региональная рабочая область Log Analytics содержит журналы и метрики как из компонентов приложения, так и из базовых ресурсов Azure.
  • Используйте запросы между рабочими областями для поддержки единой "единой панели" в разных рабочих областях.

  • Используйте пакеты запросов для защиты запросов к журналам в случае недоступности рабочей области.

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

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

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

    • Настоятельно рекомендуется использовать службу хранилища Azure в конфигурации GRS для долгосрочного хранения операционных данных.
      • Используйте возможность экспорта рабочей области Log Analytics для экспорта всех доступных источников данных в службу хранилища Azure.
  • Выберите подходящие сроки хранения для операционных типов данных в Log Analytics, настроив более длительные сроки хранения в рабочей области, где существуют "горячие" требования к наблюдаемости.

  • Используйте Политика Azure, чтобы убедиться, что все региональные ресурсы направляют операционные данные в правильную рабочую область Log Analytics.

Примечание

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

Если требуется интеграция SIEM, не отправляйте необработанные записи журнала, а отправляйте критические оповещения.

  • Настраивайте выборку в Application Insights, только если она требуется для оптимизации производительности или если выборка не становится слишком затратной.

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

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

    • Код приложения должен использовать Application Insights для упрощения распределенной трассировки, предоставляя вызывающей объекту исчерпывающее сообщение об ошибке, включающее идентификатор корреляции при возникновении сбоя.
  • Используйте структурированное ведение журнала для всех сообщений журнала.

  • Добавьте значимые пробы работоспособности во все компоненты приложения.

    • При использовании AKS настройте конечные точки работоспособности для каждого развертывания (pod), чтобы Kubernetes правильно определял, когда модуль pod работоспособен или неработоспособен.
    • При использовании Служба приложений Azure настройте проверки работоспособности таким образом, чтобы операции горизонтального увеличения масштаба не приводили к ошибкам, отправляя трафик на экземпляры, которые еще не готовы, и проверяя, что неработоспособные экземпляры быстро перезапускаются.

Если приложение подписано на службу поддержки Microsoft Mission-Critical, рассмотрите возможность предоставления ключевых проб работоспособности служба поддержки Майкрософт, чтобы можно было точнее моделировать работоспособность приложения с помощью служба поддержки Майкрософт.

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

  • Не настраивайте рабочие области Log Analytics для применения ежедневного ограничения, которое ограничивает ежедневный прием операционных данных, так как это может привести к потере критически важных операционных данных.

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

  • Настоятельно рекомендуется хранить запросы Log Analytics с помощью системы управления версиями и использовать автоматизацию CI/CD для их развертывания в соответствующих экземплярах рабочей области Log Analytics.

Визуализация

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

Корпорация Майкрософт предоставляет несколько технологий визуализации данных, включая панели мониторинга Azure, Power BI и Azure Managed Grafana (в настоящее время находится в предварительной версии). Панели мониторинга Azure предоставляют тесно интегрированное встроенное решение для визуализации операционных данных в Azure Monitor. Поэтому она играет фундаментальную роль в визуальном представлении операционных данных и работоспособности приложений для критически важной рабочей нагрузки. Однако существует несколько ограничений с точки зрения позиционирования панелей мониторинга Azure как целостной платформы наблюдаемости, и в результате следует учитывать дополнительное использование ведущих на рынке решений для наблюдения, таких как Grafana, которое также предоставляется в качестве управляемого решения в Azure.

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

Рекомендации по проектированию

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

  • Запросы для получения операционных данных, используемых для вычисления и представления оценок работоспособности, можно создавать и выполнять в Log Analytics или Azure Data Explorer.

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

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

  • Если несколько пользователей используют панели мониторинга в средстве, например Grafana, количество запросов, отправленных в Log Analytics, быстро увеличивается.

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

Рекомендации по проектированию

  • Соберите и представите запрашиваемые выходные данные из всех региональных рабочих областей Log Analytics и глобальной рабочей области Log Analytics, чтобы создать единое представление о работоспособности приложения.

Примечание

При развертывании в целевой зоне Azure рекомендуется запрашивать центральную рабочую область Log Analytics платформы , если существуют ключевые зависимости от ресурсов платформы, например ExpressRoute для локального взаимодействия.

  • Модель "светофора" должна использоваться для визуального представления "работоспособных" и "неработоспособных" состояний. Зеленый цвет используется для демонстрации полного выполнения ключевых нефункционирующих требований и оптимального использования ресурсов. Используйте "Зеленый", "Желтый" и "Красный" для обозначения состояний "Работоспособно", "Понижено" и "Недоступно".

  • Панели мониторинга Azure используются для создания операционных линз для глобальных ресурсов и региональных меток развертывания, представляющих ключевые метрики, такие как количество запросов для Azure Front Door, задержка на стороне сервера для Azure Cosmos DB, входящие и исходящие сообщения для Центров событий, а также загрузка ЦП или состояния развертывания для AKS. Панели мониторинга должны быть адаптированы для повышения операционной эффективности, включив в них знания из сценариев сбоев, чтобы команды DevOps могли напрямую видеть ключевые метрики.

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

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

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

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

      • Развертывание экземпляров Служба приложений в рассматриваемых регионах развертывания.

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

    • Используйте службу хранилища Azure в конфигурации GRS для размещения пользовательских визуальных элементов и подключаемых модулей и управления ими.

    • Разверните службу приложений и базу данных реплика компонентов Grafana как минимум в двух регионах развертывания и рассмотрите возможность использования модели, в которой Grafana развертывается во всех рассматриваемых регионах развертывания.

Для сценариев, >предназначенных для 99,99 % SLO, Grafana следует развернуть как минимум в трех регионах развертывания, чтобы обеспечить максимальную общую надежность ключевых операционных панелей мониторинга.

  • Уменьшите ограничения запросов Log Analytics, объединяя запросы в один или небольшое количество запросов, например с помощью оператора объединения KQL, и задайте соответствующую частоту обновления на панели мониторинга.

    • Соответствующая максимальная частота обновления будет зависеть от количества и сложности запросов к панели мониторинга; требуется анализ реализованных запросов.
  • Если достигается ограничение одновременных запросов Log Analytics, рассмотрите возможность оптимизации шаблона извлечения путем (временно) хранения данных, необходимых для панели мониторинга, в высокопроизводительном хранилище данных, таком как Azure SQL.

Автоматизированное реагирование на инциденты

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

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

Важно!

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

Рекомендации по проектированию

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

  • Оповещения можно определить в Log Analytics или Azure Monitor для определенного ресурса.

  • Некоторые метрики можно запросить только в Azure Monitor, так как не все точки диагностических данных доступны в Log Analytics.

  • API оповещений Azure Monitor можно использовать для получения активных и исторических оповещений.

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

    • Существуют ограничения на количество настраиваемых правил генерации оповещений.
    • API оповещений имеет ограничения регулирования, которые следует учитывать при экстремальных сценариях использования.
    • Группы действий имеют несколько жестких ограничений на количество настраиваемых ответов, которые должны быть разработаны.
      • Каждый тип ответа имеет ограничение в 10 действий, помимо электронной почты, которое имеет ограничение в 1000 действий.
  • Оповещения можно интегрировать в многоуровневую модель работоспособности, создав правило генерации оповещений для сохраненного запроса поиска по журналам из функции оценки "root" модели. Например, использование WebsiteHealthScore и оповещение о числовом значении, представляющее состояние «Неработоспособно».

Рекомендации по проектированию

  • Для создания оповещений, ориентированных на ресурсы, создайте правила генерации оповещений в Azure Monitor, чтобы обеспечить доступность всех диагностических данных для условий правила генерации оповещений.

  • Консолидация автоматизированных действий в рамках минимального количества групп действий в соответствии с командами обслуживания для поддержки подхода DevOps.

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

  • Смоделируйте действия для размещения приоритетных заказов, которые должны определяться влиянием на бизнес.

  • Используйте API оповещений Azure Monitor для сбора исторических оповещений для включения в "холодное" операционное хранилище для расширенной аналитики.

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

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

  • Проводите тесты готовности к работе в рамках процессов CI/CD, чтобы проверить ключевые правила генерации оповещений для обновлений развертывания.

Прогнозные действия и операции ИИ (AIOps)

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

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

Критически важные методологии AIOps— критически

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

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

Рекомендации по проектированию

  • Azure Synapse Analytics предлагает несколько возможностей машинного обучения.

    • Модели машинного обучения можно обучать и запускать в пулах Synapse Spark с библиотеками, включая MLLib, SparkML и MMLSpark, а также популярными библиотеками с открытым кодом, такими как Scikit Learn.
    • Модели машинного обучения можно обучить с помощью распространенных средств обработки и анализа данных, таких как PySpark/Python, Scala или .NET.
  • Synapse Analytics интегрирована с Машинным обучением Azure с помощью записных книжек Azure Synapse, что позволяет обучать модели машинного обучения в рабочей области Машинного обучения Azure с помощью автоматизированного машинного обучения.

  • Synapse Analytics также предоставляет возможности машинного обучения с помощью Azure Cognitive Services для решения общих проблем в различных областях, таких как обнаружение аномалий. Cognitive Services можно использовать в Azure Synapse, Azure Databricks, а также с помощью пакетов SDK и REST API в клиентских приложениях.

  • Azure Synapse изначально интегрируется с средствами Фабрика данных Azure для извлечения, преобразования и загрузки (ETL) или приема данных в конвейерах оркестрации.

  • Azure Synapse позволяет регистрировать внешние наборы данных для данных, хранящихся в хранилище BLOB-объектов Azure или Azure Data Lake Storage.

    • Зарегистрированные наборы данных можно использовать в задачах аналитики данных пула Synapse Spark.
  • Azure Databricks можно интегрировать в конвейеры Azure Synapse Analytics для дополнительных возможностей Spark.

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

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

    • Для сценариев AIOps, таких как выполнение прогнозов регрессии или деградации в конвейере CI/CD, может потребоваться оценка в режиме реального времени .
  • Существуют ограничения подписки на Azure Synapse, которые должны быть полностью понятны в контексте методологии AIOps.

  • Чтобы полностью внедрить AIOps, необходимо регулярно передавать данные о наблюдаемости практически в реальном времени в модели вывода машинного обучения в режиме реального времени.

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

Рекомендации по проектированию

  • Убедитесь, что все ресурсы Azure и компоненты приложения полностью инструментированы, чтобы для обучения модели AIOps был доступен полный рабочий набор данных.

  • Прием операционных данных Log Analytics из глобальных и региональных учетных записей хранения Azure в Azure Synapse для анализа.

  • Используйте API оповещений Azure Monitor для получения исторических оповещений и их хранения в холодном хранилище, чтобы операционные данные впоследствии использовались в моделях машинного обучения. Если используется экспорт данных Log Analytics, храните исторические данные оповещений в той же учетной записи хранения Azure, что и экспортированные данные Log Analytics.

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

  • Убедитесь, что ввод в эксплуатацию модели машинного обучения поддерживает как пакетную, так и оценку в режиме реального времени.

  • По мере создания моделей AIOps реализуйте MLOps и применяйте методики DevOps для автоматизации жизненного цикла машинного обучения для обучения, ввода в эксплуатацию, оценки и непрерывного улучшения. Создание итеративного процесса CI/CD для моделей AIOps ML.

  • Оцените Azure Cognitive Services для конкретных прогнозных сценариев из-за низкой нагрузки на администрирование и интеграцию. Рассмотрите возможность обнаружения аномалий , чтобы быстро пометить непредвиденные дисперсии в потоках данных наблюдаемости.

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

Ознакомьтесь с рекомендациями по развертыванию и тестированию.