Linux용 Log Analytics 에이전트 문제 해결

이 문서에서는 Azure Monitor의 Linux용 Log Analytics 에이전트에서 발생할 수 있는 오류 문제 해결에 대한 문서를 제공합니다.

Log Analytics 문제 해결 도구

Linux용 Log Analytics 에이전트 문제 해결 도구는 Log Analytics 에이전트의 문제를 찾고 진단하는 데 도움이 되도록 설계된 스크립트입니다. 이는 설치 시 자동으로 에이전트에 포함됩니다. 이 도구의 실행은 문제를 진단하는 첫 번째 단계여야 합니다.

문제 해결 도구 사용

문제 해결 도구를 실행하려면 다음 명령을 Log Analytics 에이전트가 있는 컴퓨터의 터미널 창에 붙여넣습니다.

sudo /opt/microsoft/omsagent/bin/troubleshooter

수동 설치

문제 해결 도구는 Log Analytics 에이전트가 설치될 때 자동으로 포함됩니다. 어떤 방식으로든 설치에 실패하면 도구를 수동으로 설치할 수도 있습니다.

1. 컴퓨터에서 문제 해결사를 사용하므로 GDB(GNU 프로젝트 디버거)가 해당 컴퓨터에 설치되어 있는지 확인합니다.
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 에이전트가 작동하지 않습니다.
• 에이전트의 CPU 또는 메모리 사용량이 높습니다.
• 에이전트에 설치 문제가 있습니다.
• 에이전트 사용자 지정 로그가 작동하지 않습니다.
• 에이전트 로그를 수집할 수 없습니다.

자세한 내용은 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 에이전트 로그 수집기를 참조하세요.

중요 구성 파일

설치 오류 코드

온보딩 오류 코드

디버그 로깅 활성화

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 출력 플러그 인을 사용하는 대신 Linux용 Log Analytics 에이전트 로그 파일에 표시되는 stdout에 직접 데이터 항목을 출력할 수 있습니다.

/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf의 Log Analytics 일반 에이전트 구성 파일에서 #을 각 줄 앞에 추가하여 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 Automation 서비스 엔드포인트가 데이터 센터의 승인된 목록에 포함되어 있지 않습니다.

해결

1. 다음 명령을 -v 옵션 사용 상태로 사용하여 Linux용 Log Analytics 에이전트로 Azure Monitor에 다시 온보딩합니다. 그러면 프록시를 통해 Azure Monitor에 연결하는 에이전트의 자세한 정보를 출력할 수 있습니다. /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

2. 프록시 설정 업데이트 섹션을 검토하여 에이전트에서 프록시 서버를 통해 통신하도록 제대로 구성했는지 확인합니다.

3. Azure Monitor 네트워크 방화벽 요구 사항 목록에 설명된 엔드포인트가 허용 목록에 올바르게 추가되었는지 다시 확인합니다. Azure Automation을 사용하는 경우 필요한 네트워크 구성 단계도 위에서 연결됩니다.

문제: 등록하는 동안 403 오류 발생

가능한 원인

• Linux 서버에서 날짜 및 시간이 잘못되었습니다.
• 작업 영역 ID 및 작업 영역 키가 잘못되었습니다.

해결

1. 명령 시간을 사용하여 Linux 서버에서 시간을 확인합니다. 시간이 현재 시간에서 15분 이상/이하인 경우 온보딩이 실패합니다. 이 상황을 수정하려면 Linux 서버의 날짜 및/또는 표준 시간대를 업데이트합니다.
2. Linux용 Log Analytics 에이전트 최신 버전이 설치되어 있는지 확인합니다. 최신 버전은 시간 차이로 인해 등록 실패가 발생하는지 여부를 알려줍니다.
3. 이 문서 앞부분의 설치 지침에서 올바른 작업 영역 ID 및 작업 영역 키를 사용하여 다시 온보딩합니다.

문제: 등록 직후에 로그 파일에 500 및 404 오류가 표시됨

이는 Linux 데이터를 Log Analytics 작업 영역에 처음 업로드할 때 발생하는 알려진 문제입니다. 이 문제는 전송되는 데이터 또는 서비스 환경에 영향을 주지 않습니다.

문제: CPU를 100% 사용하는 omiagent가 표시됩니다.

가능한 원인

v1.0.3-5.el7 nss-pem 패키지의 회귀로 인해 심각한 성능 문제가 발생했습니다. 이 문제가 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. 30% CPU 임계값을 사용하여 24시간 동안 진단을 실행합니다.
   bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

3. 호출 스택은 omiagent_trace 파일에 덤프됩니다. curl 및 NSS 함수 호출이 많은 경우 다음 해결 방법 단계를 따르세요.

해결

1. nss-pem 패키지를 v1.0.3-5.el7_6.1로 업그레이드합니다.
   sudo yum upgrade nss-pem

2. 대부분 CentOS에서 발생하는 nss-pem을 업그레이드에 사용할 수 없는 경우 curl을 7.29.0-46으로 다운그레이드합니다. 실수로 "yum update"를 실행하면 curl이 7.29.0-51로 업그레이드되고 문제가 다시 발생합니다.
   sudo yum downgrade curl libcurl

3. OMI를 다시 실행합니다.
   sudo scxadmin -restart

문제: 전달된 Syslog 메시지가 표시되지 않음

가능한 원인

• Linux 서버에 적용된 구성에서는 전송된 기능 또는 로그 수준을 수집할 수 없습니다.
• Syslog가 Linux 서버에 올바르게 전달되지 않습니다.
• 초당 전달되는 메시지 수가 너무 많아 Linux용 Log Analytics 에이전트의 기본 구성에서 처리할 수 없습니다.

해결

• Syslog용 Log Analytics 작업 영역의 구성에서 모든 설비가 있고 로그 수준이 올바른지 확인합니다. Azure Portal에서 Syslog 수집 구성을 검토합니다.
• 네이티브 Syslog 메시징 디먼(rsyslog, syslog-ng)에서 전달된 메시지를 받을 수 있는지 확인합니다.
• Syslog 서버에서 방화벽 설정을 확인하여 메시지가 차단되지 않도록 합니다.
• logger 명령을 사용하여 Log Analytics에 대한 Syslog 메시지를 시뮬레이션 합니다.
  logger -p local0.err "This is my test message"

문제: 이미 omsagent 로그 파일에서 사용 중인 Errno 주소를 수신함

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>가 표시됩니다.

가능한 원인

이 오류는 LAD(Linux 진단 확장)가 Log Analytics Linux VM 확장과 함께 설치되었음을 나타냅니다. omsagent와 동일한 Syslog 데이터 수집 포트를 사용하고 있습니다.

해결

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. VM에서 rsyslogd를 실행하는 경우 수정할 파일은 있는 경우 /etc/rsyslog.d/95-omsagent.conf입니다(없는 경우 /etc/rsyslog). VM에서 syslog_ng를 실행하는 경우 수정할 파일은 /etc/syslog-ng/syslog-ng.conf입니다.

3. omsagent sudo /opt/microsoft/omsagent/bin/service_control restart를 다시 시작합니다.

4. Syslog 서비스를 다시 시작합니다.

문제: 제거 옵션을 사용하여 omsagent를 제거할 수 없음

가능한 원인

• Linux 진단 확장이 설치되었습니다.
• Linux 진단 확장을 설치하고 제거했지만, mdsd에서 omsagent를 사용 중이며 제거할 수 없다는 오류가 계속 표시됩니다.

해결

1. Linux 진단 확장을 제거합니다.
2. Linux 진단 확장 파일이 /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ 및 /var/opt/microsoft/omsagent/LAD/ 위치에 있는 경우 컴퓨터에서 해당 파일을 제거합니다.

문제: Nagios 데이터를 볼 수 없음

가능한 원인

• omsagent 사용자는 Nagios 로그 파일에서 읽을 수 있는 권한이 없습니다.
• Nagios 원본 및 필터가 omsagent.conf 파일에서 주석 처리 제거되지 않았습니다.

해결

1. 다음 지침에 따라 Nagios 파일에서 읽을 omsagent 사용자를 추가합니다.

2. /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf의 Linux용 Log Analytics 에이전트 일반 구성 파일에서, 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 패키지가 Linux용 Log Analytics 에이전트 패키지에서 설치한 것과 비교하여 최신 버전으로 수동으로 업그레이드되었습니다.
• OMI가 고정되어 OMS 에이전트를 차단합니다.
• DSC 리소스에서 클래스를 찾을 수 없음 오류를 omsconfig.log 로그 파일에 로그합니다.
• 데이터용 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 배포 시스템에서는 가상 머신이 다시 부팅된 후 omid OMI 서버 디먼이 시작되지 않습니다. 이 경우 Audit, ChangeTracking 또는 UpdateManagement 솔루션 관련 데이터가 표시되지 않습니다. 해결 방법은 sudo /opt/omi/bin/service_control restart를 실행하여 OMI 서버를 수동으로 시작하는 것입니다.

5. OMI 패키지가 최신 버전으로 수동으로 업그레이드되면 수동으로 다시 시작해야만 Log Analytics 에이전트가 계속 작동합니다. 이 단계는 OMI 서버가 업그레이드되면 자동으로 시작되지 않는 일부 배포판에 필요합니다. sudo /opt/omi/bin/service_control restart를 실행하여 OMI를 다시 시작합니다.

   경우에 따라 OMI가 고정될 수 있습니다. OMS 에이전트는 모든 데이터 수집을 차단하는 OMI를 기다리는 차단된 상태에 들어갈 수 있습니다. OMS 에이전트 프로세스는 실행되지만 omsagent.log에 있는 새 로그 행(예: 보낸 하트비트)이 없는 것으로 확인되는 작업이 없습니다. 에이전트를 복구하기 위해 sudo /opt/omi/bin/service_control restart를 사용하여 OMI를 다시 시작합니다.

6. DSC 리소스 클래스를 찾을 수 없음 오류가 omsconfig.log에 표시되면 sudo /opt/omi/bin/service_control restart를 실행합니다.

7. 경우에 따라 Linux용 Log Analytics 에이전트에서 Azure Monitor와 통신할 수 없는 경우 에이전트의 데이터가 50MB의 전체 버퍼 크기로 백업됩니다. /opt/microsoft/omsagent/bin/service_control restart 명령을 실행하여 에이전트를 다시 시작해야 합니다.

   참고 항목

   이 문제는 에이전트 버전 1.1.0-28 이상에서 해결되었습니다.

   • 시스템에서 PerformRequiredConfigurationChecks 작업이 주기적으로 실행되고 있다고 omsconfig.log 로그 파일에 표시되지 않으면 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
     

문제: 포털에서 Syslog 또는 Linux 성능 카운터에 대한 수집을 구성할 때 설정이 적용되지 않음

가능한 원인

• Linux용 Log Analytics 에이전트에서 최신 구성을 선택하지 않았습니다.
• 포털에서 변경한 설정이 적용되지 않았습니다.

해결

백그라운드: omsconfig는 5분마다 새로운 포털 쪽 구성을 찾는 Linux용 Log Analytics 에이전트 구성 에이전트입니다. 이 구성은 /etc/opt/microsoft/omsagent/conf/omsagent.conf에 있는 Linux용 Log Analytics 에이전트 구성 파일에 적용됩니다.

경우에 따라 Linux용 Log Analytics 에이전트 구성 에이전트에서 포털 구성 서비스와 통신하지 못할 수 있습니다. 이 시나리오에서는 최신 구성이 적용되지 않습니다.

1. dpkg --list omsconfig 또는 rpm -qi omsconfig 명령을 실행하여 omsconfig 에이전트가 설치되어 있는지 확인합니다. 설치되지 않은 경우 최신 버전의 Linux용 Log Analytics 에이전트를 다시 설치합니다.

2. 다음 명령을 실행하여 omsconfig 에이전트에서 Azure Monitor와 통신할 수 있는지 확인합니다. sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py' 이 명령은 Syslog 설정, Linux 성능 카운터, 사용자 지정 로그를 포함하여 에이전트에서 서비스로부터 받는 구성을 반환합니다. 이 명령이 실패하면 다음 명령을 실행합니다. sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py' 이 명령은 omsconfig 에이전트가 Azure Monitor와 통신하여 최신 구성을 검색하도록 강제합니다.

문제: 사용자 지정 로그 데이터가 표시되지 않음

가능한 원인

• Azure Monitor에 온보딩이 실패하였습니다.
• 다음 구성을 Linux 서버에 적용 설정이 선택되지 않았습니다.
• omsconfig에서 서비스의 최신 사용자 지정 로그 구성을 선택하지 않았습니다.
• Linux용 Log Analytics 에이전트 사용자(omsagent)가 권한으로 인해 사용자 지정 로그에 액세스할 수 없거나 이를 찾을 수 없습니다. 다음 오류가 표시될 수 있습니다.
  • [DATETIME] [warn]: file not found. Continuing without tailing it.
  • [DATETIME] [error]: file not accessible by omsagent.
• Linux용 Log Analytics 에이전트 버전 1.1.0-217에서 수정된 경합 상태의 알려진 문제입니다.

해결

1. 다음 파일이 있는지 확인하여 Azure Monitor 온보딩이 성공했는지 확인합니다. /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. 실패한 경우 둘 중 하나를 수행합니다.

   1. omsadmin.sh 명령줄 지침을 사용하여 다시 온보딩합니다.
   2. Azure Portal의 고급 설정 아래에서 다음 구성을 Linux 서버에 적용 설정을 사용합니다.

2. 다음 명령을 실행하여 omsconfig 에이전트에서 Azure Monitor와 통신할 수 있는지 확인합니다. sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py' 이 명령은 Syslog 설정, Linux 성능 카운터, 사용자 지정 로그를 포함하여 에이전트에서 서비스로부터 받는 구성을 반환합니다. 이 명령이 실패하면 다음 명령을 실행합니다. sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py' 이 명령은 omsconfig 에이전트에서 Azure Monitor와 통신하여 최신 구성을 검색하도록 강제합니다.

백그라운드: Linux용 Log Analytics 에이전트가 권한 있는 사용자 root로 실행되지 않고 omsagent 사용자로 실행됩니다. 대부분의 경우 이 사용자에게 특정 파일을 읽을 수 있는 명시적 권한을 부여해야 합니다. omsagent 사용자에게 권한을 부여하려면 다음 명령을 실행합니다.

1. omsagent 사용자를 특정 그룹에 추가합니다(sudo usermod -a -G <GROUPNAME> <USERNAME>).
2. 필요한 파일에 대한 유니버설 읽기 액세스 권한을 부여합니다(sudo chmod -R ugo+rx <FILE DIRECTORY>).

Linux용 Log Analytics 에이전트 버전 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 옵션을 사용한 후 다시 온보딩할 수 있습니다.

문제: Azure Portal의 Log Analytics 에이전트 확장이 실패 상태('프로비전 실패')로 표시됨

가능한 원인

• Log Analytics 에이전트가 운영 체제에서 제거되었습니다.
• Log Analytics 에이전트 서비스가 가동 중지되었거나, 사용하지 않도록 설정되었거나, 구성되지 않았습니다.

해결

1. Azure Portal에서 확장을 제거합니다.
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 명령을 실행하여 패키지를 업그레이드합니다.

문제: 설치가 실패하고 Python3을 사용하고 있더라도 Python2에서 ctypes를 지원할 수 없다고 표시됨

가능한 원인

이 알려진 문제에서는 VM의 언어가 영어가 아닌 경우 사용하고 있는 Python 버전을 확인할 때 확인이 실패합니다. 이 문제로 인해 에이전트에서 항상 Python2가 사용되고 있다고 가정하여 Python2가 없으면 실패합니다.

해결

VM의 환경 언어를 영어로 변경합니다.

export LANG=en_US.UTF-8