Эта архитектура описывает решение, которое обеспечивает мониторинг и наблюдаемость систем и данных телеметрии устройства конечного пользователя в режиме реального времени. Он фокусируется на варианте использования для медиаиндустрии.
Grafana является товарным знаком соответствующей компании. Никакое подтверждение не подразумевается использованием этого знака.
Архитектура
Скачайте файл Visio для этой архитектуры.
Поток данных
В наблюдаемой системе, показанной на схеме, необработанные данные телеметрии передаются в Хранилище BLOB-объектов Azure через HTTP и соединители. Необработанные данные телеметрии обрабатываются, преобразуются, нормализованы и сохраняются в Azure Data Explorer для анализа. Такие системы, как Grafana и Помощник по метрикам Azure, считывают данные из Обозревателя данных и предоставляют аналитические сведения конечным пользователям.
В частности, это элементы системы на схеме:
- Инструментирование. Инструментирование происходит с помощью проб или агентов, установленных в системах для мониторинга данных. Эти агенты приходят в различных формах. Например, на платформе потоковой передачи видео по запросу компания может использовать открытые стандарты dash.js для сбора метрик качества опыта от клиентов.
- Прием. Эта необработанные данные телеметрии могут поступать непосредственно от конечных клиентов через HTTP-вызовы. Кроме того, вы можете передать его через сторонние системы в постоянное хранилище и озера данных, такие как хранилище BLOB-объектов. Служба хранилища блогов поддерживает возможность вызова функции Azure при отправке нового файла. Этот механизм триггера можно использовать для перемещения необработанных данных телеметрии в структурированные хранилища данных.
- Преобразование и сохраняемость. Для нормализации данных может потребоваться система преобразования. Приложение Функции Azure преобразует данные по мере необходимости, а затем записывает его в обозреватель данных. Обозреватель данных идеально подходит для аналитики больших данных, так как он предназначен для высокой производительности и пропускной способности больших наборов данных.
- Мониторинг. Управляемая Grafana Azure поддерживает интеграцию с Data Explorer. Функции перетаскивания Grafana можно использовать для быстрого создания панелей мониторинга и диаграмм. Grafana является хорошим подходом для мониторинга мультимедиа, так как он обеспечивает подминутное обновление плиток панели мониторинга и также может использоваться для оповещения.
- обнаружение аномалий; Панель мониторинга Grafana обеспечивает поддержку ручного мониторинга в NOC. Однако при наличии большого набора данных и пользовательской базы, распределенной по географическим регионам и с помощью различных устройств, ручное определение проблем с помощью диаграмм и правил генерации оповещений, которые имеют жестко закодированные пороговые значения, становятся неэффективными. Вы можете использовать ИИ для решения этой проблемы. Службы, такие как помощник по метрикам, используют алгоритмы машинного обучения для автоматического понимания и обнаружения аномалий на основе данных временных рядов. Кроме того, платформа данных Kusto имеет встроенные функции обнаружения аномалий, которые учитывают сезонные и базовые тенденции в данных.
Компоненты
- Data Explorer — это управляемая служба аналитики данных для анализа больших объемов данных в режиме реального времени. Обозреватель данных — это отличное средство для обработки больших наборов данных, требующих высокой скорости и пропускной способности извлечения данных. Эта архитектура использует Data Explorer для хранения и запроса наборов данных для анализа.
- Хранилище BLOB-объектов используется для хранения необработанных данных телеметрии. Эта телеметрия может поступать из приложений и служб или сторонних поставщиков. Данные можно рассматривать как временные, если вам не нужно выполнять более подробный анализ позже. Данные из хранилища BLOB-объектов добавляются в кластеры Обозревателя данных.
- Сетка событий Azure — это система доставки событий. Он используется для прослушивания событий, опубликованных хранилищем BLOB-объектов. служба хранилища Azure события позволяют приложениям реагировать на такие события, как создание и удаление больших двоичных объектов. Функция Azure подписывается на события, опубликованные сеткой событий.
- Центры событий Azure — это служба приема данных в режиме реального времени, которую можно использовать для приема миллионов событий в секунду из любого источника. Центры событий представляют входную дверь, часто называемую методом обработки событий для конвейера событий. Ingestor — это компонент или служба, расположенная между издателями событий и потребителями событий. Он отделяет производство потока событий от потребления событий.
- Функции Azure — это бессерверное решение, которое используется для анализа и преобразования данных через конечные точки HTTP и BLOB-объектов и записи в кластер Data Explorer.
- Управляемый Grafana Azure легко подключается к Обозревателе данных. В этой архитектуре создаются диаграммы и панели мониторинга, которые визуализируют данные телеметрии. Управляемая Grafana Azure обеспечивает глубокую интеграцию с идентификатором Microsoft Entra, чтобы реализовать доступ на основе ролей к панелям мониторинга и представлениям.
- Помощник по метрикам является частью приложение Azure лиированных служб ИИ. Он использует ИИ для мониторинга данных и обнаружения аномалий в данных временных рядов. Помощник по метрикам автоматизирует процесс применения моделей к данным и предоставляет набор API и веб-рабочую область для приема данных, обнаружения аномалий и диагностика. Его можно использовать, даже если у вас нет знаний об машинном обучении.
Альтернативные варианты
Фабрика данных Azure и Azure Synapse Analytics предоставляют средства и рабочие области для создания рабочих процессов ETL и возможности отслеживания и повторных попыток заданий из графического интерфейса. Обратите внимание, что фабрика данных и Azure Synapse имеют минимальную задержку около 5 минут с момента приема к сохраняемости. Эта задержка может быть приемлемой в вашей системе мониторинга. Если это так, рекомендуется рассмотреть эти альтернативные варианты.
Подробности сценария
Организации часто развертывают разнообразные и крупномасштабные технологии для решения бизнес-задач. Эти системы и устройства конечных пользователей создают большие наборы данных телеметрии.
Эта архитектура основана на варианте использования для индустрии мультимедиа. Потоковая передача мультимедиа для воспроизведения видео по запросу требует практически в реальном времени идентификации и реагирования на проблемы приложения. Для поддержки этого сценария в режиме реального времени организации должны собирать массовый набор данных телеметрии, для которого требуется масштабируемая архитектура. После сбора данных другие типы анализа, такие как ИИ и обнаружение аномалий, необходимы для эффективного выявления проблем в большом наборе данных.
При развертывании крупномасштабных технологий системные и конечные устройства, взаимодействующие с ними, создают массивные наборы данных телеметрии. В традиционных сценариях эти данные анализируются с помощью системы хранилища данных для создания аналитических сведений, которые можно использовать для поддержки решений по управлению. Этот подход может работать в некоторых сценариях, но он недостаточно реагирует для вариантов использования потоковых носителей. Чтобы решить эту проблему, аналитика в режиме реального времени требуется для данных телеметрии, созданных на серверах мониторинга, сетях и устройствах конечных пользователей, взаимодействующих с ними. Системы мониторинга, которые перехватывают ошибки и ошибки, являются распространенными, но для их перехвата в почти реальном времени трудно. Это фокус этой архитектуры.
В режиме потоковой передачи или видео по запросу данные телеметрии создаются из систем и разнородных клиентов (мобильных, настольных и телевизионных). Решение включает использование необработанных данных и связывание контекста с точками данных, например измерениями, такими как география, операционная система конечных пользователей, идентификатор содержимого и поставщик CDN. Необработанные данные телеметрии собираются, преобразуются и сохраняются в обозревателе данных для анализа. Затем вы можете использовать ИИ для анализа данных и автоматизации ручных процессов наблюдения и оповещений. Вы можете использовать такие системы, как Grafana и помощник по метрикам, чтобы считывать данные из обозревателя данных для отображения интерактивных панелей мониторинга и активации оповещений.
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, набор руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Надежность
Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см. в контрольном списке проверки конструктора длянадежности.
Критически важные для бизнеса приложения должны работать даже во время нарушений, таких как регион Azure или сбои CDN. Существует две основные стратегии и одна гибридная стратегия для создания избыточности в системе:
- Активный — активный. Выполняется повторяющийся код и функции. Любая система может взять на себя во время сбоя.
- Активный или резервный. Только один узел является активным или первичным. Другой готов взять на себя, если основной узел исчезнет.
- Смешанный. Некоторые компоненты и службы находятся в активной/активной конфигурации, а некоторые находятся в режиме "активный или резервный".
Помните, что не все службы Azure имеют встроенную избыточность. Например, Функции Azure запускает приложение-функцию только в определенном регионе. Функции Azure гео-аварийное восстановление описывает различные стратегии, которые можно реализовать в зависимости от того, как активируются функции (HTTP и pub/sub).
Приложение-функция приема и преобразования может работать в активном или активном режиме. Обозреватель данных можно запускать как в активных, так и в активных и резервных конфигурациях.
Управляемый Grafana Azure поддерживает избыточность зоны доступности. Одной из стратегий создания избыточности между регионами является настройка Grafana в каждом регионе, в котором развернут кластер Data Explorer.
Оптимизация затрат
Оптимизация затрат заключается в том, чтобы подумать о способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке конструктора дляоптимизации затрат.
Стоимость этой архитектуры зависит от количества событий телеметрии входящего трафика, хранилища необработанных данных телеметрии в хранилище BLOB-объектов и обозревателя данных, почасовой стоимости для Управляемой Grafana Azure и статической стоимости для количества диаграмм временных рядов в помощнике по метрикам.
Вы можете использовать калькулятор цен Azure для оценки почасовой или ежемесячной стоимости.
Эффективность производительности
Эффективность производительности — это возможность масштабирования рабочей нагрузки в соответствии с требованиями, заданными пользователями. Дополнительные сведения см. в контрольном списке проверки конструктора дляпроизводительности.
В зависимости от масштаба и частоты входящих запросов приложение-функция может быть узким местом по двум основным причинам:
- Холодный запуск. Холодный запуск является следствием бессерверных выполнений. Он ссылается на время планирования и установки, необходимое для создания среды перед запуском функции. В большинстве случаев требуется несколько секунд.
- Частота запросов. Предположим, что у вас есть 1000 HTTP-запросов, но только однопоточный сервер для их обработки. Вы не сможете одновременно обслуживать все 1000 HTTP-запросов. Чтобы своевременно обслуживать эти запросы, необходимо развернуть больше серверов. То есть необходимо горизонтально масштабироваться.
Рекомендуется использовать номера SKU уровня "Премиум" или "Выделенный" для:
- Исключите холодный запуск.
- Обработка требований к параллельным запросам путем масштабирования числа обслуживающих виртуальных машин вверх или вниз.
Дополнительные сведения см. в разделе "Выбор SKU" для кластера Azure Data Explorer.
Развертывание этого сценария
Сведения о развертывании этого сценария см. в разделе "Мониторинг и наблюдение" в режиме реального времени на сайте GitHub. Этот пример кода включает в себя необходимую инфраструктуру как код (IaC) для начальной загрузки разработки и функций Azure для приема и преобразования данных из конечных точек HTTP и BLOB-объектов.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Основные авторы:
- Джон Хауппа | Старший технический руководитель программы
- Уффаз Натаниэль | Главный инженер программного обеспечения
Другие участники:
- Мик Альбертс | Технический писатель
- Dilmurod Makhamadaliev | Программист
- Омедом Мусави | Главный руководитель разработчика программного обеспечения
- Ayo Mustapha | Главный технический руководитель программы
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Дополнительные примеры кода
- Документация по Azure Data Explorer
- Общие сведения о Azure Data Explorer — обучение
- Общие сведения о Функциях Azure