none
Report Error wenn writing EventLog fails

    Frage

  • Hallo zusammen,

    in meinen Scripts möchte ich die Fehler ins Eventlog schrieben. Wenn jetzt die Funktionen die dazu erforderlich sind selbst einen Fehler werfen wird auch kein Log-Eintrag generiert. Das heißt falls

    System.Diagnostics.EventLog]::SourceExists($logSrc)

    einen Fehler wirft kann ich auch keinen Eventlog schreiben, der sich auf den Try-Block bezieht.

    $logSrc="test"
    
    if(![System.Diagnostics.EventLog]::SourceExists($logSrc)){
        New-EventLog -LogName "Application" -Source $logSrc
    }
    
    
    try{
    
       echos "ich bin ein ungültiger Command" 
    
    }catch{
        Write-EventLog -LogName Application -source $logSrc -EntryType Error -EventId $error.Count -message "$PSItem"
    }


     Wie kann man diesen Fehlerfall überwachen? Denn der Fehler steckt ja immer noch in dem jeweiligen Script.






    • Bearbeitet Zero3000 Dienstag, 27. November 2018 17:12
    Dienstag, 27. November 2018 16:39

Antworten

  • Ja, das hätte man gern :-)

    Was ich in mehreren Projekten gemacht habe, ist eine zentrale SQL-DB, in die jedes Skript beim Start einen Datensatz mit Startzeitpunkt schreibt und ihn bei Abschluss dann mit Endzeitpunkt und Statuscode ergänzt.

    Dann kannst Du über die DB einen Report ziehen und fehlerhaften Datensätzen (oder fehlenden Datensätzen) nachgehen.

    Muss auch keine SQL-DB sein, ein Webservice, Message Queue oder was auch immer tut's auch. Wenn man Nagios am Start hat, kann man da passive Checks reinschieben.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert Zero3000 Mittwoch, 28. November 2018 12:46
    Mittwoch, 28. November 2018 10:38

Alle Antworten

  • Moin,

    hier eine ganz gute Übersicht zur Orientierung: https://blogs.msdn.microsoft.com/kebab/2013/06/09/an-introduction-to-error-handling-in-powershell/


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 27. November 2018 16:46
  • Hi.

    Die Seite kenn ich. Zugeben ich hatte sie nur quergelesen. Ich glaube da wird meine Frage nicht behandelt. Ich habe meinen Post noch einmal editiert um meine Frage deutlicher zu gestalten.

    Dienstag, 27. November 2018 17:05
  • Moin,

    wenn ein Befehl einen terminierenden Fehler wirft, kann man ihn normalerweise mit try/catch überwachen ;-)

    try {
        if([System.Diagnostics.EventLog]::SourceExists($logSrc)){
            New-EventLog -LogName "Application" -Source $logSrc -ErrorAction Stop
        }
    } catch {
        Write-Warning "Konnte die EventLog-Quelle $logSrc nicht anlegen!"
    }

    Und dann kannst Du entscheiden, ob Dein Skript ohne die Quelle weiter läuft, oder abbricht, oder nochmal versucht, sie anzulegen.

    In welchem Fall kommt es denn hier zu Fehlern?


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 27. November 2018 17:18
  • Ok evtl. fehlt es meinem Post immer noch an Kontext. "Write-Warning" schreibt auf den std-output, diesen überwache ich aber nicht. Das Script wird i.d.R. zu ieinem Zeitpunkt automatisch ausgeführt.

    std-out könnte ich natürlich in ein Textfile umleiten, das bringt mich aber wieder zu ähnlichen Problemen, denn wie dokumentiert man dann, wenn es zu Fehlern beim Schreiben dieser Textdatei kommt...

    Dienstag, 27. November 2018 17:44
  • Ja, und auch nach dieser Erläuterung verstehe ich nicht, welche Art Benachrichtigung Du gern hättest. Write-Warning schreibt übrigens nicht an den Std-Out sondern an Warning (Stream 3) (s. auch https://blogs.technet.microsoft.com/heyscriptingguy/2014/03/30/understanding-streams-redirection-and-write-host-in-PowerShell/), außerdem habe ich Write-Warning nur als Beispiel genommen, Du kannst im Catch-Block alles mögliche tun.

    Du könntest Dir eine Mail senden (Send-MailMessage), eine Datei schreiben (Out-File), die wieder ein anderer Skript per FileSystemWatcher überwacht, aber im Endeffekt brauchst Du halt einen Benachrichtigungskanal ;-)


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.


    Dienstag, 27. November 2018 18:04
  • ...aber im Endeffekt brauchst Du halt einen Benachrichtigungskanal ;-)

    Ja genau, auf dieses Problem bezieht sich meine Frage. Sobald ich den Benachrichtungskanal in mein eigenes Programm einbaue, so lange kann ich nicht alle Fehler dokumentieren. Denn sobald die Benachrichtigungsroutine selbst einen Fehler wirft, bekomme ich das nicht mit, es sei denn ich würde davon ausgehen jeden Tag/Stunde eine Nachricht zu bekommen, dass das Programm noch läuft anstatt im Fehlerfall benachrichtigt zu werden.

    Wonach ich suche ist eine Art Monitoring (Strategie), das außerhalb meines Programms, mein Programm überwacht und meldet falls dort iein Fehler geworfen wird. Nehmen wir bspw. ein PSScript welches über Sheduled Task ausgeführt werden soll. Dieses Script enthält natürlich möglichen Fehlerbehandlung, welche mir über ieine Nachricht signalisiert falls es zu einem Fehler gekommen ist. Dieses Signal fällt natürlich aus, wenn die Message-Routine selbst betroffen ist. Dann hätte ich trotzdem gerne das mir bspw. die Aufgabenplanung iwie signalisiert das etwas beim Ausführen des Scripts schief lief.


    • Bearbeitet Zero3000 Mittwoch, 28. November 2018 09:17
    Mittwoch, 28. November 2018 09:15
  • Ja, das hätte man gern :-)

    Was ich in mehreren Projekten gemacht habe, ist eine zentrale SQL-DB, in die jedes Skript beim Start einen Datensatz mit Startzeitpunkt schreibt und ihn bei Abschluss dann mit Endzeitpunkt und Statuscode ergänzt.

    Dann kannst Du über die DB einen Report ziehen und fehlerhaften Datensätzen (oder fehlenden Datensätzen) nachgehen.

    Muss auch keine SQL-DB sein, ein Webservice, Message Queue oder was auch immer tut's auch. Wenn man Nagios am Start hat, kann man da passive Checks reinschieben.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert Zero3000 Mittwoch, 28. November 2018 12:46
    Mittwoch, 28. November 2018 10:38
  • Du prüfst zwar ab, ob die EventSource existiert, erstellst du aber im Im NOT-Fall auch eine Neue?
    Denn sonst klappt ja das Eventlog nicht.

    https://docs.microsoft.com/de-de/dotnet/api/system.diagnostics.eventlog?view=netframework-4.7.2

    Alternativ kann man ja auch sein eigenes Logfile z.B. im Verzeichnis %APPDATA% oder %LOCALAPPDATA% als Unterverzeichnis ablegen. Das mache ich auch lieber.

    Mittwoch, 28. November 2018 11:32
  • Du prüfst zwar ab, ob die EventSource existiert, erstellst du aber im Im NOT-Fall auch eine Neue?
    Denn sonst klappt ja das Eventlog nicht.

    Ich verstehe die Frage nicht. Natürlich erstellt man eine neue EventSource falls nicht vorhanden. Wie in meinem Startpost am Ausrufezeichen zu erkennen.

    https://docs.microsoft.com/de-de/dotnet/api/system.diagnostics.eventlog?view=netframework-4.7.2

    Alternativ kann man ja auch sein eigenes Logfile z.B. im Verzeichnis %APPDATA% oder %LOCALAPPDATA% als Unterverzeichnis ablegen. Das mache ich auch lieber.


    Das habe ich doch bereits mit Evgenij diskutiert, dass das nur ein weiterer Kanal ist und genauso gut ausfallen kann.


    • Bearbeitet Zero3000 Mittwoch, 28. November 2018 13:01
    Mittwoch, 28. November 2018 12:46
  • Nun, wenn das Schreiben auf die lokale Platte ausfällt, hast du glaube ich ganz andere Probleme.

    Dieser "Kanal" ist bei mir noch nie ausgefallen. Alles andere, was von laufenden Diensten abhängt, da hast du sicherlich Recht.

    Mittwoch, 28. November 2018 13:36