Разработка для рабочих областей журналов Azure Monitor (Log Analytics)
Azure Monitor хранит данные журналов в рабочей области журналов Azure Monitor (Log Analytics). Рабочая область представляет собой ресурс Azure, который выступает в роли административной границы или географического расположения для хранилища данных. Она также является контейнером, в котором собираются и агрегируются данные.
Хотя вы можете развернуть одну или несколько рабочих областей в подписке Azure, необходимо убедиться, что первоначальное развертывание следует рекомендациям Майкрософт. Рабочая область должна обеспечивать экономичное, управляемое и масштабируемое развертывание, которое соответствует потребностям организации.
Сведения о рабочих областях журналов Azure Monitor
Просмотрите следующие характеристики рабочих областей журналов Azure Monitor и определите, как их можно использовать в решении для мониторинга для Tailwind Traders.
В рабочей области можно изолировать данные за счет предоставления различным пользователям прав доступа согласно рекомендуемым стратегиям проектирования Майкрософт.
Данные в рабочей области журналов Azure Monitor структурированы в таблицы. Каждая таблица хранит различные виды данных и имеет собственный уникальный набор свойств в зависимости от ресурса, который породил эти данные. Большинство источников данных записывают сведения в собственные таблицы в рабочей области журналов Azure Monitor.
Рабочая область позволяет настраивать такие параметры, как ценовая категория, период хранения и ограничение на объем данных, на основе административных границ или географических расположений.
С помощью управления доступом на основе ролей Azure (Azure RBAC) можно сделать так, чтобы пользователям и группам предоставлялся доступ только к тем ресурсам, которые им необходимы для работы с данными мониторинга в рабочей области. Управление доступом пользователей можно настроить в соответствии с моделью функционирования вашей ИТ-организации с помощью одной рабочей области, включенной для всех ресурсов, в которой будут храниться собранные данные.
Рабочие области размещаются в физических кластерах. Эти кластеры по умолчанию создаются и управляются системой. Если система выполняет прием более 500 ГБ данных в день, вы создадите собственные выделенные кластеры для рабочих областей, чтобы обеспечить больший контроль и более высокую скорость приема.
Аспекты, которые следует учитывать при работе с рабочими областями журналов Azure Monitor
Теперь вы готовы просмотреть рекомендации по проектированию с использованием рабочих областей журналов Azure Monitor в архитектуре Tailwind Traders.
Проанализируйте свою стратегию управления доступом. При расчете количества рабочих областей, которые понадобятся вам в организации Tailwind Traders, учитывайте следующие возможные факторы:
- Ваша организация является международной компанией? Вам нужно хранить данные журналов в определенных регионах для обеспечения независимости данных или соответствия требованиям?
- В вашей архитектуре используется Azure? Вы хотите избежать расходов на передачу исходящих данных с помощью рабочей области, расположенной в том же регионе, что и управляемые ею ресурсы Azure?
- Ваша система поддерживает различные отделы или бизнес-группы? Каждая группа должна иметь доступ к своим данным и не иметь доступа к данным других групп. При этом не требуется иметь объединенное представление по всем отделам или бизнес-группам.
Проанализируйте варианты модели развертывания. В большинстве архитектур ИТ-организаций используется централизованная, децентрализованная или гибридная модель. Изучите эти распространенные модели развертывания рабочих областей, а также варианты их применения в организации Tailwind Traders:
Развертывание Description Централизованный Все журналы хранятся в основной рабочей области и управляются одной командой. Azure Monitor обеспечивает разный доступ для каждой команды. Этот сценарий облегчает управление, поиск по ресурсам и корреляцию журналов. Рабочую область можно существенно увеличить в зависимости от объема собранных из различных ресурсов данных в подписке. Дополнительные административные издержки необходимы для обеспечения управления доступом различных пользователей. Эта модель называется звездообразной. Децентрализованный У каждой команды есть собственная рабочая область, созданная в группе ресурсов, которая принадлежит команде и управляется ею. Данные журналов разделяются по ресурсам. В этом сценарии обеспечивается защита рабочей области, а управление доступом согласуется со способом организации доступа к ресурсам. К недостаткам этой модели можно отнести затруднительную корреляцию журналов. У пользователей, которым нужно понимать общую картину по множеству ресурсов, нет возможности осмысленно проанализировать данные. Гибридный Гибридный подход может усложнить требования к соответствию требованиям аудита безопасности. Многие организации реализуют обе модели развертывания одновременно. В результате обычно получается сложная, дорогостоящая и трудная в обслуживании гибридная конфигурация, некоторые аспекты работы которой не отражаются в журналах. Проанализируйте режим доступа. Определите варианты предоставления пользователям доступа к рабочим областям журналов Azure Monitor, а также область предоставляемых данных. У пользователей организации Tailwind Traders есть два варианта доступа к данным:
Режим доступа Description Контекст рабочей области Пользователь может просмотреть все журналы в рабочей области, к которой у него есть доступ. Область запросов ограничена всеми данными во всех таблицах такой рабочей области. Журналы также входят в эту область, просмотреть их можно на вкладке Журналы в меню Azure Monitor на портале Azure. Контекст ресурсов Пользователь получает доступ к конкретному ресурсу, группе ресурсов или подписке в рабочей области. На вкладке Журналы в меню ресурсов на портале Azure можно просмотреть только журналы для ресурсов в таблицах, к которым у пользователя есть доступ. Запросы ограничиваются только данными, связанными с этим ресурсом. В этом режиме поддерживается также Azure RBAC с детализацией. Проанализируйте RBAC Azure и рабочие области. Управляйте доступом пользователей к ресурсам в зависимости от их связей с рабочими областями. Предположим, что вам необходимо предоставить доступ команде, ответственной за службы инфраструктуры Tailwind Traders, которые размещены на виртуальных машинах Azure. Можно предоставить команде доступ только к журналам, созданным виртуальными машинами. Такой подход соответствует модели журналов контекста ресурсов. Основа этой модели — для каждой записи журнала, созданной ресурсом Azure. Журналы пересылаются в центральную рабочую область, в которой обеспечивается разграничение областей доступа и реализуется Azure RBAC на основе ресурсов.
Проанализируйте ограничения на масштаб и объем приема данных. Azure Monitor — это высокомасштабируемая служба, которая обслуживает тысячи клиентов, ежемесячно отправляющих стремительными темпами петабайты данных. Занимаемое рабочими областями пространство не ограничено и может достигать петабайтов данных. Разбивать рабочие области не нужно, так как они масштабируются.
Рекомендации
Во время изучения вариантов реализации рабочих областей журналов Azure Monitor и управления доступом в решении для мониторинга и ведения журналов ознакомьтесь со следующими рекомендациями. В следующем сценарии представлен рекомендуемый план для одной рабочей области в подписке вашей ИТ-организации.
Рабочая область не требует обеспечения независимости данных или соответствия нормативным требованиям. Рабочая область не должна сопоставляться с регионами, в которых развертываются ресурсы. Команды по безопасности и ИТ-администрированию вашей организации могут воспользоваться преимуществами улучшенной интеграции со средствами управления доступом Azure и обеспечить более безопасное управление доступом.
Все ресурсы, решения для мониторинга и такие источники аналитических сведений, как Application Insights и аналитика виртуальных машин, настроены для пересылки собранных ими данных журналов в централизованную общую рабочую область ИТ-организации. Данные журналов из второстепенной инфраструктуры и приложений, которые обслуживаются различными командами, также отправляются в централизованную общую рабочую область.
Пользователи каждой команды получают доступ к журналам для ресурсов, для которых у них есть доступ.
После развертывания архитектуры рабочей области ту же модель можно применить к ресурсам Azure с помощью Политики Azure. Она позволяет определить политики и обеспечить соответствие требованиям для ресурсов Azure, чтобы они отправляли все журналы ресурсов в определенную рабочую область. С помощью Azure Виртуальные машины или Масштабируемые наборы виртуальных машин можно использовать существующие политики, которые оценивают соответствие рабочей области и результаты отчета, или настраивать для исправления, если они не соответствуют требованиям.