in onze “aan de slag met Logging” serie, hebben we al behandeld logging voor vele talen en frameworks: C#, Java, Python, Ruby, Ruby on Rails, Node.js, Symfony, Kotlin, kolf, hoekig en Laravel. Vandaag voegen we er nog een toe aan deze serie: PowerShell.

Het kan een vreemde zijn om aan de lijst toe te voegen; PowerShell is een scripttaal, terwijl de andere kunnen worden gezien als volledige programmeertalen of frameworks., Toch is PowerShell zo krachtig genoeg dat het systemen complex en belangrijk genoeg kan maken om logging te garanderen.

PowerShell wordt vaak gebruikt om kritieke onderhoudstaken uit te voeren op computers of servers. Het is belangrijk voor admins om te weten hoe als deze scripts goed liep of niet.

We zullen bekijken hoe je op een zeer eenvoudige manier kunt loggen met PowerShell door je eigen logfunctie te schrijven. Dan zullen we behandelen waarom loggen van PowerShell nuttig is. We zullen ook praten over wat je moet loggen en wat je niet moet loggen., Tot slot zullen we kijken naar twee verschillende opties die uw logging leven gemakkelijker zal maken.

een eenvoudig PowerShell-Script

laten we beginnen met dit uiterst eenvoudige PowerShell-script:

Dit basisscript neemt een geheel getal als invoer. Het maakt dan de som van de cijfers van dat nummer. Als het resultaat langer is dan een enkel cijfer, voert het de bewerking opnieuw uit, totdat dit resulteert in een enkel cijfer.,

Hier zijn enkele voorbeelden om dingen te verduidelijken:

  • 45 -> 4 + 5 = 9
  • 397 -> 3 + 9 + 7 = 19 -> 1 + 9 = 10 -> 1 + 0 = 1
  • 3 -> 3

Zet dit script in een tekstbestand en sla het op als recursiveSum.ps1. Vervolgens, u kunt uitvoeren op de PowerShell command-line door het uitvoeren van recursiveSum.ps1 45, bijvoorbeeld., De uitvoer zal 9 zijn:

Dit is een script dat eenvoudig genoeg is om als voorbeeld te functioneren, maar genoeg stappen heeft om te kunnen loggen. Natuurlijk zullen real-life PowerShell-scripts veel complexer zijn, wat de behoefte aan logging nog meer garandeert.

de makkelijkste manier om in te loggen in PowerShell

laten we het resultaat van elke stap naar de console schrijven. We schrijven al iets naar de console met behulp van de Write-Output statement, dus we kunnen dat gemakkelijk opnieuw gebruiken., Verander de While lus om zo ‘ n statement op te nemen:

wanneer je het nu uitvoert, zou je een uitvoer als deze moeten kunnen zien:

dat is geweldig! Er wordt gekapt. Deze log statements zullen echter altijd zichtbaar zijn. In een complexer programma kan het zinvol zijn om niets te laten zien, tenzij de gebruiker de logging wil zien. Het is waarschijnlijk ook handig om de gebruiker enige controle te geven over de hoeveelheid detail die ze zien. Dit is waar log niveaus komen in.,

Log Levels in PowerShell

PowerShell heeft enkele Write – * statements die worden toegewezen aan traditionele log levels zoals:

  • Write-Verbose
  • Write-Debug
  • Write-Information
  • Write-Warning
  • Write-Error

Verbose

laten we eerst Write-Verbose bekijken. We kunnen onze berichten over de tussenliggende stappen wijzigen om Write-Verbose te gebruiken., Wanneer wij onze script nu, we het niet zien onze tussenliggende stappen:

Maar als we de -Verbose vlag, onze logboeken worden nogmaals:

Debug Informatie en waarschuwingen

De Debug, info en Waarschuwing niveaus werkt een beetje anders dan we gewend zijn van de traditionele logging frameworks in andere talen., Laten we eerst wat extra statements toevoegen:

Write-Debug "This is a debug statement"Write-Information "This is an info statement"Write-Warning "This is a warning statement"

De Write-Debug zal alleen zichtbaar zijn als je de-Debug vlag toevoegt. Het zal ook stoppen met uw script uit te voeren en vragen om bevestiging om verder te gaan. Dit is handig om stap voor stap door je scripts te lopen.

maar u hebt wel enige controle over het al dan niet tonen van waarschuwingen en informatieberichten. De Write-Warning en Write-Information commando ‘ s kunnen worden bestuurd met behulp van de-WarningAction en-InformationAction flags.,se vlaggen, alleen de waarschuwingsberichten worden weergegeven:

Als we willen om de informatie in berichten, kunnen wij dit doen door het toevoegen van -InformationAction Blijven vlag:

En als we willen verbergen van de waarschuwingen, kunnen we gebruik maken van de -WarningAction SilentlyContinue optie:

Error

tot slot, laten we eens kijken hoe Schrijf-Fout werkt., We kunnen zo ‘ n statement aan ons script toevoegen:

Write-Error "Something went wrong"

wanneer dit statement wordt uitgevoerd, stopt PowerShell de uitvoering van ons script en schrijft de fout naar de console, samen met enkele details die nuttig kunnen zijn:

Wat is logging van toepassingen?

laten we nu een stap verwijderd van ons PowerShell script en kijken naar wat applicatielogging precies is., Het eerste bericht in onze serie definieerde het goed:

Toepassingsregistratie omvat het opnemen van informatie over het runtime-gedrag van uw toepassing op een meer persistent medium.

We zijn al bezig met het eerste deel: met andere woorden, het vastleggen van informatie over het runtime-gedrag van onze toepassing. We tonen de tussentijdse resultaten van ons proces. Maar we doen het tweede deel niet. We nemen deze informatie niet op in een persistent medium. Wanneer we onze PowerShell-sessie sluiten, zijn we deze informatie kwijt. Laten we dat eerst doen.,

Logging naar een bestand

we voegen deze logfunctie toe aan ons scriptbestand:

Function Log { param( $msg ) Add-Content log.txt $msg}

Het neemt gewoon een String in en voegt het vervolgens toe aan een log.txt-bestand.,

Dan kunnen we veranderen onze log instructie zodat deze niet langer gebruik van Schrijf-Uitgebreid maar dit Logboek functie in:

Log "Intermediate result: $($sum)"

Nu kunnen we ons script en het zal u een bestand met ons tussenliggende stappen:

Maar als wij ons script meerdere keren is het gewoon een lange lijst van instructies. We weten niet wanneer de lijnen zijn gelogd. In een complexer scenario, dat meerdere scripts bevat, hebben we ook geen manier om te weten waar de logregel vandaan kwam-d.w.z.,, van waaruit ps1 bestand. Er is meer informatie dat we kunnen loggen.

nogmaals, laten we een stap terug doen en kijken naar wat we proberen te bereiken met loggen.

waarom loggen we?

PowerShell wordt vaak gebruikt om bepaalde taken te automatiseren en te script die anders vervelend en foutgevoelig zouden zijn. Automatisering begint echt waarde te bieden wanneer het wordt toegepast op meer complexe taken. Maar deze complexe scripts hebben misschien ook meer kans om te breken: services reageren mogelijk niet, machineconfiguraties kunnen veranderd zijn, enz.,

zonder logging is het moeilijk om te weten of scripts goed liepen of dat er iets mis ging. Als er iets mis ging, zal loggen ons helpen om uit te vinden waar en waarom het gebeurde. Application logging kan u ook helpen inzicht te krijgen in welke stukken van uw scripts het meest worden gebruikt of waar prestatieverbeteringen nog steeds kunnen worden gemaakt.

Wat moet u niet loggen?

wanneer u uw login statements schrijft, zorg er dan voor dat u gevoelige of persoonlijke gegevens weglaat., Voorbeelden zijn:

  • wachtwoorden en toegangstokens
  • creditcardnummers of bankrekeningnummers
  • burgerservicenummers
  • e-mailadressen
  • straatadressen
  • versleutelingssleutels
  • burgerservicenummers

het OWASP-spiekbriefje bij het loggen heeft een sectie over gegevens die moeten worden uitgesloten en die interessant is om te lezen. Hoewel het gericht is op volwaardige toepassingen, kan het ook nuttig zijn voor PowerShell-scripts. Ik kan me voorstellen scenario ‘ s waar PowerShell scripts omgaan met e-mailadressen of bepaalde API-sleutels.,

het registreren van dergelijke persoonlijk identificeerbare informatie (of PII) is gevaarlijk. Niet alleen hebt u in de meeste landen uitdrukkelijke toestemming van de gebruiker nodig, maar als de gegevens ooit worden gelekt, kunt u of uw bedrijf verantwoordelijk worden gehouden. Als het niet echt nodig is, is het beter om deze gegevens weg te laten.

Wat moet u loggen?

ons artikel over aan de slag gaan met Ruby logging maakt een groot punt:

een logboekvermelding moet je zien als een gebeurtenis—iets dat van belang is voor je app die op een bepaald moment is gebeurd.,

Dit betekent dat we minimaal een tijdstempel en een beschrijving van de gebeurtenis nodig hebben. De beschrijving kan ook relevante gegevens bevatten. Dit is niet altijd gemakkelijk vooraf te bepalen. Denk na over wat je nodig zou hebben om problemen op te lossen met een script dat niet succesvol kan worden uitgevoerd. En als u later een situatie tegenkomt waarin u meer informatie nodig zou hebben om een probleem op te lossen, voeg dit dan toe aan de logging voor de volgende keer.,

minder voor de hand liggend, maar zeer nuttig, is het opnemen van een log niveau:

  • op het laagste niveau kunnen Debug statements nuttig zijn om de uitgevoerde stroom van uw PowerShell script te volgen.
  • een niveau hoger zijn informatieve berichten over de functionele kant van uw script: wat werd uitgevoerd, waarom, en met welke gegevens?
  • dan is er ook het niveau van waarschuwingen: dingen die niet normaal zijn en potentieel schadelijk, maar die het script niet verhinderen om verder te gaan.
  • tot slot, Error-level berichten zijn er om fouten te loggen die het script hebben laten crashen.,

u kunt ervoor kiezen om al deze niveaus te loggen of alleen een specifiek niveau en hoger (bijvoorbeeld waarschuwingen en fouten). Als je dan meer informatie nodig hebt, kun je je script configureren om ook meer details bij de volgende uitvoering in te loggen.

onze eigen eenvoudige logfunctie bevatte geen logniveaus. Het heeft ook geen tijdstempel toegevoegd. We kunnen deze functionaliteit natuurlijk toevoegen, maar gelukkig hebben anderen al fatsoenlijke logging scripts gemaakt.

voer het Logboekscript in

Er is een eenvoudig maar nuttig script op Technet genaamd Write-Log., Als we het downloaden, kunnen we ons script veranderen om er zo uit te zien:

we hebben het Function-Write-Log.ps1 bestand Toegevoegd, onze Log functie verwijderd en de aanroep vervangen door een aanroep naar Write-Log. We kunnen een boodschap doorgeven, een niveau en een pad. Het niveau kan Info, Warn of Error zijn. Merk op dat dit script geen Debug-niveau heeft, wat jammer is. U kunt het echter gemakkelijk wijzigen om het op te nemen, omdat het script is uitgebracht onder de MIT-licentie die modificatie toestaat.,

wanneer we dit script gebruiken, zal onze log er als volgt uitzien:

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

we hebben nu duidelijke logregels die een tijdstempel, het logniveau en ons bericht bevatten. Dat is veel beter dan wat we eerder hadden. Dit kan voldoende zijn voor uw behoeften, maar laten we nog een stap verder gaan en kijken naar een andere optie: het PSFramework.

Enter the Logging Framework

Het PSFramework is een PowerShell framework dat verschillende nuttige hulpprogramma ‘ s bevat. We gaan alleen kijken naar het houtkap gedeelte.,

om te beginnen met het PSFramework, moet u het eerst installeren door het uitvoeren van Install-Module PSFramework in PowerShell. (Het kan zijn dat je je PowerShell console als beheerder moet draaien). Vervolgens kunt u naar de logbestanden schrijven door het script Write-PSFMessage aan te roepen. In ons geval zou het er zo uitzien:

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

merk op dat we geen Info niveau gebruiken. In plaats daarvan gebruiken we Output. Dit komt omdat PSFramework log levels gebruikt die beter overeenkomen met de verschillende uitvoerstromen die PowerShell standaard heeft: uitgebreid, Host, Output, waarschuwing, fout, enz.,

het logbestand zal er ook iets anders uitzien dan we gewend zijn:

de kolomkoppen ontbreken, maar dat kan eenvoudig worden verholpen door eerst de logboekprovider in te stellen:

dit logbestand zal een tijdstempel in de bestandsnaam bevatten, en zal nu een kopregel bevatten. Dit komt omdat de standaard Logprovider van PSFramework geen header-rij zal toevoegen, maar de logfile-provider wel., Het logbestand zal er nu zo uitzien:

Dit bevat nu veel nuttige informatie zoals de bestandsnaam van ons script, de regel waar de logging plaatsvond en de gebruikersnaam van de gebruiker die het script draait. Een ander groot voordeel van de logging door PSFramework is dat het logt asynchroon. Het loggen zal je scripts niet vertragen. Tot slot, het zal ook automatisch opruimen van uw logs. Standaard zal het logbestanden verwijderen na zeven dagen of wanneer ze meer dan 100 megabytes bedragen.,

een vergelijking

Het Function-Write-Log script komt meer overeen met wat veel applicatieprogrammeurs gewend zijn. Het bevat de standaard log niveaus (met uitzondering van Debug) en schrijft een log bestand zoals veel logging frameworks doen: een tijdstempel, het log niveau, en het bericht.

echter, het mist een aantal extra functionaliteit die cruciaal voor u kan zijn: log opruimen; asynchrone logging; en extra technische informatie zoals het script, regelnummer, en het uitvoeren van de gebruiker.,

De PSFramework logging biedt deze functies, hoewel het vereist dat je het hele framework installeert. Dit zou geen echt probleem moeten zijn, maar het is iets om in gedachten te houden. Het PSFramework gebruikt ook verschillende logging niveaus dan we gewend zijn. Ze komen echter nauw overeen met de PowerShell-uitvoerstromen. Dit kan natuurlijker aanvoelen voor doorgewinterde PowerShell-gebruikers.

wat volgt?

We hebben een eenvoudige manier bekeken om in te loggen in PowerShell. We hebben ook onze eigen oplossing verbeterd door een beter script te gebruiken (Function-Write-Log.ps1) en door de logging te gebruiken die is opgenomen in PSFramework.,

een ding dat me opviel was dat het inloggen in PowerShell nog steeds vrij basic is. Het is niet dat de opties die we bekeken slecht zijn of ontbreken. Maar ik heb geen enkele logboekscript of module gevonden die meerdere logniveaus, asynchrone logboekregistratie, logopruiming en, belangrijker nog, meerdere logbestemmingen bevat.

Wat als we fouten naar een e-mailadres willen sturen? Of wat als we in een database willen loggen? Voor zover ik kan zien, PSFramework biedt de meeste opties hier, maar e-mail of database zijn niet inbegrepen. Het is misschien mogelijk om uw eigen te schrijven en te registreren in PSFramework, hoewel.,

Dit kan zijn omdat de wereld van PowerShell anders is dan de wereld van applicatieontwikkeling. PowerShell scripts kunnen veel meer op maat gemaakt, bedoeld voor een specifiek scenario, en samengesteld uit meerdere afzonderlijke scripts.

toch blijft loggen belangrijk, vooral met scripts die regelmatig draaien en een bepaald niveau van complexiteit hebben. PowerShell is een krachtige taal om een veelheid van taken te automatiseren. Wanneer er iets mis gaat met zo ‘ n taak, wil je weten wat er mis ging, wat eraan vooraf ging, en hoe je het kunt oplossen. Logboeken geven je deze informatie.,

als volgende stap wilt u misschien kijken naar het aggregeren en beheren van uw logs. Scalyr is een geweldig hulpmiddel hiervoor. Kijk eens naar de Scalyr API voor de verschillende opties van het verzenden van log gebeurtenissen naar Scalyr. Dit kan eenvoudig worden aangeroepen vanuit PowerShell en zal uw vermogen om uw PowerShell-scripts te monitoren en problemen op te lossen verbeteren.

Dit bericht is geschreven door Peter Morlion., Peter is een gepassioneerde programmeur die mensen en bedrijven helpt de kwaliteit van hun code te verbeteren, vooral in oudere codebases. Hij is ervan overtuigd dat beste praktijken in de industrie van onschatbare waarde zijn bij het werken naar dit doel, en zijn specialiteiten omvatten TDD, DI, en SOLID principles.