Гибридный мониторинг доступности и производительности

В этой эталонной архитектуре показано, как использовать Azure Monitor для мониторинга производительности и доступности рабочих нагрузок операционной системы (ОС), выполняемых на виртуальных машинах. Виртуальные машины могут находиться в Microsoft Azure, в локальных средах или в облаках, отличных от Azure.

Архитектура

Скачайте файл Visio для этой архитектуры.

Рабочий процесс

• Локальный главный офис — виртуальная машина 1. Этот компонент представляет собой веб-приложение с доступом к Интернету и общедоступной веб-страницей, а также установленными агентами Log Analytics и зависимостей. Сведения об агентах см. в обзоре агента Log Analytics и обзоре агентов Azure Monitor, агента зависимостей.
• Локальный главный офис — виртуальная машина 2. Эта среда бизнес-логики не имеет доступа к Интернету. Однако в ней установлены агенты Log Analytics и зависимостей.
• Локальный главный офис — виртуальная машина 3. Этот компонент является хранилищем данных без доступа к Интернету, но с установленными агентами Log Analytics и зависимостей.
• Локальный главный офис — шлюз Log Analytics. Шлюз Log Analytics собирает данные журналов и метрик из трех локальных виртуальных машин и передает их в рабочую область Log Analytics по протоколу TCP через порт 443.
• Локальный главный офис — брандмауэр. Трафик из локальной среды направляется через брандмауэр.
• Шлюз. Шлюз обеспечивает подключение к филиалу.
• Локальный филиал — виртуальная машина 4. Этот компонент — это бизнес-приложение, работающее без доступа к Интернету, но с установленными агентами Log Analytics и зависимостей. Агент Log Analytics, установленный на виртуальной машине, настроен для передачи данных непосредственно в рабочую область Log Analytics без необходимости в шлюзе Log Analytics.
• Локальный филиал — шлюз. Этот шлюз подключает филиал к локальному главному офису через виртуальную частную сеть (VPN).
• Сторонний поставщик облачных служб — виртуальная машина 5. Этот компонент — это веб-приложение с доступом к Интернету, общедоступной веб-страницей, а также установленными агентами Log Analytics и зависимостей.
• Сторонний поставщик облачных служб — виртуальная машина 6. Этот компонент является средой хранилища данных без доступа к Интернету, но с установленными агентами Log Analytics и зависимостей. Нет прямого подключения из сторонних облачных сред к локальным средам.
• Azure — VMSS. Это масштабируемый набор, созданный с помощью Azure Масштабируемые наборы виртуальных машин. Он запускает бизнес-приложение с установленными агентами log analytics и диагностическими агентами.
• Azure — сервер приложений. На этом сервере установлена одна виртуальная машина с бизнес-приложением с установленными агентами Log Analytics и диагностическими агентами.
• Метрики Azure Monitor. Данные, собранные метриками Azure Monitor, хранятся в базе данных временных рядов, оптимизированной для анализа меток времени. Она также хранит метрики, отправляемые из локальных виртуальных машин и виртуальных машин Azure.
• Azure Monitor — рабочая область Log Analytics. Эта рабочая область хранит журналы, отправленные из локальных виртуальных машин, виртуальных машин Azure и виртуальных машин на сторонних поставщиках облачных служб. Рабочая область — это ресурс Azure, в котором данные агрегируются, и она служит административной границей для доступа к этим данным. Другие службы Azure Monitor затем подключаются к рабочей области Log Analytics и используют данные для различных целей. Дополнительные сведения см. в статье "Проектирование развертывания журналов Azure Monitor".
• Azure Monitor — Аналитика — Аналитика приложения. Приложение Аналитика предоставляет анализ приложений и аналитических сведений об их использовании. В этом примере архитектуры проверка связи доступности проверка доступность локального веб-приложения. Правила генерации оповещений включены для предоставления уведомления о неудачном тесте. Дополнительные сведения см. в разделе "Что такое приложение Аналитика?", а также мониторинг доступности любого веб-сайта.
• Azure Monitor — Аналитика — Azure Monitor для виртуальных машин. Azure Monitor для виртуальных машин отслеживает производительность и работоспособность виртуальных машин и масштабируемых наборов виртуальных машин. Мониторинг включает их выполняемые процессы и зависимости от других ресурсов. В этом сценарии Azure Monitor для виртуальных машин предоставляет аналитические сведения о виртуальных машинах. Дополнительные сведения см. в разделе "Что такое Azure Monitor для виртуальных машин?".
• Azure Monitor — анализ. Данные журналов и метрик из виртуальных машин запрашиваются в метриках Azure Monitor и рабочей области Log Analytics с помощью язык запросов Kusto (KQL). Результаты предоставляют аналитические сведения о инфраструктуре, топологии и ресурсах. Дополнительные сведения см. в статье Kusto: Обзор и примеры запросов к журналам Azure Monitor.
• Azure Monitor — визуализации. Azure Monitor использует средства визуализации для просмотра компонентов приложения и инфраструктуры и обмена данными между службами в Azure Monitor. Средства визуализации включают карту приложений в приложение Azure Insights, функцию карты Azure Monitor для виртуальных машин, книг Azure Monitor и различные представления панелей мониторинга, доступные в Azure Monitor. Дополнительные сведения см. в статье "Использование функции карты" Azure Monitor для виртуальных машин для понимания компонентов приложений, создания и совместного использования панелей мониторинга данных Log Analytics и книг Azure Monitor.
• Azure Monitor — интеграции. Azure Monitor интегрируется с различными партнерскими и сторонними инструментами и расширениями. Эти средства и расширения повышают и опираются на существующие функциональные возможности Azure Monitor, такие как анализ и визуализации.
• Azure Monitor — действия — оповещения. Варианты данных метрик и журналов могут указывать на возникновение событий. Правила определяют варианты данных, которые активируют оповещения, предоставляют уведомления и инициируют ответы на исправление. В этой архитектуре при активации оповещения модули Runbook службы автоматизации автоматически устраняют локальные виртуальные машины и виртуальные машины Azure. Также доступны действия веб-перехватчика, интеграция управления службами и другие типы действий. Дополнительные сведения см. в статье "Создание, просмотр и управление оповещениями метрик" с помощью Azure Monitor и создания, просмотра оповещений журналов и управления ими с помощью Azure Monitor.
• Azure Monitor — действия — автомасштабирование. Автомасштабирование добавляет или удаляет экземпляры виртуальных машин в соответствии с deman, что обеспечивает производительность и повышает эффективность затрат. В этой архитектуре автомасштабирование имеет условия, определенные вокруг средней загрузки ЦП (в процентах). При выполнении условий автомасштабирование Azure Monitor настраивает масштабируемый набор в соответствии с требованиями. Дополнительные сведения см. в разделе Общие сведения об автомасштабировании в Microsoft Azure.

Компоненты

Она состоит из следующих компонентов:

• Виртуальные машины Azure
• Azure Monitor
• Политика Azure
• Центры событий Azure
• Хранилище Azure

Рекомендации

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

Рабочая область Log Analytics

При разработке рабочей области Log Analytics следует учитывать следующие рекомендации.

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

видны узлы

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

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

Чтобы собирать пользовательские показатели производительности или метрики для конкретного бизнеса, чтобы обеспечить более подробную аналитику, используйте пользовательские метрики. Дополнительные сведения см. в разделе "Пользовательские метрики" в Azure Monitor (предварительная версия).

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

Анализ и диагностика

Рассмотрим следующие рекомендации по анализу и диагностика:

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

  • Укажите подробные сведения о событиях (по сравнению с метриками).
  • Происходит периодически.
  • Упростите более глубокую диагностика после начального флага метрик.

• Настройка сбора данных журнала (аналогично метрик) с помощью API сборщика данных HTTP для отправки данных журнала в рабочую область Log Analytics. Дополнительные сведения см. в статье "Отправка данных журнала в Azure Monitor" с помощью API сборщика данных HTTP (общедоступная предварительная версия).

• Проанализируйте приложения с помощью функции интеллектуального обнаружения Application Insights. Интеллектуальное обнаружение применяет возможности машинного обучения Azure и статистического анализа для обнаружения таких проблем, как аномалии производительности или сбоя, утечки памяти или общее снижение производительности приложения. Дополнительные сведения см. в разделе "Интеллектуальное обнаружение" в Аналитика приложения.

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

Запросы Log Analytics

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

Установка агента

Автоматическая установка агентов и в масштабе, а не по отдельности с помощью таких параметров автоматизации, как Политика Azure, Azure PowerShell, шаблоны Resource Manager или конфигурация требуемого состояния (DSC). Дополнительные сведения см. в статье "Включить Azure Monitor для виртуальных машин с помощью Политика Azure", "Включить Azure Monitor для виртуальных машин" с помощью Azure PowerShell и включить Azure Monitor для виртуальных машин для гибридной виртуальной машины — требуемая конфигурация состояния.

Информационная панель

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

Рекомендации

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

Надежность

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

Ниже приведены рекомендации по обеспечению доступности в вашей среде.

• Тесты доступности. Тест связи URL-адресов, используемый в этой архитектуре, является самым простым тестом доступности вне сети. Однако другие варианты доступны, например:
  • Многоэтапный веб-тест. Воспроизводит записи последовательно выполняемых веб-запросов для тестирования сложных сценариев. Многошаговые веб-тесты создаются в Microsoft Visual Studio Enterprise, а затем отправляются на портал для выполнения.
  • Пользовательские тесты доступности отслеживания. Используйте метод для отправки TrackAvailability() результатов теста в приложение Аналитика.
• Оповещения. При создании теста доступности в приложении Аналитика уведомления об оповещениях о событиях включены по умолчанию. Правила генерации оповещений можно изменить, указав тип уведомления и сведения из оповещений Azure Monitor>.

Безопасность

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

Ниже приведены рекомендации по обеспечению безопасности среды.

• область Azure Log Analytics. Режимы доступа определяются как один из следующих контекстов:
  • Контекст рабочей области. Все журналы, доступ к которым имеет рабочая область, могут запрашиваться. Это вертикальный подход к доступу. Например, группе безопасности может потребоваться доступ ко всем данным ресурсов сверху вниз.
  • Контекст ресурса. Можно запрашивать только журналы для определенных ресурсов. Например, группе приложений можно предоставить доступ к журналам для конкретного ресурса, над которым они работают.
• Защита данных при передаче в Log Analytics. Данные при передаче защищены с помощью минимального протокола TLS 1.2. Эту функцию не нужно включить явным образом. Дополнительные сведения см. в разделе "Безопасность данных Log Analytics".
• Защита неактивных данных в Log Analytics. Данные неактивных данных в Log Analytics защищены по умолчанию в служба хранилища Azure с помощью 256-разрядного шифрования расширенного шифрования (AES).
• Интеллектуальное обнаружение. Используйте интеллектуальное обнаружение в приложении Аналитика для анализа телеметрии, созданной приложением, и для обнаружения проблем безопасности. Дополнительные сведения см. в пакете обнаружения безопасности приложений (предварительная версия).
• Интеграция Azure Monitor с средствами управления сведениями о безопасности и событиями (SIEM). Перенаправьте данные мониторинга в концентратор событий с помощью Azure Monitor для интеграции внешних средств SIEM и мониторинга. Дополнительные сведения см. в статье Stream Azure monitoring data to an event hub or external partner.

Оптимизация затрат

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

Ниже приведены рекомендации по управлению затратами в вашей среде и управлению ими.

• Azure Monitor. Затраты Azure Monitor основаны на потреблении, часто называются оплатой по мере использования.
• Анализ журналов. Вы оплачиваете прием данных и хранение данных. Вы можете оценить и прогнозировать количество виртуальных машин и объем данных (в гигабайтах), которые будут собираться с каждой виртуальной машины. Типичная виртуальная машина Azure потребляет от 1 гигабайта (ГБ) до 3 ГБ данных каждый месяц. Если вы оцениваете использование данных с помощью журналов Azure Monitor, используйте статистику данных из собственной среды и получите скидку на резервирование емкости.
• Application Insights. Этот компонент оплачивается в соответствии с объемом данных телеметрии, отправляемых приложением, и количество выполняемых веб-тестов.
• Запросы метрик. Запросы метрик выставляются по количеству выполненных вызовов.
• Оповещения. Счета за оповещения выставляются на основе типа и количества отслеживаемых сигналов.
• Уведомления. Счета за уведомления выставляются в соответствии с типом и числом отправляемых уведомлений.
• Azure Monitor. В разделе "Использование и предполагаемые затраты" в Azure Monitor оценивается ежемесячные затраты на основе предыдущих 31 дней использования.
• Дополнительные сведения см. в статье о ценах и калькуляторе цен Azure Monitor.

Эффективность работы

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

Управляемость

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

• Книги Azure. Используйте книги для дальнейшего анализа и создания расширенных отчетов. Книги объединяют текст, запросы журналов, метрики и параметры в интерактивные отчеты. Участники группы с доступом к тем же ресурсам Azure могут изменять книги. Дополнительные сведения см. в статье "Создание интерактивных отчетов Azure Monitor для виртуальных машин с книгами".
• Интеграция партнеров. Интеграция Azure Monitor с партнерскими и сторонними средствами для анализа, визуализации, оповещений или управления службами и Azure Pipelines. Дополнительные сведения см. в статье Интеграция Azure Monitor с продуктами партнеров.
• Интеграция Azure Monitor с Microsoft System Center. Интеграция Azure Monitor с набором продуктов System Center. Дополнительные сведения см. в статье Подключение Operations Manager к Azure Monitor.
• Отправка данных в Центры событий Azure. Чтобы интегрировать Azure Monitor с средствами визуализации и внешнего мониторинга, обратитесь к данным мониторинга Stream Azure в концентратор событий или внешний партнер.
• Шлюз Log Analytics. Для небольших сред, таких как филиал, используйте агент для передачи данных в рабочую область Log Analytics, а не в шлюз. Дополнительные сведения см. в статье "Установка подключения к Azure Log Analytics".

DevOps

Ниже приведены рекомендации по интеграции среды с процессами и решениями DevOps.

• Application Insights. Интеграция приложений Аналитика в Azure Pipelines для повышения производительности и удобства использования. Аналитика приложения могут автоматически обнаруживать аномалии производительности. Он подключается к различным средствам разработки, таким как Azure DevOps Services и GitHub.
• Инструментирование приложений. Инструментирование приложений путем изменения кода приложения для включения телеметрии с помощью приложения Аналитика. Ниже приведены способы инструментирования приложений.
  • Во время выполнения. Инструментирование веб-приложения на сервере во время выполнения идеально подходит для приложений, развернутых уже, так как это позволяет избежать необходимости обновлять код. К подходящим сценариям относятся:
    • Приложения Microsoft ASP.NET или ASP.NET Core, размещенные в Azure веб-приложения
    • ASP.NET приложения, размещенные в Microsoft IIS (IIS) на виртуальной машине или масштабируемом наборе виртуальных машин
    • ASP.NET приложения, размещенные в IIS на локальной виртуальной машине
    • Функции Azure на основе Java
    • приложения Node.JS в Служба приложений Linux
    • Микрослужбы, размещенные в AKS
  • Во время разработки. Добавьте приложение Аналитика в код для настройки сбора данных телеметрии и отправки дополнительных данных. Поддерживаются языки и платформы:
    • Приложения ASP.NET
    • Приложения ASP.NET Core
    • Консольные приложения .NET
    • Java
    • Node.js
    • Python
• Используйте Подключение управления ИТ-службами (ITSMC) для подключения к внешним средствам управления ИТ-службами (ITSM). ITSMC подключает Azure к поддерживаемым продуктам и службам ITSM, где обычно находятся рабочие элементы, связанные с проблемой. Дополнительные сведения см. в статье Подключение Azure в средства ITSM с помощью Подключение управления ИТ-службами.

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

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

Ниже приведены рекомендации по масштабированию среды.

• Автоматизация установки и настройки ресурсов и приложений.
• Крупномасштабные географически распределенные приложения. Используйте распределенную трассировку в Аналитика приложения для отслеживания зависимостей и вызовов между несколькими компонентами приложения, внутренними ресурсами и средами микрослужб. С помощью распределенной трассировки можно отлаживать приложения, которые вызываются через границы процесса за пределами локального стека. (Вам не нужно включить Распределенная трассировка доступна автоматически как часть приложения Аналитика.)
  • Ниже приведены два варианта использования распределенных данных трассировки:
    • Интерфейс диагностика транзакций. Этот интерфейс аналогичен стеку вызовов с добавленным измерением времени. Интерфейс диагностика транзакции обеспечивает видимость одной транзакции или запроса. Оно помогает обнаружить первопричину проблем с надежностью и узких мест производительности для каждого запроса. Дополнительные сведения см. в разделе "Что такое распределенная трассировка"?
    • Интерфейс карты приложений. Это объединяет множество транзакций, чтобы продемонстрировать, как системы взаимодействуют топологино, а также обеспечивают среднюю производительность и частоту ошибок. Дополнительные сведения см. в статье "Карта приложений: триаж распределенных приложений".

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

Дополнительные сведения о технологиях компонентов:

• Центры событий Azure — платформа потоковой передачи больших данных и служба приема событий
• Общие сведения о службе Azure Monitor
• Обзор Log Analytics в Azure Monitor
• Что такое масштабируемый набор виртуальных машин?
• Общие сведения об автомасштабировании в Microsoft Azure
• Что такое Azure Application Insights?

Связанные ресурсы

Сведения о связанных архитектурах:

• Обработка бессерверных событий
• Мониторинг Обозреватель данных Azure
• Мониторинг приложения микрослужб в AKS