Устранение проблем с агентом Log Analytics для Linux

  • Статья

Эта статья содержит справку по устранению ошибок, которые могут возникнуть при работе с агентом Log Analytics для Linux в Azure Monitor.

Средство устранения неполадок в Log Analytics

Средство устранения неполадок в агенте Log Analytics для Linux — это вспомогательный скрипт для поиска и диагностики проблем с агентом. Он автоматически включается в состав агента при его установке. Запуск этого средства — рекомендуемый первый шаг по диагностике проблем.

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

Чтобы запустить средство устранения неполадок, на компьютере с агентом Log Analytics вставьте в окне терминала следующую команду:

sudo /opt/microsoft/omsagent/bin/troubleshooter

Установка вручную

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

  1. Убедитесь, что на компьютере установлен отладчик GNU Project Debugger (GDB), необходимый средству устранения неполадок для работы.
  2. Скопируйте пакет установки средства устранения неполадок на свой компьютер: wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
  3. Распакуйте пакет: tar -xzvf omsagent_tst.tar.gz
  4. Выполните установку вручную: sudo ./install_tst

Рассматриваемые сценарии

Средство устранения неполадок проверяет следующие сценарии:

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

Дополнительные сведения см. в документации по средству устранения неполадок на GitHub.

Примечание

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

Очистка и переустановка агента Linux

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

  1. Скачайте сценарий очистки:

    $ wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh

  2. Запустите сценарий очистки (с разрешениями sudo):

    $ sudo sh purge_omsagent.sh

Местонахождение важных журналов и средство сборщика журналируемых данных

Файл Путь
Файл журнала агента Log Analytics для Linux /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
Файл журнала конфигурации агента Log Analytics /var/opt/microsoft/omsconfig/omsconfig.log

Рекомендуем использовать средство сборщика журналируемых данных для получения важных журналов для устранения неполадок, а также перед регистрацией проблемы на GitHub. Дополнительные сведения о средстве и его запуске: Сборщик журналируемых данных агента OMS для Linux.

Важные файлы конфигурации

Категория Размещение файла
Системный журнал /etc/syslog-ng/syslog-ng.conf, /etc/rsyslog.conf или /etc/rsyslog.d/95-omsagent.conf
Производительность, Nagios, Zabbix, выходные данные Log Analytics и общие настройки агента /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
Дополнительные конфигурации /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

Примечание

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

sudo /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable && sudo rm /etc/opt/omi/conf/omsconfig/configuration/Current.mof* /etc/opt/omi/conf/omsconfig/configuration/Pending.mof*

Коды ошибок установки

Код ошибки Значение
NOT_DEFINED Подключаемый модуль auoms auditd не будет установлен, так как не установлены необходимые зависимости. Установка auoms не выполнена. Установите пакет auditd.
2 Набору оболочки предоставлен недопустимый параметр. Выполните sudo sh ./omsagent-*.universal*.sh --help, чтобы получить сведения об использовании.
3 Набору оболочки не предоставлен параметр. Выполните sudo sh ./omsagent-*.universal*.sh --help, чтобы получить сведения об использовании.
4 Недопустимый тип пакета или недопустимые параметры прокси-сервера. Пакеты omsagent-rpm.sh можно устанавливать только для систем на основе RPM. Пакеты omsagent-deb.sh можно устанавливать только для систем на основе Debian. Рекомендуем использовать универсальный установщик из последнего выпуска. Кроме того, просмотрите и проверьте настройки прокси-сервера.
5 Пакет оболочки должен выполняться от имени привилегированного пользователя, или при подключении получена ошибка 403. Выполните команду с использованием sudo.
6 Недопустимая архитектура пакета, или при подключении получена ошибка 200. Пакеты omsagent-*x64.sh можно устанавливать только на 64-разрядных системах. Пакеты omsagent-*x86.sh можно устанавливать только на 32-разрядных системах. Скачайте правильный пакет для используемой архитектуры из последнего выпуска.
17 Не удалось установить пакет OMS. Просмотрите выходные данные команды, чтобы определить причину сбоя.
18 Не удалось установить пакет OMSConfig. Просмотрите выходные данные команды, чтобы определить причину сбоя.
19 Не удалось установить пакет OMI. Просмотрите выходные данные команды, чтобы определить причину сбоя.
20 Не удалось установить пакет SCX. Просмотрите выходные данные команды, чтобы определить причину сбоя.
21 Не удалось установить комплекты поставщика. Просмотрите выходные данные команды, чтобы определить причину сбоя.
22 Не удалось установить объединенный пакет. Просмотрите выходные данные команды, чтобы найти причину сбоя.
23 Пакет SCX или OMI уже установлен. Используйте --upgrade вместо --install, чтобы установить пакет оболочки.
30 Внутренняя ошибка пакета. Сообщите об ошибке на GitHub, предоставив сведения из выходных данных.
55 Версия openssl не поддерживается, или невозможно подключиться к Azure Monitor, или пакет dpkg заблокирован, или отсутствует программа curl.
61 Отсутствует библиотека ctypes для Python. Установите библиотеку ctypes Python или соответствующий пакет (python-ctypes).
62 Отсутствует программа tar. Установите tar.
63 Отсутствует программа sed. Установите sed.
64 Отсутствует программа curl. Установите curl.
65 Отсутствует программа gpg. Установите gpg.

Коды ошибок подключения

Код ошибки Значение
2 Скрипту omsadmin предоставлен недопустимый параметр. Выполните sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h, чтобы получить сведения об использовании.
3 Скрипту omsadmin предоставлена недопустимая конфигурация. Выполните sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h, чтобы получить сведения об использовании.
4 Скрипту omsadmin предоставлена недопустимый прокси-сервер. Проверьте прокси-сервер и изучите документацию по использованию прокси-сервера HTTP.
5 Azure Monitor выдал ошибку HTTP 403. Изучите выходные данные скрипта omsadmin, чтобы получить подробные сведения.
6 Azure Monitor выдал ошибку, кроме HTTP 200. Изучите выходные данные скрипта omsadmin, чтобы получить подробные сведения.
7 Не удалось подключиться к Azure Monitor. Изучите выходные данные скрипта omsadmin, чтобы получить подробные сведения.
8 Ошибка подключения к рабочей области Log Analytics. Изучите выходные данные скрипта omsadmin, чтобы получить подробные сведения.
30 Внутренняя ошибка скрипта. Сообщите об ошибке на GitHub, предоставив сведения из выходных данных.
31 Ошибка при создании идентификатора агента. Сообщите об ошибке на GitHub, предоставив сведения из выходных данных.
32 Ошибка создания сертификата. Изучите выходные данные скрипта omsadmin, чтобы получить подробные сведения.
33 Ошибка при создании метаконфигурации для omsconfig. Сообщите об ошибке на GitHub, предоставив сведения из выходных данных.
34 Скрипт создания метаконфигурации отсутствует. Повторите попытку подключения с помощью sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>.

Включение ведения журнала отладки

Отладка в подключаемом модуле выходных данных OMS

Fluentd позволяет задавать разные уровни ведения журнала для входных и выходных данных и для конкретных подключаемых модулей. Чтобы изменить уровень ведения журнала для выходных данных OMS, измените общую конфигурацию агента в файле /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

В подключаемом модуле выходных данных OMS перед окончанием файла конфигурации измените значение свойства log_level с info на debug:

<match oms.** docker.**>
  type out_oms
  log_level debug
  num_threads 5
  buffer_chunk_limit 5m
  buffer_type file
  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
  buffer_queue_limit 10
  flush_interval 20s
  retry_limit 10
  retry_wait 30s
</match>

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

Пример журнала, включающего данные отладки:

Success sending oms.nagios x 1 in 0.14s
Success sending oms.omi x 4 in 0.52s
Success sending oms.syslog.authpriv.info x 1 in 0.91s

Подробные выходные данные

Вместо подключаемого модуля выходных данных OMS вы можете выводить элементы данных напрямую в stdout. Этот вывод отображается в файле журнала агента Log Analytics для Linux.

В файле общей конфигурации агента Log Analytics по адресу /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf закомментируйте подключаемый модуль выходных данных OMS, добавив в начало каждой строки символ #:

#<match oms.** docker.**>
#  type out_oms
#  log_level info
#  num_threads 5
#  buffer_chunk_limit 5m
#  buffer_type file
#  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
#  buffer_queue_limit 10
#  flush_interval 20s
#  retry_limit 10
#  retry_wait 30s
#</match>

Ниже после подключаемого модуля раскомментируйте следующий раздел, удалив # перед каждой строкой:

<match **>
  type stdout
</match>

Проблема. Не удается подключиться к Azure Monitor через прокси-сервер

Возможные причины

  • При подключении был указан недопустимый прокси-сервер.
  • Конечные точки службы Azure Monitor и службы автоматизации Azure не включены в утвержденный список в вашем центре обработки данных.

Решение

  1. Повторно подключитесь к Azure Monitor через агент Log Analytics для Linux, используя следующую команду с включенным параметром -v. Он включает подробные выходные данные агента при подключении к Azure Monitor через прокси-сервер: /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

  2. Воспользуйтесь разделом Обновление параметров прокси-сервера и проверьте настройку агента для обмена данными через прокси-сервер.

  3. Убедитесь, что конечные точки, описанные в списке требований к брандмауэру сети Azure Monitor, правильно добавлены в список разрешений. Если вы используете службу автоматизации Azure, необходимые этапы настройки сети также приведены по ссылке выше.

Проблема. При попытке подключения возникает ошибка 403.

Возможные причины

  • На сервере Linux неверно установлены дата и время.
  • Идентификатор и ключ рабочей области неверны.

Решение

  1. Проверьте время на своем сервере Linux с помощью команды. Если время отличается от текущего на 15 минут, подключение завершится сбоем. Чтобы исправить это, обновите на сервере Linux дату и (или) часовой пояс.
  2. Убедитесь, что установлена последняя версия агента Log Analytics для Linux. В последней версии вы получаете уведомления, если разница во времени приводит к сбою подключения.
  3. Повторите подключение, используя корректный идентификатор и ключ рабочей области и следуя инструкциям по установке, приведенным ранее в этой статье.

Проблема. Сразу после подключения в файле журнала появляется ошибка 500 и 404.

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

Проблема. Вы видите, что omiagent использует 100 % ЦП

Возможные причины

Регрессия в пакете nss-pem v1.0.3-5.el7 вызвала серьезную проблему с производительностью. Мы часто сталкивались с этой проблемой в дистрибутивах Redhat/CentOS 7.x. Дополнительные сведения: Ошибка 1667121 — регрессия в производительности libcurl.

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

  1. Скачайте скрипт:
    wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh

  2. Запустите диагностику на 24 часа с пороговым значением загрузки ЦП в 30 %:
    bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

  3. Будет создан дамп стека вызовов в файле omiagent_trace. Если вы заметите много вызовов функций curl и NSS, выполните следующие действия для решения проблемы.

Решение

  1. Обновите пакет nss-pem до версии 1.0.3-5.el7_6.1:
    sudo yum upgrade nss-pem

  2. Если nss-pem недоступен для обновления, что в основном происходит в CentOS, понизите версию curl до версии 7.29.0-46. Если по ошибке выполнить команду "yum update", версия curl будет обновлена до 7.29.0-51 и проблема возникнет вновь:
    sudo yum downgrade curl libcurl

  3. Перезапустите OMI:
    sudo scxadmin -restart

Проблема: не отображаются перенаправленные сообщения системного журнала

Возможные причины

  • Применяемая конфигурация сервера Linux не позволяет осуществлять сбор данных с использованием отправленных средств или уровней ведения журнала.
  • Системный журнал не переадресуется на сервер Linux должным образом.
  • Число переадресуемых в секунду сообщений слишком велико, и агент Log Analytics для Linux в базовой конфигурации не может их обработать.

Решение

  • Убедитесь, что в рабочей области Log Analytics для системного журнала предоставлены все средства и правильно настроены уровни ведения журнала. См. сведения о настройке сбора данных системного журнала на портале Azure.
  • Убедитесь, что встроенные управляющие программы для сообщений системного журнала (rsyslog, syslog-ng) могут получать переадресуемые сообщения.
  • Отключите блокировку сообщений в параметрах брандмауэра на сервере системного журнала.
  • Смоделируйте отправку сообщения системного журнала в Log Analytics с помощью команды logger:
    logger -p local0.err "This is my test message"

Проблема: возникает ошибка address already in use in omsagent log file (адрес уже используется в файле журнала агента OMS)

В omsagent.log отображается ошибка [error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224>.

Возможные причины

Эта ошибка указывает, что диагностическое расширение для Linux (LAD) установлено параллельно с расширением Log Analytics для виртуальной машины Linux. Оно использует тот же порт для сбора данных системного журнала, что и omsagent.

Решение

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

    /opt/microsoft/omsagent/bin/configure_syslog.sh configure LAD 25229

sed -i -e 's/25224/25229/' /etc/opt/microsoft/omsagent/LAD/conf/omsagent.d/syslog.conf

    После этого измените нужный файл конфигурации rsyslogd или syslog_ng, изменив настройки для LAD таким образом, чтобы запись выполнялась через порт 25229.

  2. Если виртуальная машина выполняет rsyslogd, необходимо изменить файл /etc/rsyslog.d/95-omsagent.conf (если он существует) или /etc/rsyslog. Если виртуальная машина выполняет syslog_ng, нужно изменить файл /etc/syslog-ng/syslog-ng.conf.

  3. Перезапустите omsagent sudo /opt/microsoft/omsagent/bin/service_control restart.

  4. Перезапустите службу системного журнала.

Проблема: невозможно удалить omsagent с помощью функции очистки

Возможные причины

  • Установлено диагностическое расширение для Linux.
  • Диагностическое расширение для Linux было установлено, а затем удалено, но вы по-прежнему получаете сообщение об ошибке, говорящее, что агент omsagent используется mdsd и не может быть удален.

Решение

  1. Удалите диагностическое расширение для Linux.
  2. Удалите файлы диагностического расширения для Linux с компьютера, если они есть в расположениях /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ и /var/opt/microsoft/omsagent/LAD/.

Проблема: не отображаются данные Nagios

Возможные причины

  • Пользователь omsagent не имеет разрешений на чтение из файла журнала Nagios.
  • Источник и фильтр Nagios не раскомментированы в файле omsagent.conf.

Решение

  1. Предоставьте пользователю omsagent право на чтение из файла Nagios, выполнив эти инструкции.

  2. В файле общей конфигурации агента Log Analytics, в области кода /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf убедитесь, что обе строки источника и фильтра Nagios раскомментированы.

    <source>
  type tail
  path /var/log/nagios/nagios.log
  format none
  tag oms.nagios
</source>

<filter oms.nagios>
  type filter_nagios_log
</filter>

Проблема: не отображаются данные Linux

Возможные причины

  • Сбой подключения к Azure Monitor.
  • Подключение к Azure Monitor заблокировано.
  • Виртуальная машина была перезагружена.
  • Пакет OMI обновлен вручную до более новой версии, чем установленная пакетом агента Log Analytics для Linux.
  • Работа OMI зависла, и агент OMS заблокирован.
  • Ошибка не удалось найти класс в файле журналов omsconfig.log для ресурса DSC.
  • Агент Log Analytics перегружен данными.
  • Журналы DSC Текущая конфигурация не существует. Выполните команду Start-DscConfiguration с параметром -Path, чтобы указать файл конфигурации и сначала создать текущую конфигурацию. в omsconfig.log файле журнала, но сообщение журнала об PerformRequiredConfigurationChecks операциях не существует.

Решение

  1. Установите все зависимости, включая пакет auditd.

  2. Проверьте состояние подключения к Azure Monitor, убедившись в наличии следующего файла: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Если подключение не установлено, повторите его, используя инструкции по omsadmin.sh для командной строки.

  3. Если используется прокси-сервер, см. приведенные выше действия по устранению неполадок для прокси-сервера.

  4. В некоторых системах распространения Azure управляющая программа сервера OMI (omid) не запускается после перезагрузки виртуальной машины. В этом случае связанные с решением данные Audit, ChangeTracking или UpdateManagement отображаться не будут. В качестве обходного решения запустите сервер OMI вручную, выполнив команду sudo /opt/omi/bin/service_control restart.

  5. Если вы обновили пакет OMI вручную до более новой версии, необходимо вручную перезапустить его, чтобы агент Log Analytics продолжил работу. Этот шаг необходим для некоторых дистрибутивов, в которых сервер OMI не запускается после обновления автоматически. Чтобы перезапустить OMI, выполните команду sudo /opt/omi/bin/service_control restart.

    В некоторых ситуациях работа OMI может зависнуть. В ожидании OMI агент OMS может перейти в заблокированное состояние, когда сбор всех данных блокируется. Процесс агента OMS будет активен, но никаких действий выполняться не будет, что подтверждается отсутствием новых строк (например отправки пульса) в журнале omsagent.log. Перезапустите OMI с помощью команды sudo /opt/omi/bin/service_control restart, чтобы восстановить работу агента.

  6. Если в файле omsconfig.log есть ошибка не удалось найти класс для ресурса DSC, выполните команду sudo /opt/omi/bin/service_control restart.

  7. Иногда, если агент Log Analytics для Linux не может установить связь с Azure Monitor, данные в агенте заполняют весь объем буфера в 50 МБ. Перезапустите агент с помощью следующей команды: /opt/microsoft/omsagent/bin/service_control restart.

    Примечание

    Эта проблема исправлена в агенте версии 1.1.0-28 и более поздних версиях.

    • Если файл журнала omsconfig.log не показывает, что в системе периодически выполняются операции PerformRequiredConfigurationChecks, может иметься проблема с заданием или службой cron. Убедитесь, что задание cron есть в разделе /etc/cron.d/OMSConsistencyInvoker. При необходимости создайте задание cron, выполнив следующие команды:

      mkdir -p /etc/cron.d/
echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee /etc/cron.d/OMSConsistencyInvoker

    • Кроме того, убедитесь, что служба cron запущена. Чтобы проверить состояние этой службы, в Debian, Ubuntu и SUSE используйте service cron status, а в RHEL, CentOS и Oracle Linux — service crond status. Если служба отсутствует, установите ее двоичные файлы и запустите службу с помощью следующих инструкций:

      Ubuntu и Debian

      # To Install the service binaries
sudo apt-get install -y cron
# To start the service
sudo service cron start

      SUSE

      # To Install the service binaries
sudo zypper in cron -y
# To start the service
sudo systemctl enable cron
sudo systemctl start cron

      RHEL или CentOS

      # To Install the service binaries
sudo yum install -y crond
# To start the service
sudo service crond start

      Oracle Linux

      # To Install the service binaries
sudo yum install -y cronie
# To start the service
sudo service crond start

Проблема: не применяются настроенные на портале параметры сбора данных для счетчиков производительности Linux или системного журнала

Возможные причины

  • Агент Log Analytics для Linux не применил последнюю конфигурацию.
  • Не применены изменения параметров, внесенные на портале.

Решение

Базовая информация: агент Log Analytics omsconfig для агента конфигурации Linux каждые пять минут выполняет поиск новых параметров конфигурации на стороне портала. Найденная конфигурация переносится в файлы конфигурации агента Log Analytics для Linux в следующем расположении: /etc/opt/microsoft/omsagent/conf/omsagent.conf.

Иногда агент Log Analytics для Linux не может установить связь со службой конфигурации портала. В результате этого в данном сценарии последняя конфигурация не применяется.

  1. Убедитесь, что агент omsconfig установлен, выполнив dpkg --list omsconfig или rpm -qi omsconfig. Если он не установлен, переустановите последнюю версию агента Log Analytics для Linux.

  2. Проверьте, может ли агент omsconfig взаимодействовать с Azure Monitor, выполнив команду sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Эта команда возвращает конфигурацию, которую агент получает от службы, включающую параметры системного журнала, счетчики производительности Linux и настраиваемые журналы. Если команда не сработает, выполните команду sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Эта команда заставляет агент omsconfig обратиться к Azure Monitor для получения последней конфигурации.

Проблема: не отображаются данные настраиваемых журналов

Возможные причины

  • Не удалось подключиться к Azure Monitor.
  • Не задан параметр Apply the following configuration to my Linux Servers (Применить следующую конфигурацию к моим серверам Linux).
  • Агент omsconfig не получил от службы последнюю конфигурацию настраиваемых журналов.
  • Пользователь агента Log Analytics для Linux omsagent не может получить доступ к настраиваемому журналу из-за отсутствия прав или файла. Возможны следующие ошибки:
    • [DATETIME] [warn]: file not found. Continuing without tailing it.
    • [DATETIME] [error]: file not accessible by omsagent.
  • Известная проблема состояния гонки исправлена в агенте Log Analytics для Linux версии 1.1.0-217.

Решение

  1. Проверьте состояние подключения к Azure Monitor, убедившись в наличии следующего файла: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Если его нет, выполните одно из следующих действий:

    1. Повторите подключение, используя инструкции по omsadmin.sh для командной строки.
    2. Убедитесь, что в разделе Дополнительные параметры на портале Azure установлен флажок Apply the following configuration to my Linux Servers (Применить следующую конфигурацию к моим серверам Linux).

  2. Проверьте, может ли агент omsconfig взаимодействовать с Azure Monitor, выполнив команду sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Эта команда возвращает конфигурацию, которую агент получает от службы, включающую параметры системного журнала, счетчики производительности Linux и настраиваемые журналы. Если команда не сработает, выполните команду sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Эта команда заставляет агент omsconfig обратиться к Azure Monitor и получить последнюю конфигурацию.

Базовая информация. Вместо привилегированного пользователя (root) для выполнения агента Log Analytics для Linux используется имя пользователя omsagent. В большинстве случаев этому пользователю необходимо предоставить явные права на чтение определенных файлов. Чтобы предоставить разрешения пользователю omsagent, выполните следующие команды:

  1. Добавьте пользователя omsagent в определенную группу: sudo usermod -a -G <GROUPNAME> <USERNAME>.
  2. Предоставьте универсальный доступ на чтение требуемого файла: sudo chmod -R ugo+rx <FILE DIRECTORY>.

Существует известная проблема с состоянием гонки в агенте Log Analytics для Linux версий до 1.1.0-217. После обновления агента до последней версии выполните следующую команду, чтобы получить последнюю версию подключаемого модуля выходных данных: sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Проблема: попытка повторного подключения к новой рабочей области

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

sudo sh ./omsagent-*.universal.x64.sh --purge

либо

sudo sh ./onboard_agent.sh --purge

После использования параметра --purge можно продолжить повторное подключение.

Проблема: пометка о состоянии сбоя подготовки для расширения агента Log Analytics на портале Azure

Возможные причины

  • Агент Log Analytics был удален из операционной системы.
  • Служба агента Log Analytics не работает, отключена или не настроена.

Решение

  1. Удалите расширение с портала Azure.
  2. Установите агент в соответствии с инструкциями.
  3. Перезапустите агент, выполнив следующую команду.
    sudo /opt/microsoft/omsagent/bin/service_control restart.
  4. Подождите несколько минут, чтобы состояние подготовки изменилось на Подготовка успешно завершена.

Проблема: агент Log Analytics требует выполнить обновление

Возможные причины

Устарели пакеты агента Log Analytics на узле.

Решение

  1. Проверьте наличие последнего выпуска на этой странице GitHub.

  2. Скачайте скрипт установки (1.4.2-124 — это пример версии):

    wget https://github.com/Microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_GA_v1.4.2-124/omsagent-1.4.2-124.universal.x64.sh

  3. Обновите пакеты, выполнив команду sudo sh ./omsagent-*.universal.x64.sh --upgrade.

Проблема: сбой установки с сообщением об отсутствии поддержки ctypes в Python2, хотя используется Python3

Возможные причины

Это известная проблема. Если на виртуальной машине используется не английский язык, то проверка используемой версии Python не проходится. Из-за этой проблемы агент всегда предполагает использование Python2 и при отсутствии этой версии выдает сбой.

Решение

Измените язык среды виртуальной машины на английский:

export LANG=en_US.UTF-8