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.

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

Agent usługi Log Analytics dla narzędzia do rozwiązywania problemów z systemem 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 za pomocą agenta usługi Log Analytics:

sudo /opt/microsoft/omsagent/bin/troubleshooter

Instalacja ręczna

Narzędzie do rozwiązywania problemów jest automatycznie uwzględniane 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

Omówione 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 systemu 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ą naszego zespołu pomocy technicznej, aby uzyskać agenta w stanie nieukorzystanym. Uruchomienie narzędzia do rozwiązywania problemów i narzędzia modułu zbierającego dzienniki oraz próba czystej instalacji pomaga szybciej rozwiązywać problemy.

  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 do 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 /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 dziennika syslog jest zastępowane, jeśli kolekcja jest skonfigurowana z konfiguracji agenta w Azure Portal dla obszaru roboczego. Aby wyłączyć konfigurację dla wszystkich agentów, wyłącz zbieranie z zarządzania starszymi agentami. W przypadku jednego 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 inspekcję pakietu.
2 Nieprawidłowa opcja podana w pakiecie powłoki. Uruchom polecenie sudo sh ./omsagent-*.universal*.sh --help w celu użycia.
3 Nie podano opcji pakietu powłoki. Uruchom polecenie sudo sh ./omsagent-*.universal*.sh --help w celu użycia.
4 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 zainstalować tylko w systemach opartych na debianie. Zalecamy użycie 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 zainstalować tylko w systemach 32-bitowych. Pobierz prawidłowy pakiet dla 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 dołączonego nie powiodła się. Przejrzyj dane wyjściowe polecenia dla błędu głównego
23 Zainstalowany pakiet SCX lub OMI. --install Zamiast --upgrade 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 pliku 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 plik 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 Podano nieprawidłową opcję 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.
4 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 pakietu 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 przy użyciu 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

Usługa FluentD umożliwia korzystanie z poziomów rejestrowania specyficznych dla wtyczek, które umożliwiają określenie 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 rozdzielonych 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 danych wyjściowych pakietu OMS, można wyświetlać elementy danych bezpośrednio do stdoutprogramu , 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ędniane na liście zatwierdzonych w centrum danych.

Rozwiązanie

  1. Ponowne dołączanie do usługi Azure Monitor za pomocą 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. Przejrzyj 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 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ć ten problem, 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, 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 usł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 omiagent, użyj skryptu omiHighCPUDiagnostics.sh, który będzie zbierać ślad stosu omiagent, 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 30% procesora CPU:
    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 serwer nss-pem nie jest dostępny do uaktualnienia, co dotyczy głównie systemu CentOS, obniżenie poziomu curl do wersji 7.29.0-46. Jeśli po błędzie uruchomisz aktualizację "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 przesyłanych dalej na sekundę jest zbyt duża, aby podstawowa konfiguracja agenta usługi Log Analytics dla systemu Linux została obsłużona.

Rozwiązanie

  • Sprawdź, czy konfiguracja w obszarze roboczym usługi Log Analytics dla usługi Syslog zawiera wszystkie obiekty i prawidłowe poziomy dziennika. Zapoznaj się z artykułem Konfigurowanie kolekcji syslog w 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.
  • Symulowanie komunikatu dziennika systemowego logger w usłudze Log Analytics przy użyciu 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 pliku 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 tego samego portu do zbierania danych dziennika syslog jako omsagent.

Rozwiązanie

  1. Jako główny wykonaj następujące polecenia. Należy pamiętać, że 25224 jest przykładem i istnieje możliwość, że w środowisku jest wyświetlany 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ć poprawny rsyslogd plik konfiguracji lub syslog_ng 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 jest wyświetlany błąd dotyczący pomijania używanego przez usługę mdsd i nie można go usunąć.

Rozwiązanie

  1. Odinstaluj rozszerzenie diagnostyczne systemu Linux.
  2. Usuń pliki rozszerzeń diagnostycznych 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 widać ż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 /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.confkonfiguracji ogólnej usługi Log Analytics dla systemu Linux upewnij się, że zarówno źródło Nagios, jak i filtr są bez komentarza.

    <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.
  • OMI jest zamrożony, blokując agenta pakietu OMS.
  • Nie można odnaleźć klasy dzienników zasobów DSC w omsconfig.log pliku dziennika.
  • Kopia zapasowa agenta usługi Log Analytics dla danych jest tworzona.
  • Dzienniki DSC Bieżące konfiguracje nie istnieją. 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, dołącz ponownie przy użyciu instrukcji omsadmin.sh wiersza polecenia.

  3. Jeśli używasz serwera proxy, sprawdź poprzednie kroki rozwiązywania problemów z serwerem proxy.

  4. W niektórych systemach dystrybucji platformy Azure demon serwera OMI omid nie uruchamia się po ponownym uruchomieniu maszyny wirtualnej. Jeśli tak jest, nie zobaczysz danych związanych z rozwiązaniem Audit, ChangeTracking lub 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 w celu kontynuowania działania. 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) znajdujących się 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 pliku 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 agenta 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. W celu sprawdzenia stanu 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 dziennika systemowego lub systemu 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

Tle:omsconfig to agent usługi Log Analytics dla agenta konfiguracji systemu Linux, który wyszukuje nową konfigurację 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 lokalizacji /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 nie powiedzie się, uruchom następujące polecenie: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. To polecenie wymusza, aby agent omsconfig komunikował się 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ę.
  • Ustawienie Zastosuj następującą konfigurację do serwerów z systemem Linux nie zostało wybrane.
  • omsconfig Nie pobrano najnowszej niestandardowej konfiguracji dziennika z usługi.
  • Agent usługi Log Analytics dla systemu omsagent Linux nie może uzyskać dostępu do dziennika niestandardowego z powodu uprawnień lub nie można go odnaleźć. Mogą zostać wyświetlone 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 Azure Portal upewnij się, że ustawienie Zastosuj następującą konfigurację do 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 nie powiedzie się, uruchom następujące polecenie: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. To polecenie wymusza omsconfig , aby agent komunikował się z usługą Azure Monitor i pobierał najnowszą konfigurację.

Tle: 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 uprawnienia muszą zostać przyznane temu użytkownikowi, aby niektóre pliki zostały odczytane. Aby udzielić uprawnień użytkownikowi 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

Lub

sudo sh ./onboard_agent.sh --purge

Możesz kontynuować ponowne dołączanie po użyciu --purge opcji .

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

Prawdopodobne przyczyny

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

Rozwiązanie

  1. Usuń rozszerzenie z 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 Aprowizowanie powiodło się.

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 (1.4.2-124 jest przykładową wersją):

    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 używany jest 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