Udostępnij za pośrednictwem

Rozwiązywanie problemów z agentem usługi Log Analytics dla systemu Linux

  • Artykuł

Ten artykuł zawiera pomoc w rozwiązywaniu problemów z błędami, które mogą wystąpić w przypadku agenta usługi Log Analytics dla systemu Linux w usłudze Azure Monitor.

Uwaga

W tym artykule odwołuje się do systemu CentOS — dystrybucji systemu Linux, która jest stanem End Of Life (EOL). Rozważ odpowiednie użycie i planowanie. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące zakończenia życia systemu CentOS.

Narzędzie do rozwiązywania problemów z usługą Log Analytics

Narzędzie do rozwiązywania problemów z usługą Log Analytics dla systemu Linux to skrypt, który ułatwia znajdowanie i diagnozowanie problemów z agentem usługi Log Analytics. Jest on automatycznie dołączany do agenta podczas instalacji. Uruchomienie narzędzia powinno być pierwszym krokiem w diagnozowaniu problemu.

Korzystanie z narzędzia do rozwiązywania problemów

Aby uruchomić narzędzie do rozwiązywania problemów, wklej następujące polecenie w oknie terminalu na maszynie z agentem usługi Log Analytics:

sudo /opt/microsoft/omsagent/bin/troubleshooter

Instalacja ręczna

Narzędzie do rozwiązywania problemów jest automatycznie dołączane po zainstalowaniu agenta usługi Log Analytics. Jeśli instalacja nie powiedzie się w jakikolwiek sposób, możesz również zainstalować narzędzie ręcznie:

  1. Upewnij się, że debuger projektu GNU (GDB) jest zainstalowany na maszynie, ponieważ narzędzie do rozwiązywania problemów opiera się na nim.
  2. Skopiuj pakiet narzędzia do rozwiązywania problemów na maszynę: wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
  3. Rozpakuj pakiet: tar -xzvf omsagent_tst.tar.gz
  4. Uruchom instalację ręczną: sudo ./install_tst

Objęte scenariusze

Narzędzie do rozwiązywania problemów sprawdza następujące scenariusze:

  • Agent jest w złej kondycji; puls nie działa prawidłowo.
  • Agent nie uruchamia się lub nie może nawiązać połączenia z usługą Log Analytics.
  • Dziennik systemowy agenta nie działa.
  • Agent ma wysokie użycie procesora CPU lub pamięci.
  • Agent ma problemy z instalacją.
  • Dzienniki niestandardowe agenta nie działają.
  • Nie można zbierać dzienników agentów.

Aby uzyskać więcej informacji, zobacz dokumentację narzędzia do rozwiązywania problemów w witrynie GitHub.

Uwaga

Uruchom narzędzie modułu zbierającego dzienniki, gdy wystąpi problem. Pierwsze dzienniki pomogą naszemu zespołowi pomocy technicznej w szybszym rozwiązywaniu problemu.

Przeczyszczanie i ponowne instalowanie agenta systemu Linux

Czysta ponowna instalacja agenta rozwiązuje większość problemów. To zadanie może być pierwszą sugestią od naszego zespołu pomocy technicznej, aby umożliwić agentowi przejście do stanu nieukorzystanego. Uruchomienie narzędzia do rozwiązywania problemów i narzędzia modułu zbierającego dzienniki oraz próba czystej instalacji ułatwia szybsze rozwiązywanie problemów.

  1. Pobierz skrypt przeczyszczania:

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

  2. Uruchom skrypt przeczyszczania (z uprawnieniami sudo):

    $ sudo sh purge_omsagent.sh

Ważne lokalizacje dziennika i narzędzie modułu zbierającego dzienniki

Plik Ścieżka
Agent usługi Log Analytics dla pliku dziennika systemu Linux /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
Plik dziennika konfiguracji agenta usługi Log Analytics /var/opt/microsoft/omsconfig/omsconfig.log

Zalecamy użycie narzędzia modułu zbierającego dzienniki w celu pobrania ważnych dzienników na potrzeby rozwiązywania problemów lub przed przesłaniem problemu z usługą GitHub. Aby uzyskać więcej informacji o narzędziu i sposobie jego uruchamiania, zobacz Moduł zbierający dzienniki agentów systemu Linux w usłudze OMS.

Ważne pliki konfiguracji

Kategoria Lokalizacja pliku
Dziennik systemu /etc/syslog-ng/syslog-ng.conflub lub /etc/rsyslog.conf/etc/rsyslog.d/95-omsagent.conf
Wydajność, Nagios, Zabbix, dane wyjściowe usługi Log Analytics i agent ogólny /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
Dodatkowe konfiguracje /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

Uwaga

Edytowanie plików konfiguracji dla liczników wydajności i dziennik syslog jest zastępowany, jeśli kolekcja jest skonfigurowana z konfiguracji agenta w witrynie Azure Portal dla obszaru roboczego. Aby wyłączyć konfigurację dla wszystkich agentów, wyłącz zbieranie z zarządzania starszymi agentami. W przypadku pojedynczego agenta uruchom następujący skrypt:

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*

Kody błędów instalacji

Kod błędu Znaczenie
NOT_DEFINED Ponieważ niezbędne zależności nie są zainstalowane, wtyczka inspekcji auoms nie zostanie zainstalowana. Instalacja auoms nie powiodła się. Zainstaluj przeprowadź inspekcję pakietu.
2 Nieprawidłowa opcja podana w pakiecie powłoki. Uruchom polecenie sudo sh ./omsagent-*.universal*.sh --help w celu użycia.
3 Brak opcji podanej w pakiecie powłoki. Uruchom polecenie sudo sh ./omsagent-*.universal*.sh --help w celu użycia.
100 Nieprawidłowy typ pakietu lub nieprawidłowe ustawienia serwera proxy. Pakiety omsagent-rpm.sh można zainstalować tylko w systemach opartych na rpm. Pakiety omsagent-deb.sh można instalować tylko w systemach opartych na debianie. Zalecamy używanie instalatora uniwersalnego z najnowszej wersji. Sprawdź również, czy ustawienia serwera proxy są weryfikowane.
5 Pakiet powłoki musi zostać wykonany jako katalog główny lub wystąpił błąd 403 zwrócony podczas dołączania. Uruchom polecenie przy użyciu polecenia sudo.
6 Nieprawidłowa architektura pakietu lub wystąpił błąd 200 zwrócony podczas dołączania. Pakiety omsagent-*x64.sh można zainstalować tylko w systemach 64-bitowych. Pakiety omsagent-*x86.sh można instalować tylko w systemach 32-bitowych. Pobierz prawidłowy pakiet dla swojej architektury z najnowszej wersji.
17 Instalacja pakietu pakietu OMS nie powiodła się. Przejrzyj dane wyjściowe polecenia dla błędu głównego.
18 Instalacja pakietu OMSConfig nie powiodła się. Przejrzyj dane wyjściowe polecenia dla błędu głównego.
19 Instalacja pakietu OMI nie powiodła się. Przejrzyj dane wyjściowe polecenia dla błędu głównego.
20 Instalacja pakietu SCX nie powiodła się. Przejrzyj dane wyjściowe polecenia dla błędu głównego.
21 Instalacja zestawów dostawcy nie powiodła się. Przejrzyj dane wyjściowe polecenia dla błędu głównego.
22 Instalacja pakietu pakietu nie powiodła się. Przejrzyj dane wyjściowe polecenia dla błędu głównego
23 Zainstalowany pakiet SCX lub OMI. Zamiast --upgrade --install instalować pakiet powłoki.
30 Wewnętrzny błąd pakietu. Zgłoś problem z usługą GitHub ze szczegółami z danych wyjściowych.
55 Nieobsługiwana wersja openssl lub nie można nawiązać połączenia z usługą Azure Monitor lub dpkg jest zablokowana lub brakuje programu curl.
61 Brak biblioteki ctypes języka Python. Zainstaluj bibliotekę lub pakiet ctypes języka Python (python-ctypes).
62 Brak programu tar. Zainstaluj tar.
63 Brak programu sed. Zainstaluj sed.
64 Brak programu curl. Zainstaluj program curl.
65 Brak programu gpg. Zainstaluj gpg.

Kody błędów dołączania

Kod błędu Znaczenie
2 Nieprawidłowa opcja podana dla skryptu omsadmin. Uruchom polecenie sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h w celu użycia.
3 Nieprawidłowa konfiguracja dostarczona do skryptu omsadmin. Uruchom polecenie sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h w celu użycia.
100 Nieprawidłowy serwer proxy dostarczony do skryptu omsadmin. Sprawdź serwer proxy i zapoznaj się z naszą dokumentacją dotyczącą korzystania z serwera proxy HTTP.
5 Błąd HTTP 403 odebrany z usługi Azure Monitor. Aby uzyskać szczegółowe informacje, zobacz pełne dane wyjściowe skryptu omsadmin.
6 Błąd HTTP inny niż 200 odebrany z usługi Azure Monitor. Aby uzyskać szczegółowe informacje, zobacz pełne dane wyjściowe skryptu omsadmin.
7 Nie można nawiązać połączenia z usługą Azure Monitor. Aby uzyskać szczegółowe informacje, zobacz pełne dane wyjściowe skryptu omsadmin.
8 Błąd podczas dołączania do obszaru roboczego usługi Log Analytics. Aby uzyskać szczegółowe informacje, zobacz pełne dane wyjściowe skryptu omsadmin.
30 Wewnętrzny błąd skryptu. Zgłoś problem z usługą GitHub ze szczegółami z danych wyjściowych.
31 Błąd podczas generowania identyfikatora agenta. Zgłoś problem z usługą GitHub ze szczegółami z danych wyjściowych.
32 Błąd podczas generowania certyfikatów. Aby uzyskać szczegółowe informacje, zobacz pełne dane wyjściowe skryptu omsadmin.
33 Błąd podczas generowania metakonfiguracji dla konfiguracji omsconfig. Zgłoś problem z usługą GitHub ze szczegółami z danych wyjściowych.
34 Skrypt generowania metakonfiguracji nie istnieje. Ponów próbę dołączenia za pomocą polecenia sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>.

Włączanie rejestrowania debugowania

Debugowanie wtyczki wyjściowej pakietu OMS

Funkcja FluentD umożliwia korzystanie z poziomów rejestrowania specyficznych dla wtyczek, które umożliwiają określanie różnych poziomów dziennika dla danych wejściowych i wyjściowych. Aby określić inny poziom dziennika dla danych wyjściowych pakietu OMS, zmodyfikuj konfigurację agenta ogólnego na stronie /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

W wtyczki wyjściowej pakietu OMS przed końcem pliku konfiguracji zmień log_level właściwość 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>

Rejestrowanie debugowania umożliwia wyświetlanie wsadowych przekazań do usługi Azure Monitor oddzielonych według typu, liczby elementów danych i czasu potrzebnego do wysłania.

Oto przykładowy dziennik z obsługą debugowania:

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

Pełne dane wyjściowe

Zamiast korzystać z wtyczki wyjściowej pakietu OMS, można wydawać elementy danych bezpośrednio do stdoutpliku , który jest widoczny w pliku dziennika usługi Log Analytics dla systemu Linux.

W pliku konfiguracji agenta ogólnego usługi Log Analytics pod adresem /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.confdodaj wtyczkę wyjściową pakietu OMS, dodając przed każdym wierszem # :

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

Poniżej wtyczki wyjściowej usuń komentarz z następującej sekcji, usuwając # komentarz przed każdym wierszem:

<match **>
  type stdout
</match>

Problem: Nie można nawiązać połączenia za pośrednictwem serwera proxy z usługą Azure Monitor

Prawdopodobne przyczyny

  • Serwer proxy określony podczas dołączania był niepoprawny.
  • Punkty końcowe usługi Azure Monitor i Azure Automation nie są uwzględnione na liście zatwierdzonych w centrum danych.

Rozwiązanie

  1. Ponowne dołączanie do usługi Azure Monitor przy użyciu agenta usługi Log Analytics dla systemu Linux przy użyciu następującego polecenia z włączoną opcją -v . Umożliwia pełne wyjście agenta łączącego się za pośrednictwem serwera proxy z usługą Azure Monitor: /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

  2. Zapoznaj się z sekcją Aktualizowanie ustawień serwera proxy, aby sprawdzić, czy agent został prawidłowo skonfigurowany do komunikacji za pośrednictwem serwera proxy.

  3. Sprawdź dokładnie, czy punkty końcowe opisane na liście wymagań zapory sieciowej usługi Azure Monitor są poprawnie dodawane do listy dozwolonych. Jeśli używasz usługi Azure Automation, wymagane kroki konfiguracji sieci są również połączone powyżej.

Problem: Podczas próby dołączenia występuje błąd 403

Prawdopodobne przyczyny

  • Data i godzina są niepoprawne na serwerze z systemem Linux.
  • Identyfikator obszaru roboczego i klucz obszaru roboczego nie są poprawne.

Rozwiązanie

  1. Sprawdź godzinę na serwerze z systemem Linux z datą polecenia. Jeśli czas wynosi +/- 15 minut od bieżącego czasu, dołączanie kończy się niepowodzeniem. Aby rozwiązać tę sytuację, zaktualizuj datę i/lub strefę czasową serwera z systemem Linux.
  2. Sprawdź, czy zainstalowano najnowszą wersję agenta usługi Log Analytics dla systemu Linux. Najnowsza wersja powiadamia teraz o tym, czy niesymetryczność czasu powoduje niepowodzenie dołączania.
  3. Ponowne dołączanie przy użyciu poprawnego identyfikatora obszaru roboczego i klucza obszaru roboczego we wcześniejszych instrukcjach instalacji w tym artykule.

Problem: Po dołączeniu zobaczysz błąd 500 i 404 w pliku dziennika

Jest to znany problem występujący podczas pierwszego przekazywania danych systemu Linux do obszaru roboczego usługi Log Analytics. Ten problem nie ma wpływu na wysyłane dane ani środowisko obsługi.

Problem: widać, że program omiagent używa 100% procesora CPU

Prawdopodobne przyczyny

Regresja w pakiecie nss-pem w wersji 1.0.3-5.el7 spowodowała poważny problem z wydajnością. Widzimy, że ten problem pojawia się dużo w dystrybucjach Redhat/CentOS 7.x. Aby dowiedzieć się więcej na temat tego problemu, zobacz 1667121 Regresja wydajności w bibliotece libcurl.

Błędy związane z wydajnością nie występują przez cały czas i są trudne do odtworzenia. Jeśli wystąpi taki problem z usługą omiagent, użyj skryptu omiHighCPUDiagnostics.sh, który zbierze ślad stosu omiagenta, gdy przekroczy określony próg.

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

  2. Uruchom diagnostykę przez 24 godziny z progiem procesora CPU 30%:
    bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

  3. Stos wywołań zostanie po cenach dumpingowych w pliku omiagent_trace. Jeśli zauważysz wiele wywołań funkcji curl i NSS, wykonaj następujące kroki rozwiązywania problemów.

Rozwiązanie

  1. Uaktualnij pakiet nss-pem do wersji 1.0.3-5.el7_6.1:
    sudo yum upgrade nss-pem

  2. Jeśli nss-pem nie jest dostępny do uaktualnienia, co dzieje się głównie w systemie CentOS, obniżenie poziomu curl do 7.29.0-46. Jeśli po błędzie uruchomisz polecenie "aktualizacja yum", program curl zostanie uaktualniony do wersji 7.29.0-51, a problem wystąpi ponownie:
    sudo yum downgrade curl libcurl

  3. Uruchom ponownie usługę OMI:
    sudo scxadmin -restart

Problem: nie są wyświetlane przekazane dalej komunikaty dziennika systemowego

Prawdopodobne przyczyny

  • Konfiguracja zastosowana do serwera z systemem Linux nie zezwala na zbieranie wysłanych obiektów ani poziomów dziennika.
  • Dziennik systemowy nie jest prawidłowo przekazywany do serwera z systemem Linux.
  • Liczba komunikatów przekazywanych na sekundę jest zbyt duża, aby podstawowa konfiguracja agenta usługi Log Analytics dla systemu Linux była zbyt duża.

Rozwiązanie

  • Sprawdź, czy konfiguracja w obszarze roboczym usługi Log Analytics dla usługi Syslog ma wszystkie obiekty i prawidłowe poziomy dziennika. Zapoznaj się z artykułem Konfigurowanie kolekcji syslog w witrynie Azure Portal.
  • Sprawdź, czy natywne demony komunikatów dziennika systemowego (rsyslog, syslog-ng) mogą odbierać przekazane komunikaty.
  • Sprawdź ustawienia zapory na serwerze Syslog, aby upewnić się, że komunikaty nie są blokowane.
  • Symuluj komunikat dziennika systemowego w usłudze Log Analytics przy użyciu logger polecenia:
    logger -p local0.err "This is my test message"

Problem: odbierasz adres Errno, który jest już używany w pliku dziennika omsagent

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

Prawdopodobne przyczyny

Ten błąd wskazuje, że rozszerzenie diagnostyczne systemu Linux (LAD) jest instalowane obok rozszerzenia maszyny wirtualnej z systemem Linux usługi Log Analytics. Używa on tego samego portu do zbierania danych dziennika systemowego jako omsagent.

Rozwiązanie

  1. Jako użytkownik główny wykonaj następujące polecenia. Należy pamiętać, że 25224 jest przykładem i możliwe, że w środowisku jest widoczny inny numer portu używany przez usługę 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

    Następnie należy edytować prawidłowy rsyslogd lub syslog_ng skonfigurowany plik i zmienić konfigurację związaną z usługą LAD, aby zapisać na porcie 25229.

  2. Jeśli maszyna wirtualna jest uruchomiona rsyslogd, plik do zmodyfikowania to /etc/rsyslog.d/95-omsagent.conf (jeśli istnieje, w przeciwnym razie /etc/rsyslog). Jeśli maszyna wirtualna jest uruchomiona syslog_ng, plik do zmodyfikowania to /etc/syslog-ng/syslog-ng.conf.

  3. Uruchom ponownie program omsagent sudo /opt/microsoft/omsagent/bin/service_control restart.

  4. Uruchom ponownie usługę Syslog.

Problem: Nie można odinstalować agenta omsagent przy użyciu opcji przeczyszczania

Prawdopodobne przyczyny

  • Zainstalowano rozszerzenie diagnostyczne systemu Linux.
  • Rozszerzenie diagnostyczne systemu Linux zostało zainstalowane i odinstalowane, ale nadal występuje błąd dotyczący agenta omsagent używanego przez rozwiązanie mdsd i nie można go usunąć.

Rozwiązanie

  1. Odinstaluj rozszerzenie diagnostyczne systemu Linux.
  2. Usuń pliki rozszerzenia diagnostycznego systemu Linux z maszyny, jeśli znajdują się w następującej lokalizacji: /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ i /var/opt/microsoft/omsagent/LAD/.

Problem: Nie widzisz żadnych danych Nagios

Prawdopodobne przyczyny

  • Użytkownik omsagent nie ma uprawnień do odczytu z pliku dziennika Nagios.
  • Źródło i filtr Nagios nie zostały odkomentowane z pliku omsagent.conf.

Rozwiązanie

  1. Dodaj użytkownika omsagent do odczytu z pliku Nagios, postępując zgodnie z tymi instrukcjami.

  2. W pliku konfiguracji ogólnej usługi Log Analytics dla systemu Linux upewnij /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.confsię, że zarówno źródło Nagios, jak i filtr są niezakomentowane.

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

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

Problem: Nie widzisz żadnych danych systemu Linux

Prawdopodobne przyczyny

  • Dołączanie do usługi Azure Monitor nie powiodło się.
  • Połączenie z usługą Azure Monitor jest zablokowane.
  • Maszyna wirtualna została ponownie uruchomiona.
  • Pakiet OMI został ręcznie uaktualniony do nowszej wersji w porównaniu z tym, co zostało zainstalowane przez agenta usługi Log Analytics dla systemu Linux.
  • Usługa OMI jest zamrożona, blokując agenta pakietu OMS.
  • Klasa dzienników zasobów DSC nie znalazła błędu w omsconfig.log pliku dziennika.
  • Kopia zapasowa agenta usługi Log Analytics dla danych jest wykonywana.
  • Dzienniki DSC Bieżąca konfiguracja nie istnieje. Wykonaj polecenie Start-DscConfiguration z parametrem -Path, aby określić plik konfiguracji i najpierw utworzyć bieżącą konfigurację. w omsconfig.log pliku dziennika, ale nie ma komunikatu dziennika o PerformRequiredConfigurationChecks operacjach.

Rozwiązanie

  1. Zainstaluj wszystkie zależności, takie jak pakiet inspekcji.

  2. Sprawdź, czy dołączanie do usługi Azure Monitor zakończyło się pomyślnie, sprawdzając, czy istnieje następujący plik: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Jeśli tak nie było, należy ponownie dołączyć przy użyciu omsadmin.sh instrukcji wiersza polecenia.

  3. Jeśli używasz serwera proxy, zapoznaj się z poprzednimi krokami rozwiązywania problemów z serwerem proxy.

  4. W niektórych systemach dystrybucji platformy Azure demon serwera OMI omid nie jest uruchamiany po ponownym uruchomieniu maszyny wirtualnej. W takim przypadku nie zobaczysz danych związanych z rozwiązaniem Audit, ChangeTracking ani UpdateManagement. Obejście polega na ręcznym uruchomieniu serwera OMI, uruchamiając polecenie sudo /opt/omi/bin/service_control restart.

  5. Po ręcznym uaktualnieniu pakietu OMI do nowszej wersji należy ręcznie ponownie uruchomić agenta usługi Log Analytics, aby kontynuować działanie. Ten krok jest wymagany w przypadku niektórych dystrybucji, w których serwer OMI nie uruchamia się automatycznie po uaktualnieniu. Uruchom polecenie sudo /opt/omi/bin/service_control restart , aby ponownie uruchomić usługę OMI.

    W niektórych sytuacjach OMI może zostać zamrożony. Agent pakietu OMS może wprowadzić zablokowany stan oczekiwania na usługę OMI, która blokuje wszystkie zbieranie danych. Proces agenta pakietu OMS zostanie uruchomiony, ale nie będzie żadnych działań, co jest dowodem na brak nowych wierszy dziennika (takich jak wysłane pulsy) w programie omsagent.log. Uruchom ponownie usługę OMI za pomocą polecenia sudo /opt/omi/bin/service_control restart , aby odzyskać agenta.

  6. Jeśli w omsconfig.log zostanie wyświetlony błąd klasy zasobów DSC, uruchom polecenie sudo /opt/omi/bin/service_control restart.

  7. W niektórych przypadkach, gdy agent usługi Log Analytics dla systemu Linux nie może komunikować się z usługą Azure Monitor, kopie zapasowe danych agenta są tworzone do pełnego rozmiaru buforu o rozmiarze 50 MB. Agent powinien zostać uruchomiony ponownie, uruchamiając następujące polecenie: /opt/microsoft/omsagent/bin/service_control restart.

    Uwaga

    Ten problem został rozwiązany w wersji 1.1.0-28 lub nowszej.

    • omsconfig.log Jeśli plik dziennika nie wskazuje, że PerformRequiredConfigurationChecks operacje są uruchamiane okresowo w systemie, może wystąpić problem z zadaniem/usługą cron. Upewnij się, że zadanie cron istnieje w obszarze /etc/cron.d/OMSConsistencyInvoker. W razie potrzeby uruchom następujące polecenia, aby utworzyć zadanie cron:

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

    • Upewnij się również, że usługa cron jest uruchomiona. Aby sprawdzić stan tej usługi, można używać z service cron status systemami Debian, Ubuntu i SUSE lub service crond status RHEL, CentOS i Oracle Linux. Jeśli usługa nie istnieje, możesz zainstalować pliki binarne i uruchomić usługę, wykonując następujące instrukcje:

      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: Podczas konfigurowania kolekcji z portalu dla liczników wydajności usługi Syslog lub Linux ustawienia nie są stosowane

Prawdopodobne przyczyny

  • Agent usługi Log Analytics dla systemu Linux nie odebrał najnowszej konfiguracji.
  • Zmienione ustawienia w portalu nie zostały zastosowane.

Rozwiązanie

Tło: omsconfig to agent usługi Log Analytics dla agenta konfiguracji systemu Linux, który szuka nowej konfiguracji po stronie portalu co pięć minut. Ta konfiguracja jest następnie stosowana do agenta usługi Log Analytics dla plików konfiguracji systemu Linux znajdujących się w folderze /etc/opt/microsoft/omsagent/conf/omsagent.conf.

W niektórych przypadkach agent usługi Log Analytics dla agenta konfiguracji systemu Linux może nie być w stanie komunikować się z usługą konfiguracji portalu. Ten scenariusz powoduje, że najnowsza konfiguracja nie jest stosowana.

  1. Sprawdź, czy omsconfig agent jest zainstalowany, uruchamiając polecenie dpkg --list omsconfig lub rpm -qi omsconfig. Jeśli nie jest zainstalowany, zainstaluj ponownie najnowszą wersję agenta usługi Log Analytics dla systemu Linux.

  2. Sprawdź, czy omsconfig agent może komunikować się z usługą Azure Monitor, uruchamiając następujące polecenie: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. To polecenie zwraca konfigurację odbieraną przez agenta z usługi, w tym ustawienia dziennika systemowego, liczniki wydajności systemu Linux i dzienniki niestandardowe. Jeśli to polecenie zakończy się niepowodzeniem, uruchom następujące polecenie: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. To polecenie wymusza, aby agent omsconfig rozmawiał z usługą Azure Monitor i pobierał najnowszą konfigurację.

Problem: Nie widzisz żadnych niestandardowych danych dziennika

Prawdopodobne przyczyny

  • Dołączanie do usługi Azure Monitor nie powiodło się.
  • Nie wybrano ustawienia Zastosuj następującą konfigurację do serwerów z systemem Linux.
  • omsconfig nie odebrano najnowszej niestandardowej konfiguracji dziennika z usługi.
  • Agent usługi Log Analytics dla użytkownika omsagent systemu Linux nie może uzyskać dostępu do dziennika niestandardowego z powodu uprawnień lub nie można go odnaleźć. Mogą wystąpić następujące błędy:
    • [DATETIME] [warn]: file not found. Continuing without tailing it.
    • [DATETIME] [error]: file not accessible by omsagent.
  • Znany problem z warunkiem wyścigu rozwiązanym w agencie usługi Log Analytics dla systemu Linux w wersji 1.1.0-217.

Rozwiązanie

  1. Sprawdź, czy dołączanie do usługi Azure Monitor zakończyło się pomyślnie, sprawdzając, czy istnieje następujący plik: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Jeśli nie, albo:

    1. Ponowne dołączanie przy użyciu instrukcji wiersza polecenia omsadmin.sh.
    2. W obszarze Ustawienia zaawansowane w witrynie Azure Portal upewnij się, że ustawienie Zastosuj następującą konfigurację do moich serwerów z systemem Linux jest włączone.

  2. Sprawdź, czy omsconfig agent może komunikować się z usługą Azure Monitor, uruchamiając następujące polecenie: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. To polecenie zwraca konfigurację odbieraną przez agenta z usługi, w tym ustawienia dziennika systemowego, liczniki wydajności systemu Linux i dzienniki niestandardowe. Jeśli to polecenie zakończy się niepowodzeniem, uruchom następujące polecenie: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. To polecenie wymusza omsconfig , aby agent rozmawiał z usługą Azure Monitor i pobierał najnowszą konfigurację.

Tło: Zamiast agenta usługi Log Analytics dla systemu Linux działającego jako użytkownik uprzywilejowany — rootagent jest uruchamiany jako omsagent użytkownik. W większości przypadków jawne uprawnienie musi zostać przyznane temu użytkownikowi, aby niektóre pliki można było odczytać. Aby udzielić użytkownikowi uprawnień omsagent , uruchom następujące polecenia:

  1. omsagent Dodaj użytkownika do określonej grupy: sudo usermod -a -G <GROUPNAME> <USERNAME>.
  2. Udziel uniwersalnego dostępu do odczytu do wymaganego pliku: sudo chmod -R ugo+rx <FILE DIRECTORY>.

Istnieje znany problem z warunkiem wyścigu z agentem usługi Log Analytics dla systemu Linux w wersji wcześniejszej niż 1.1.0-217. Po zaktualizowaniu do najnowszego agenta uruchom następujące polecenie, aby pobrać najnowszą wersję wtyczki wyjściowej: sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Problem: Próbujesz ponownie dołączyć do nowego obszaru roboczego

Podczas próby ponownego dołączenia agenta do nowego obszaru roboczego przed ponownym dołączaniem należy wyczyścić konfigurację agenta usługi Log Analytics. Aby wyczyścić starą konfigurację z agenta, uruchom pakiet powłoki za pomocą polecenia --purge:

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

Or

sudo sh ./onboard_agent.sh --purge

Po użyciu --purge opcji możesz kontynuować ponowne dołączanie.

Problem: Rozszerzenie agenta usługi Log Analytics w witrynie Azure Portal jest oznaczone stanem niepowodzenia: Aprowizowanie nie powiodło się

Prawdopodobne przyczyny

  • Agent usługi Log Analytics został usunięty z systemu operacyjnego.
  • Usługa agenta usługi Log Analytics nie działa, jest wyłączona lub nieskonfigurowane.

Rozwiązanie

  1. Usuń rozszerzenie z witryny Azure Portal.
  2. Zainstaluj agenta, postępując zgodnie z instrukcjami.
  3. Uruchom ponownie agenta, uruchamiając następujące polecenie:
    sudo /opt/microsoft/omsagent/bin/service_control restart.
  4. Poczekaj kilka minut, aż stan aprowizacji zmieni się na Aprowizacja zakończyła się pomyślnie.

Problem: Uaktualnienie agenta usługi Log Analytics na żądanie

Prawdopodobne przyczyny

Pakiety agenta usługi Log Analytics na hoście są nieaktualne.

Rozwiązanie

  1. Sprawdź najnowszą wersję na tej stronie usługi GitHub.

  2. Pobierz skrypt instalacyjny (wersja 1.4.2-124 to przykładowa wersja):

    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. Uaktualnij pakiety, wykonując polecenie sudo sh ./omsagent-*.universal.x64.sh --upgrade.

Problem: Instalacja kończy się niepowodzeniem i mówi, że język Python2 nie może obsługiwać typów ctype, mimo że jest używany język Python3

Prawdopodobne przyczyny

W przypadku tego znanego problemu, jeśli język maszyny wirtualnej nie jest angielski, sprawdzanie zakończy się niepowodzeniem podczas sprawdzania, która wersja języka Python jest używana. Ten problem prowadzi do agenta zawsze przy założeniu, że język Python2 jest używany i kończy się niepowodzeniem, jeśli nie ma języka Python2.

Rozwiązanie

Zmień język środowiska maszyny wirtualnej na angielski:

export LANG=en_US.UTF-8