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

  • Článek

Tento článek poskytuje pomoc při řešení chyb, ke kterým může dojít u agenta Log Analytics pro Linux ve službě Azure Monitor.

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

Nástroj pro řešení potíží s agentem Log Analytics pro Linux je skript, který pomáhá najít a diagnostikovat problémy s agentem Log Analytics. Při 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íží

Nástroj pro řešení potíží spustíte tak, že do okna terminálu na počítači s agentem Log Analytics vložíte 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 se instalace jakýmkoli způsobem nezdaří, můžete nástroj nainstalovat také ručně:

  1. Ujistěte se, že je na počítači nainstalovaný program GNU Project Debugger (GDB), protože na něj poradce při potížích spoléhá.
  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 balíček: 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; prezentní signál nefunguje správně.
  • Agent se nespustí nebo se nemůže připojit ke službě Log Analytics.
  • Syslog agenta 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 narazíte na problém, spusťte nástroj Kolektor protokolů. Počáteční nastavení protokolů našemu týmu podpory pomůže rychleji vyřešit váš problém.

Vymazání a přeinstalace agenta pro Linux

Většinu problémů vyřeší čistá přeinstalace agenta. Tato úloha může být prvním návrhem od našeho týmu podpory, jak dostat agenta do stavu, který není poškozený. Rychlejší řešení problémů vám pomůže spuštění nástroje Pro řešení potíží a nástroje Kolektoru protokolů a pokus o čistou přeinstalaci.

  1. Stáhněte si skript pro vymazání:

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

  2. Spusťte skript pro vymazá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
Soubor protokolu agenta Log Analytics pro Linux /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
Konfigurační soubor protokolu agenta Log Analytics /var/opt/microsoft/omsconfig/omsconfig.log

Doporučujeme, abyste k načtení důležitých protokolů pro řešení potíží nebo před odesláním problému na GitHubu použili nástroj Kolektor protokolů. Další informace o nástroji a jeho spuštění najdete v tématu Kolektor protokolů agenta OMS pro Linux.

Důležité konfigurační soubory

Kategorie Umístění souboru
Syslog /etc/syslog-ng/syslog-ng.confnebo nebo /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

Úpravy konfiguračních souborů pro čítače výkonu a syslog se přepíšou, pokud je kolekce nakonfigurovaná z konfigurace agenta v Azure Portal pro váš pracovní prostor. Pokud chcete zakázat konfiguraci pro všechny agenty, zakažte shromažďování 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, nebude modul plug-in auoms auditovaný modul plug-in nainstalován. Instalace auoms se nezdařila. Instalace balíčku je auditovaná.
2 Sada prostředí má zadanou neplatnou možnost. Spusťte příkaz sudo sh ./omsagent-*.universal*.sh --help pro použití.
3 Sada prostředí nemá k dispozici žádnou možnost. Spusťte příkaz 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í musí být spuštěna jako root nebo se během onboardingu vrátila chyba 403. Spusťte příkaz pomocí příkazu sudo.
6 Neplatná architektura balíčku nebo se během onboardingu vrátila chyba 200. Balíčky omsagent-*x64.sh lze nainstalovat pouze do 64bitových systémů. Balíčky omsagent-*x86.sh lze nainstalovat pouze do 32bitových systémů. Stáhněte si správný balíček pro vaši architekturu z nejnovější verze.
17 Instalace balíčku OMS se nezdařila. Ve výstupu příkazu vyhledejte chybu kořenového adresáře.
18 Instalace balíčku OMSConfig se nezdařila. Ve výstupu příkazu vyhledejte chybu kořenového adresáře.
19 Instalace balíčku OMI se nezdařila. Ve výstupu příkazu vyhledejte chybu kořenového adresáře.
20 Instalace balíčku SCX se nezdařila. Ve výstupu příkazu vyhledejte chybu kořenového adresáře.
21 Instalace sad zprostředkovatele se nezdařila. Ve výstupu příkazu vyhledejte chybu kořenového adresáře.
22 Instalace balíčku se nezdařila. Ve výstupu příkazu vyhledejte chybu kořenového adresáře.
23 Balíček SCX nebo OMI už je nainstalovaný. K instalaci sady prostředí použijte --upgrade místo --install .
30 Vnitřní chyba sady prostředků. Vytvořte problém na GitHubu s podrobnostmi z výstupu.
55 Nepodporovaná verze openssl , nejde se připojit ke službě Azure Monitor nebo dpkg je uzamčená nebo chybí program curl.
61 Chybí knihovna Python ctypes. Nainstalujte knihovnu nebo balíček Python ctypes (python-ctypes).
62 Chybí program tar. Nainstalujte tar.
63 Chybí program sed. Nainstalujte sed.
64 Chybí program curl. Nainstalujte nástroj curl.
65 Chybí program gpg. Nainstalujte gpg.

Kódy chyb onboardingu

Kód chyby Význam
2 Skript omsadmin má zadanou neplatnou možnost. Pokud chcete informace o využití, spusťte příkaz sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h .
3 Skript omsadmin má zadanou neplatnou konfiguraci. Pokud chcete informace o využití, spusťte příkaz sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h .
4 Pro skript omsadmin byl poskytnut neplatný proxy server. Ověřte proxy server a projděte si naši dokumentaci k použití proxy serveru HTTP.
5 Ze služby Azure Monitor došlo k chybě 403 PROTOKOLU HTTP. Podrobnosti najdete v úplném výstupu skriptu omsadmin.
6 Ze služby Azure Monitor došlo k chybě protokolu HTTP jiného typu než 200. 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 na GitHubu s podrobnostmi z výstupu.
31 Při generování ID agenta došlo k chybě. Vytvořte problém na 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 na GitHubu s podrobnostmi z výstupu.
34 Skript generování metakonfigurace není k dispozici. Zkuste se znovu připojit pomocí sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>.

Povolení protokolování ladění

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

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

Ve výstupním modulu plug-in OMS změňte log_level před koncem konfiguračního souboru vlastnost z info na 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ého 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í položky dat zobrazit přímo do stdoutsouboru protokolu linuxového agenta Log Analytics.

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

#<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 jednotlivými řádky:

<match **>
  type stdout
</match>

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

Pravděpodobné příčiny

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

Řešení

  1. Znovu se připojte k Azure Monitoru pomocí agenta Log Analytics pro Linux pomocí následujícího příkazu s povolenou možností -v . Umožňuje podrobný výstup agenta připojujícího se 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. Projděte si část Aktualizace nastavení proxy serveru a ověřte, že jste agenta správně nakonfigurovali tak, aby komunikoval přes proxy server.

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

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

Pravděpodobné příčiny

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

Řešení

  1. Zkontrolujte čas na serveru s Linuxem pomocí data příkazu. Pokud je čas +/- 15 minut od aktuálního času, onboarding se nezdaří. Pokud chcete tuto situaci vyřešit, aktualizujte datum nebo časové pásmo serveru s Linuxem.
  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 nerovnoměrná distribuce času.
  3. Znovu se připojte pomocí správného ID a klíče pracovního prostoru v pokynech k instalaci výše v tomto článku.

Problém: Hned po onboardingu se v souboru protokolu 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 odesílaná data ani na prostředí 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í často v distribucích Redhat/CentOS 7.x. Další informace o tomto problému najdete v tématu regrese výkonu 1667121 v knihovně libcurl.

Chyby související s výkonem se nedějí po celou dobu a je obtížné je reprodukovat. Pokud narazíte na takový problém s agentem omiagent, použijte skript omiHighCPUDiagnostics.sh, který shromáždí trasování zásobníku agenta 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 vyhozeno. Pokud si všimnete mnoha volání funkcí curl a NSS, postupujte podle těchto kroků řešení.

Řešení

  1. Upgradujte balíček nss-pem na verzi 1.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 verzi 7.29.0-51 a k problému dojde 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 linuxový server neumožňuje shromažďování odeslaných zařízení nebo úrovní protokolu.
  • Syslog se nepřesměrovává správně na linuxový server.
  • Počet zpráv, které se přeposílají za sekundu, je příliš velký na to, aby základní konfigurace agenta Log Analytics pro Linux zvládla.

Řešení

  • Ověřte, že konfigurace v pracovním prostoru služby Log Analytics pro Syslog obsahuje všechny možnosti a správné úrovně protokolu. Projděte si konfiguraci kolekce Syslog v Azure Portal.
  • Ověřte, že nativní démoni 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 se zprávy neblokují.
  • 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

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

Pravděpodobné příčiny

Tato chyba značí, že se souběžně s rozšířením virtuálních počítačů s Linuxem instaluje rozšíření Linux Diagnostic Extension (LAD). Pro shromažďování dat Syslog používá stejný port jako omsagent.

Řešení

  1. Jako root 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 soubor nebo syslog_ng konfigurační soubor a změnit konfiguraci související s LAD tak, aby se zapisovala na port 25229.

  2. Pokud je virtuální počítač spuštěný rsyslogd, soubor, který se má upravit, je /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 vymazání nejde odinstalovat agenta omsagent.

Pravděpodobné příčiny

  • Nainstaluje se rozšíření diagnostiky Linuxu.
  • Rozšíření diagnostiky pro Linux se nainstalovalo a odinstalovalo, ale stále se zobrazuje chyba týkající se používání agenta omsagent v mdsd, kterou nejde odebrat.

Řešení

  1. Odinstalujte rozšíření diagnostiky linuxu.
  2. Odeberte z počítače soubory rozšíření diagnostiky Linuxu, pokud jsou 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 se ze souboru omsagent.conf neodkomentoval.

Řešení

  1. Podle těchto pokynů přidejte uživatele omsagent ke čtení ze souboru Nagios.

  2. V obecném konfiguračním souboru agenta Log Analytics pro Linux na adrese /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.confse ujistěte , že zdroj i filtr Nagios nejsou komentáře.

    <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á data z Linuxu

Pravděpodobné příčiny

  • Onboarding do Služby Azure Monitor se nezdařil.
  • 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 balíčkem nainstalovaným agentem Log Analytics pro Linux.
  • OMI je zablokovaný a blokuje agenta OMS.
  • Chyba třídy protokolů prostředků DSC nebyla nalezena v omsconfig.log souboru protokolu.
  • 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 určete konfigurační soubor a nejprve vytvořte aktuální konfiguraci. v omsconfig.log souboru protokolu, ale neexistuje žádná zpráva protokolu o PerformRequiredConfigurationChecks operacích.

Řešení

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

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

  3. Pokud používáte proxy server, projděte si předchozí postup ř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. V takovém případě neuvidíte data týkající se řešení Audit, ChangeTracking nebo UpdateManagement. Alternativním řešením je ručně spustit server OMI spuštěním příkazu sudo /opt/omi/bin/service_control restart.

  5. Po ručním upgradu balíčku OMI na novější verzi je nutné ho ručně restartovat, aby agent Log Analytics dál fungoval. Tento krok je nutný pro některé distribuce, ve kterých se server OMI po upgradu nespustí automaticky. Spuštěním příkazu sudo /opt/omi/bin/service_control restart restartujte OMI.

    V některých situacích může být OMI zablokovaný. Agent OMS může přejít do zablokovaného stavu čekajícího na OMI, který blokuje veškeré shromažďování dat. Proces agenta OMS bude spuštěný, ale nebude k dispozici žádná aktivita, což dokládá, že v omsagent.logsystému nejsou žádné nové řádky protokolu (například odeslané prezenční signály). Restartujte OMI s a sudo /opt/omi/bin/service_control restart obnovte agenta.

  6. Pokud se v souboru omsconfig.log zobrazí chyba Třída 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, se data v agentovi zálohují do plné velikosti vyrovnávací paměti 50 MB. Agent by se měl restartovat 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 nenaznačuje, že PerformRequiredConfigurationChecks se v systému pravidelně spouští operace, může být problém s úlohou nebo službou cron. Ujistěte se, že úloha cron existuje v části /etc/cron.d/OMSConsistencyInvoker. V případě potřeby spusťte následující příkazy a vytvořte úlohu cron:

      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. Ke kontrole stavu této služby můžete použít service cron status debian, Ubuntu a SUSE nebo service crond status RHEL, CentOS a Oracle Linux. Pokud služba neexistuje, můžete nainstalovat binární soubory a spustit ji podle 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 na portálu pro čítače výkonu Syslogu nebo Linuxu, nastavení se nepoužije.

Pravděpodobné příčiny

  • Agent Log Analytics pro Linux nezístil nejnovější konfiguraci.
  • Změněné nastavení na portálu se nepoužádalo.

Řešení

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

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

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

  2. Spuštěním omsconfig následujícího příkazu zkontrolujte, že 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 obdrží 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í, aby agent omsconfig mluvil se službou Azure Monitor a načetl nejnovější konfiguraci.

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

Pravděpodobné příčiny

  • Onboarding do služby Azure Monitor selhal.
  • Nastavení Použít následující konfiguraci na servery s Linuxem nebylo vybráno.
  • omsconfig nezíská ze služby nejnovější vlastní konfiguraci protokolu.
  • Agent Log Analytics pro uživatele omsagent Linuxu nemůže získat přístup k vlastnímu protokolu kvůli oprávněním nebo kvůli tomu, že se nenašel. Můžou 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 opravou časování v agentu Log Analytics pro Linux verze 1.1.0-217

Řešení

  1. Ověřte, že onboarding do služby Azure Monitor proběhl úspěšně. Zkontrolujte, jestli existuje následující soubor: /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í v Azure Portal se ujistěte, že je povolené nastavení Použít následující konfiguraci pro servery s Linuxem.

  2. Spuštěním omsconfig následujícího příkazu zkontrolujte, že 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 obdrží 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í omsconfig , aby agent komunikovat s Azure Monitorem a načetl nejnovější konfiguraci.

Pozadí: Místo agenta Log Analytics pro Linux spuštěného jako privilegovaný uživatel root– se agent spouští jako omsagent uživatel. Ve většině případů musí být tomuto uživateli uděleno explicitní oprávnění ke čtení určitých souborů. 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 k požadovanému souboru univerzální přístup pro čtení: sudo chmod -R ugo+rx <FILE DIRECTORY>.

Existuje známý problém s konfliktem časování agenta Log Analytics pro linuxovou verzi starší než 1.1.0–217. Po aktualizaci na nejnovějšího agenta spusťte následující příkaz, abyste získali 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 z agenta vyčistit starou konfiguraci, 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í --purge této možnosti můžete pokračovat v opětovném nasazení.

Problém: Rozšíření agenta Log Analytics v Azure Portal je označené ve stavu selhání: Zřizování selhalo

Pravděpodobné příčiny

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

Řešení

  1. Odeberte rozšíření ze Azure Portal.
  2. Nainstalujte agenta podle pokynů.
  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ěkolik minut, než se stav zřizování změní na Zřizování bylo úspěšné.

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

Pravděpodobné příčiny

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

Řešení

  1. Podívejte se na nejnovější verzi na této stránce GitHubu.

  2. Stáhněte si instalační skript (příklad verze je 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. Upgradujte balíčky spuštěním sudo sh ./omsagent-*.universal.x64.sh --upgradepříkazu .

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

Pravděpodobné příčiny

V případě tohoto známého problému platí, že pokud jazyk virtuálního počítače není angličtina, kontrola při ověřování používané verze Pythonu selže. Tento problém vede k tomu, že agent vždy předpokládá, že se používá Python2, a pokud neexistuje Žádný Python2, selže.

Řešení

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

export LANG=en_US.UTF-8