Перспектива Azure Well-Architected Framework в Log Analytics

  • Статья

Функции и производительность рабочей нагрузки Well-Architected Framework должны отслеживаться различными способами и по разным причинам. Рабочие области Log Analytics Azure Monitor являются основным приемником журналов и метрик для большой части данных мониторинга. Рабочие области поддерживают несколько функций в Azure Monitor, включая нерегламентированные запросы, визуализации и оповещения. Общие принципы мониторинга см. в статье Руководство по мониторингу и диагностика. В руководстве представлены общие принципы мониторинга. Он определяет различные типы данных. Он определяет необходимый анализ, поддерживаемый Azure Monitor, а также данные, хранящиеся в рабочей области, которая обеспечивает анализ.

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

Важно!

Как пользоваться руководством

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

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

Технологические область

В этом руководстве рассматриваются взаимосвязанные решения для следующих ресурсов Azure.

  • Рабочие области Log Analytics
  • Данные журнала операций рабочей нагрузки
  • Параметры диагностики для ресурсов Azure в рабочей нагрузке

надежность;

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

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

Для рабочих областей Log Analytics следует учитывать следующие ситуации надежности:

  • Доступность рабочей области.
  • Защита собранных данных в редких случаях сбоя центра обработки данных Azure или региона.

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

Контрольный список проектирования для обеспечения надежности

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

  • Ознакомьтесь с ограничениями служб для рабочих областей Log Analytics. Раздел ограничения службы поможет вам понять ограничения на сбор и хранение данных, а также другие аспекты службы. Эти ограничения помогают определить, как правильно спроектировать стратегию наблюдаемости рабочей нагрузки. Обязательно ознакомьтесь с ограничениями службы Azure Monitor , так как многие из рассмотренных в нем функций, таких как запросы, работают рука об руку с рабочими областями Log Analytics.
  • Планирование устойчивости и восстановления рабочей области. Рабочие области Log Analytics являются региональными и не поддерживают межрегиональная избыточность или репликацию. Кроме того, варианты избыточности зоны доступности ограничены. Таким образом, необходимо определить требования к надежности рабочих областей и выработать стратегию для достижения этих целей. В ваших требованиях может быть указано, что рабочая область должна быть устойчивой к сбоям центра обработки данных или региональным сбоям, или они могут указывать, что вы должны иметь возможность восстановить данные в новой рабочей области в регионе отработки отказа. Для успешного выполнения каждого из этих сценариев требуются дополнительные ресурсы и процессы, поэтому следует тщательно продумать балансировку целевых показателей надежности с затратами и сложностью.
  • Выберите подходящие регионы развертывания в соответствии с требованиями к надежности. Разверните рабочую область Log Analytics и конечные точки сбора данных (DCE), расположенные вместе с компонентами рабочей нагрузки, создающими операционные данные. Ваш выбор соответствующего региона для развертывания рабочей области и контроллеров домена должен быть проинформирован о том, где вы развертываете рабочую нагрузку. Возможно, вам потребуется взвесить региональную доступность определенных функций Log Analytics, таких как выделенные кластеры, с учетом других факторов, которые более важны для требований к надежности, стоимости и производительности рабочей нагрузки.
  • Убедитесь, что системы наблюдаемости работоспособны. Как и любой другой компонент рабочей нагрузки, убедитесь, что системы мониторинга и ведения журнала работают правильно. Для этого включите функции, которые отправляют сигналы о работоспособности в рабочие группы. Настройте сигналы данных о работоспособности, относящиеся к рабочим областям Log Analytics и связанным ресурсам.

Рекомендации по настройке для обеспечения надежности

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

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

Контроллеры домена используются агентом Azure Monitor и API приема журналов для отправки операционных данных рабочей нагрузки в рабочую область Log Analytics. Может потребоваться несколько контроллеров домена, даже если в развертывании есть только одна рабочая область. Дополнительные сведения о настройке dce для конкретной среды см. в статье Настройка конечных точек сбора данных на основе развертывания.<Br
Если рабочая нагрузка развернута в режиме "активный — активный", рассмотрите возможность использования нескольких рабочих областей и контроллеров домена, распределенных по регионам, в которых развернута рабочая нагрузка.

Развертывание рабочих областей в нескольких регионах усложняет вашу среду. Сбалансируйте критерии, описанные в разделе Проектирование архитектуры рабочей области Log Analytics , с требованиями к доступности.
Если требуется, чтобы рабочая область была доступна в регионе или вы не собираете достаточно данных для выделенного кластера, настройте сбор данных для отправки критически важных данных в несколько рабочих областей в разных регионах. Эта практика также называется многоадресной рассылкой журналов.

Например, настройте DCR для нескольких рабочих областей для агента Azure Monitor, работающего на виртуальных машинах. Настройте несколько параметров диагностики для сбора журналов ресурсов из ресурсов Azure и отправки журналов в несколько рабочих областей.
Таким образом, операционные данные рабочей нагрузки доступны в альтернативной рабочей области в случае регионального сбоя. Но знайте, что ресурсы, использующие такие данные, как оповещения и книги, не будут автоматически реплицироваться в другие регионы. Рекомендуется хранить шаблоны Azure Resource Manager (ARM) для критически важных ресурсов оповещений с конфигурацией для альтернативной рабочей области или развертывать их во всех регионах, но отключить их, чтобы предотвратить избыточные оповещения. Оба варианта поддерживают быстрое включение в случае регионального сбоя.

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

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

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

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

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

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

Эта стратегия исключает затраты на исходящий трафик в разных регионах и остается работоспособной при сбое региона. Но это требует большей сложности, чем необходимо управлять с помощью конфигурации и процессов, описанных в разделе Моделирование работоспособности и наблюдаемость критически важных рабочих нагрузок в Azure.
Используйте инфраструктуру как код (IaC) для развертывания рабочих областей и связанных функций и управления ими. Автоматизация развертывания и механизмов обеспечения устойчивости и восстановления в максимальной степени обеспечивает надежность этих операций. Вы экономите критическое время в операционных процессах и минимизируете риск человеческих ошибок.

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

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

Кроме того, минимизируйте преобразование в DCR.		 При использовании узконационалных DDR снижается риск неправильной настройки правила, который будет иметь более широкий эффект. Он ограничивает эффект только область, для которых был создан DCR. Дополнительные сведения см. в статье Рекомендации по созданию правил сбора данных и управлению ими в Azure Monitor.

Хотя преобразование может быть эффективным и необходимым в некоторых ситуациях, тестирование и устранение неполадок ключевое слово работы на языке запросов (KQL) может оказаться сложной задачей. По возможности сведите к минимуму риск потери данных, принимая необработанные данные и обрабатывая преобразования во время запроса.
При установке ежедневного ограничения или политики хранения убедитесь, что вы поддерживаете требования к надежности, принимая и сохраняя необходимые журналы. Ежедневное ограничение останавливает сбор данных для рабочей области после достижения указанного объема, что помогает контролировать объем приема данных. Но используйте эту функцию только после тщательного планирования. Убедитесь, что ежедневное ограничение не попадает с регулярностью. В этом случае ограничение устанавливается слишком строго. Необходимо перенастроить ежедневное ограничение, чтобы не пропустить критические сигналы, поступающие от рабочей нагрузки.

Кроме того, не забудьте тщательно и вдумчиво подойти к снижению политики хранения данных, чтобы предотвратить непреднамеренно потерю критически важных данных.
Используйте аналитику рабочей области Log Analytics для отслеживания объема приема, количества принимаемых данных и ограничения данных, источников журналов без ответа и неудачных запросов среди других данных. Создание оповещений о состоянии работоспособности для упреждающего уведомления о том, что рабочая область становится недоступной из-за сбоя центра обработки данных или регионального сбоя. Эта стратегия гарантирует, что вы сможете успешно отслеживать работоспособность рабочих областей и заранее действовать, если работоспособность находится под угрозой ухудшения. Как и любой другой компонент рабочей нагрузки, важно знать о метриках работоспособности и выявлять тенденции для повышения надежности с течением времени.

Политика Azure

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

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

Помощник по Azure

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

Безопасность

Основной компонент безопасности — обеспечение конфиденциальности, целостности и доступности рабочей нагрузке.

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

Контрольный список разработки для обеспечения безопасности

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

  • Ознакомьтесь с разделами Базовые показатели безопасности Azure Monitor и Управление доступом к рабочим областям Log Analytics. В этих разделах содержатся рекомендации по обеспечению безопасности.
  • Развертывание рабочих областей с сегментацией в качестве ключевого принципа. Реализуйте сегментацию на уровне сети, данных и доступа. Сегментация помогает обеспечить надлежащую изоляцию рабочих областей и лучшую защиту от несанкционированного доступа в максимально возможной степени, в то же время выполняя требования к надежности, оптимизации затрат, эффективности работы и эффективности производительности.
  • Убедитесь, что вы можете выполнять аудит операций чтения и записи в рабочей области, а также связанных удостоверений. Злоумышленники могут воспользоваться преимуществами просмотра операционных журналов. Скомпрометированное удостоверение может привести к атакам путем внедрения журнала. Включите аудит операций, выполняемых на портале Azure или с помощью взаимодействия API и связанных пользователей. Если вы не настроены для аудита рабочей области, возможно, вы рискуете нарушить требования соответствия вашей организации.
  • Реализуйте надежные элементы управления сетью. Помогает защитить сетевой доступ к рабочей области и журналам с помощью функций сетевой изоляции и брандмауэра. Недостаточно настроенные элементы управления сетью могут поставить вас под угрозу доступа неавторизованных или вредоносных субъектов.
  • Определите, какие типы данных требуют неизменяемости или долгосрочного хранения. Данные журнала должны обрабатываться с той же строгостью, что и данные рабочей нагрузки в рабочих системах. Включите данные журнала в методы классификации данных, чтобы обеспечить успешное хранение конфиденциальных данных журнала в соответствии с требованиями к соответствию.
  • Защита неактивных данных журнала с помощью шифрования. Сегментация сама по себе не обеспечивает полную защиту конфиденциальности данных журнала. Если происходит несанкционированный необработанный доступ, шифрование неактивных данных журнала помогает предотвратить использование этих данных злоумышленниками за пределами рабочей области.
  • Защита конфиденциальных данных журнала с помощью маскировки. Как и данные рабочей нагрузки, размещенные в рабочих системах, необходимо принять дополнительные меры для обеспечения конфиденциальности конфиденциальной информации, которая может намеренно или непреднамеренно присутствовать в операционных журналах. При использовании методов обфускации это помогает скрыть конфиденциальные данные журнала от несанкционированных глаз.

Рекомендации по настройке безопасности

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

Azure Monitor обеспечивает шифрование всех неактивных данных и сохраненных запросов с помощью управляемых Майкрософт ключей (MMK). Если вам нужен собственный ключ шифрования и собрать достаточно данных для выделенного кластера, используйте ключ, управляемый клиентом. Вы можете зашифровать данные с помощью собственного ключа в Azure Key Vault, чтобы контролировать жизненный цикл ключа и отменять доступ к данным.

Если вы используете Microsoft Sentinel, убедитесь, что вы знакомы с рекомендациями в статье Настройка ключа Microsoft Sentinel, управляемого клиентом.		 Эта стратегия позволяет шифровать данные с помощью собственного ключа в Azure Key Vault для управления жизненным циклом ключа и возможности отзыва доступа к данным.
Настройте аудит запросов журнала , чтобы отслеживать, какие пользователи выполняют запросы.

Настройте журналы аудита для каждой рабочей области, которые будут отправляться в локальную рабочую область или консолидироваться в выделенной рабочей области безопасности, если вы отделяете операционные данные и данные безопасности. Используйте аналитику рабочей области Log Analytics для периодической проверки этих данных. Рекомендуется создать правила генерации оповещений о запросах к журналам, чтобы заблаговременно уведомлять вас о попытках выполнения запросов неавторизованными пользователями.		 Аудит запросов журнала записывает сведения о каждом выполнении запроса в рабочей области. Рассматривайте эти данные аудита как данные безопасности и обеспечьте надлежащую защиту таблицы LAQueryLogs . Эта стратегия повышает уровень безопасности, помогая гарантировать, что несанкционированный доступ будет немедленно схвачен, если он когда-либо произойдет.
Обеспечьте защиту рабочей области с помощью частных сетей и мер сегментации.

Используйте функцию приватного канала , чтобы ограничить обмен данными между источниками журналов и рабочими областями частной сетью.		 При использовании приватного канала он также позволяет контролировать, какие виртуальные сети могут получать доступ к определенной рабочей области, что еще больше повышает безопасность за счет сегментации.
Используйте Microsoft Entra ID вместо ключей API для доступа к API рабочей области, где это возможно. Доступ на основе ключей API к API-интерфейсам запросов не оставляет журнал аудита для каждого клиента. Используйте доступ на основе идентификаторов Entra с достаточной областью, чтобы можно было правильно проводить аудит программного доступа.
Настройте доступ для различных типов данных в рабочей области, необходимых для разных ролей в организации.

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

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

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

Пользователи с разрешениями таблицы имеют доступ ко всем данным в таблице независимо от разрешений на доступ к ресурсам.

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

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

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

Если у вас есть стандарты, требующие неизменить исходные данные, можно использовать литерал "h" в KQL-запросах, чтобы скрыть результаты запросов, отображаемые в книгах.		 Скрытие или фильтрация конфиденциальных данных в рабочей области помогает обеспечить конфиденциальность конфиденциальной информации. Во многих случаях требования к соответствию определяют способы обработки конфиденциальной информации. Эта стратегия помогает выполнять требования заранее.

Политика Azure

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

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

Помощник по Azure

Azure не предлагает рекомендаций Помощника по Azure, связанных с безопасностью рабочих областей Log Analytics.

Оптимизация затрат

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

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

Дополнительные сведения о том, как вычисляются затраты на данные для рабочих областей Log Analytics, см. в статье Расчеты затрат и параметры журналов Azure Monitor.

Контрольный список разработки для оптимизации затрат

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

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

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

Рекомендации по настройке для оптимизации затрат

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

Дополнительные сведения об уровнях обязательств и рекомендации по определению того, что наиболее подходит для вашего уровня использования, см. в статье Расчеты и параметры затрат на журналы Azure Monitor. Сведения о предполагаемых затратах на использование в разных ценовых категориях см. в статье Использование и предполагаемые затраты.
Настройка хранения и архивации данных. За хранение данных в рабочей области Log Analytics взимается плата за период, превышающий 31 день по умолчанию. Если Microsoft Sentinel включен в рабочей области, это 90 дней, а для данных Application Insights — 90 дней. Учитывайте конкретные требования к доступности данных для запросов к журналам. Вы можете значительно сократить затраты, настроив архивные журналы. Архивные журналы позволяют хранить данные до семи лет и периодически получать к ним доступ. Доступ к данным можно получить с помощью заданий поиска или восстановления набора данных в рабочей области.
Если вы используете Microsoft Sentinel для анализа журналов безопасности, рассмотрите возможность использования отдельной рабочей области для хранения этих журналов. При использовании выделенной рабочей области для данных журнала, используемых SIEM, это может помочь вам контролировать затраты. На рабочие области, которые использует Microsoft Sentinel, распространяется цена на Microsoft Sentinel. Требования к безопасности определяют типы журналов, которые необходимо включить в решение SIEM. Вы можете исключить операционные журналы, которые будут оплачиваться по стандартным ценам Log Analytics, если они будут находиться в отдельной рабочей области.
Настройте таблицы, используемые для отладки, устранения неполадок и аудита, в качестве базовых журналов. Таблицы в рабочей области Log Analytics, настроенной для базовых журналов , имеют более низкую стоимость приема в обмен на ограниченные функции и плату за запросы к журналам. Если вы запрашиваете эти таблицы нечасто и не используете их для создания оповещений, затраты на этот запрос могут быть более чем компенсированы снижением затрат на прием.
Ограничение сбора данных из источников данных для рабочей области. Основным фактором, определяющим стоимость Azure Monitor, является объем данных, собираемых в рабочей области Log Analytics. Убедитесь, что вы собираете не больше данных, чем требуется для оценки работоспособности и производительности служб и приложений. Для каждого ресурса выберите правильные категории для параметров диагностики, которые вы настраиваете, чтобы предоставить необходимый объем операционных данных. Это помогает успешно управлять рабочей нагрузкой, а не игнорированием данных.

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

Используйте аналитику рабочей области Log Analytics для периодического просмотра объема данных, собираемых в рабочей области. Выполните дальнейший анализ сбора данных с помощью методов в разделе Анализ использования в рабочей области Log Analytics , чтобы определить, существуют ли другие конфигурации, которые могут еще больше уменьшить использование.		 Помогая понять объем данных, собранных различными источниками, он выявляет аномалии и восходящие тенденции в сборе данных, которые могут привести к избыточным затратам. Это важно при добавлении нового набора источников данных в рабочую нагрузку. Например, если вы добавляете новый набор виртуальных машин, включите новые параметры azure диагностика в службе или измените уровни журнала в приложении.
Создайте оповещение при высоком уровне сбора данных. Чтобы избежать непредвиденных счетов, вы должны получать упреждающие уведомления при возникновении чрезмерного использования. Уведомление позволяет устранить любые потенциальные аномалии до окончания расчетного периода.
Рассмотрите ежедневное ограничение в качестве профилактической меры, чтобы гарантировать, что вы не превысите определенный бюджет. Ежедневное ограничение отключает сбор данных в рабочей области Log Analytics в течение остального дня после достижения настроенного значения ограничения. Не используйте этот метод для снижения затрат, как описано в разделе Когда следует использовать ежедневное ограничение, а для предотвращения беглого приема из-за неправильной конфигурации или злоупотреблений.

Если вы установили ежедневное ограничение, создайте оповещение по достижении ограничения. Не забудьте также создать правило генерации оповещений при достижении определенного процента. Например, можно задать правило генерации оповещений при достижении емкости 90 %. Это оповещение дает возможность исследовать и устранить причину увеличения объема данных, прежде чем ограничение отключит сбор критически важных данных из рабочей нагрузки.

Политика Azure

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

Помощник по Azure

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

Эффективность операционных процессов

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

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

Контрольный список разработки для повышения эффективности операций

Начните свою стратегию проектирования на основе контрольного списка проверки проектирования для обеспечения эффективности работы , чтобы определить процессы наблюдаемости, тестирования и развертывания, связанные с рабочими областями Log Analytics.

  • Используйте инфраструктуру как код (IaC) для всех функций, связанных с рабочими областями Log Analytics рабочей нагрузки. Сведите к минимуму риск человеческих ошибок, которые могут возникнуть при администрировании и эксплуатации сборов журналов, приеме, хранении и выполнении запросов, включая сохраненные запросы и пакеты запросов, за счет автоматизации как можно больше этих функций с помощью кода. Кроме того, включите оповещения, сообщающие об изменениях состояния работоспособности и конфигурации параметров диагностики для ресурсов, которые отправляют журналы в рабочие области в коде IaC. Включите код в другой код, связанный с рабочей нагрузкой, чтобы обеспечить соблюдение безопасных методов развертывания для управления рабочими областями.
  • Убедитесь, что рабочие области работоспособны, и вы будете получать уведомления при возникновении проблем. Как и любой другой компонент рабочей нагрузки, в рабочих областях могут возникнуть проблемы. Эти проблемы могут стоить ценного времени и ресурсов для устранения неполадок и, возможно, оставить вашу команду в неведении о состоянии рабочей нагрузки. Возможность упреждающего мониторинга рабочих областей и устранения потенциальных проблем помогает операционным группам свести к минимуму время, затрачивается на устранение и устранение проблем.
  • Отделите рабочую среду от непроизводственных рабочих нагрузок. Избегайте ненужных сложностей, которые могут привести к дополнительной работе для рабочей группы, используя рабочие области для рабочей среды, отличные от рабочих областей, используемых в непроизводственных средах. Поступающие данные также могут привести к путанице, так как действия тестирования могут показаться событиями в рабочей среде.
  • Предпочитать встроенные средства и функции решениям сторонних разработчиков Используйте встроенные средства для расширения функциональных возможностей систем мониторинга и ведения журнала. Может потребоваться добавить дополнительные конфигурации для поддержки таких требований, как возможность восстановления или независимость данных, которые недоступны в рабочих областях Log Analytics. В таких случаях, когда это целесообразно, используйте собственные средства Azure или Майкрософт, чтобы свести к минимуму количество средств, которые должна поддерживать ваша организация.
  • Рассматривайте рабочие области как статические, а не временные компоненты Как и другие типы хранилищ данных, рабочие области не следует рассматривать как временные компоненты рабочей нагрузки. Платформа Well-Architected, как правило, предпочитает неизменяемую инфраструктуру и возможность быстро и легко заменять ресурсы в рабочей нагрузке в рамках развертываний. Но потеря данных рабочей области может быть катастрофической и необратимой. По этой причине оставьте рабочие области вне пакетов развертывания, которые заменяют инфраструктуру во время обновлений, и выполняйте обновления только на месте рабочих областей.
  • Убедитесь, что операционный персонал обучен язык запросов Kusto Обучение сотрудников созданию или изменению запросов при необходимости. Если операторы не могут писать или изменять запросы, это может замедлить устранение критических неполадок или другие функции, так как операторы должны полагаться на другие команды для выполнения этой работы.

Рекомендации по настройке для операционной эффективности

Рекомендация Преимущество
Разработайте стратегию рабочей области в соответствии с бизнес-требованиями.

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

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

Для поддержки требований к доступности могут потребоваться рабочие области для нескольких рабочих областей, например для нескольких клиентов. Поэтому убедитесь, что у вас есть соответствующие процессы для управления этой повышенной сложностью.
Используйте инфраструктуру как код (IaC) для развертывания рабочих областей и связанных функций и управления ими. Используйте инфраструктуру как код (IaC) для определения сведений о рабочих областях в шаблонах ARM, Azure BICEP или Terraform. Она позволяет использовать существующие процессы DevOps для развертывания новых рабочих областей и Политика Azure для принудительного применения их конфигурации.

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

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

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

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

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

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

Политика Azure и Помощник по Azure

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

Оптимизация производительности

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

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

Контрольный список разработки для повышения производительности

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

  • Ознакомьтесь с основами задержки приема данных журнала в Azure Monitor. Существует несколько факторов, влияющих на задержку при приеме журналов в рабочие области. Многие из этих факторов присущи платформе Azure Monitor. Понимание факторов и нормальной задержки может помочь вам задать соответствующие ожидания в рабочих группах.
  • Разделите непроизводственные и рабочие нагрузки. Рабочие области, относящиеся к рабочей среде, устраняют любые издержки, которые могут возникнуть в непроизводственных системах. Это сокращает общий объем рабочих областей, требуя меньше ресурсов для обработки данных журнала.
  • Выберите подходящие регионы развертывания в соответствии с требованиями к производительности. Разверните рабочую область Log Analytics и конечные точки сбора данных (DCE) рядом с рабочей нагрузкой. Ваш выбор подходящего региона для развертывания рабочей области и контроллеров домена должен быть информирован о том, где вы развертываете рабочую нагрузку. Возможно, вам потребуется взвесить преимущества производительности развертывания рабочих областей и контроллеров домена в том же регионе, что и ваша рабочая нагрузка, с учетом требований к надежности, если вы уже развернули рабочую нагрузку в регионе, который не поддерживает эти требования к данным журнала.

Рекомендации по настройке для повышения производительности

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

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

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

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

Взвесите проектные решения, чтобы уменьшить ограничения служб в соответствии с требованиями и целевыми показателями для других компонентов.
Создание DCR, относящихся к типам источников данных, в одной или нескольких определенных областях наблюдаемости. Создайте отдельные DCR для производительности и событий, чтобы оптимизировать использование вычислительных ресурсов серверной обработки. При использовании отдельных DCR для производительности и событий это помогает устранить нехватку ресурсов серверной части. Благодаря DCR, объединяющим события производительности, каждая связанная виртуальная машина должна передавать, обрабатывать и запускать конфигурации, которые могут быть неприменимы в соответствии с установленным программным обеспечением. Чрезмерное потребление вычислительных ресурсов и ошибки при обработке конфигурации могут привести к тому, что агент Azure Monitor (AMA) перестанет отвечать на запросы.

Политика Azure и Помощник по Azure

Azure не предлагает ни политик, ни рекомендаций Помощника по Azure, связанных с производительностью рабочих областей Log Analytics.

Следующий шаг