Freigeben über

about_Logging_Non-Windows

Kurzbeschreibung

PowerShell protokolliert interne Vorgänge der Engine, der Anbieter und der Cmdlets.

Lange Beschreibung

PowerShell protokolliert Details von PowerShell Operationen, wie z. B. das Starten und Stoppen der Engine und das Starten und Stoppen von Providern. Außerdem werden Details zu PowerShell-Befehlen protokolliert.

Informationen zur Protokollierung in Windows PowerShell 5.1 finden Sie unter about_Logging.

Der Speicherort von PowerShell-Protokollen hängt von der Zielplattform ab.

  • Unter Linux protokolliert PowerShell in das systemd journal, das an einen syslog Server weitergeleitet werden kann. Weitere Informationen finden Sie auf den man Seiten Ihrer Linux-Distribution.
  • Unter macOS wird das einheitliche Protokollierungssystem von Apple verwendet. Weitere Informationen finden Sie unter Apples Entwicklerdokumentation zur Protokollierung.

PowerShell unterstützt das Konfigurieren von zwei Protokollierungskategorien:

  • Modulprotokollierung – Zeichnen Sie die Pipelineausführungsereignisse für Elemente der angegebenen Module auf. Die Modulprotokollierung muss sowohl für die Sitzung als auch für bestimmte Module aktiviert sein. Weitere Informationen zum Konfigurieren dieser Protokollierung finden Sie unter about_PowerShell_Config.

    Wenn die Modulprotokollierung über die Konfiguration aktiviert ist, können Sie die Protokollierung für bestimmte Module in einer Sitzung aktivieren und deaktivieren, indem Sie den Wert der LogPipelineExecutionDetails Eigenschaft des Moduls festlegen.

    So aktivieren Sie beispielsweise die Modulprotokollierung für das PSReadLine Modul:

    $psrl = Get-Module PSReadLine
$psrl.LogPipelineExecutionDetails = $true
Get-Module PSReadLine | Select-Object Name, LogPipelineExecutionDetails

    Name       LogPipelineExecutionDetails
----       ---------------------------
PSReadLine                        True

  • Protokollierung von Skriptblocks – Aufzeichnen der Verarbeitung von Befehlen, Skriptblocks, Funktionen und Skripts, unabhängig davon, ob sie interaktiv oder durch Automatisierung aufgerufen werden.

    Wenn Sie die Skriptblockprotokollierung aktivieren, zeichnet PowerShell den Inhalt aller skriptblocks auf, die verarbeitet werden. Nach der Aktivierung protokolliert jede neue PowerShell-Sitzung diese Informationen.

    Anmerkung

    Es wird empfohlen, die geschützte Ereignisprotokollierung zu aktivieren, wenn Sie die Skriptblockprotokollierung für andere Zwecke als Diagnosezwecke verwenden. Weitere Informationen finden Sie unter about_PowerShell_Config.

Konfigurieren der Protokollierung unter Linux oder macOS

Die Konfiguration für die Protokollierung unter Linux und macOS wird in der powershell.config.json Datei gespeichert. Die powershell.config.json-Datei ist eine JSON- formatierte Datei, die sich im PowerShell-$PSHOME Verzeichnis befindet. Wenn diese Konfigurationsdatei nicht vorhanden ist, müssen Sie sie erstellen, um die Standardeinstellungen zu ändern. Jede Installation von PowerShell verwendet eine eigene Kopie dieser Datei.

Standardmäßig aktiviert PowerShell die Informational Protokollierung auf dem Operational Kanal. Sie können die Konfiguration ändern, wenn Sie zusätzliche Protokollausgaben benötigen, wie z. B. verbose oder die Aktivierung von analytischen Protokollausgaben.

Der folgende Code ist eine Beispielkonfiguration:

{
    "ModuleLogging": {
        "EnableModuleLogging": false,
        "ModuleNames": [
            "PSReadLine",
            "PowerShellGet"
        ]
    },
    "ScriptBlockLogging": {
        "EnableScriptBlockInvocationLogging": true,
        "EnableScriptBlockLogging": true
    },
    "LogLevel": "verbose"
}

Im Folgenden finden Sie eine Liste der Eigenschaften zum Konfigurieren der PowerShell-Protokollierung. Wenn die Eigenschaft nicht in der Konfiguration aufgeführt ist, verwendet PowerShell den Standardwert.

  • LogIdentity
    • Werte: <string name>, powershell
    • Beschreibung: Der Name, der bei der Protokollierung verwendet werden soll. Die Standardidentität ist powershell. Dieser Wert kann verwendet werden, um den Unterschied zwischen zwei Instanzen einer PowerShell-Installation zu ermitteln, z. B. einer Release- und Betaversion. Dieser Wert wird auch verwendet, um die Protokollausgabe an eine separate Datei umzuleiten.
  • LogChannels
    • Werte: Operational, Analytic
    • Beschreibung: Die zu aktivierenden Kanäle. Trennen Sie die Werte durch ein Komma, wenn Sie mehrere angeben. Der Standardwert ist Operational.
  • LogLevel
    • Werte: Always, Critical, Error, Warning, Informational, Verbose, Debug
    • Beschreibung: Geben Sie einen einzelnen Wert an. Die Werte sind in aufsteigender Reihenfolge der Ausführlichkeit aufgeführt. Der von Ihnen ausgewählte Wert aktiviert sich selbst und alle Werte davor. Der Standardwert ist Informational.
  • LogKeywords
    • Werte: Runspace, Pipeline, Protocol, Transport, Host, Cmdlets, Serializer, Session, ManagedPlugin
    • Beschreibung: Schlüsselwörter bieten die Möglichkeit, die Protokollierung auf bestimmte Komponenten in PowerShell zu beschränken. Standardmäßig sind alle Schlüsselwörter aktiviert, und das Ändern dieses Wertes ist nur für spezielle Fehlerbehebungen nützlich.
  • PowerShellPolicies
    • Beschreibung: Die einstellung PowerShellPolicies enthält die Optionen ModuleLogging, ProtectedEventLoggingund ScriptBlockLogging. Weitere Informationen finden Sie unter allgemeine Konfigurationseinstellungen.

Anzeigen von PowerShell-Protokolldaten im Journal unter Linux

PowerShell protokolliert unter Linux Distributionen wie z. B. Ubuntu und Red Hat Enterprise Linux (RHEL) mit dem Daemon journald in das systemd journal.

Der journald Daemon speichert Protokollnachrichten in einem Binärformat. Verwenden Sie das Hilfsprogramm journalctl, um das Journalprotokoll für PowerShell-Einträge abzufragen.

journalctl --grep powershell

Der journald Daemon kann Log-Nachrichten an einen System Logging Protocol (syslog) Server weiterleiten. Aktivieren Sie die Option ForwardToSysLog in der Konfigurationsdatei /etc/systemd/journald.confjournald, wenn Sie syslog für die Protokollierung auf Ihrem Linux-System verwenden möchten. Dies ist die Standardkonfiguration für viele Linux-Distributionen.

Anzeigen von PowerShell-Protokolldaten in Syslog unter Linux

Verwenden Sie den Paket-Manager für Ihre Linux-Verteilung, um einen Syslog--Server wie rsyslog zu installieren, wenn Sie die Syslog-Protokollierung auf Ihrem Linux-System verwenden möchten. Einige Linux-Distributionen wie Ubuntu installieren rsyslogvor.

Das Syslog-Protokoll speichert Protokollmeldungen in einem standardisierten Textformat. Sie können ein beliebiges Hilfsprogramm für die Textverarbeitung verwenden, um Syslog- Inhalt abzufragen oder anzuzeigen.

Standardmäßig schreibt syslog Protokolleinträge an den folgenden Speicherort:

  • Auf Debian-basierten Distributionen, einschließlich Ubuntu: /var/log/syslog
  • Auf RHEL-basierten Distributionen: /var/log/messages

Im folgenden Beispiel wird der Befehl cat verwendet, um PowerShell-Syslog--Einträge auf Ubuntu abzufragen.

cat /var/log/syslog | grep -i powershell

Syslog-Nachrichtenformat

Syslog-Nachrichten weisen das folgende Format auf:

TIMESTAMP MACHINENAME powershell[PID]: (COMMITID:TID:CID)
  [EVENTID:TASK.OPCODE.LEVEL] MESSAGE
  • TIMESTAMP- – Ein Datum/eine Uhrzeit, zu der der Protokolleintrag erstellt wurde.
  • MACHINENAME – Der Name des Systems, in dem das Protokoll erstellt wurde.
  • PID- – Die Prozess-ID des Prozesses, der den Protokolleintrag geschrieben hat.
  • COMMITID – Die Git Commit ID oder Markierung, die zur Erstellung des Builds verwendet wurde.
  • TID- – Die Thread-ID des Threads, der den Protokolleintrag geschrieben hat.
  • CID- – Der Hexkanalbezeichner des Protokolleintrags.
    • 0x10 = Betriebsbereit
    • 0x11 = Analyse
  • EVENTID- – Der Ereignisbezeichner des Protokolleintrags.
  • TASK – Der Task-Identifikator für den Eintrag des Ereignisses
  • OPCODE – Der Opcode für den Ereigniseintrag
  • LEVEL – Die Protokollstufe für den Ereigniseintrag
  • MESSAGE – Die Nachricht, die dem Ereigniseintrag zugeordnet ist

EVENTID-, TASK-, OPCODE-und LEVEL- sind die gleichen Werte wie beim Anmelden beim Windows-Ereignisprotokoll.

Schreiben einer PowerShell-Protokollnachricht in eine separate Datei

Es ist auch möglich, die PowerShell-Protokolleinträge an eine separate Datei umzuleiten. Wenn die PowerShell-Protokolleinträge zu einer separaten Datei umgeleitet werden, werden sie nicht mehr mit der Standard syslog-Datei protokolliert.

Die folgenden Schritte konfigurieren PowerShell-Protokolleinträge auf Ubuntu so, dass sie in eine Protokolldatei mit dem Namen powershell.logschreiben.

  1. Erstellen Sie eine Konfigurationsdatei (conf) für die PowerShell-Protokollkonfiguration im /etc/rsyslog.d Verzeichnis mithilfe eines Textdatei-Editors wie nano. Stellen Sie dem Dateinamen eine Zahl voran, die kleiner als der Standardwert ist. Beispiel: 40-powershell.conf, in dem der Standardwert 50-default.confist.

    sudo nano /etc/rsyslog.d/40-powershell.conf

  2. Fügen Sie der datei 40-powershell.conf die folgenden Informationen hinzu:

    :syslogtag, contains, "powershell[" /var/log/powershell.log
& stop

  3. Stellen Sie sicher, dass /etc/rsyslog.conf über eine Include-Anweisung für die neue Datei verfügt. Es kann eine generische Anweisung enthalten, wie z. B.:

    $IncludeConfig /etc/rsyslog.d/*.conf

    Wenn dies nicht der Fall ist, müssen Sie manuell eine Include-Anweisung hinzufügen.

  4. Überprüfen Sie, ob die Attribute und Berechtigungen entsprechend festgelegt sind.

    ls -l /etc/rsyslog.d/40-powershell.conf

    -rw-r--r-- 1 root root   67 Nov 28 12:51 40-powershell.conf

    Wenn Ihre 40-powershell.conf Datei über unterschiedliche Besitzrechte oder Berechtigungen verfügt, führen Sie die folgenden Schritte aus:

    1. Legen Sie den Besitz auf root fest.

      sudo chown root:root /etc/rsyslog.d/40-powershell.conf

    2. Legen Sie die Berechtigungen für den Zugriff fest: Root hat Lesen/Schreiben, Benutzer haben Lesen.

      sudo chmod 644 /etc/rsyslog.d/40-powershell.conf

  5. Starten Sie den rsyslog Dienst neu.

    sudo systemctl restart rsyslog.service

  6. Führen Sie pwsh aus, um PowerShell-Informationen zum Protokollieren zu generieren.

    pwsh

    Anmerkung

    Die /var/log/powershell.log Datei wird erst erstellt, wenn der rsyslog Dienst neu gestartet wird und PowerShell Informationen generiert, die protokolliert werden sollen.

  7. Fragen Sie die powershell.log-Datei ab, um zu überprüfen, ob PowerShell-Informationen in die neue Datei protokolliert werden.

    cat /var/log/powershell.log

Anzeigen von PowerShell-Protokolldaten unter macOS

PowerShell protokolliert das einheitliche Protokollierungssystem von Apple, ein Feature von macOS, das die Sammlung und Speicherung von System- und Anwendungsprotokollen an einem zentralen Ort ermöglicht.

Das einheitliche Protokollierungssystem von Apple speichert Protokollnachrichten im Binärformat. Sie müssen das tool log verwenden, um das einheitliche Protokollierungssystem für PowerShell-Protokollereignisse abzufragen. Die PowerShell-Protokollereignisse werden nicht in der Konsole Anwendung unter macOS angezeigt. Die Konsolen-App wurde für die ältere syslog-basierte Protokollierung entwickelt, die dem einheitlichen Protokollierungssystem zeitlich vorausgeht.

Anzeigen von PowerShell-Protokolldaten über die Befehlszeile unter macOS

Um PowerShell-Protokolldaten über eine Befehlszeile unter macOS anzuzeigen, verwenden Sie den befehl log im Terminal- oder einer anderen Shellhostanwendung. Diese Befehle können über PowerShell-, Z Shell-oder Bashausgeführt werden.

Im folgenden Beispiel wird der Befehl "log" verwendet, um die Protokolldaten in Ihrem System anzuzeigen, da er in Echtzeit auftritt. Der Prozess Parameter filtert die Protokolldaten nur für den pwsh Prozess. Wenn mehrere Instanzen von pwsh ausgeführt werden, akzeptiert der Prozess Parameter auch eine Prozess-ID als Wert. Der Parameter Level zeigt Nachrichten auf der angegebenen Ebene und darunter an.

log stream --predicate "subsystem == 'com.microsoft.powershell'" --level info

Der Befehl log show kann zum Exportieren von Protokollelementen verwendet werden. Der befehl log show bietet Optionen zum Exportieren der letzten N Elemente, Elemente seit einer bestimmten Zeit oder Elemente innerhalb eines bestimmten Zeitraums.

Der folgende Befehl exportiert beispielsweise Elemente seit 9am on April 5, 2022:

log show --start "2022-04-05 09:00:00" --predicate "subsystem == 'com.microsoft.powershell'"

Wenn Sie weitere Informationen wünschen, führen Sie log show --help aus, um die Hilfe für den Befehl log show anzuzeigen.

Sie können die Protokolldaten auch im JSON-Format ausgeben, sodass Sie die Ereignisdaten in PowerShell-Objekte konvertieren können. Im folgenden Beispiel werden die Ereignisse im JSON-Format ausgegeben. Das Cmdlet ConvertFrom-Json wird verwendet, um die JSON-Daten in PowerShell-Objekte zu konvertieren, die in der variablen $logRecord gespeichert werden.

log show --predicate "subsystem == 'com.microsoft.powershell'" --style json |
    ConvertFrom-Json | Set-Variable logRecord

Sie könnten auch in Erwägung ziehen, die Protokolle an einem sichereren Ort wie zum Beispiel einem SIEM (Security Information and Event Management) Aggregator zu speichern. Mit Microsoft Defender für Cloud-Apps können Sie SIEM in Azure einrichten. Weitere Informationen finden Sie unter generische SIEM-Integration.

Modi und Ebenen von PowerShell-Protokolldaten unter macOS

Standardmäßig protokolliert das PowerShell-Subsystem unter macOS Nachrichten der Stufe info im Speicher (mode) und Nachrichten der Stufe default auf Datenträger (persistence). Dieses Verhalten kann geändert werden, um einen anderen Modus und eine andere Protokollierungsebene mithilfe des Befehls log config zu aktivieren.

Im folgenden Beispiel wird die Protokollierung und Persistenz auf Informationsebene für das PowerShell-Subsystem aktiviert:

sudo log config --subsystem com.microsoft.powershell --mode level:info,persist:info

Verwenden Sie die zurücksetzen Parameter, um die Protokolleinstellungen auf die Standardwerte für das PowerShell-Subsystem zurückzusetzen:

sudo log config --subsystem com.microsoft.powershell --reset

Siehe auch

  • Last updated on