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

Статья
11/14/2024

Общие сведения об агенте Azure Monitor

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

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

Имя.	Сокращение	Description
Агент Azure Monitor	AMA	Новый агент Azure Monitor
Правила сбора данных	DCR	Правила для настройки сбора данных агентом, т. е. правила, касающихся собираемых данных, назначения, в которое они отправляются, и многого другого
Служба настройки Azure Monitor	AMCS	Региональная служба, размещенная в Azure, которая управляет сбором данных для этого агента и других компонентов Azure Monitor. Агент вызывает эту службу для получения правил DCR.
Конечная точка журналов	--	Конечная точка для отправки данных в рабочие области Log Analytics.
Конечная точка метрик	--	Конечная точка для отправки данных в базы данных метрик Azure Monitor
Служба метаданных экземпляров и гибридная среда	IMDS и HIMDS	Службы, размещенные в Azure, которые предоставляют сведения о работающих сейчас виртуальных машинах, масштабируемых наборах (через IMDS) и серверах с поддержкой Arc (через HIMDS) соответственно.
Рабочая область Log Analytics	LAW	Назначение в Azure Monitor, в которое вы можете отправлять журналы, собранные агентом
Пользовательские метрики	--	Назначение в Azure Monitor, в которое вы можете отправлять гостевые метрики, собранные агентом

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

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

Внимательно изучите предварительные требования, приведенные здесь.
Убедитесь, что расширение успешно установлено и подготовлено, что предусматривает установку двоичных файлов агента на вашем компьютере:
1. Откройте портал Azure > выберите параметры открытия виртуальной машины>: расширения и приложения из области слева > "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/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/ на вашем компьютере.
Проверьте, работает ли агент:
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.* на вашем компьютере.
Убедитесь, что правило DCR существует и связано с виртуальной машиной:
1. При использовании рабочей области Log Analytics в качестве назначения убедитесь, что DCR существует в том же физическом регионе, что и рабочая область Log Analytics.
2. Откройте портал Azure > выберите правило > сбора данных Open Configuration: Ресурсы в области слева > вы увидите виртуальную машину, указанную здесь.
3. Если она не указана, нажмите кнопку "Добавить" и выберите нужную виртуальную машину в средстве выбора ресурсов. Повторите эти действия для всех правил DCR.
Убедитесь, что агенту удалось скачать связанные правила DCR из службы AMCS:
1. Проверьте, отображается ли последнее скачанное правило DCR в этом расположении: /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/.

Проблемы со сбором данных системного журнала

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

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

Например, приведенный ниже фрагмент показывает, что за 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
```

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

Сначала ознакомьтесь с разделом Основные шаги по устранению неполадок с AMA Linux. Если агент генерирует пульс, перейдите к шагу 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 на предмет возможных ошибок конфигурации.
Проверьте макет рабочего процесса сбора данных системного журнала, чтобы убедиться, что все необходимые компоненты установлены и доступны:
1. Для пользователей rsyslog убедитесь, что файл /etc/rsyslog.d/10-azuremonitoragent.conf присутствует, не является пустым и доступен для управляющей программы rsyslog (пользователь системного журнала).
  1. Проверьте конфигурацию /etc/rsyslog.conf rsyslog и /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. Убедитесь, что очередь управляющей программы системного журнала не переполнена, из-за чего происходит сбой отправки. Для этого обратитесь к руководству Данные системного журнала не отправляются из-за отсутствия дискового пространства в агенте Linux AMA.
Для дальнейшей отладки событий системного журнала вы можете добавить флаг трассировки -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"
```
После воспроизведения проблемы с включенным флагом трассировки вы найдете дополнительные сведения об отладке в расположении /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.

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