Felsöka problem med Log Analytics-agenten för Linux

  • Artikel

Den här artikeln innehåller hjälp med felsökningsfel som kan uppstå med Log Analytics-agenten för Linux i Azure Monitor.

Felsökningsverktyg för Log Analytics

Log Analytics-agenten för Linux-felsökningsverktyget är ett skript som är utformat för att hitta och diagnostisera problem med Log Analytics-agenten. Den ingår automatiskt i agenten vid installationen. Att köra verktyget bör vara det första steget för att diagnostisera ett problem.

Använda felsökningsverktyget

Om du vill köra felsökningsverktyget klistrar du in följande kommando i ett terminalfönster på en dator med Log Analytics-agenten:

sudo /opt/microsoft/omsagent/bin/troubleshooter

Manuell installation

Felsökningsverktyget inkluderas automatiskt när Log Analytics-agenten installeras. Om installationen misslyckas på något sätt kan du även installera verktyget manuellt:

  1. Kontrollera att GNU Project Debugger (GDB) är installerat på datorn eftersom felsökaren är beroende av den.
  2. Kopiera felsökningspaketet till datorn: wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
  3. Packa upp paketet: tar -xzvf omsagent_tst.tar.gz
  4. Kör den manuella installationen: sudo ./install_tst

Scenarier som omfattas

Felsökningsverktyget kontrollerar följande scenarier:

  • Agenten är inte felfri. pulsslag fungerar inte korrekt.
  • Agenten startar inte eller kan inte ansluta till Log Analytics.
  • Agenten Syslog fungerar inte.
  • Agenten har hög processor- eller minnesanvändning.
  • Agenten har installationsproblem.
  • Agentens anpassade loggar fungerar inte.
  • Agentloggar kan inte samlas in.

Mer information finns i dokumentationen för felsökningsverktyget på GitHub.

Anteckning

Kör verktyget Logginsamlare när du upplever ett problem. Om du har loggarna kan vårt supportteam felsöka problemet snabbare.

Rensa och installera om Linux-agenten

En ren ominstallation av agenten åtgärdar de flesta problem. Den här uppgiften kan vara det första förslaget från vårt supportteam att få agenten i ett odekorrupt tillstånd. Om du kör felsökningsverktyget och logginsamlaren och försöker utföra en ren ominstallation kan du lösa problem snabbare.

  1. Ladda ned rensningsskriptet:

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

  2. Kör rensningsskriptet (med sudo-behörigheter):

    $ sudo sh purge_omsagent.sh

Viktiga loggplatser och logginsamlareverktyget

Fil Sökväg
Log Analytics-agent för Linux-loggfil /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
Loggfil för Log Analytics-agentkonfiguration /var/opt/microsoft/omsconfig/omsconfig.log

Vi rekommenderar att du använder verktyget Log Collector för att hämta viktiga loggar för felsökning eller innan du skickar ett GitHub-problem. Mer information om verktyget och hur du kör det finns i OMS Linux Agent Log Collector.

Viktiga konfigurationsfiler

Kategori Filplats
Syslog /etc/syslog-ng/syslog-ng.confeller eller /etc/rsyslog.conf/etc/rsyslog.d/95-omsagent.conf
Prestanda, Nagios, Zabbix, Log Analytics-utdata och allmän agent /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
Extra konfigurationer /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

Anteckning

Redigering av konfigurationsfiler för prestandaräknare och Syslog skrivs över om samlingen har konfigurerats från agentens konfiguration i Azure Portal för arbetsytan. Inaktivera insamling från hantering av äldre agenter om du vill inaktivera konfigurationen för alla agenter. Kör följande skript för en enda agent:

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*

Felkoder vid installation

Felkod Innebörd
NOT_DEFINED Eftersom nödvändiga beroenden inte är installerade installeras inte det granskade plugin-programmet auoms. Installationen av auoms misslyckades. Installera paketet granskas.
2 Ogiltigt alternativ för shell-paketet. Kör sudo sh ./omsagent-*.universal*.sh --help för användning.
3 Inget alternativ har angetts för shell-paketet. Kör sudo sh ./omsagent-*.universal*.sh --help för användning.
4 Ogiltig pakettyp eller ogiltiga proxyinställningar. Paketen omsagent-rpm.sh kan bara installeras på RPM-baserade system. Omsagent-deb.sh-paketen kan endast installeras på Debian-baserade system. Vi rekommenderar att du använder det universella installationsprogrammet från den senaste versionen. Granska även för att verifiera proxyinställningarna.
5 Shell-paketet måste köras som rot eller så returnerades ett 403-fel under registreringen. Kör kommandot med hjälp sudoav .
6 Ogiltig paketarkitektur eller ett 200-fel returnerades under registreringen. Omsagent-*x64.sh-paketen kan bara installeras på 64-bitarssystem. Omsagent-*x86.sh-paketen kan bara installeras på 32-bitarssystem. Ladda ned rätt paket för din arkitektur från den senaste versionen.
17 Installationen av OMS-paketet misslyckades. Titta igenom kommandoutdata för rotfelet.
18 Installationen av OMSConfig-paketet misslyckades. Titta igenom kommandoutdata för rotfelet.
19 Installationen av OMI-paketet misslyckades. Titta igenom kommandoutdata för rotfelet.
20 Installationen av SCX-paketet misslyckades. Titta igenom kommandoutdata för rotfelet.
21 Installationen av providerpaket misslyckades. Titta igenom kommandoutdata för rotfelet.
22 Installationen av paketpaketet misslyckades. Titta igenom kommandoutdata för rotfelet
23 SCX- eller OMI-paketet är redan installerat. Använd --upgrade i stället --install för att installera shell-paketet.
30 Internt paketfel. Skapa ett GitHub-problem med information från utdata.
55 Opensl-versionen stöds inte eller kan inte ansluta till Azure Monitor eller dpkg är låst eller saknar curl-program.
61 Python ctypes-bibliotek saknas. Installera Python ctypes-biblioteket eller paketet (python-ctypes).
62 Tar-program saknas. Installera tjära.
63 SED-program saknas. Installera sed.
64 Curl-program saknas. Installera curl.
65 Gpg-programmet saknas. Installera gpg.

Felkoder vid registrering

Felkod Innebörd
2 Ogiltigt alternativ för omsadmin-skriptet. Kör sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h för användning.
3 Ogiltig konfiguration har angetts för omsadmin-skriptet. Kör sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h för användning.
4 Ogiltig proxy som angetts för omsadmin-skriptet. Verifiera proxyn och se vår dokumentation för att använda en HTTP-proxy.
5 403 HTTP-fel togs emot från Azure Monitor. Mer information finns i fullständiga utdata för omsadmin-skriptet.
6 Http-fel som inte är 200 tas emot från Azure Monitor. Mer information finns i fullständiga utdata för omsadmin-skriptet.
7 Det går inte att ansluta till Azure Monitor. Mer information finns i fullständiga utdata för omsadmin-skriptet.
8 Fel vid registrering till Log Analytics-arbetsyta. Mer information finns i fullständiga utdata för omsadmin-skriptet.
30 Internt skriptfel. Skapa ett GitHub-problem med information från utdata.
31 Det gick inte att generera agent-ID. Skapa ett GitHub-problem med information från utdata.
32 Fel vid generering av certifikat. Mer information finns i fullständiga utdata för omsadmin-skriptet.
33 Det gick inte att generera metakonfiguration för omsconfig. Skapa ett GitHub-problem med information från utdata.
34 Skriptet för metakonfigurationsgenerering finns inte. Försök att registrera igen med sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>.

Aktivera felsökningsloggning

Felsökning av PLUGIN-program för OMS-utdata

FluentD möjliggör plugin-specifika loggningsnivåer som gör att du kan ange olika loggnivåer för indata och utdata. Om du vill ange en annan loggnivå för OMS-utdata redigerar du den allmänna agentkonfigurationen på /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

I plugin-programmet för OMS-utdata, innan konfigurationsfilen är slut, ändrar du log_level egenskapen från info till 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>

Med felsökningsloggning kan du se batchuppladdningar till Azure Monitor avgränsade efter typ, antal dataobjekt och den tid det tar att skicka.

Här är ett exempel på en felsökningsaktiverad logg:

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

Utförliga utdata

I stället för att använda PLUGIN-programmet för OMS-utdata kan du mata ut dataobjekt direkt till stdout, som visas i Log Analytics-agenten för Linux-loggfilen.

I Log Analytics allmänna agentkonfigurationsfil på /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.confkommenterar du ut PLUGIN-programmet för OMS-utdata genom att lägga till en # framför varje rad:

#<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>

Under plugin-programmet för utdata avkommentarer du följande avsnitt genom att ta bort # framför varje rad:

<match **>
  type stdout
</match>

Problem: Det går inte att ansluta via proxy till Azure Monitor

Sannolika orsaker

  • Proxyn som angavs under registrering var felaktig.
  • Azure Monitor- och Azure Automation-tjänstslutpunkter ingår inte i listan över godkända i ditt datacenter.

Lösning

  1. Registrera om till Azure Monitor med Log Analytics-agenten för Linux med hjälp av följande kommando med alternativet -v aktiverat. Den tillåter utförliga utdata från agenten som ansluter via proxyn till Azure Monitor: /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

  2. Granska avsnittet Uppdatera proxyinställningar för att kontrollera att du har konfigurerat agenten så att den kommunicerar via en proxyserver.

  3. Kontrollera att slutpunkterna som beskrivs i listan krav för Azure Monitor-nätverksbrandvägg har lagts till i en lista över tillåtna. Om du använder Azure Automation länkas även de nödvändiga nätverkskonfigurationsstegen ovan.

Problem: Du får ett 403-fel när du försöker publicera

Sannolika orsaker

  • Datum och tid är felaktiga på Linux-servern.
  • Arbetsytans ID och arbetsytenyckeln är inte korrekta.

Lösning

  1. Kontrollera tiden på Linux-servern med kommandodatumet. Om tiden är +/- 15 minuter från den aktuella tiden misslyckas registrering. Du kan åtgärda det här genom att uppdatera datum- och/eller tidszonen för Din Linux-server.
  2. Kontrollera att du har installerat den senaste versionen av Log Analytics-agenten för Linux. Den senaste versionen meddelar dig nu om tidsförskjutning orsakar onboarding-felet.
  3. Publicera igen med rätt arbetsyte-ID och arbetsytenyckel i installationsanvisningarna tidigare i den här artikeln.

Problem: Du ser felet 500 och 404 i loggfilen direkt efter registrering

Det här är ett känt problem som uppstår vid den första uppladdningen av Linux-data till en Log Analytics-arbetsyta. Det här problemet påverkar inte data som skickas eller tjänstens upplevelse.

Problem: Du ser omiagent med 100 % CPU

Sannolika orsaker

En regression i nss-pem-paketet v1.0.3-5.el7 orsakade ett allvarligt prestandaproblem. Vi har sett det här problemet komma upp mycket i Redhat/CentOS 7.x-distributioner. Mer information om det här problemet finns i 1667121 Prestandaregression i libcurl.

Prestandarelaterade buggar inträffar inte hela tiden och de är svåra att återskapa. Om du upplever ett sådant problem med omiagent använder du skriptet omiHighCPUDiagnostics.sh, som samlar in stackspårningen av omiagenten när den överskrider ett visst tröskelvärde.

  1. Ladda ned skriptet:
    wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh

  2. Kör diagnostik i 24 timmar med 30 % CPU-tröskelvärde:
    bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

  3. Callstack dumpas i omiagent_trace-filen. Om du ser många curl- och NSS-funktionsanrop följer du dessa lösningssteg.

Lösning

  1. Uppgradera nss-pem-paketet till v1.0.3-5.el7_6.1:
    sudo yum upgrade nss-pem

  2. Om nss-pem inte är tillgängligt för uppgradering, vilket oftast sker på CentOS, nedgraderar du curl till 7.29.0-46. Om du kör "yum update" av misstag uppgraderas curl till 7.29.0-51 och problemet inträffar igen:
    sudo yum downgrade curl libcurl

  3. Starta om OMI:
    sudo scxadmin -restart

Problem: Du ser inte vidarebefordrade Syslog-meddelanden

Sannolika orsaker

  • Den konfiguration som tillämpas på Linux-servern tillåter inte insamling av de skickade anläggningarna eller loggnivåerna.
  • Syslog vidarebefordras inte korrekt till Linux-servern.
  • Antalet meddelanden som vidarebefordras per sekund är för stort för att baskonfigurationen av Log Analytics-agenten för Linux ska kunna hantera.

Lösning

  • Kontrollera att konfigurationen på Log Analytics-arbetsytan för Syslog har alla resurser och rätt loggnivåer. Granska konfigurera Syslog-samlingen i Azure Portal.
  • Kontrollera att de interna syslog-meddelandedaemonerna (rsyslog, syslog-ng) kan ta emot vidarebefordrade meddelanden.
  • Kontrollera brandväggsinställningarna på Syslog-servern för att säkerställa att meddelanden inte blockeras.
  • Simulera ett Syslog-meddelande till Log Analytics med hjälp av ett logger kommando:
    logger -p local0.err "This is my test message"

Problem: Du får Errno-adressen som redan används i loggfilen omsagent

Du ser [error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224> i omsagent.log.

Sannolika orsaker

Det här felet anger att Linux-diagnostiktillägget (LAD) installeras sida vid sida med log analytics-tillägget för virtuella Linux-datorer. Den använder samma port för Syslog-datainsamling som omsagent.

Lösning

  1. Kör följande kommandon som rot. Observera att 25224 är ett exempel och det är möjligt att du i din miljö ser ett annat portnummer som används av 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

    Sedan måste du redigera rätt rsyslogd eller syslog_ng konfigurationsfil och ändra den LAD-relaterade konfigurationen så att den skriver till port 25229.

  2. Om den virtuella datorn körs rsyslogdär /etc/rsyslog.d/95-omsagent.conf filen som ska ändras (om den finns, annars /etc/rsyslog). Om den virtuella datorn körs syslog_ngär /etc/syslog-ng/syslog-ng.conffilen som ska ändras .

  3. Starta om omsagent sudo /opt/microsoft/omsagent/bin/service_control restart.

  4. Starta om Syslog-tjänsten.

Problem: Du kan inte avinstallera omsagent med hjälp av rensningsalternativet

Sannolika orsaker

  • Linux-diagnostiktillägget är installerat.
  • Linux-diagnostiktillägget installerades och avinstallerades, men du ser fortfarande ett fel om att omsagent används av mdsd och att det inte går att ta bort det.

Lösning

  1. Avinstallera Linux-diagnostiktillägget.
  2. Ta bort filer för Linux-diagnostiktillägg från datorn om de finns på följande plats: /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ och /var/opt/microsoft/omsagent/LAD/.

Problem: Du kan inte se några Nagios-data

Sannolika orsaker

  • Omsagent-användaren har inte behörighet att läsa från Nagios-loggfilen.
  • Nagios-källan och -filtret har inte tagits bort från omsagent.conf-filen.

Lösning

  1. Lägg till omsagent-användaren som ska läsas från Nagios-filen genom att följa dessa instruktioner.

  2. I Log Analytics-agenten för den allmänna Linux-konfigurationsfilen på /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.confkontrollerar du att både Nagios-källan och filtret är okommenterade.

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

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

Problem: Du ser inga Linux-data

Sannolika orsaker

  • Registrering till Azure Monitor misslyckades.
  • Anslutningen till Azure Monitor blockeras.
  • Den virtuella datorn startades om.
  • OMI-paketet uppgraderades manuellt till en nyare version jämfört med vad som installerades av Log Analytics-agenten för Linux-paketet.
  • OMI är låst och blockerar OMS-agenten.
  • Det gick inte att hitta fel i DSC-resursloggklassen i omsconfig.log loggfilen.
  • Log Analytics-agenten för data säkerhetskopieras.
  • DSC-loggar Aktuell konfiguration finns inte. Kör Start-DscConfiguration kommando med parametern -Path för att ange en konfigurationsfil och skapa en aktuell konfiguration först. i omsconfig.log loggfilen, men det finns inget loggmeddelande om PerformRequiredConfigurationChecks åtgärder.

Lösning

  1. Installera alla beroenden som det granskade paketet.

  2. Kontrollera om registreringen till Azure Monitor lyckades genom att kontrollera om följande fil finns: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Annars kan du registrera igen med hjälp av omsadmin.sh kommandoradsinstruktioner.

  3. Om du använder en proxy kontrollerar du föregående steg för proxyfelsökning.

  4. I vissa Azure-distributionssystem startar inte omid OMI-serverdaemonen när den virtuella datorn har startats om. I så fall visas inte lösningsrelaterade data relaterade till Granskning, ChangeTracking eller UpdateManagement. Lösningen är att starta OMI-servern manuellt genom att köra sudo /opt/omi/bin/service_control restart.

  5. När OMI-paketet har uppgraderats manuellt till en nyare version måste det startas om manuellt för att Log Analytics-agenten ska fortsätta att fungera. Det här steget krävs för vissa distributioner där OMI-servern inte startas automatiskt när den har uppgraderats. Kör sudo /opt/omi/bin/service_control restart för att starta om OMI.

    I vissa situationer kan OMI frysas. OMS-agenten kan ange ett blockerat tillstånd som väntar på OMI, som blockerar all datainsamling. OMS-agentprocessen körs men det kommer inte att finnas någon aktivitet, vilket framgår av att inga nya loggrader (till exempel skickade pulsslag) finns i omsagent.log. Starta om OMI med sudo /opt/omi/bin/service_control restart för att återställa agenten.

  6. Om du ser felet DSC-resursklassen hittades inte i omsconfig.log kör du sudo /opt/omi/bin/service_control restart.

  7. I vissa fall, när Log Analytics-agenten för Linux inte kan kommunicera med Azure Monitor, säkerhetskopieras data på agenten till den fulla buffertstorleken på 50 MB. Agenten ska startas om genom att köra följande kommando: /opt/microsoft/omsagent/bin/service_control restart.

    Anteckning

    Det här problemet åtgärdas i agentversion 1.1.0-28 eller senare.

    • omsconfig.log Om loggfilen inte anger att PerformRequiredConfigurationChecks åtgärder körs regelbundet i systemet kan det finnas ett problem med cron-jobbet/tjänsten. Kontrollera att cron-jobbet finns under /etc/cron.d/OMSConsistencyInvoker. Om det behövs kör du följande kommandon för att skapa cron-jobbet:

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

    • Kontrollera också att cron-tjänsten körs. Du kan använda service cron status med Debian, Ubuntu och SUSE eller service crond status med RHEL, CentOS och Oracle Linux för att kontrollera status för den här tjänsten. Om tjänsten inte finns kan du installera binärfilerna och starta tjänsten med hjälp av följande instruktioner:

      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

Problem: När du konfigurerar samling från portalen för Syslog- eller Linux-prestandaräknare tillämpas inte inställningarna

Sannolika orsaker

  • Log Analytics-agenten för Linux har inte hämtat den senaste konfigurationen.
  • De ändrade inställningarna i portalen tillämpades inte.

Lösning

Bakgrund:omsconfig är Log Analytics-agenten för Linux-konfigurationsagenten som söker efter ny konfiguration på portalsidan var femte minut. Den här konfigurationen tillämpas sedan på Log Analytics-agenten för Linux-konfigurationsfiler som finns på /etc/opt/microsoft/omsagent/conf/omsagent.conf.

I vissa fall kanske Log Analytics-agenten för Linux-konfigurationsagenten inte kan kommunicera med portalkonfigurationstjänsten. Det här scenariot resulterar i att den senaste konfigurationen inte tillämpas.

  1. Kontrollera att agenten omsconfig har installerats genom att köra dpkg --list omsconfig eller rpm -qi omsconfig. Om den inte är installerad installerar du om den senaste versionen av Log Analytics-agenten för Linux.

  2. Kontrollera att agenten omsconfig kan kommunicera med Azure Monitor genom att köra följande kommando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Det här kommandot returnerar konfigurationen som agenten tar emot från tjänsten, inklusive Syslog-inställningar, Linux-prestandaräknare och anpassade loggar. Om det här kommandot misslyckas kör du följande kommando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Det här kommandot tvingar omsconfig-agenten att kommunicera med Azure Monitor och hämta den senaste konfigurationen.

Problem: Du ser inga anpassade loggdata

Sannolika orsaker

  • Registrering till Azure Monitor misslyckades.
  • Inställningen Tillämpa följande konfiguration på mina Linux-servrar har inte valts.
  • omsconfig har inte hämtat den senaste anpassade loggkonfigurationen från tjänsten.
  • Log Analytics-agenten för Linux-användaren omsagent kan inte komma åt den anpassade loggen på grund av behörigheter eller att den inte hittas. Du kan se följande fel:
    • [DATETIME] [warn]: file not found. Continuing without tailing it.
    • [DATETIME] [error]: file not accessible by omsagent.
  • Kända problem med konkurrenstillstånd som har åtgärdats i Log Analytics-agenten för Linux version 1.1.0-217.

Lösning

  1. Kontrollera att registreringen till Azure Monitor lyckades genom att kontrollera om följande fil finns: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Om inte, antingen:

    1. Publicera igen med hjälp av omsadmin.sh kommandoradsinstruktioner.
    2. Under Avancerade inställningar i Azure Portal kontrollerar du att inställningen Tillämpa följande konfiguration på mina Linux-servrar är aktiverad.

  2. Kontrollera att agenten omsconfig kan kommunicera med Azure Monitor genom att köra följande kommando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Det här kommandot returnerar konfigurationen som agenten tar emot från tjänsten, inklusive Syslog-inställningar, Linux-prestandaräknare och anpassade loggar. Om det här kommandot misslyckas kör du följande kommando: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Det här kommandot tvingar agenten omsconfig att kommunicera med Azure Monitor och hämta den senaste konfigurationen.

Bakgrund: I stället för att Log Analytics-agenten för Linux körs som en privilegierad användare – rootkörs agenten omsagent som användaren. I de flesta fall måste uttrycklig behörighet beviljas till den här användaren för att vissa filer ska kunna läsas. Om du vill bevilja behörighet till omsagent användaren kör du följande kommandon:

  1. Lägg till användaren i omsagent den specifika gruppen: sudo usermod -a -G <GROUPNAME> <USERNAME>.
  2. Bevilja universell läsbehörighet till den nödvändiga filen: sudo chmod -R ugo+rx <FILE DIRECTORY>.

Det finns ett känt problem med ett konkurrenstillstånd med Log Analytics-agenten för Linux-versionen tidigare än 1.1.0-217. När du har uppdaterat till den senaste agenten kör du följande kommando för att hämta den senaste versionen av plugin-programmet för utdata: sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Problem: Du försöker återregistrera till en ny arbetsyta

När du försöker publicera om en agent till en ny arbetsyta måste Log Analytics-agentkonfigurationen rensas innan du registrerar om den. Om du vill rensa den gamla konfigurationen från agenten kör du shell-paketet med --purge:

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

Eller

sudo sh ./onboard_agent.sh --purge

Du kan fortsätta att publicera igen när du har använt --purge alternativet .

Problem: Log Analytics-agenttillägget i Azure Portal har markerats med ett feltillstånd: Etableringen misslyckades

Sannolika orsaker

  • Log Analytics-agenten har tagits bort från operativsystemet.
  • Log Analytics-agenttjänsten är inte tillgänglig, inaktiverad eller inte konfigurerad.

Lösning

  1. Ta bort tillägget från Azure Portal.
  2. Installera agenten genom att följa anvisningarna.
  3. Starta om agenten genom att köra följande kommando:
    sudo /opt/microsoft/omsagent/bin/service_control restart.
  4. Vänta några minuter tills etableringstillståndet ändras till Etableringen har slutförts.

Problem: Log Analytics-agentuppgradering på begäran

Sannolika orsaker

Log Analytics-agentpaketen på värden är inaktuella.

Lösning

  1. Sök efter den senaste versionen på den här GitHub-sidan.

  2. Ladda ned installationsskriptet (1.4.2-124 är en exempelversion):

    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. Uppgradera paket genom att sudo sh ./omsagent-*.universal.x64.sh --upgradeköra .

Problem: Installationen misslyckas och säger att Python2 inte stöder ctypes, även om Python3 används

Sannolika orsaker

Om den virtuella datorns språk inte är engelska för det här kända problemet misslyckas en kontroll när du verifierar vilken version av Python som används. Det här problemet leder till att agenten alltid antar att Python2 används och misslyckas om det inte finns någon Python2.

Lösning

Ändra den virtuella datorns miljöspråk till engelska:

export LANG=en_US.UTF-8