Измерение влияния сбоя с помощью рабочей книги Azure Monitor

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

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

Создайте вашу книгу анализа ошибок

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

  1. Перейдите к Azure Monitor на портале Azure.

  2. Выберите Рабочие книги из меню слева.

  3. Нажмите + Новый, чтобы создать пустую рабочую книгу.

  4. Для повторного использования книги в разных экспериментах необходимо добавить параметры. Нажмите кнопку +Добавить и выберите "Добавить параметры".

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

    • Подписка (задать "Обязательный")
    • ResourceGroup (Задать "Обязательный")
    • TargetResource (set "Required")

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

  6. Теперь вы добавите первую диаграмму метрик, чтобы визуализировать влияние. Нажмите кнопку +Добавить и выберите "Добавить метрику".

  7. Настройте диаграмму метрик с помощью созданных параметров:

    • Source: Azure
    • Тип ресурса: виртуальные машины
    • Подписка: выберите параметр "Параметр" и выберите параметр подписки
    • Группа ресурсов: выберите параметр "Параметр" и выберите параметр ResourceGroup
    • Ресурс: выберите параметр "Параметр" и выберите параметр TargetResource

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

  9. Нажмите кнопку "Готово редактирование" , а затем сохраните книгу с описательным именем, например "Панель мониторинга анализа экспериментов Хаоса".

Теперь можно добавить дополнительные диаграммы метрик для других типов ресурсов (например, службы приложений, AKS, Cosmos DB), повторяя шаги 7-9 и изменяя тип ресурса. Этот модульный подход позволяет создать комплексную панель мониторинга, которая охватывает все ресурсы, участвующие в экспериментах хаоса.

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

ошибки, связанных с агентами

Целевой ресурс: виртуальная машина или масштабируемый набор виртуальных машин

Наименование ошибки Рекомендуемые метрики Azure Monitor Notes
Давление ЦП Percentage CPU, CPU Credits Remaining Отслеживайте повышение нагрузки на ЦП до настроенного уровня.
Давление физической или виртуальной памяти Available Memory Bytes, Percentage Memory Доступная память должна значительно сократиться.
Давление ввода-вывода диска OS Disk Read Bytes/sec OS Disk Write Bytes/sec OS Disk Queue Depth Data Disk Latency Ожидается пик операций ввода-вывода и задержки.
Завершение процесса / Остановка службы Уровень приложения: Http Server Errors (5xx), Response Time.
Уровень платформы: Percentage CPU (может отпасть).		 Метрики платформы не отображают один процесс. Найдите вторичные эффекты.
Сетевое отключение Network In Total Network Out Total Outbound Flows Inbound Flows Трафик должен отпасть до нуля во время сбоя.
Задержка сети Уровень платформы: Outbound Flows RTT (Наблюдатель за сетями).
Уровень приложения: Dependency Duration, Response Time.		 Ожидается четкое увеличение времени полного цикла или времени вызова зависимостей.
Потеря пакетов в сети TCP Segments Retransmitted, Outbound Packets Dropped Эти метрики указывают, что сетевой стек активнее перепосылает потерянные данные.
Сбой DNS Уровень приложения: Dependency call failure rate (из Application Insights). Наиболее отчетливо это наблюдается на уровне приложения, когда оно пытается и не может разрешить DNS-имена.
Изменение времени (Нет прямой метрики) Проверьте влияние, проверяя журналы приложений или гостевой ОС на ошибки временного отклонения.
Произвольный стресс-ng Стрессор (зависит) Используйте метрику, соответствующую включенной стрессору.

ошибки Azure Kubernetes Service (AKS)

Целевой ресурс: кластер AKS (Метрики, которые обычно просматриваются с помощью Аналитики контейнеров)

Название сбоя Рекомендуемые метрики Azure Monitor Notes
Pod Chaos kube_pod_container_status_restarts_total, kube_deployment_status_replicas_ready, kube_pod_status_ready Ищите увеличение количества перезапусков pod или снижение числа готовых pod.
Сетевой хаос ingress_controller_request_duration_seconds(задержка), node_network_in_bytesnode_network_out_bytes Задержки увеличивают длительность запроса.
Стресс-Хаос Container CPU Usage Percentage, Container Memory Working Set Bytes, node_cpu_usage_percentage Ищите скачки в использовании ресурсов на уровне контейнера и/или узла.
Хаос ввода-вывода node_disk_io_time_seconds_total, node_disk_read_bytes_total Эти метрики уровня узла показывают увеличение активности ввода-вывода и задержки.
DNS Chaos Prometheus: coredns_dns_request_failures_total.
Уровень приложения: Dependency call failure rate.		 Лучше всего наблюдается в CoreDNS кластера или на уровне приложения.
HTTP Chaos ingress_controller_requests (с размерностью кода состояния), Http Server Errors, apiserver_current_inflight_requests Обратите внимание на увеличение количества ошибок HTTP 5xx или неудачных запросов.

Ошибки paaS и других ресурсов

Категория сбоя Имя сбоя Целевой тип ресурса Рекомендуемые метрики Azure Monitor
Служба приложений Остановка службы приложений App Service Http 5xx Requests Response Time Health check status
Autoscale Отключение автомасштабирования Параметры автомасштабирования Virtual Machine Scale Set Instance Count (без увеличения), Average Percentage CPU (рост)
Кэш для Redis Перезагрузка узла кэша Кэш Azure для Redis Connected Clients(падение), Server Load(пик), Errors(тип: отработка отказа), Cache Latency
Cosmos DB Переключение на резервный сервер Cosmos DB Учетная запись Cosmos DB Server Side Latency, Total Requests (по StatusCode), Throttled RequestsService Availability
Центры событий Изменить состояние центра событий Пространства имен Центров событий Incoming Requests Throttled Requests User Errors Active Connections
Key Vault Запрет доступа и отключение сертификата Хранилище ключей Availability, Service Api Latency, Service Api Results (по типу результата)
Network Правило безопасности NSG Группа безопасности сети На затронутой виртуальной машине: Inbound/Outbound Flows
В журналах потоков NSG: [Rule Name]_Denied_Packets
служебная шина Изменение состояния очереди пространство имен служебная шина Incoming Messages User Errors Server Errors Active Messages
виртуальная машина Завершение работы и повторное развертывание виртуальной машины Виртуальная машина VM Availability, Percentage CPU (падение до нуля), Network In/Out Total
VM Scale Set (Масштабируемый набор виртуальных машин) Завершение работы VMSS Масштабируемый набор виртуальных машин Virtual Machine Scale Set Instance Count, Instance-level Percentage CPU

Orchestration

Название ошибки Notes
Запуск и остановка нагрузочного теста Это не ошибка. За метриками необходимо следить на ресурсах, предназначенных для службы Нагрузочное тестирование Azure.
Delay Это действие, в котором требуется ожидание. Он не имеет прямого влияния на метрики, но используется для управления временем выполнения шагов эксперимента.
  • Last updated on