Поделиться через

Настройте параметры диагностики в масштабе с помощью политик и инициатив Azure

  • Статья

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

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

Группы категорий журналирования

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

Встроенные определения политик для Azure Monitor

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

  • Рабочие области Log Analytics
  • Учетные записи хранения Azure
  • Центры событий

Назначьте политики для типа ресурса в соответствии с нужными назначениями.

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

Для полного списка встроенных политик для Azure Monitor см. встроенные определения политик Azure для Azure Monitor.

Пользовательские определения политик

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

Скрипт Create-AzDiagPolicy создает файлы политики для определенного типа ресурсов, которые затем можно установить с помощью PowerShell или Azure CLI. Чтобы создать настраиваемое определение политики для параметров диагностики, выполните указанные ниже действия.

  1. Убедитесь, чтоб у вас установлен Azure PowerShell.

  2. Установите этот скрипт, используя следующую команду:

    Install-Script -Name Create-AzDiagPolicy

  3. Запустите скрипт с помощью параметров, которые указывают место отправки журналов. Укажите подписку и тип ресурса в запросе.

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

    Create-AzDiagPolicy.ps1 -ExportLA -ExportEH -ExportDir ".\PolicyFiles"

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

    Create-AzDiagPolicy.ps1 -SubscriptionID <subscription id> -ResourceType Microsoft.Sql/servers/databases -ExportLA -ExportEH -ExportDir ".\PolicyFiles"

  4. Скрипт создает отдельные папки для каждого определения политики. Каждая папка содержит три файла: azurepolicy.json, azurepolicy.rules.json и azurepolicy.parameters.json. Если вы хотите создать политику вручную на портале Azure, вы можете скопировать и вставить содержимое файла azurepolicy.json, так как оно включает в себя полное определение политики. С помощью двух других файлов в PowerShell или Azure CLI вы можете создать определение политики из командной строки.

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

    New-AzPolicyDefinition -name "Deploy Diagnostic Settings for SQL Server database to Log Analytics workspace" -policy .\Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.rules.json -parameter .\Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.parameters.json -mode All -Metadata '{"category":"Monitoring"}'

    az policy definition create --name 'deploy-diag-setting-sql-database--workspace' --display-name 'Deploy Diagnostic Settings for SQL Server database to Log Analytics workspace'  --rules 'Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.rules.json' --params 'Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.parameters.json' --subscription 'AzureMonitor_Docs' --mode All

Инициатива

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

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

Сведения о создании инициативы см. в статье Создание определения инициативы и его назначение. Рассмотрите следующие рекомендации.

  • Установите Категорию на Мониторинг, чтобы сгруппировать его с связанными встроенными и настраиваемыми определениями политики.
  • Вместо того чтобы указывать параметры рабочей области Log Analytics и концентратора событий для определений политики в инициативе, используйте общий параметр инициативы. Он позволяет легко настраивать общие значения для всех определений политик и при необходимости менять их.

Снимок экрана: параметры определения инициативы.

Задание

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

Снимок экрана параметров вкладки

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

Снимок экрана: параметры инициативы на вкладке

Устранение неполадок

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

При создании назначения с помощью портала Azure можно сразу же создать задачу исправления. Дополнительные сведения об исправлении см. в разделе "Исправление несоответствующих ресурсов" с помощью Политика Azure.

Снимок экрана, который показывает корректировку инициативы для рабочей области Log Analytics.

Устранение неполадок

Категория метрики не поддерживается

При развертывании параметра диагностики появляется сообщение об ошибке, подобное этому: Категория метрики "xxxx" не поддерживается. Эта ошибка может возникнуть, даже если предыдущее развертывание выполнено успешно.

Эта проблема возникает при использовании шаблона Resource Manager, REST API, Azure CLI или Azure PowerShell. Параметры диагностики, созданные с помощью портал Azure, не затрагиваются, так как отображаются только поддерживаемые имена категорий.

Категории метрик, отличные от AllMetrics, не поддерживаются, за исключением некоторых ограниченных сервисов Azure. Ранее имена других категорий были проигнорированы при развертывании параметра диагностики, перенаправляя их в AllMetrics. По состоянию на февраль 2021 года категория метрик подтверждена. Это изменение привело к сбою некоторых развертываний.

Чтобы устранить эту проблему, обновите развертывания, чтобы удалить имена категорий метрик, отличные от AllMetrics. Если развертывание добавляет несколько категорий, используйте только одну AllMetrics категорию. Если проблема не исчезнет, обратитесь в службу поддержки Azure через портал Azure.

Параметр исчезает из-за использования в resourceID символов, не входящих в ASCII

Параметры диагностики не поддерживают идентификаторы ресурсов с символами, отличными от ASCII (например, Preproduccón). Так как вы не можете переименовать ресурсы в Azure, необходимо создать новый ресурс без символов, отличных от ASCII. Если персонажи находятся в группе ресурсов, можно переместить ресурсы в новую группу.

Возможность дублирования или потери данных

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

Неактивные ресурсы

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

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

Это поведение применяется только к экспортируемым метрикам и не влияет на оповещения на основе метрик или автомасштабирование.

Дальнейшие действия