Oracle Cloud Infrastructure-Dokumentation

Fehlerprotokollierung

Mit den Informationen zur Fehlerbehebung können Sie allgemeine Probleme erkennen und beheben, die beim Arbeiten mit Logging auftreten können.

Allgemeine Probleme mit Unified Monitoring Agent

Hardwareanforderungen

Je nach Logginganforderungen und Konfiguration (Anzahl der Logs, Typ der Pufferung usw.) können die Hardwareanforderungen und die Performance des Unified Monitoring Agent stark variieren. Wenn kein operativer Druck besteht (weniger als 1.000 Logereignisse pro Minute), sollte der Agent nicht mehr als 200 MB RAM und 20 % eines CPU-Cores verbrauchen. Die hartcodierten Limits des Unified Monitoring Agent-Service sind 5 GB RAM und 40 % eines Cores. 1 GB RAM wird empfohlen.

Monitoring aktivieren

Monitoring kann bei der Fehlerbehebung hilfreich sein. Weitere Informationen zum Aktivieren von Monitoring (Metriken und Logging) in Ihren Oracle Cloud Infrastructure Compute-Instanzen finden Sie unter Monitoring für Compute-Instanzen aktivieren.

Linux Unified Monitoring Agent

systemd-Einheiten

Der Unified Monitoring Agent basiert auf systemd-Einheiten und besteht aus den folgenden Komponenten:

  1. unified-monitoring-agent.service: Der wichtigste Unified Monitoring Agent-Service.
  2. unified-monitoring-agent_config_downloader.service: Der automatische Konfigurations-Updater-Service.
  3. unified-monitoring-agent_config_downloader.timer: Die Timereinheit, die den automatischen Downloader-Service in angegebenen, zufälligen Intervallen auslöst.
  4. unified-monitoring-agent_restarter.path: Die Pfadeinheit, die das erneute Laden der Konfiguration durch den Unified Monitoring Agent auslöst, wenn eine Änderung erkannt wird. (Eine neue Konfiguration wird vom automatischen Updater-Service heruntergeladen.)
Hinweis

Die meisten systemctl- oder journalctl-Befehle müssen mit Superuser-Berechtigungen ausgeführt werden (root oder über sudo).

Um die korrekte Funktionsweise dieser systemd-Einheiten zu prüfen, können Sie den systemctl-Befehl wie folgt verwenden:

systemctl status <unit_name>

Dabei muss <unit_name> durch einen der folgenden Werte ersetzt werden:

  1. unified-monitoring-agent.service
  2. unified-monitoring-agent_config_downloader.service
  3. unified-monitoring-agent_config_downloader.timer
  4. unified-monitoring-agent_restarter.path

In der Regel geben diese systemctl-Befehle in etwa Folgendes aus:

systemctl status unified-monitoring-agent.service
   unified-monitoring-agent.service - unified-monitoring-agent: Fluentd based data collector for Oracle Cloud Infrastructure
   Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-09-29 13:54:03 UTC; 1min 37s ago
     Docs: https://docs.cloud.oracle.com/
  Process: 2337 ExecReload=/bin/kill -USR2 ${MAINPID} (code=exited, status=0/SUCCESS)
  Process: 2321 ExecStart=/opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10 $EXTRA_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 2327 (fluentd)
   Memory: 66.3M (limit: 5.0G)
   CGroup: /system.slice/unified-monitoring-agent.service
           ├─2327 /opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unif...
           └─2330 /opt/unified-monitoring-agent/embedded/bin/ruby -Eascii-8bit:ascii-8bit /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.lo...
systemctl status unified-monitoring-agent_config_downloader.service
  unified-monitoring-agent_config_downloader.service - unified-monitoring-agent Fluentd configuration downloader.
  Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_config_downloader.service; enabled; vendor preset: disabled)
  Active: inactive (dead) since Tue 2020-09-29 13:54:38 UTC; 1min 30s ago
 Process: 2333 ExecStart=/opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluent_config_updater.rb -c /etc/unified-monitoring-agent/conf.d/ -b 10 (code=exited, status=0/SUCCESS)
Main PID: 2333 (code=exited, status=0/SUCCESS) 
systemctl status unified-monitoring-agent_config_downloader.timer
  unified-monitoring-agent_config_downloader.timer - Run unified-monitoring-agent configuration automatic updater.
   Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_config_downloader.timer; enabled; vendor preset: disabled)
   Active: active (waiting) since Tue 2020-09-29 13:54:03 UTC; 3min 57s ago 
systemctl status unified-monitoring-agent_restarter.path
  unified-monitoring-agent_restarter.path - "Monitor the /etc/unified-monitoring-agent/conf.d/ directory for changes"
   Loaded: loaded (/usr/lib/systemd/system/unified-monitoring-agent_restarter.path; enabled; vendor preset: disabled)
   Active: active (waiting) since Tue 2020-09-29 13:54:03 UTC; 4min 9s ago

Die wichtigsten Teile der Ausgabe des systemctl-Befehls sind die Felder Loaded und Active. Das Feld Loaded hat den Wert loaded für alle Systemeinheiten. Das Feld Active hat die folgenden Werte:

  • active (running) für die Einheit "unified-monitoring-agent.service".
  • active (waiting) oder active (running) für die Einheiten "unified-monitoring-agent_restarter.path" und "unified-monitoring-agent_config_downloader.timer".
  • active (running) oder inactive (dead) für die Einheit "unified-monitoring-agent_config_downloader.service". Bei letzterem Wert enthält das Feld Main PID den Wert code=exited, status=0/SUCCESS).

Laufende Prozesse prüfen

Eine weitere Möglichkeit, die korrekte Funktionsweise des Unified Monitoring Agent zu überprüfen, besteht darin, die laufenden Prozesse des Systems zu prüfen. Wenn der Unified Monitoring Agent richtig funktioniert, werden zwei Prozesse ausgeführt: ein Supervisor-Prozess und ein Worker-Prozess. Sie können ihre Existenz überprüfen, indem Sie den folgenden Befehl in einem Terminal ausführen (Beispielausgabe enthalten):

ps aux | grep unified-monitoring-agen[t]
root      2327  0.0  2.3 307704 40864 ?        Sl   13:54   0:00 /opt/unified-monitoring-agent/embedded/bin/ruby /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10
root      2330  0.2  2.1 297456 38192 ?        S    13:54   0:03 /opt/unified-monitoring-agent/embedded/bin/ruby -Eascii-8bit:ascii-8bit /opt/unified-monitoring-agent/embedded/bin/fluentd --log /var/log/unified-monitoring-agent/unified-monitoring-agent.log --daemon /var/run/unified-monitoring-agent/unified-monitoring-agent.pid --log-rotate-size 1048576 --log-rotate-age 10 --under-supervisor

Wie im vorhergehenden Beispiel dargestellt, werden zwei Prozesse mit denselben Argumenten ausgeführt. Die einzige Ausnahme ist, dass dem zweiten der Parameter –under-supervisor hinzugefügt wurde. Dies deutet auf den Worker-Prozess hin, d.h., dass es sich bei dem Prozess ohne diesen Parameter um den Supervisor-Prozess handelt.

Speicherort des Unified Monitoring Agent-Logs

Hinweis

Die meisten systemctl- oder journalctl-Befehle müssen mit Superuser-Berechtigungen ausgeführt werden (root oder über sudo).

Die Unified Monitoring Agent-Logs finden Sie unter /var/log/unified-monitoring-agent/unified-monitoring-agent.log. Diese Datei enthält Logs vom Unified Monitoring Agent.

Neben den Agent-Logs, die keine systembezogenen Ereignisse enthalten (z.B. Servicestart, Servicestopp usw.), können Sie auch die Logs von journald, dem Systemloggingservice von systemd, anzeigen. Um die für eine Einheit spezifischen Systemlogs anzuzeigen, können Sie beispielsweise den folgenden journalctl-Befehl verwenden:

journalctl -u <unit_name>

Dabei muss <unit_name> durch einen der folgenden Werte ersetzt werden:

  1. unified-monitoring-agent.service
  2. unified-monitoring-agent_config_downloader.service
  3. unified-monitoring-agent_config_downloader.timer
  4. unified-monitoring-agent_restarter.path
Wenn Sie journald-Logs über journalctl abfragen, können Sie auch bestimmte Zeiträume definieren: 
journalctl --since "2020-12-30 00:00:01" --until "2020-12-31 23:59:59"
Das verwendete Datumsformat lautet JJJJ-MM-TT HH:MM:SS.
Sie können auch Tails an die Journallogs anhängen, indem Sie den Parameter -f hinzufügen: 
journalctl -f

Der Unified Monitoring Agent ist nicht installiert

Bei neu erstellten Instanzen kann es bis zu 25 Minuten dauern, bis der Agent automatisch installiert wird. Wenn er nach dieser Zeit nicht installiert ist, prüfen Sie Folgendes:

  1. Die Netzwerkkonnektivität der Instanz.
  2. Ob Monitoring in der Konsole aktiviert ist.

Informationen zur Installation des Unified Monitoring Agent durch den Oracle Cloud Agent finden Sie in der Logdatei /var/log/oracle-cloud-agent/plugins/unifiedmonitoring/unifiedmonitoring.log.

Der Unified Monitoring Agent wird nicht ausgeführt

Wenn der Status nicht geladen oder aktiv ist und weder Supervisor- noch Worker-Prozesse ausgeführt werden, starten Sie den Unified Monitoring Agent neu, und prüfen Sie die Logs auf Probleme: 

systemctl restart unified-monitoring-agent

Konfiguration nicht automatisch heruntergeladen

Stellen Sie sicher, dass Sie die Schritte unter Agent installieren und Agent-Installation prüfen ausgeführt haben. Lesen Sie das Journal des automatischen Konfigurations-Updater-Service, indem Sie Folgendes ausführen: 

journalctl -u unified-monitoring-agent_config_downloader.service

Konfiguration nicht automatisch neu geladen

Stellen Sie sicher, dass Sie die Schritte unter Agent installieren und Agent-Installation prüfen ausgeführt haben. Lesen Sie das Journal aller Einheiten:

  1. Die Timereinheit muss mindestens einmal ausgeführt worden sein.
  2. Der automatische Konfigurations-Download-Service muss ausgeführt worden sein, nachdem die entsprechende Zeiteinheit ihn ausgelöst hat. Sie können anhand der zugehörigen Logs prüfen, ob die Konfiguration heruntergeladen und in das Konfigurationsverzeichnis des Unified Monitoring Agent extrahiert wurde. Sie können dies auch überprüfen, indem Sie die Dateien im folgenden Verzeichnis auflisten: ls -lhatR /etc/unified-monitoring-agent.
  3. Prüfen Sie, ob die Pfadeinheit aktiv ist, indem Sie den Status prüfen: systemctl status unified-monitoring-agent_restarter.path.
  4. Prüfen Sie, ob ein Neuladesignal vom Unified Monitoring Agent empfangen wurde, indem Sie dessen Journal prüfen: journalctl -u unified-monitoring-agent_config_downloader.service. In der Ausgabe dieses Befehls wird "Reloading unified-monitoring-agent" angezeigt.

Parsingmuster testen und Agent zwingen, die Konfiguration sofort herunterzuladen

Führen Sie den folgenden Befehl aus:

systemctl restart unified-monitoring-agent_config_downloader
Hinweis

Das automatische Update der Konfiguration auf Agent-Seite kann bis zu 30 Minuten dauern.

Benutzerdefiniertes Log erstellen, um den Inhalt eines Alertlogs eines Datenbanksystems mit OCI anzuzeigen

Der Unified Monitoring Agent unterstützt das Datenbanksystem nicht.

Datenerfassung

Wenn Sie ein Ticket erstellen möchten, damit ein Techniker Ihnen bei Ihrem Problem mit dem Unified Monitoring Agent helfen kann, geben Sie die Ausgabe der folgenden Befehle an. Für einige davon sind möglicherweise Superuser-Berechtigungen erforderlich.

yum info unified-monitoring-agent
rpm -ql unified-monitoring-agent |  xargs sha512sum
systemctl status --full unified-monitoring-agent.service
systemctl status --full unified-monitoring-agent_config_downloader.service
systemctl status --full unified-monitoring-agent_config_downloader.timer
systemctl status --full unified-monitoring-agent_restarter.path
journalctl -a --no-pager -u unified-monitoring-agent.service
journalctl -a --no-pager -u unified-monitoring-agent_config_downloader.service
journalctl -a --no-pager -u unified-monitoring-agent_config_downloader.timer
journalctl -a --no-pager -u unified-monitoring-agent_restarter.path

Verwenden Sie für Ubuntu einen Befehl, der in etwa wie folgt aussieht:

apt show unified-monitoring-agent
dpkg -L unified-monitoring-agent | xargs sha512sum

Fügen Sie außerdem ein Archiv der Dateien unter /var/log/unified-monitoring-agent/ und /var/log/oracle-cloud-agent/ hinzu. Mit dem folgenden Befehl können Sie ein mit gzip komprimiertes TAR-Archiv dieser Verzeichnisse erstellen:

tar cvzf agent_logs_$(date +%s).tar.gz /var/log/unified-monitoring-agent/ /var/log/oracle-cloud-agent/

Wenn der Unified Monitoring Agent zwar ausgeführt wird, aber fehlerhaft ist, können Sie auch Informationen zu Backtrace und dem Speicherprofil hinzufügen, indem Sie den folgenden Befehl ausführen und die Dateien /tmp/sigdump-<integer>.log in Ihren Bericht aufnehmen (wobei <integer> eine Ganzzahl mit 1-6 Ziffern ist, die in seltenen Fällen auch länger sein kann).

ps aux | grep unified-monitoring-agen[t] | grep ruby | awk '{print $2}' | xargs kill -SIGCONT

Dieser Befehl sucht die Unified Monitoring Agent-Prozess-PIDs und sendet das SIGCONT-Signal an sie. Dadurch wird ein Dump in /tmp/sigdump-<integer>.log generiert.

Deinstallieren und neu installieren

Sie können den Unified Monitoring Agent entfernen, ohne dabei die Konfiguration des Agent zu entfernen. Führen Sie dazu den folgenden Befehl aus:

yum -y remove unified-monitoring-agent

Für Ubuntu:

apt -y remove unified-monitoring-agent

Die Konfiguration des Agent bleibt im Verzeichnis /etc/unified-monitoring-agent/ erhalten. Wenn Sie die Konfiguration für eine zukünftige (Neu-)Installation des Unified Monitoring Agent-Packages nicht beibehalten möchten, müssen Sie sie manuell entfernen:

# use the following command to print the contents of the agent's configuration directory
find /etc/unified-monitoring-agent/
# use the following command to remove the directory and all of its contents (this step cannot be undone)
rm -rf /etc/unified-monitoring-agent/

Der Agent wird automatisch vom Oracle Cloud Agent neu installiert. Dieser Vorgang dauert höchstens 25 Minuten. Damit dies geschieht, muss Monitoring für Ihre Instanz in der Konsole aktiviert sein. Weitere Informationen finden Sie unter Oracle Cloud Agent.

Windows Unified Monitoring Agent

So wird der Servicestatus geprüft

  1. Der Agent wird als Teil eines Windows-Service ausgeführt. Um seinen Status anzuzeigen, öffnen Sie das Startmenü, geben Sie Services.msc ein, und starten Sie die Anwendung. Rufen Sie den Service Oracle Cloud Unified Monitoring Service auf, um den Status anzuzeigen.
  2. Klicken Sie mit der rechten Maustaste auf den Service, und wählen Sie Eigenschaften aus, um weitere Informationen anzuzeigen. Hier finden Sie die Optionen zum Starten/Stoppen/Neu starten.
  3. Geben Sie im Menü Start cmd ein, klicken Sie mit der rechten Maustaste auf Eingabeaufforderung, und wählen Sie Als Administrator ausführen aus. Führen Sie die folgenden Befehle aus:
  • So zeigen Sie den Status des Unified Monitoring Agent-Service an:
    sc query unified-monitoring-agent
  • Starten Sie den Unified Monitoring Agent-Service neu:
    sc stop unified-monitoring-agent
sc start unified-monitoring-agent
Hinweis

Die oben genannten Befehle funktionieren in PowerShell nicht, sodass Sie stattdessen die Windows-Eingabeaufforderung verwenden müssen.

So suchen Sie Windows-Service-Fehler

  1. Geben Sie im Menü Start Event Viewer ein, und wählen Sie die Anwendung aus.
  2. Öffnen Sie Windows-Logs und dann System. Jedes Mal, wenn ein Service gestartet oder gestoppt wird, wenn beide Vorgänge nicht erfolgreich verlaufen oder wenn der Service plötzlich abstürzt, wird dies hier aufgezeichnet.
    Hinweis

    Auf den meisten Windows-Rechnern gibt es eine Obergrenze für die Anzahl der Ereignisse im Ereignis-Viewer. Wenn also ein Ereignis vor langer Zeit stattgefunden hat, sind die Logs möglicherweise nicht verfügbar.

So zeigen Sie Fluentd-Logs an

  1. Öffnen Sie die Datei explorer.exe (Dateisymbol in der Taskleiste)
  2. Gehen Sie zu C:\oracle_unified_agent.
  3. Wenn Sie nur eine Datei sehen, bedeutet dies, dass keine gültige Konfigurationsdatei auf dem Rechner vorhanden ist.
  4. Wenn Sie zwei Dateien sehen, ist sowohl ein Supervisor-Log, das alle Setup-/Startup-Logs enthält, als auch ein Worker-Log mit allen Parsing-/Ausgabelogs vorhanden. Wenn die Konfigurationsdatei ordnungsgemäß heruntergeladen wurde, lautet ihr Name unified-monitoring-agent.conf.
  5. Führen Sie Fluentd manuell aus. Führen Sie die oben genannten Schritte aus, um das Problem zu identifizieren. Bei Bedarf können Sie ein Problem durch manuelle Ausführung von Fluentd debuggen.
    Hinweis

    Wenn Fluentd manuell ausgeführt wird, wird dafür der Windows-Service verwendet. Dadurch wird die normale Ausführung des Service verhindert. Dies ist ein anderes Verhalten als bei Linux.
  6. Mit dem folgenden Befehl können Sie Fluentd manuell ausführen. Sie können dafür PowerShell oder die Eingabeaufforderung verwenden, jedoch müssen Sie den Befehl als Administrator ausführen:
    C:\oracle_unified_agent\unified-monitoring-agent\embedded\bin\fluentd -c C:\oracle_unified_agent\unified-monitoring-agent.conf -vv

Automatic Configuration Updater-Schritte

  1. Prüfen Sie, ob der Taskplaner wie erwartet ausgeführt wird.
  2. Geben Sie im Menü Start Task Scheduler ein.
  3. Gehen Sie zu Taskplaner (lokal) und dann zu Taskplanerbibliothek. Suchen Sie die Aufgabe UnifiedAgentConfigUpdater.
  4. Prüfen Sie die letzte Ausführungszeit. Wenn das Datum ungültig ist oder die Meldung nicht ausgeführt angezeigt wird, wird als nächste Ausführungszeit der Zeitpunkt angegeben, zu dem der Vorgang zum ersten Mal ausgeführt werden soll. Wählen Sie zum Debugging zunächst die Aufgabe und anschließend Ausführen aus, wenn die Aufgabe sofort ausgeführt werden soll.
  5. Letztes Ausführungsergebnis gibt das Ergebnis des Downloads der Konfiguration aus der Control Plane an. Wenn ein Fehler auftritt, müssen Sie den Vorgang manuell ausführen, um zu bestimmen, was passiert ist. Der Taskplaner speichert keine Ausgabelogs.
  6. Führen Sie den Konfigurations-Updater manuell aus.
    Hinweis

    Führen Sie den Updater in PowerShell als Administrator aus, um optimale Ergebnisse zu erzielen.
    C:\oracle_unified_agent\unified-monitoring-agent\embedded\bin\ruby.exe C:\oracle_unified_agent\unified-monitoring-agent\embedded\lib\ruby\gems\2.6.0\gems\fluent-public-config-updater*\lib\fluent_config_updater.rb -c C:\oracle_unified_agent -b 10

Oracle Cloud Agent-Logs prüfen

Für Windows Server 2012r2 oder 2016 finden Sie die Logdateien an folgenden Speicherorten:

  • C:\Users\OCA\AppData\Local\Local\OracleCloudAgent\agent.log
  • C:\Users\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring.log (Laufzeitlogs)
  • C:\Users\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring_msi.log (Installationslogs)
  • C:\oracle_unified_agent\unified-monitoring-agent-0.log (Agent-Worker-Log, das je nach Status möglicherweise nicht vorhanden ist)
  • C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log (Agent-Supervisor-Log, das je nach Status möglicherweise nicht vorhanden ist)

Speicherorte der Logdateien für Windows Server 2019/2022:

  • C:\Windows\ServiceProfiles\OCA\AppData\Local\OracleCloudAgent\agent.log
  • C:\Windows\ServiceProfiles\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring.log (Laufzeitlogs)
  • C:\Windows\ServiceProfiles\OCAUM\AppData\Local\OracleCloudAgent\plugins\unifiedmonitoring\unifiedmonitoring_msi.log (Installationslogs)
  • C:\oracle_unified_agent\unified-monitoring-agent-0.log (Agent-Worker-Log, das je nach Status möglicherweise nicht vorhanden ist)
  • C:\oracle_unified_agent\unified-monitoring-agent-supervisor-0.log (Agent-Supervisor-Log, das je nach Status möglicherweise nicht vorhanden ist)

Zeitweise nicht erfolgreiche MSI-Installation

Eine zweitweise nicht erfolgreiche MSI-Installation kann aus zwei Gründen auftreten:

  1. Eine MSI-Installation wurde unterbrochen (Systemneustart, Prozessstopp usw.), und bei der zweiten Ausführung weist der Prozess msiexec.exe noch immer ein Datei-Handle zu einem von ihm erstellten Ordner auf.
  2. Während eines Upgrades, bei dem der MSI keinen Zugriff auf den Haupt-Agent-Ordner erhält, weil die Ruby.exe nicht so endet, wie sie sollte (ein Fluentd-Problem). Dies führt dazu, dass der MSI nicht erfolgreich ausgeführt und das System bereinigt wird, wodurch ein Großteil des Agent entfernt wird (nicht jedoch die Positions- oder Pufferdateien).

In beiden Fällen wird das Problem entweder durch eine zweite Installation oder dadurch behoben, dass der Oracle Cloud Agent die Installation ein zweites Mal durchführt. Sollte die Installation dann immer noch nicht erfolgreich sein, führen Sie folgende Schritte aus:

  1. Stoppen Sie alle msiexec- und ruby-Prozesse im Task-Manager unter "Details".
  2. Benennen Sie C:\oracle_unified_agent in C:\oracle_unified_agent_old um.
  3. Installieren Sie den Agent erneut, oder warten Sie, bis der Oracle Cloud Agent ihn installiert hat.

Generische Pfade, die nicht mit Agent-Konfiguration arbeiten

Verwenden Sie einen Schrägstrich (/) bei der Konfiguration von Pfaden für die Windows-Agent-Konfiguration. Ein umgekehrter Schrägstrich (\) mit einem Sternchen (*) funktioniert aufgrund interner Einschränkungen nicht unter Windows. Um dies zu vermeiden, verwenden Sie keinen Pfad wie C:\\path\\to\\*\\foo.log. Verwenden Sie stattdessen die folgende Schrägstrichmethode:

path C:/path/to/*/foo.log

Die folgenden Pfade unterstützen allgemeine Arbeitspfadbeispiele für Windows:

  • C:/logs/*
  • C:/logs/t2*.txt
  • C:/logs/a*b.txt
  • C:/logs/abc*
  • C:/logs/*.txt
  • C:/logs/*/abc*
  • C:/logs/*/a.txt
  • C:/logs/*/a*b.txt
  • C:/logs*/*.txt

Der generische Pfad C:/logs/*log.txt funktioniert jedoch nicht für Windows.