Руководство по устранению неполадок агента Azure Monitor на виртуальных машинах Linux и масштабируемых наборах

Обзор агента Azure Monitor

Прежде чем читать дальше, необходимо ознакомиться с агентом Azure Monitor и правилами сбора данных.

Терминология

Основные шаги по устранению неполадок

Чтобы устранить неполадки с последней версией агента Azure Monitor, работающего на виртуальной машине Linux, выполните следующие действия.

1. Внимательно изучите предварительные требования, приведенные здесь.

2. Убедитесь, что расширение успешно установлено и подготовлено, что предусматривает установку двоичных файлов агента на вашем компьютере:

   1. Откройте портал Azure > выберите виртуальную машину > Open Settings : Extensions + приложения на панели слева > "AzureMonitorLinuxAgent" должно отображаться с состоянием: "Подготовка выполнена успешно".

   2. Если вы не видите указанное расширение, проверьте, может ли компьютер достичь Azure и найти расширение для установки с помощью следующей команды:

      az vm extension image list-versions --location <machine-region> --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor
      

   3. Подождите 10–15 минут, поскольку расширение может находиться в переходном режиме. Если оно по-прежнему не отображается, как описано ранее, удалите и установите расширение еще раз.

   4. Проверьте наличие ошибок в журналах расширений, расположенных по адресу /var/log/azure/Майкрософт.Azure.Monitor.AzureMonitorLinuxAgent/ на компьютере

3. Проверьте, работает ли агент:

   1. Проверьте, генерирует ли агент журналы пульса для Log Analytics рабочей области с помощью следующего запроса. Пропустите, если "Пользовательские метрики" — единственный пункт назначения в правиле сбора данных (DCR):

      Heartbeat | where Category == "Azure Monitor Agent" and Computer == "<computer-name>" | take 10
      

   2. Проверьте, запущена ли служба агента

      systemctl status azuremonitoragent
      

   3. Проверьте, отображаются ли сообщения об ошибках в журналах основного агента, расположенных по пути /var/opt/microsoft/azuremonitoragent/log/mdsd.* на вашем компьютере.

4. ** Убедитесь в наличии DCR и его ассоциации с виртуальной машиной:

   1. При использовании рабочей области Log Analytics в качестве места назначения убедитесь, что DCR существует в том же физическом регионе, что и рабочая область Log Analytics.
   2. Откройте портал Azure > выберите правило сбора данных > Open Configuration : Resources на панели слева > Вы увидите виртуальную машину, указанную здесь.
   3. Если он не указан, выберите "Добавить " и выберите виртуальную машину из средства выбора ресурсов. Повторите для всех DCR.

5. Убедитесь, что агент смог скачать связанные правила сбора данных (DCR) из службы AMCS:

   1. Проверьте, видите ли вы последнюю версию DCR, загруженную в этом расположении: /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/.

6. Если каталог или файлы отсутствуют:

   1. Агент Azure Monitor не смог скачать правило сбора данных (DCR) из службы конфигурации Azure Monitor (AMCS).
   2. Обычно это означает одно из следующих элементов:
   3. Виртуальная машина не связана с любым DCR.
   4. Виртуальная машина не может достичь AMCS из-за ограничений сети или DNS.
   5. Служба агента Azure Monitor не запущена или вышла из строя при запуске.

7. Выполните следующие действия:

   1. Убедитесь, что DCR связан с виртуальной машиной:

      • Портал Azure → Правила сбора данных → Выберите ваш DCR → Ресурсы
      • Убедитесь, что виртуальная машина появится в списке.

   2. Проверьте исходящее подключение с виртуальной машины:

      curl -v https://global.handler.control.monitor.azure.com
      

   3. Успешное подключение TLS подтверждает, что виртуальная машина может получить доступ к AMCS.

   4. Перезапустите агент:

      sudo systemctl restart azuremonitoragent
      sudo systemctl status azuremonitoragent
      

   5. Проверьте журналы ошибок агента:

      sudo tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.err
      

8. Как выглядит допустимый файл конфигурации:

   1. Каждый файл под /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/ представляет собой разобранное правило сбора данных, скачанное из Azure.

   2. Пример:

      ls /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/
      

   3. Выходные данные:

      dcr_1a2b3c4d.json
      dcr_5e6f7g8h.json
      

   4. Проверка файла:

      cat /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/dcr_1a2b3c4d.json
      

   5. Обычное содержимое:

      {
      "dataSources": {
      "syslog": [
      {
      "facilityNames": ["daemon"],
      "logLevels": ["Info", "Warning", "Error"]
      }
      ]
      },
      "destinations": {
      "logAnalytics": [
      {
      "workspaceResourceId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>"
      }
      ]
      }
      }
      

Если эти файлы пусты, отсутствуют или неправильно сформированы, агент не собирает или не отправляет данные.

Проблемы со сбором Syslog

Дополнительные сведения об устранении неполадок системного журнала с агентом Azure Monitor см. в разделе here.

• Файл качества обслуживания (QoS) /var/opt/microsoft/azuremonitoragent/log/mdsd.qos предоставляет 15-минутные агрегаты обработанных событий в формате CSV и содержит сведения о количестве обработанных событий системного журнала в заданном временном интервале. Этот файл полезен при отслеживании падений поступления событий Syslog.

  В следующем примере показано, что в течение 15 минут до этого 2022-02-28T19:55:23.5432920Zагент получил 77 событий системного журнала с управляющей функцией объекта и сведениями о уровне и отправил 77 из указанных событий в задачу отправки. Кроме того, задача загрузки агента получила 77 сообщений в формате daemon.info и успешно загрузила все 77 из них.

  #Time: 2022-02-28T19:55:23.5432920Z
  #Fields: Operation,Object,TotalCount,SuccessCount,Retries,AverageDuration,AverageSize,AverageDelay,TotalSize,TotalRowsRead,TotalRowsSent
  ...
  MaRunTaskLocal,daemon.debug,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.info,15,15,0,60000,46.2,0,693,77,77
  MaRunTaskLocal,daemon.notice,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.warning,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.error,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.critical,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.alert,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.emergency,15,15,0,60000,0,0,0,0,0
  ...
  MaODSRequest,https://e73fd5e3-ea2b-4637-8da0-5c8144b670c8_LogManagement,15,15,0,455067,476.467,0,7147,77,77
  

Действия по устранению неполадок

1. Сначала ознакомьтесь с разделом Основные шаги по устранению неполадок с AMA Linux. Если агент генерирует пульс, перейдите к шагу 2.

2. Проанализированная конфигурация хранится в расположении /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/. Убедитесь, что сбор данных системного журнала определен, а назначения журнала совпадают с назначениями, созданными в пользовательском интерфейсе DCR или JSON DCR.

   1. Если это так, перейдите к шагу 3. Если нет, проблема связана с рабочим процессом конфигурации.
   2. Изучите файлы mdsd.err,mdsd.warn и mdsd.info в разделе /var/opt/microsoft/azuremonitoragent/log на предмет возможных ошибок конфигурации.

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

   1. Для пользователей rsyslog убедитесь, что файл /etc/rsyslog.d/10-azuremonitoragent.conf присутствует, не является пустым и доступен для управляющей программы rsyslog (пользователь системного журнала).
      1. Проверьте конфигурацию rsyslog по адресу /etc/rsyslog.conf и /etc/rsyslog.d/*, чтобы узнать, привязаны ли какие-либо входные данные к неразделимому набору правил, так как сообщения из этих входных данных не перенаправляются в агент Azure Monitor. Например, сообщения из входа, настроенные с нестандартным набором правил, как input(type="imtcp" port="514" ruleset="myruleset"), не пересылаются.
   2. Для пользователей syslog-ng убедитесь, что файл /etc/syslog-ng/conf.d/azuremonitoragent.conf присутствует, не является пустым и доступен для управляющей программы syslog-ng (пользователь системного журнала).
   3. Убедитесь, что файл /run/azuremonitoragent/default_syslog.socket существует и доступен для rsyslog или syslog-ng соответственно.
   4. Убедитесь, что очередь демона syslog не переполнена, что приводит к сбою отправки. Для этого обратитесь к руководству Данные Rsyslog не отправлены из-за проблемы с полным дисковым пространством на агенте AMA Linux.

4. Для отладки приема событий syslog можно использовать флаг трассировки -T 0x2002 в конце MDSD_OPTIONS в файле /etc/default/azuremonitoragent, и затем перезапустить агент:

   export MDSD_OPTIONS="-A -c /etc/opt/microsoft/azuremonitoragent/mdsd.xml -d -r $MDSD_ROLE_PREFIX -S $MDSD_SPOOL_DIRECTORY/eh -L $MDSD_SPOOL_DIRECTORY/events -e $MDSD_LOG_DIR/mdsd.err -w $MDSD_LOG_DIR/mdsd.warn -o $MDSD_LOG_DIR/mdsd.info -T 0x2002"
   

5. После воспроизведения проблемы с включенным флагом трассировки вы найдете больше информации об отладке в /var/opt/microsoft/azuremonitoragent/log/mdsd.info. Проверьте файл, чтобы найти возможную причину проблемы со сбором данных системного журнала (например, синтаксический анализ, обработка, настройка и отправка сообщений об ошибках).

   Предупреждение

   Убедитесь, что удалили установку флага трассировки -T 0x2002 после завершения сеанса отладки, так как он создает множество инструкций трассировки, которые могут быстрее заполнить диск или усложнить визуальный анализ файла журнала.

Устранение неполадок на сервере с поддержкой Arc

Если после проверки основных действий по устранению неполадок вы не видите, как агент Azure Monitor записывает журналы, или появилось сообщение об ошибке 'Не удалось получить токен MSI с конечной точки IMDS' в файле журнала /var/opt/microsoft/azuremonitoragent/log/mdsd.err, вероятно, пользователь syslog не является членом группы himds. Добавьте syslog пользователя в himds группу пользователей, если пользователь не является членом этой группы. При необходимости создайте пользователя syslog и группу syslogи убедитесь, что пользователь находится в этой группе. Для получения дополнительной информации об условиях аутентификации серверов, включенных в Azure Arc, см. здесь.

Проблемы с автоматическими обновлениями в Масштабируемые наборы виртуальных машин

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

Вы можете применить последнюю модель на портале Azure или программно.

az vmss update-instances -g <resource-group> -n <vmss> --instance-ids "*"

Update-AzVmssInstance -ResourceGroupName <resource-group> -VMScaleSetName <vmss> -InstanceId "*"

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

az vmss update -g <resource-group> -n <vmss> --set upgradePolicy.mode=Rolling

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