Вы управляете 200 виртуальными машинами Windows и Linux в трех регионах. Требования: 1) Командам безопасности и эксплуатации необходим ролевой доступ к журналам по регионам, но при этом вам требуется возможность выполнять централизованные запросы ко всем виртуальным машинам. 2) Сохранять SecurityEvent в течение 180 дней, но счетчики производительности (Perf) — только 30 дней. 3) Собирать только определенные идентификаторы событий Windows и фильтровать «шумные» данные во время сбора. Какую рабочую область и дизайн сбора данных вы порекомендуете?

Правильный ответ соответствует всем требованиям. Развертывание одной рабочей области Log Analytics на регион позволяет применять региональное RBAC для команд безопасности и эксплуатации. Использование Azure Monitor Agent с правилами сбора данных (DCR) и преобразованиями позволяет фильтровать "шумные" данные и собирать только необходимые идентификаторы событий Windows. Настройка хранения для каждой таблицы (SecurityEvent – 180 дней, Perf – 30 дней) удовлетворяет требованиям к срокам хранения. Межрабочие запросы KQL (cross-workspace queries) обеспечивают централизованный анализ данных со всех виртуальных машин. Неправильные варианты: Единая глобальная рабочая область не позволяет региональное RBAC. Использование устаревшего агента MMA и отсутствие DCR не позволяют фильтровать данные при сборе. Рабочая область для каждой команды приложения не соответствует региональному RBAC. Сбор всех событий без DCR и ежедневный экспорт неэффективны для фильтрации и не обеспечивают гибкое хранение. Отправка журналов напрямую в Event Hubs и Stream Analytics усложняет архитектуру и не предоставляет нативного решения для RBAC и гибкого хранения в Log Analytics. Использование Azure Sentinel для всех данных избыточно и не обеспечивает гибкого хранения для каждой таблицы. Отсутствие фильтрации при приеме увеличивает затраты.