Стратегии архитектуры для мониторинга надежности рабочей нагрузки

Применяется к этой рекомендации по контрольным спискам надежности Azure Well-Architected Framework:

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

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

Основные стратегии, описанные в этой статье, опирались на базовую операционную практику наблюдаемости, описанную в стратегиях архитектуры OE:07 для разработки системы мониторинга. Руководство по реализации практики мониторинга доступно в руководстве по проектированию мониторинга. Сначала рекомендуется просмотреть эти ресурсы.

Определения

Мониторинг функциональных возможностей рабочей нагрузки

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

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

Мониторинг взаимодействия с пользователем

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

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

Отслеживание целевых показателей доступности

Отслеживайте, насколько хорошо ваша система соответствует заданным целям доступности, пропускной способности и времени отклика. Эти целевые показатели часто формализованы как соглашения об уровне обслуживания (СОГЛАШЕНИЯ об уровне обслуживания) и цели уровня обслуживания (SLOS) и отражают ожидания, заданные пользователями. Мониторинг в отношении них согласуется с реальными бизнес-результатами, обеспечивая надежность. Дополнительные сведения см. в разделе "Целевые показатели надежности " и "Соглашения об уровне обслуживания".

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

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

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

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

Отслеживание целевых показателей восстановимости

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

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

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

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

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

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

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

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

Мониторинг всех уровней системы

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

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

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

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

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

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

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

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

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

Подробное отслеживание каждого слоя рассматривается в руководстве по проектированию мониторинга.

Определение и мониторинг вместимости штампа

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

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

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

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

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

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

Обнаружение режимов сбоя

В рамках упражнения по анализу режима сбоя (FMA) необходимо определить потенциальные точки сбоя.

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

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

Сведения о FMA см. в стратегиях архитектуры для анализа режима сбоя.

Узнайте о состоянии надежности платформы

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

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

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

• Включение служб мониторинга и оповещений облачной платформы, в том числе:

  • Состояние уровня платформы, например Состояние службы Azure.

  • Общее состояние ресурсов, например Состояние ресурсов Azure.

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

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

• Application Insights — это расширение Azure Monitor. Он предоставляет функции мониторинга производительности приложений (APM).

• Аналитика Azure Monitor — это расширенные средства аналитики, которые помогают отслеживать службы Azure, такие как виртуальные машины, службы приложений и контейнеры. Инсайты основаны на Azure Monitor и Log Analytics.

• Azure Monitor для решений SAP — это собственный продукт мониторинга Azure для ландшафтов SAP, работающих в Azure.

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

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

• Рекомендации по работе с несколькими рабочими областями см. в статье "Проектирование архитектуры рабочей области Log Analytics".

Example

Примеры реальных решений мониторинга см. в статье "Мониторинг веб-приложений в Azure" и "Базовая архитектура для кластера Azure Kubernetes Service".

Ссылки на ресурсы сообщества

• Azure Monitor Baseline Alerts (AMBA) — это централизованное хранилище описаний оповещений, которым могут воспользоваться клиенты и партнеры для улучшения их процесса мониторинга путем внедрения Azure Monitor.

Контрольный список надежности

Ознакомьтесь с полным набором рекомендаций.