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

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

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

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

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

Определения

Использование метрик на основе процентиля

Измеряйте метрики производительности, такие как задержка, время отклика или время загрузки, с процентилями (p50, p95, p99), а не средними значениями. Средние показатели могут быть вводящими в заблуждение. Если большинство запросов быстрые, но некоторые очень медленные, среднее значение будет скрывать негативный опыт.

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

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

Определение границ улучшения производительности

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

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

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

Сегментирование сигналов по среде и назначению

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

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

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

Создание оповещений о производительности с областью действия

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

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

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

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

Мониторинг эластичности

Измерение того, как система реагирует на изменения спроса и события масштабирования.

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

Отслеживание производительности с течением времени

Отслеживайте, как производительность развивается с изменениями в проектировании и внешних факторах.

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

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

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

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

Сбор данных о производительности приложения

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

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

Захват трех основных типов сигналов производительности:

• Метрики для статистического поведения производительности (распределение задержки, пропускная способность, скорость ошибок)
• Трассировки для понимания распределения времени между путями запроса и системными компонентами
• Журналы для подробного контекста выполнения при определенных шагах или событиях

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

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

Сбор данных о производительности ресурсов

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

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

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

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

Сбор данных из баз данных и систем хранения

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

Сосредоточьтесь на ключевых измерениях производительности:

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

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

Сбор данных о производительности операционной системы

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

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

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

Создание искусственных данных при необходимости

Если система не используется последовательно, трудно определить, будет ли она работать хорошо при возврате трафика.

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

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

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

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

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

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

База данных и хранилище. Azure Monitor обеспечивает встроенный мониторинг для баз данных SQL Azure, MySQL, PostgreSQL и служб хранения. Аналитика хранилища Azure отслеживает ключевые показатели производительности, такие как пропускная способность и задержка в хранилищах объектов Blob, таблиц и очередей.

Оповещения и анализ. Создание правил генерации оповещений с настраиваемыми пороговыми значениями, окнами времени и действиями (электронная почта, веб-перехватчики, функции Azure). Используйте журналы Azure Monitor для перекрестного запроса и сопоставления данных о производительности. Сведения о ценах см. в разделе о ценах На Azure Monitor.

Примеры

• Базовое высокодоступное веб-приложение служб приложений с зональной избыточностью
• Следить за приложением микрослужб в службе Azure Kubernetes (AKS)
• Мониторинг компонентов целевой зоны платформ Azure

Связанные ссылки

• Метрики платформы
• Параметры диагностики
• Журналы аудита

Контрольный список по обеспечению эффективности процессов

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