komma igång snabbt med PowerShell loggning

men om vi kör vårt skript flera gånger kommer det bara att vara en lång lista med uttalanden. Vi vet inte när linjerna loggades. I ett mer komplext scenario, som innehåller flera skript, har vi inte heller något sätt att veta var logglinjen härstammar—dvs,, från vilken ps1 fil. Det finns mer information som vi kan logga.

igen, låt oss ta ett steg tillbaka och titta på vad vi försöker uppnå med loggning.

varför loggar vi?

PowerShell används ofta för att automatisera och skript vissa uppgifter som annars skulle vara tråkiga och felbenägna. Automatisering börjar verkligen ge värde när det tillämpas på mer komplexa uppgifter. Men dessa komplexa skript kan också ha större chans att bryta: tjänster kanske inte svarar, maskinkonfigurationer kan ha ändrats etc.,

utan loggning är det svårt att veta om skript gick bra eller om något gick fel. Om något gick fel, loggning hjälper oss att ta reda på var och varför det gjorde. Programloggning kan också hjälpa dig att samla insikter i vilka delar av dina skript som används mest eller där prestandavinster fortfarande kan göras.

Vad ska du inte logga in?

När du skriver dina loggningsuppgifter, se till att du lämnar ut känsliga eller personuppgifter., Exempel är:

• lösenord och åtkomsttokens
• kreditkortsnummer eller bankkontonummer
• personnummer
• e-postadresser
• gatuadresser
• krypteringsnycklar
• personnummer

OWASP cheat sheet vid loggning har ett avsnitt om data för att utesluta det är intressant att läsa. Även om det syftar till fullfjädrade applikationer kan det vara användbart för PowerShell-skript också. Jag kan föreställa mig scenarios där PowerShell-skript hanterar e-postadresser eller vissa API-nycklar.,

loggning av sådan personligt identifierbar information (eller PII) är farlig. Inte bara behöver du uttryckligt samtycke från användaren i de flesta länder, men om uppgifterna någonsin läckt, kan du eller ditt företag hållas ansvariga. Om det inte är nödvändigt är det bättre att lämna dessa data ut.

Vad ska du logga?

vår artikel om att komma igång med Ruby loggning gör en stor punkt:

Du bör tänka på en loggpost som en händelse—något som är av intresse för din app som hände någon gång.,

detta innebär att vi åtminstone behöver en tidsstämpel och en beskrivning av händelsen. Beskrivningen kan också innehålla relevanta uppgifter. Detta är inte alltid lätt att bestämma i förskott. Tänk på vad du skulle behöva felsöka ett skript som misslyckades med att köra framgångsrikt. Och om du senare stöter på en situation där du skulle ha krävt mer information för att åtgärda ett problem, lägg till det i loggningen för nästa gång.,

mindre uppenbart, men mycket användbart, är att inkludera en loggnivå:

• på lägsta nivå kan Felsökningsutdrag vara användbara för att spåra det exekverade flödet av ditt PowerShell-skript.
• en nivå upp är informativa meddelanden om den funktionella sidan av ditt skript: vad utfördes, varför och med vilka data?
• då finns det också nivån på varningar: saker som inte är normala och potentiellt skadliga men som inte hindrar skriptet från att fortsätta.
• slutligen finns felnivåmeddelanden där för att logga fel som har gjort skriptkraschen.,

Du kan välja att logga alla dessa nivåer eller bara en viss nivå och uppåt (till exempel varningar och fel). Sedan, när du behöver mer information, kan du konfigurera ditt skript för att också logga mer information om nästa utförande.

vår egen enkla loggningsfunktion inkluderade inte loggnivåer. Inte heller lade det till en tidsstämpel. Vi kan naturligtvis lägga till denna funktionalitet, men lyckligtvis har andra redan skapat anständiga loggningsskript.

skriv in Loggningsskriptet

det finns ett enkelt men användbart skript på Technet som heter Write-Log., Om vi laddar ner det kan vi ändra vårt skript för att se ut så här:

Vi har inkluderat filen Function-Write-Log.ps1, tagit bort vår loggfunktion och ersatt samtalet med ett samtal för att skriva-Log. Vi kan skicka ett meddelande, en nivå och en väg. Nivån kan vara Info, Varna eller fel. Observera att det här skriptet inte har en Felsökningsnivå, vilket är olyckligt. Du kan dock enkelt ändra det för att inkludera det, eftersom skriptet släpps under MIT-licensen tillåter modifiering.,

När vi använder det här skriptet kommer vår logg att se ut så här:

2019-08-20 09:18:29 INFO: Intermediate result: 512019-08-20 09:18:29 INFO: Intermediate result: 6

Vi har nu tydliga logglinjer som inkluderar en tidsstämpel, loggnivån och vårt meddelande. Det är mycket bättre än vad vi hade tidigare. Detta kan vara tillräckligt för dina behov, men låt oss ta det ett steg längre och titta på ett annat alternativ: Psframen.

ange Loggningsramen

PSFramework är ett PowerShell-ramverk som innehåller flera användbara verktyg. Vi ska bara titta på loggningsdelen.,

för att komma igång med PSFramework måste du först installera det genom att köra Install-Module PSFramework i PowerShell. (Du kanske måste köra PowerShell-konsolen som administratör). Sedan kan du skriva till loggfilerna genom att ringa skriv-psfmessage script. I vårt fall skulle det se ut så här:

Write-PSFMessage -Level Output -Message "Intermediate result: $($sum)"

Lägg märke till hur vi inte använder en informationsnivå. Istället använder vi utgång. Detta beror på att psframework använder loggnivåer som matchar mer snyggt med de olika utdataströmmarna som PowerShell har som standard: Verbose, Host, Output, Warning, Error, etc.,

loggfilen kommer också att se lite annorlunda ut än vad vi är vana vid:

kolumnrubrikerna saknas, men det kan enkelt åtgärdas genom att ange loggleverantören först:

den här loggfilen kommer att innehålla en tidsstämpel i filnamnet och kommer nu att innehålla en rubrikrad. Detta beror på att psframeworks standardloggleverantör inte lägger till en rubrikrad, men logfile-leverantören kommer., Loggfilen kommer nu att se ut så här:

det här innehåller nu mycket användbar information som filnamnet på vårt skript, raden där loggningen inträffade och användarnamnet för användaren som kör skriptet. En annan stor fördel med loggningen av PSFramework är att den loggar asynkront. Loggningen kommer inte att sakta ner dina skript. Slutligen kommer det också automatiskt rensa upp dina loggar. Som standard kommer det att ta bort loggfiler efter sju dagar eller när de överstiger 100 megabyte.,

en jämförelse

skriptet Function-Write-Log matchar mer med vad många applikationsprogrammerare används till. Den innehåller standardloggnivåerna (förutom Debug) och skriver en loggfil som många loggningsramar gör: en tidsstämpel, loggnivån och meddelandet.

det saknar dock några extra funktioner som kan vara avgörande för dig: logga städa upp; asynkron loggning; och extra teknisk information som manus, radnummer och verkställande användare.,

psframework loggning ger dessa funktioner, men det kräver att du installerar hela ramen. Detta borde inte vara ett verkligt problem, men det är något att komma ihåg. PSFramework använder också olika loggningsnivåer än vi är vana vid. De matchar dock nära PowerShell – utmatningsströmmarna. Detta kan känna sig mer naturligt för erfarna PowerShell-användare.

vad händer härnäst?

Vi har tagit en titt på ett enkelt sätt att logga in PowerShell. Vi förbättrade också vår egen lösning genom att använda ett bättre skript (Function-Write-Log.ps1) och genom att använda loggningen som ingår i PSFramework.,

en sak som slog mig var att logga in PowerShell fortfarande är ganska grundläggande. Det är inte så att alternativen vi tittade på är dåliga eller saknas. Men jag hittade inte ett enda loggningsskript eller en modul som innehåller flera loggnivåer, asynkron loggning, log clean up och, viktigast av allt, flera loggdestinationer.

vad händer om vi vill skicka fel till en e-postadress? Eller vad händer om vi vill logga in i en databas? Såvitt jag kan se erbjuder PSFramework flest alternativ här, men e-post eller databas ingår inte. Det kan dock vara möjligt att skriva din egen och registrera den i PSFramework.,

detta kan bero på att Powershells värld är annorlunda än applikationsutvecklingsvärlden. PowerShell-skript kan vara mycket mer skräddarsydda, avsedda för ett visst scenario, och består av flera separata skript.

men loggning är fortfarande viktigt, särskilt med skript som körs regelbundet och har en viss grad av komplexitet. PowerShell är ett kraftfullt språk för att automatisera en mängd uppgifter. När något går fel med en sådan uppgift vill du veta vad som gick fel, vad som föregick det och hur man fixar det. Loggar ger dig denna information.,

som nästa steg upp kanske du vill titta på aggregera och hantera dina loggar. Scalyr är ett bra verktyg för detta. Titta på Scalyr API för de olika alternativen för att skicka logghändelser till Scalyr. Detta kan enkelt kallas från PowerShell och kommer att förbättra din förmåga att övervaka och felsöka dina PowerShell skript.

det här inlägget skrevs av Peter Morlion., Peter är en passionerad programmerare som hjälper människor och företag att förbättra kvaliteten på deras kod, särskilt i äldre kodbaser. Han är övertygad om att branschens bästa praxis är ovärderlig när man arbetar mot detta mål, och hans specialiteter inkluderar TDD, DI och solida principer.