Моделирование работоспособности для рабочих нагрузок

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

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

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

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

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

Терминология

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

Мы рекомендуем посмотреть это видео, чтобы изучить моделирование состояния здоровья.

Что такое здоровье, моделирование работоспособности и модель работоспособности?

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

Мы рекомендуем представлять состояние системы в одном из трех состояний:

• Работоспособно: работает оптимально и соответствует ожиданиям качества

• Деградация: демонстрирует менее здоровое поведение, что указывает на потенциальные проблемы

• В опасном состоянии: в критическом состоянии и требует немедленного внимания

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

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

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

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

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

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

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

На изображении:

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

  Примечание.

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

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

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

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

Моделирование работоспособности было важно в предыдущем сценарии следующим образом:

• Это улучшило время обнаружения (TTD) и времени для устранения (TTM) путем ускорения изоляции проблем, что привело к более быстрому обнаружению проблем и потенциальных исправлений.

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

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

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

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

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

Схема модели работоспособности

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

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

Например, рассмотрим ресурсы Azure одного типа в вашей рабочей среде.

• Виртуальная машина A запускает приложение, чувствительное к нагрузке на процессор.
• Виртуальная машина B обрабатывает службу с большим объемом памяти.

Определения работоспособности для этих компьютеров отличаются. Метрики использования ЦП, вероятно, влияют на состояние работоспособности виртуальной машины A, и виртуальная машина B может определять приоритеты метрик, связанных с памятью.

Создание модели здоровья

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

Оценка структуры рабочей нагрузки

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

• Компоненты инфраструктуры, такие как вычислительные кластеры и базы данных

• Компоненты приложения, которые выполняются на вычислительных ресурсах и их соответствующих компонентах

• Логические или физические зависимости между компонентами

• Потоки пользователей и системы

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

Контекстуализация с помощью бизнес-требований

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

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

Карта метрик надежности

Найдите соответствующие метрики надежности в проектировании приложения.

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

Определение сигналов здоровья

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

Использование метрик и журналов платформы

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

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

Добавление журналов приложений

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

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

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

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

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

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

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

Реализуйте распределенную трассировку

Реализуйте распределенную трассировку путем сопоставления телеметрии в критически важных системных потоках. Корреляция телеметрии предоставляет аналитические сведения о сквозных транзакциях и является важным для эффективного анализа первопричин (RCA) при возникновении сбоев.

Использование проб работоспособности

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

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

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

Внедрение структурных и функциональных методов мониторинга

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

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

Моделировать дизайн

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

Настройка оповещений, доступных для действий

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

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

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

Визуализация модели

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

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

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

Примите вашу модель здоровья

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

Применимость к различным ролям

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

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

Непрерывная проверка

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

Здоровье организации

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

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

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

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

Тенденции здоровья и ИИ для ИТ-операций

Моделирование работоспособности предоставляет квантифицированные операционные базовые показатели, настроенные на конкретный бизнес-контекст. ИИ для ИТ-операций (AIOps) — это популярный способ повышения эффективности работы. Данные о здоровье — это основная информация для моделей машинного обучения для анализа тенденций здоровья. Например, модели машинного обучения могут:

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

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

Поддержание вашей модели здоровья

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

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

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

Упрощение функций Azure

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

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

Дополнительные ссылки

• Дополнительные сведения о нативных для Azure моделях работоспособности см. в обзоре моделей работоспособности Azure Monitor.
• Сведения о реализации проб работоспособности в ASP.NET см. в разделе "Проверка работоспособности" в ASP.NET Core.
• Сведения о мониторинге метрик см. в статье Общие сведения о метриках Azure Monitor.
• Сведения об использовании Application Insights см. в разделе Application Insights.
• Рекомендации по проектированию и рекомендации, относящиеся к критически важным рабочим нагрузкам, см. в статье Критичные рабочие нагрузки Azure.
• Для практического ознакомления см. Создайте модель работоспособности для критически важной рабочей нагрузки.

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