Рекомендации по архитектуре log Analytics

Просмотрите ограничения служб для рабочих областей Log Analytics: В разделе ограничений службы описываются ограничения на сбор данных, хранение данных и другие аспекты службы. Эти ограничения помогают разработать эффективную стратегию наблюдения за рабочей нагрузкой. Убедитесь, что вы просматриваете ограничения службы Azure Monitor , так как многие функции, такие как запросы, работают в тандеме с рабочими областями Log Analytics.

Планирование устойчивости и восстановления рабочей области: Рабочие области Log Analytics являются региональными и не поддерживают встроенную поддержку межрегиональная избыточность или репликация. Параметры избыточности зоны доступности ограничены. Из-за этих ограничений необходимо определить требования к надежности рабочих областей и стратегизировать для удовлетворения этих целей.

Требования могут указывать на то, что рабочая область должна быть устойчивой к сбоям центра обработки данных или региональным сбоям. Или они могут указать, что вы должны иметь возможность восстановить данные в новой рабочей области в регионе отработки отказа.

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

Выберите нужные регионы развертывания, чтобы соответствовать вашим требованиям к надежности: Разверните рабочую область Log Analytics и конечные точки сбора данных (DCEs) с компонентами рабочей нагрузки, которые выдают операционные данные. При развертывании рабочей нагрузки следует сообщить о выбранном регионе, в котором будет развернута рабочая область и контроллеры домена.

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

Исключите рабочие области из зависимостей критического пути: Рабочие области Log Analytics служат важными компонентами системы наблюдения, но их не следует включать в критически важный путь рабочей нагрузки. Эти рабочие области собирают и хранят операционные данные, необходимые для мониторинга и устранения неполадок. Однако основные функциональные возможности рабочей нагрузки должны оставаться независимо от доступности рабочей области. Это разделение архитектуры гарантирует, что системные сбои системы наблюдения не каскады в сбои среды выполнения рабочей нагрузки.

Убедитесь, что системы наблюдаемости работоспособны: Как и любой другой компонент рабочей нагрузки, убедитесь, что системы мониторинга и ведения журнала работают правильно. Чтобы обеспечить надежную наблюдаемость, включите функции, которые отправляют сигналы о работоспособности данных в команды операций. Настройте сигналы о работоспособности, относящиеся к рабочим областям Log Analytics и связанным ресурсам.

Ознакомьтесь с рекомендациями по обеспечению безопасности: Ознакомьтесь с рекомендациями по обеспечению безопасности в базовых показателях безопасности Azure Monitor и управлении доступом к рабочим областям Log Analytics .

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

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

Если вы не настроены для аудита рабочей области, вы можете поставить организацию под угрозу нарушения требований соответствия требованиям.

Реализуйте надежные сетевые элементы управления: Помогите защитить сетевой доступ к рабочей области и журналам с помощью функций сетевой изоляции и брандмауэра. Недостаточно настроенные сетевые элементы управления повышают риск несанкционированного или вредоносного доступа.

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

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

Защита конфиденциальных данных журнала с помощью обфускации: Как и данные рабочей нагрузки, находящиеся в рабочих системах, необходимо принять дополнительные меры, чтобы обеспечить хранение конфиденциальной информации для конфиденциальной информации, которая может быть намеренно или непреднамеренно присутствует в операционных журналах. При использовании методов маскирования можно скрыть конфиденциальные данные журнала от несанкционированного доступа.

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

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

Помните, что вы можете выбрать разные модели выставления счетов для каждой рабочей области. Вы также можете объединить затраты на рабочую область в конкретных случаях, чтобы можно было детализировать анализ и принятие решений.

Соберите только нужный объем данных журнала: Регулярно проводите регулярный анализ параметров диагностики в ресурсах, конфигурации правила сбора данных и ведения журнала пользовательского кода приложения, чтобы не собирать ненужные данные журнала.

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

Используйте инфраструктуру в качестве кода (IaC) для всех функций, связанных с рабочими областями Log Analytics рабочей нагрузки: Свести к минимуму риск человеческой ошибки, которая может возникать от ручного администрирования и эксплуатации коллекции журналов, приема, хранения и запросов функций, включая сохраненные запросы и пакеты запросов, автоматизируя как можно больше этих функций с помощью кода.

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

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

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

Предпочитайте встроенные средства и функции для решений, отличных от Майкрософт: Используйте встроенные средства для расширения функциональных возможностей систем мониторинга и ведения журнала. Вам может потребоваться установить дополнительные конфигурации для поддержки таких требований, как возможность восстановления или суверенитет данных, которые недоступны вне поля с рабочими областями Log Analytics. В таких случаях используйте собственные средства Azure или Майкрософт, чтобы свести к минимуму количество средств, которые должна поддерживать ваша организация.

Рассматривайте рабочие области как статические, а не временные компоненты: Как и другие типы хранилищ данных, рабочие области не должны рассматриваться среди временных компонентов рабочей нагрузки. Платформа Well-Architected, как правило, предпочитает неизменяемую инфраструктуру и возможность быстро и легко заменить ресурсы в рабочей нагрузке в рамках развертываний. Но потеря данных рабочей области может быть катастрофической и необратимой.

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

Убедитесь, что сотрудники по операциям обучены на языке запросов Kusto: При необходимости обучить сотрудников создавать или изменять запросы. Если операторы не могут записывать или изменять запросы, это может замедлить критическое устранение неполадок или другие функции, так как операторы должны полагаться на другие команды, чтобы сделать это для них.

Ознакомьтесь с основами задержки приема данных журнала в Azure Monitor: Существует несколько факторов, которые влияют на задержку при приеме журналов в рабочие области. Многие из этих факторов присущи платформе Azure Monitor.

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

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

Выберите нужные регионы развертывания, чтобы соответствовать вашим требованиям к производительности: Разверните рабочую область Log Analytics и контроллеры домена, близкие к рабочей нагрузке. При развертывании рабочей нагрузки следует сообщить о выбранном регионе, в котором будет развернута рабочая область и контроллеры домена.

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