Параметры диагностики в Azure Monitor
В этой статье приведены сведения о создании и настройке параметров диагностики для отправки метрик и журналов платформы Azure в разные места назначения.
Метрики платформы автоматически отправляются в метрики Azure Monitor по умолчанию и без дополнительной настройки.
Журналы платформы предоставляют подробные сведения о диагностике и аудите для ресурсов Azure и платформы Azure, от которых они зависят:
- Журналы ресурсов не собираются, пока для них не будет указано место назначения.
- Журнал действий существует самостоятельно, но может быть перенаправлен в другие места.
Для каждого ресурса Azure требуется собственный параметр диагностики, который определяет следующие критерии:
- Источники — тип метрики и данных журналов, отправляемых в места назначения, определенные в параметре. Доступные типы зависят от типа ресурса.
- Назначения — одно или несколько мест назначения.
Один параметр диагностики может определять не более одного назначения каждого типа. Если необходимо отправить данные в места назначения нескольких типов (например, в две разные рабочие области Log Analytics), создайте несколько параметров. Каждый ресурс может иметь до пяти параметров диагностики.
Предупреждение
Если необходимо удалить ресурс, сначала удалите его параметры диагностики. В противном случае при повторном создании этого ресурса параметры диагностики для удаленного ресурса могут быть включены в новый ресурс в зависимости от конфигурации каждого ресурса. Если параметры диагностики включены в новый ресурс, это возобновляет сбор журналов ресурсов, как определено в параметре диагностики, и отправляет соответствующие метрики и данные журнала в ранее настроенное назначение.
Кроме того, рекомендуется удалить параметры диагностики для ресурса, который вы собираетесь удалить, и не планируете использовать его повторно, чтобы обеспечить чистоту среды.
В этом видео показано, как выполнить маршрутизацию журналов платформы ресурсов с помощью параметров диагностики. Видеоролик был снят раньше. Обратите внимание на следующие изменения:
- Сейчас существует четыре места назначения. Метрики и журналы платформы можно отправлять определенным партнерам Azure Monitor.
- В ноябре 2021 года появилась новая функция — группы категорий.
Сведения о новых функциях приведены в этой статье.
Источники
Варианты источников приведены ниже.
Метрики
Параметр AllMetrics направляет метрики платформы ресурсов в другие места назначения. Этот параметр может быть недоступен для некоторых поставщиков ресурсов.
Журналы ресурсов
С помощью журналов можно выбрать категории журналов, которые нужно перенаправлять по отдельности, или выбрать группу категорий.
Примечание
Группы категорий не применяются к метрикам. Группы категорий есть не для всех ресурсов.
Вы можете использовать группы категорий, чтобы динамически собирать журналы ресурсов на основе предварительно определенной группировки, а не выбирать отдельные категории журналов. Корпорация Майкрософт определяет группы, которые помогают отслеживать конкретные случаи использования, во всех службах Azure.
Со временем категории в группе могут обновляться по мере развертывания новых журналов или изменения оценок. Когда категории журналов добавляются в группу категорий или удаляются из нее, коллекция журналов автоматически изменяется без необходимости обновлять параметры диагностики.
При использовании групп категорий вы:
- больше не можете выбирать журналы ресурсов по отдельности на основе отдельных типов категорий.
- больше не можете применять параметры хранения к журналам, отправленным в службу хранилища Azure.
Сейчас существует две группы категорий:
- Все — все журналы ресурсов.
- Аудит — все журналы ресурсов, в которых фиксируется взаимодействие с пользователем с помощью данных или параметров службы. Обратите внимание, что журналы аудита — это попытка каждого поставщика ресурсов предоставить наиболее релевантные данные аудита, но их может быть недостаточно с точки зрения стандартов аудита.
Примечание. Включение аудита для базы данных Azure SQL не включает аудит для базы данных Azure SQL. Чтобы включить аудит базы данных, необходимо включить его в колонке аудита для Базы данных Azure.
Журнал действий
См. раздел Параметры журналов действий.
Места назначения
Журналы и метрики платформы можно отправлять в места назначения, перечисленные в следующей таблице.
Чтобы обеспечить безопасность передаваемых данных, настоятельно рекомендуется настроить протокол TLS. Все конечные точки назначения поддерживают TLS 1.2.
| Назначение | Описание |
|---|---|
| Рабочая область Log Analytics | Метрики преобразуются в форму журнала. Этот параметр может быть недоступен для некоторых типов ресурсов. Отправив их в хранилище журналов Azure Monitor (которое доступно через Log Analytics), вы сможете интегрировать их в запросы, оповещения и визуализации с существующими данными журналов. |
| Учетная запись хранения Azure | Архивирование журналов и метрик в учетную запись хранения оптимально использовать для аудита, статического анализа и резервного копирования. По сравнению с использованием журналов Azure Monitor и рабочей области Log Analytics служба хранилища Azure предполагает меньше затрат, а журналы могут храниться в течение неопределенного срока. |
| Центры событий Azure | Отправка журналов и метрик в Центры событий позволяет выполнять потоковую передачу данных во внешние системы, такие как сторонние решения SIEM и другие решения Log Analytics. |
| Интеграция Azure Monitor с продуктами партнеров | Специализированные средства интеграции могут использоваться для интеграции Azure Monitor с платформами мониторинга сторонних производителей. Это удобно, если вы уже работаете с одним из наших партнеров. |
Параметры журналов действий
В журнале действий используется параметр диагностики, но он имеет собственный пользовательский интерфейс, так как применяется ко всей подписке, а не к отдельным ресурсам. Информация о месте назначения, указанная ниже, остается в силе. Дополнительные сведения см. в разделе Журнал действий Azure.
Требования и ограничения
В этом разделе рассматриваются требования и ограничения.
Время, прежде чем данные телеметрии добираются до места назначения
После настройки параметра диагностики данные должны начать поступать в выбранные места назначения через 90 минут. Если вы не получите информацию в течение 24 часов, то либо
- журналы не создаются или
- что-то не так в базовом механизме маршрутизации. Попробуйте отключить конфигурацию, а затем повторно ее изменить. Если у вас по-прежнему возникают проблемы, обратитесь к поддержка Azure через портал Azure.
Метрики в качестве источника
Существуют определенные ограничения на экспорт метрик:
- Отправка многомерных метрик через параметры диагностики сейчас не поддерживается — метрики с измерениями экспортируются как преобразованные в плоскую структуру одномерные метрики, агрегированные по значениям измерений. Например, метрику IOReadBytes на основе блокчейна можно исследовать и отображать на диаграмме на уровне каждого узла. Однако при экспорте с помощью параметров диагностики эта метрика отображается как общее количество считанных байтов для всех узлов.
- Не все метрики можно экспортировать с помощью параметров диагностики. Из-за внутренних ограничений не все метрики можно экспортировать в журналы Azure Monitor и Log Analytics. Дополнительные сведения см. в столбце Экспортируемые в списке поддерживаемых метрик.
Чтобы изучить эти ограничения для конкретных метрик, вы можете вручную извлечь их из REST API метрик. Затем их можно импортировать в журналы Azure Monitor с помощью API сборщика данных Azure Monitor.
Ограничения по месту назначения
Перед созданием параметра диагностики необходимо создать для него все места назначения. Назначение не обязательно должно находиться в той же подписке, что и ресурс, отправляющий журналы, если пользователь, настраивающий параметр, обладает соответствующим доступом RBAC Azure к обеим подпискам. С помощью Azure Lighthouse также можно обеспечить отправку параметров диагностики в рабочую область, учетную запись хранения или центр событий в другом клиенте Azure Active Directory.
В следующей таблице приведены уникальные требования к каждому назначению, включая региональные ограничения:
| Назначение | Требования |
|---|---|
| Рабочая область Log Analytics | Рабочая область не обязательно должна находиться в том же регионе, что и отслеживаемый ресурс. |
| Учетная запись хранения | Не используйте имеющуюся учетную запись хранения, в которой содержатся другие данные (не данные мониторинга). Это позволит лучше контролировать доступ к данным мониторинга. Если вы архивируете журнал действий и журналы ресурсов, то можете использовать одну и ту же учетную запись хранения для централизованного хранения всех данных мониторинга. Чтобы отправить данные в неизменяемое хранилище, задайте политику неизменяемости для учетной записи хранения, как описано в статье Настройка и администрирование политик неизменяемости для хранилища BLOB-объектов. Необходимо выполнить все действия, описанные в статье по ссылке выше, в том числе включить защищенные операции записи для добавления BLOB-объектов. Учетная запись хранения должна находиться в том же регионе, что и отслеживаемый ресурс, если ресурс является региональным. Параметры диагностики не могут получить доступ к учетным записям хранения при включении виртуальных сетей. Необходимо включить параметр Разрешить доверенным службам Майкрософт обходить этот параметр брандмауэра в учетных записях хранения, чтобы служба параметров диагностики Azure Monitor получила доступ к вашей учетной записи хранения. Конечные точки зоны Azure DNS (предварительная версия) и учетные записи хранения Azure Premium LRS (локально избыточное хранилище) не поддерживаются в качестве назначения журналов или метрик. |
| Центры событий | Политика общего доступа для пространства имен определяет разрешения, предоставленные механизму потоковой передачи. Для потоковой передачи журналов в Центры событий нужны разрешения на управление, отправку и прослушивание. Чтобы обновить параметр диагностики для включения потоковой передачи, необходимо иметь разрешение ListKey для правила авторизации этих Центров событий. Пространство имен концентратора событий должно находиться в том же регионе, что и отслеживаемый ресурс, если ресурс является региональным. Параметры диагностики не могут получить доступ к ресурсам Центров событий, если включены виртуальные сети. Необходимо включить параметр Разрешить доверенным службам Майкрософт обходить этот брандмауэр в центре событий, чтобы служба Azure Monitor (параметры диагностики) получила доступ к ресурсам центров событий. |
| Интеграция с партнерскими решениями | Решения зависят от партнера. Дополнительные сведения см. в статье Интеграция Azure Monitor с продуктами партнеров. |
Управление затратами
Сбор данных в рабочей области Log Analytics связан с затратами, поэтому необходимо собирать только те категории, которые требуются для каждой службы. Объем данных для журналов ресурсов значительно отличается в разных службах.
Вы также можете не собирать метрики платформы из ресурсов Azure, поскольку эти данные уже собираются в метриках. Настраивайте данные диагностики для сбора метрик, только если вам нужны данные метрик в рабочей области для более сложного анализа с помощью запросов к журналам.
Параметры диагностики не позволяют осуществлять детализированную фильтрацию журналов ресурсов. Для определенных категорий могут потребоваться одни журналы и не потребоваться другие. Или может потребоваться удалить ненужные столбцы из данных. В таких случаях используйте преобразования в рабочей области для фильтрации журналов, которые вам не нужны.
Преобразования также можно использовать для снижения требований к хранилищу записей, удаляя столбцы без полезной информации. Например, у вас могут быть события ошибок в журнале ресурсов, о которых вы хотели бы получать предупреждения. Но вам могут не потребоваться определенные столбцы в тех записях, которые содержат большой объем данных. Вы можете создать преобразование для этой таблицы, которая удаляет столбцы.
Совет
Стратегии снижения затрат на Azure Monitor см. в статье Оптимизация затрат и Azure Monitor.
Создание параметров диагностики
Параметры диагностики можно создавать и изменять с использованием нескольких методов.
Параметры диагностики можно настроить на портале Azure в меню Azure Monitor или в меню для ресурса.
Настройка параметров диагностики на портале Azure зависит от ресурса:
Для одного ресурса: выберите пункт Параметры диагностики в разделе Мониторинг в меню ресурса.
Для одного или нескольких ресурсов: выберите пункт Параметры диагностики в разделе Параметры меню Azure Monitor, а затем выберите ресурс.
Для журнала действий: выберите пункт Журнал действий в меню Azure Monitor, а затем выберите Параметры диагностики. Убедитесь, что отключены все устаревшие конфигурации для журнала действий. Инструкции см. в разделе Отключение существующих параметров.
Если параметров для выбранного ресурса не существует, вам будет предложено создать параметр. Выберите Добавить параметр диагностики.
Если для ресурса есть настроенные параметры, отображается их список. Чтобы добавить новые параметры, выберите Добавить параметр диагностики. Или нажмите кнопку Изменить, чтобы изменить существующий параметр. Каждый параметр может иметь не более одного из целевых типов.
Присвойте параметру имя, если его еще нет.
Журналы и метрики для перенаправления. Для журналов выберите группу категорий или установите флажки для каждой категории данных, которые нужно отправить в места назначения, которые вы укажете позже. Списки категорий для разных служб Azure различаются. Выберите AllMetrics, если хотите также сохранять метрики в журналах Azure Monitor.
Сведения о назначении: установите флажок для каждого места назначения. Отображаются параметры, чтобы можно было добавить дополнительные сведения.
Анализ журналов. Укажите подписку и рабочую область. Если у вас нет рабочей области, ее необходимо создать, прежде чем продолжить.
Центры событий. Укажите следующие критерии:
- Subscription — подписка, к которой относится центр событий.
- Пространство имен центра событий: если у вас его нет, необходимо его создать.
- Имя центра событий (необязательно) — имя для отправки всех данных. Если имя не указано, для каждой категории журналов создается концентратор событий. При отправке нескольких категорий может потребоваться указать имя, чтобы ограничить число создаваемых центров событий. Дополнительные сведения доступны в документации по квотам и ограничениям Центрам событий Azure.
- Имя политики центра событий (также необязательно). Политика определяет разрешения, которые предоставляются механизму потоковой передачи. Дополнительные сведения см. в статье Возможности центров событий Azure.
Хранение. Выберите подписку, учетную запись хранения и политику хранения.
Совет
Попробуйте задать для политики хранения значение 0 и использовать Политику жизненного цикла службы хранилища Azure, либо удалить данные из хранилища с помощью запланированного задания. Эти приемы должны обеспечить более последовательную работу.
Во-первых, если вы используете хранилище для архивирования, обычно требуется, чтобы данные хранились более 365 дней.
Во-вторых, если выбрать для политики хранения значение больше 0, дата окончания срока действия будет прикреплена к журналам во время хранения. После сохранения журналов вы не сможете изменить эту дату.
Например, если установить политику хранения для WorkflowRuntime равной 180 дням, а через 24 часа поменять это значение на 365 дней, то журналы, сохраненные в течение первых 24 часов, будут автоматически удалены через 180 дней. Все последующие журналы этого типа будут автоматически удалены через 365 дней. Изменение политики хранения в дальнейшем не приведет к хранению журналов, сохраненных в первые 24 часа, в течение 365 дней.
Интеграция партнеров. Сначала в подписке необходимо установить интеграцию с партнерами. Варианты конфигурации зависят от партнера. Дополнительные сведения см. в статье Интеграция Azure Monitor с продуктами партнеров.
Щелкните Сохранить.
Через несколько секунд в списке параметров для этой фабрики данных появится новый ресурс. Журналы передаются в указанные места назначения по мере создания новых данных о событиях. С момента создания события до его отображения в рабочей области Log Analytics может пройти до 15 минут.
Устранение неполадок
Подсказки для устранения неполадок.
Категория метрики не поддерживается
При развертывании параметра диагностики вы получаете сообщение об ошибке, похожее на "Категория метрик "xxxx" не поддерживается". Эта ошибка может появиться, даже если предыдущее развертывание выполнено успешно.
Эта проблема возникает при использовании шаблона Resource Manager, REST API, CLI или Azure PowerShell. Параметры диагностики, созданные с помощью портала Azure, не затрагиваются, так как там отображаются только имена поддерживаемых категорий.
Проблема вызвана недавним изменением в базовом API. Категории метрик, отличные от AllMetrics, не поддерживаются и никогда не поддерживались, за исключением нескольких специфических служб Azure. В прошлом имена других категорий игнорировались при развертывании параметра диагностики. Серверная часть Azure Monitor перенаправляла эти категории на AllMetrics. По состоянию на февраль 2021 г. серверная часть обновлена и теперь специально проверяет, правильно ли указана категория метрик. Это изменение привело к сбою некоторых развертываний.
При возникновении этой ошибки обновите развертывания, чтобы заменить все имена категорий метрик на AllMetrics, и проблема исчезнет. Если в развертывание ранее было добавлено несколько категорий, сохраните только одну из них с именем AllMetrics. Если проблема не исчезнет, обратитесь в службу поддержки Azure через портал Azure.
Параметр исчезает из-за использования в resourceID символов, не входящих в ASCII
Параметры диагностики не поддерживают идентификаторы ресурсов с символами, отличными от ASCII. Например, рассмотрим термин Preproducción. Поскольку вы не можете переименовывать ресурсы в Azure, единственный вариант — создать новый ресурс без символов, не входящих в ASCII. Если такие символы присутствуют в группе ресурсов, можно переместить ресурсы в новую. В противном случае вам потребуется создавать ресурс повторно.
Возможность дублирования или удаления данных
Предпринимаются все усилия, чтобы обеспечить правильную отправку всех данных журнала в места назначения, однако гарантировать 100%-ную передачу данных журналов между конечными точками невозможно. Существуют повторные попытки и другие механизмы, чтобы обойти эти проблемы и попытаться обеспечить поступление данных журнала в конечную точку.