Sdílet prostřednictvím


Řešení potíží s agentem Log Analytics pro Linux

Tento článek obsahuje nápovědu k řešení chyb, ke kterým může docházet u agenta Log Analytics pro Linux ve službě Azure Monitor.

Upozornění

Tento článek odkazuje na CentOS, což je linuxová distribuce se stavem Konec životnosti (EOL). Zvažte své použití a plánování odpovídajícím způsobem. Další informace najdete v doprovodných materiálech CentOS End Of Life.

Nástroj pro řešení potíží s Log Analytics

Agent Log Analytics pro linuxový nástroj pro řešení potíží je skript navržený tak, aby vám pomohl najít a diagnostikovat problémy s agentem Log Analytics. Po instalaci je automaticky součástí agenta. Spuštění nástroje by mělo být prvním krokem při diagnostice problému.

Použití nástroje pro řešení potíží

Pokud chcete spustit nástroj pro řešení potíží, vložte do okna terminálu na počítači s agentem Log Analytics následující příkaz:

sudo /opt/microsoft/omsagent/bin/troubleshooter

Ruční instalace

Nástroj pro řešení potíží se automaticky zahrne při instalaci agenta Log Analytics. Pokud instalace selže jakýmkoli způsobem, můžete nástroj nainstalovat také ručně:

  1. Ujistěte se, že je na počítači nainstalovaný ladicí program GNU Project Debugger (GDB), protože na něm spoléhá poradce při potížích.
  2. Zkopírujte sadu poradce při potížích do počítače: wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
  3. Rozbalte sadu: tar -xzvf omsagent_tst.tar.gz
  4. Spusťte ruční instalaci: sudo ./install_tst

Probírané scénáře

Nástroj pro řešení potíží kontroluje následující scénáře:

  • Agent není v pořádku; prezenční signál nefunguje správně.
  • Agent se nespustí nebo se nemůže připojit ke službě Log Analytics.
  • Agent Syslog nefunguje.
  • Agent má vysoké využití procesoru nebo paměti.
  • Agent má problémy s instalací.
  • Vlastní protokoly agenta nefungují.
  • Protokoly agenta se nedají shromažďovat.

Další informace najdete v dokumentaci k nástroji pro řešení potíží na GitHubu.

Poznámka:

Pokud dojde k problému, spusťte nástroj Kolektor protokolů. Počáteční protokoly nám pomůžou náš tým podpory rychleji vyřešit váš problém.

Vyprázdnění a přeinstalace agenta Linuxu

Čistá přeinstalace agenta řeší většinu problémů. Tento úkol může být prvním návrhem od našeho týmu podpory, který agenta dostane do nerušovaného stavu. Spuštění nástroje pro řešení potíží a nástroje Kolektor protokolů a pokus o čistou přeinstalaci pomáhá rychleji vyřešit problémy.

  1. Stáhněte si skript vyprázdnění:

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

  2. Spusťte skript mazání (s oprávněními sudo):

    $ sudo sh purge_omsagent.sh

Důležitá umístění protokolů a nástroj Kolektor protokolů

Soubor Cesta
Agent Log Analytics pro soubor protokolu Linuxu /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
Soubor protokolu konfigurace agenta Log Analytics /var/opt/microsoft/omsconfig/omsconfig.log

K načtení důležitých protokolů pro řešení potíží nebo před odesláním problému z GitHubu doporučujeme použít nástroj Kolektor protokolů. Další informace o nástroji a jeho spuštění naleznete v tématu OMS Linux Agent Log Collector.

Důležité konfigurační soubory

Kategorie Umístění souboru
Syslog /etc/syslog-ng/syslog-ng.confnebo /etc/rsyslog.conf/etc/rsyslog.d/95-omsagent.conf
Výkon, Nagios, Zabbix, výstup Log Analytics a obecný agent /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
Další konfigurace /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

Poznámka:

Úprava konfiguračních souborů pro čítače výkonu a Syslog se přepíše, pokud je kolekce nakonfigurovaná z konfigurace agenta na webu Azure Portal pro váš pracovní prostor. Pokud chcete zakázat konfiguraci pro všechny agenty, zakažte kolekci ze správy starších agentů. Pro jednoho agenta spusťte následující skript:

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*

Kódy chyb instalace

Kód chyby Význam
NOT_DEFINED Vzhledem k tomu, že nejsou nainstalované potřebné závislosti, modul plug-in auditovaný auoms se nenainstaluje. Instalace auoms se nezdařila. Nainstalujte balíček auditovaný.
2 Neplatná možnost poskytnutá sadě prostředí Spusťte sudo sh ./omsagent-*.universal*.sh --help pro použití.
3 Pro sadu prostředí není k dispozici žádná možnost. Spusťte sudo sh ./omsagent-*.universal*.sh --help pro použití.
4 Neplatný typ balíčku nebo neplatné nastavení proxy serveru. Balíčky omsagent-rpm.sh lze nainstalovat pouze v systémech založených na RPM. Balíčky omsagent-deb.sh lze nainstalovat pouze v systémech založených na Debianu. Doporučujeme použít univerzální instalační program z nejnovější verze. Zkontrolujte také nastavení proxy serveru.
5 Sada prostředí se musí spustit jako kořen nebo při připojování došlo k chybě 403. Spusťte příkaz pomocí příkazu sudo.
6 Při onboardingu došlo k chybě 200 nebo došlo k chybě 200. Balíčky omsagent-*x64.sh lze nainstalovat pouze v 64bitových systémech. Balíčky omsagent-*x86.sh lze nainstalovat pouze v 32bitových systémech. Stáhněte si správný balíček pro vaši architekturu z nejnovější verze.
17 Instalace balíčku OMS se nezdařila. Projděte si výstup příkazu pro selhání kořenového adresáře.
18 Instalace balíčku OMSConfig se nezdařila. Projděte si výstup příkazu pro selhání kořenového adresáře.
19 Instalace balíčku OMI se nezdařila. Projděte si výstup příkazu pro selhání kořenového adresáře.
20 Instalace balíčku SCX se nezdařila. Projděte si výstup příkazu pro selhání kořenového adresáře.
21 Instalace sad zprostředkovatele se nezdařila. Projděte si výstup příkazu pro selhání kořenového adresáře.
22 Instalace balíčku se nezdařila. Projděte si výstup příkazu pro selhání kořenového adresáře.
23 Balíček SCX nebo OMI je již nainstalovaný. --install Místo instalace sady prostředí použijte--upgrade.
30 Vnitřní chyba sady. Vytvořte problém GitHubu s podrobnostmi z výstupu.
55 Nepodporovaná verze openssl nebo se nemůže připojit ke službě Azure Monitor nebo dpkg je uzamčená nebo chybí program curl.
61 Chybí knihovna ctypes Pythonu. Nainstalujte knihovnu nebo balíček ctypes Pythonu (python-ctypes).
62 Chybí program tar. Nainstalujte tar.
63 Chybí program sed. Nainstalujte sed.
64 Chybí program curl. Nainstalujte curl.
65 Chybí program gpg. Nainstalujte gpg.

Kódy chyb onboardingu

Kód chyby Význam
2 Neplatná možnost poskytnutá skriptu omsadmin. Spusťte sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h pro použití.
3 Neplatná konfigurace poskytnutá skriptu omsadmin. Spusťte sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h pro použití.
4 Neplatný proxy server zadaný skriptem omsadmin. Ověřte proxy server a projděte si naši dokumentaci k používání proxy serveru HTTP.
5 Chyba HTTP 403 přijatá ze služby Azure Monitor Podrobnosti najdete v úplném výstupu skriptu omsadmin.
6 Chyba HTTP, která není 200, se zobrazila ze služby Azure Monitor. Podrobnosti najdete v úplném výstupu skriptu omsadmin.
7 Nejde se připojit ke službě Azure Monitor. Podrobnosti najdete v úplném výstupu skriptu omsadmin.
8 Při onboardingu do pracovního prostoru služby Log Analytics došlo k chybě. Podrobnosti najdete v úplném výstupu skriptu omsadmin.
30 Vnitřní chyba skriptu Vytvořte problém GitHubu s podrobnostmi z výstupu.
31 Při generování ID agenta došlo k chybě. Vytvořte problém GitHubu s podrobnostmi z výstupu.
32 Při generování certifikátů došlo k chybě. Podrobnosti najdete v úplném výstupu skriptu omsadmin.
33 Při generování metakonfigurace pro omsconfig došlo k chybě. Vytvořte problém GitHubu s podrobnostmi z výstupu.
34 Skript generování metakonfigurace není k dispozici. Zopakujte onboarding pomocí sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>funkce .

Povolení protokolování ladění

Ladění výstupního modulu plug-in OMS

FluentD umožňuje úrovně protokolování specifické pro modul plug-in, které umožňují určit různé úrovně protokolů pro vstupy a výstupy. Pokud chcete zadat jinou úroveň protokolu pro výstup OMS, upravte obecnou konfiguraci agenta na adrese /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Ve výstupním modulu plug-in OMS před koncem konfiguračního souboru změňte log_level vlastnost z 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>

Protokolování ladění umožňuje zobrazit dávkové nahrávání do služby Azure Monitor oddělené podle typu, počtu datových položek a času potřebných k odeslání.

Tady je příklad protokolu s povoleným laděním:

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

Podrobný výstup

Místo použití výstupního modulu plug-in OMS můžete výstupní datové položky přímo do stdoutsouboru protokolu Log Analytics zobrazit v agentu Log Analytics.

V konfiguračním souboru obecného agenta Log Analytics zakomentujte /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.confvýstupní modul plug-in OMS přidáním # před každý řádek:

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

Pod výstupním modulem plug-in odkomentujte následující část odebráním # před každým řádkem:

<match **>
  type stdout
</match>

Problém: Nejde se připojit přes proxy server ke službě Azure Monitor

Pravděpodobné příčiny

  • Proxy zadaný během onboardingu byl nesprávný.
  • Koncové body služby Azure Monitor a Azure Automation nejsou zahrnuté do schváleného seznamu ve vašem datacentru.

Rozlišení

  1. Znovu se připojte ke službě Azure Monitor s agentem Log Analytics pro Linux pomocí následujícího příkazu s povolenou možností -v . Umožňuje podrobný výstup agenta, který se připojuje přes proxy server ke službě Azure Monitor: /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

  2. Zkontrolujte část Aktualizace nastavení proxy serveru a ověřte, že jste správně nakonfigurovali agenta tak, aby komunikoval přes proxy server.

  3. Pečlivě zkontrolujte, jestli jsou koncové body uvedené v seznamu požadavků na síťovou bránu firewall služby Azure Monitor přidané do seznamu povolených správně. Pokud používáte Azure Automation, propojí se výše i nezbytné kroky konfigurace sítě.

Problém: Při pokusu o připojení se zobrazí chyba 403

Pravděpodobné příčiny

  • Datum a čas jsou na serveru s Linuxem nesprávné.
  • ID pracovního prostoru a klíč pracovního prostoru nejsou správné.

Rozlišení

  1. Zkontrolujte čas na serveru s Linuxem s datem příkazu. Pokud je čas od aktuálního času +/- 15 minut, onboarding selže. Chcete-li tuto situaci opravit, aktualizujte datum a/nebo časové pásmo vašeho linuxového serveru.
  2. Ověřte, že jste nainstalovali nejnovější verzi agenta Log Analytics pro Linux. Nejnovější verze vás teď upozorní, pokud příčinou selhání onboardingu je časová nerovnoměrná distribuce.
  3. Znovu se připojte pomocí správného ID pracovního prostoru a klíče pracovního prostoru v pokynech k instalaci dříve v tomto článku.

Problém: V souboru protokolu se hned po připojení zobrazí chyba 500 a 404.

Jedná se o známý problém, ke kterému dochází při prvním nahrání dat Linuxu do pracovního prostoru služby Log Analytics. Tento problém nemá vliv na data odesílaná nebo služby.

Problém: Vidíte, že omiagent využívá procesor na 100 %

Pravděpodobné příčiny

Regrese v balíčku nss-pem v1.0.3-5.el7 způsobila závažný problém s výkonem. K tomuto problému dochází hodně v distribucích Redhat/CentOS 7.x. Další informace o tomto problému najdete v tématu 1667121 Regrese výkonu v knihovně libcurl.

Chyby související s výkonem se nedějí neustále a jejich reprodukování je obtížné. Pokud narazíte na takový problém s omiagent, použijte skript omiHighCPUDiagnostics.sh, který shromáždí trasování zásobníku omiagent, když překročí určitou prahovou hodnotu.

  1. Stáhněte si skript:
    wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh

  2. Spusťte diagnostiku po dobu 24 hodin s 30% prahovou hodnotou procesoru:
    bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

  3. Volání bude v souboru omiagent_trace výpisem. Pokud si všimnete mnoha volání funkcí curl a NSS, postupujte podle těchto kroků řešení.

Rozlišení

  1. Upgradujte balíček nss-pem na v1.0.3-5.el7_6.1:
    sudo yum upgrade nss-pem

  2. Pokud nss-pem není k dispozici pro upgrade, což se většinou děje v CentOS, downgrade curl na 7.29.0-46. Pokud spustíte "yum update" omylem, curl se upgraduje na 7.29.0-51 a problém se stane znovu:
    sudo yum downgrade curl libcurl

  3. Restartujte OMI:
    sudo scxadmin -restart

Problém: Nezobrazují se přeposílané zprávy syslogu

Pravděpodobné příčiny

  • Konfigurace použitá na server s Linuxem neumožňuje shromažďování odeslaných zařízení nebo úrovní protokolů.
  • Syslog se nepředává správně na linuxový server.
  • Počet přeposílaných zpráv za sekundu je pro základní konfiguraci agenta Log Analytics pro Linux příliš velký.

Rozlišení

  • Ověřte, že konfigurace v pracovním prostoru služby Log Analytics pro Syslog má všechna zařízení a správné úrovně protokolů. Zkontrolujte konfiguraci kolekce Syslog na webu Azure Portal.
  • Ověřte, že nativní démony zasílání zpráv syslogu (rsyslog, syslog-ng) mohou přijímat přeposílané zprávy.
  • Zkontrolujte nastavení brány firewall na serveru Syslog a ujistěte se, že zprávy nejsou blokované.
  • Simulace zprávy Syslogu do Log Analytics pomocí logger příkazu:
    logger -p local0.err "This is my test message"

Problém: Dostáváte adresu errno, která se už používá v souboru protokolu agenta omsagent

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

Pravděpodobné příčiny

Tato chyba značí, že se rozšíření diagnostiky Linuxu (LAD) instaluje souběžně s rozšířením log Analytics pro virtuální počítače s Linuxem. Používá stejný port pro shromažďování dat Syslog jako omsagent.

Rozlišení

  1. Jako kořen spusťte následující příkazy. Všimněte si, že 25224 je příkladem a je možné, že ve vašem prostředí uvidíte jiné číslo portu, které používá 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
    

    Pak musíte upravit správný rsyslogd nebo syslog_ng konfigurační soubor a změnit konfiguraci související s LAD na port 25229.

  2. Pokud je virtuální počítač spuštěný rsyslogd, soubor, který se má upravit /etc/rsyslog.d/95-omsagent.conf (pokud existuje, jinak /etc/rsyslog). Pokud je virtuální počítač spuštěný syslog_ng, soubor, který se má upravit, je /etc/syslog-ng/syslog-ng.conf.

  3. Restartujte omsagent sudo /opt/microsoft/omsagent/bin/service_control restart.

  4. Restartujte službu Syslog.

Problém: Pomocí možnosti vyprázdnění nemůžete odinstalovat omsagent

Pravděpodobné příčiny

  • Nainstaluje se rozšíření linuxové diagnostiky.
  • Diagnostické rozšíření Linuxu bylo nainstalováno a odinstalováno, ale stále se zobrazuje chyba týkající se agenta omsagent používaného nástrojem mdsd a nejde ho odebrat.

Rozlišení

  1. Odinstalujte rozšíření linuxové diagnostiky.
  2. Odeberte soubory s příponou Linuxu z počítače, pokud jsou k dispozici v následujícím umístění: /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ a /var/opt/microsoft/omsagent/LAD/.

Problém: Nezobrazují se žádná data Nagios

Pravděpodobné příčiny

  • Uživatel omsagent nemá oprávnění ke čtení ze souboru protokolu Nagios.
  • Zdroj a filtr Nagios nebyl odkomentován ze souboru omsagent.conf.

Rozlišení

  1. Přidejte uživatele omsagent pro čtení ze souboru Nagios podle těchto pokynů.

  2. V agentovi Log Analytics pro linuxový obecný konfigurační soubor /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.confse ujistěte, že zdroj a filtr Nagios nejsou nekommentovány.

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

Problém: Nezobrazují se žádná linuxová data

Pravděpodobné příčiny

  • Připojení ke službě Azure Monitor se nezdařilo.
  • Připojení ke službě Azure Monitor je zablokované.
  • Virtuální počítač se restartoval.
  • Balíček OMI byl ručně upgradován na novější verzi v porovnání s tím, co nainstaloval agent Log Analytics pro linuxový balíček.
  • OMI se zablokuje a blokuje agenta OMS.
  • Třída protokolů prostředků DSC nebyla v omsconfig.log souboru protokolu nalezena chyba.
  • Agent Log Analytics pro data se zálohuje.
  • Protokoly DSC – Aktuální konfigurace neexistuje. Spuštěním příkazu Start-DscConfiguration s parametrem -Path zadejte konfigurační soubor a nejprve vytvořte aktuální konfiguraci. v omsconfig.log souboru protokolu, ale o operacích neexistuje PerformRequiredConfigurationChecks žádná zpráva protokolu.

Rozlišení

  1. Nainstalujte všechny závislosti, jako je auditovaný balíček.

  2. Zkontrolujte, jestli nasazení do služby Azure Monitor proběhlo úspěšně, a zkontrolujte, jestli existuje následující soubor: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Pokud tomu tak nebylo, znovu se připojte pomocí omsadmin.sh pokynů příkazového řádku.

  3. Pokud používáte proxy server, zkontrolujte předchozí kroky pro řešení potíží s proxy serverem.

  4. V některých distribučních systémech Azure se po restartování virtuálního počítače nespustí proces démon serveru OMI. Pokud tomu tak je, neuvidíte data související s řešením Audit, ChangeTracking nebo UpdateManagement. Alternativním řešením je ruční spuštění serveru OMI spuštěním sudo /opt/omi/bin/service_control restartpříkazu .

  5. Po ručním upgradu balíčku OMI na novější verzi je nutné ho ručně restartovat, aby agent Log Analytics pokračoval v fungování. Tento krok se vyžaduje u některých distribucí, kde se server OMI po upgradu automaticky nespustí. Spusťte restartování sudo /opt/omi/bin/service_control restart OMI.

    V některých situacích se OMI může zmrazit. Agent OMS může zadat blokovaný stav čekající na OMI, který blokuje všechny shromažďování dat. Proces agenta OMS bude spuštěný, ale nedojde k žádné aktivitě, což je důkazem žádných nových řádků protokolu (například odeslaných prezenčních signálů) v omsagent.log. Restartujte OMI a sudo /opt/omi/bin/service_control restart obnovte agenta.

  6. Pokud se v omsconfig.log zobrazí chyba třídy prostředků DSC nebyla nalezena , spusťte sudo /opt/omi/bin/service_control restartpříkaz .

  7. V některých případech, když agent Log Analytics pro Linux nemůže komunikovat se službou Azure Monitor, data agenta se zálohují do plné velikosti vyrovnávací paměti 50 MB. Agent by měl být restartován spuštěním následujícího příkazu: /opt/microsoft/omsagent/bin/service_control restart.

    Poznámka:

    Tento problém je opravený ve verzi agenta 1.1.0-28 nebo novější.

    • omsconfig.log Pokud soubor protokolu neznamená, že PerformRequiredConfigurationChecks operace v systému běží pravidelně, může dojít k potížím s úlohou nebo službou cron. Ujistěte se, že v části /etc/cron.d/OMSConsistencyInvoker. V případě potřeby vytvořte úlohu cron spuštěním následujících příkazů:

      mkdir -p /etc/cron.d/
      echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee /etc/cron.d/OMSConsistencyInvoker
      
    • Také se ujistěte, že je spuštěná služba cron. Stav této služby můžete zkontrolovat pomocí service cron status Debianu, Ubuntu a SUSE nebo SUSE nebo service crond status RHEL, CentOS a Oracle Linuxu. Pokud služba neexistuje, můžete binární soubory nainstalovat a spustit ji pomocí následujících pokynů:

      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
      

Problém: Když nakonfigurujete kolekci z portálu pro čítače výkonu Syslogu nebo Linuxu, nastavení se nepoužije.

Pravděpodobné příčiny

  • Agent Log Analytics pro Linux nenabídl nejnovější konfiguraci.
  • Změněná nastavení na portálu nebyla použita.

Rozlišení

Pozadí: omsconfig je agent Log Analytics pro agenta konfigurace Linuxu, který každých pět minut hledá novou konfiguraci na straně portálu. Tato konfigurace se pak použije pro agenta Log Analytics pro konfigurační soubory Linuxu umístěné na adrese /etc/opt/microsoft/omsagent/conf/omsagent.conf.

V některých případech nemusí agent Log Analytics pro agenta konfigurace Linuxu komunikovat se službou konfigurace portálu. Výsledkem tohoto scénáře je, že se nepoužívá nejnovější konfigurace.

  1. Zkontrolujte, jestli omsconfig je agent nainstalovaný spuštěním dpkg --list omsconfig nebo rpm -qi omsconfig. Pokud není nainstalovaný, přeinstalujte nejnovější verzi agenta Log Analytics pro Linux.

  2. Spuštěním následujícího příkazu zkontrolujte, že omsconfig agent může komunikovat se službou Azure Monitor: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py' Tento příkaz vrátí konfiguraci, kterou agent přijímá ze služby, včetně nastavení Syslogu, čítačů výkonu Linuxu a vlastních protokolů. Pokud tento příkaz selže, spusťte následující příkaz: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Tento příkaz vynutí agenta omsconfig komunikovat se službou Azure Monitor a načíst nejnovější konfiguraci.

Problém: Nezobrazují se žádná vlastní data protokolu

Pravděpodobné příčiny

  • Připojení ke službě Azure Monitor se nezdařilo.
  • Nastavení Použít následující konfiguraci na servery s Linuxem nebylo vybráno.
  • omsconfig nenabídl nejnovější konfiguraci vlastního protokolu ze služby.
  • Agent Log Analytics pro uživatele omsagent s Linuxem nemá přístup k vlastnímu protokolu kvůli oprávněním nebo se nenašel. Může se zobrazit následující chyby:
    • [DATETIME] [warn]: file not found. Continuing without tailing it.
    • [DATETIME] [error]: file not accessible by omsagent.
  • Známý problém s podmínkou časování opravený v agentu Log Analytics pro Linux verze 1.1.0-217

Rozlišení

  1. Zkontrolujte, jestli existuje následující soubor, a ověřte, jestli se onboarding do služby Azure Monitor úspěšně nasadí: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf Pokud ne, buď:

    1. Znovu se připojte pomocí pokynů příkazového řádku omsadmin.sh.
    2. V části Upřesnit nastavení na webu Azure Portal se ujistěte, že je pro servery s Linuxem povolené nastavení Použít následující konfiguraci.
  2. Spuštěním následujícího příkazu zkontrolujte, že omsconfig agent může komunikovat se službou Azure Monitor: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py' Tento příkaz vrátí konfiguraci, kterou agent přijímá ze služby, včetně nastavení Syslogu, čítačů výkonu Linuxu a vlastních protokolů. Pokud tento příkaz selže, spusťte následující příkaz: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Tento příkaz vynutí agenta omsconfig komunikovat se službou Azure Monitor a načíst nejnovější konfiguraci.

Pozadí: Místo agenta Log Analytics pro Linux spuštěného jako privilegovaný uživatel – rootagent běží jako omsagent uživatel. Ve většině případů musí být tomuto uživateli udělena explicitní oprávnění, aby se určité soubory četly. Pokud chcete uživateli udělit oprávnění omsagent , spusťte následující příkazy:

  1. omsagent Přidejte uživatele do konkrétní skupiny: sudo usermod -a -G <GROUPNAME> <USERNAME>.
  2. Udělte univerzální přístup pro čtení požadovanému souboru: sudo chmod -R ugo+rx <FILE DIRECTORY>.

Existuje známý problém s podmínkou časování s agentem Log Analytics pro Linux starší než 1.1.0-217. Po aktualizaci na nejnovějšího agenta spusťte následující příkaz a získejte nejnovější verzi výstupního modulu plug-in: sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Problém: Pokoušíte se znovu připojit k novému pracovnímu prostoru

Při pokusu o opětovné připojení agenta do nového pracovního prostoru je potřeba před opětovným zprovozněním vyčistit konfiguraci agenta Log Analytics. Pokud chcete vyčistit starou konfiguraci z agenta, spusťte sadu prostředí pomocí --purgepříkazu :

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

Nebo

sudo sh ./onboard_agent.sh --purge

Po použití této možnosti můžete pokračovat v opětovném --purge zprovoznit.

Problém: Rozšíření agenta Log Analytics na webu Azure Portal je označené stavem selhání: Zřizování selhalo

Pravděpodobné příčiny

  • Agent Log Analytics byl z operačního systému odebrán.
  • Služba agenta Log Analytics je vypnutá, zakázaná nebo není nakonfigurovaná.

Rozlišení

  1. Odeberte rozšíření z webu Azure Portal.
  2. Podle pokynů nainstalujte agenta.
  3. Restartujte agenta spuštěním následujícího příkazu:
    sudo /opt/microsoft/omsagent/bin/service_control restart.
  4. Počkejte několikminutch

Problém: Upgrade agenta Log Analytics na vyžádání

Pravděpodobné příčiny

Balíčky agenta Log Analytics na hostiteli jsou zastaralé.

Rozlišení

  1. Na této stránce GitHubu vyhledejte nejnovější verzi.

  2. Stáhněte si instalační skript (1.4.2-124 je ukázková verze):

    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. Upgradujte balíčky spuštěním sudo sh ./omsagent-*.universal.x64.sh --upgradepříkazu .

Problém: Instalace selhává a říká, že Python2 nemůže podporovat typy ctype, i když se používá Python3

Pravděpodobné příčiny

U tohoto známého problému platí, že pokud jazyk virtuálního počítače není angličtina, kontrola se nezdaří při ověření používané verze Pythonu. Tento problém vede k agentovi vždy za předpokladu, že se Python2 používá a selhává, pokud neexistuje žádný Python2.

Rozlišení

Změňte jazyk prostředí virtuálního počítače na angličtinu:

export LANG=en_US.UTF-8