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

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

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

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

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

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

sudo /opt/microsoft/omsagent/bin/troubleshooter

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

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

1. Убедитесь, что GNU Project отладчик (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.
• Агент Syslog не работает.
• Агент использует большой объем ресурсов ЦП или памяти.
• У агента возникли проблемы с установкой.
• Не работают настраиваемые журналы агента.
• Невозможен сбор журналов агента.

Дополнительные сведения см. в документации Troubleshooting Tool на 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

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

Используйте средство для сбора журналов, чтобы получить важные данные для устранения неполадок или перед отправкой запроса в GitHub. Для получения дополнительной информации о средстве и о том, как его запустить, см. OMS Linux Agent Log Collector.

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

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

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

Отладка подключаемого модуля выходных данных 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 и службы Cлужба автоматизации 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 сети добавляются в список разрешений правильно. Если вы используете Cлужба автоматизации Azure, необходимые шаги по настройке сети уже были предоставлены ранее.

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

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

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

Разрешение

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

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

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

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

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

Регрессия в пакете nss-pem версии 1.0.3-5.el7 приводит к серьезной проблеме производительности. Эта проблема часто отображается в дистрибутивах Redhat и CentOS 7.x. Дополнительные сведения об этой проблеме см. в регрессии производительности 1667121 в libcurl.

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

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 по ошибке, curl обновляется до 7.29.0-51, и проблема повторится:
   sudo yum downgrade curl libcurl

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

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

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

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

Разрешение

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

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

Вы видите [error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224> в файле omsagent.log.

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

Эта ошибка означает, что расширение диагностики Linux (LAD) устанавливается параллельно с расширением виртуальной машины Linux Log Analytics. Они оба используют один и тот же порт для сбора данных Системного журнала, что и 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 был установлен и удален. Однако по-прежнему отображается сообщение об ошибке: mdsd использует omsagent, и его невозможно удалить.

Разрешение

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

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

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

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

Разрешение

1. Добавьте пользователя omsagent для чтения из файла Nagios, следуя этим инструкциям.

2. В общем конфигурационном файле агента Log Analytics для Linux /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.

Разрешение

1. Установите все зависимости, такие как проверенный пакет.

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

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

4. В некоторых системах распространения Azure управляющая программа сервера OMI не запускается после перезагрузки виртуальной машины. Если это условие верно, данные, связанные с решением 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 не взял последнюю конфигурацию.
• Не применены изменения параметров, внесенные на портале.

Разрешение

Background:omsconfig — это агент Log Analytics для конфигурации 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.
• Параметр Применить следующую конфигурацию к серверам 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. Если нет, выполните одно из следующих действий:

   • Повторное подключение с помощью omsadmin.sh команд командной строки instructions.
   1. В параметрах Advanced Settings на портале Azure убедитесь, что параметр Применить следующую конфигурацию к моим серверам 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 и получать последнюю конфигурацию.

Background: вместо агента Log Analytics для Linux, работающего в качестве привилегированного пользователя, — root агент запускается как пользователь 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.

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

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

Для данной известной проблемы, если язык ВМ не английский, проверка версии Python завершится ошибкой. Эта проблема приводит к тому, что агент всегда предполагает, что используется Python 2 и завершается ошибкой, если нет Python 2.

Разрешение

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

export LANG=en_US.UTF-8

Связанный контент

• Перейдите с агента Log Analytics на агента Azure Monitor
• Устранение неполадок агента мониторинга Azure на виртуальных машинах Linux
• Обзор агента Azure Monitor