Рекомендации по применению лучших архитектурных практик для Log Analytics

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

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

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

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

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

Возможно, потребуется взвесить региональную доступность определенных функциональных возможностей 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 и конечные точки сбора данных (DCE) ближе к рабочей нагрузке. Место развертывания рабочей нагрузки должно определять выбор подходящего региона для развертывания рабочей области и конечных точек сбора данных (DCE).

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