Noțiuni de bază rapid cu logare PowerShell

în seria noastră „Noțiuni de bază cu logare”, am acoperit deja logare pentru mai multe limbi și cadre: C#, Java, Python, Ruby, Ruby on Rails, Node.js, Symfony, Kotlin, Flask, Angular și Laravel. Astăzi, vom adăuga un altul la această serie: PowerShell.

ar putea fi unul ciudat pentru a adăuga la listă; PowerShell este un limbaj de scripting, în timp ce celelalte pot fi văzute ca limbaje de programare completă a aplicațiilor sau cadre., Cu toate acestea, PowerShell este atât de puternic încât poate crea sisteme complexe și suficient de importante pentru a justifica logarea.PowerShell este adesea folosit pentru a efectua sarcini critice de întreținere pe computere sau servere. Este important ca administratorii să știe dacă aceste scripturi au funcționat bine sau nu.

vom analiza modul în care vă puteți conecta cu PowerShell într-un mod foarte de bază, scriind propria funcție de logare. Apoi vom acoperi de ce logarea de la PowerShell este utilă. Vom vorbi, de asemenea, despre ce ar trebui să vă conectați și ce nu ar trebui să vă conectați., În cele din urmă, vom analiza două opțiuni diferite care vă vor ușura viața de logare.

Un Simplu PowerShell Script

Să începem cu acest lucru extrem de simplu PowerShell script:

Acest script de bază are un număr întreg ca intrare. Apoi face suma cifrelor acelui număr. Dacă rezultatul este mai lung decât o singură cifră, acesta efectuează din nou operația, până când aceasta are ca rezultat o singură cifră.,

Aici sunt câteva exemple pentru a clarifica lucrurile:

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

Pune acest script într-un fișier text și salvați-l ca recursiveSum.ps1. Apoi, puteți rula la comanda PowerShell linie de funcționare recursiveSum.ps1 45, de exemplu., Producția va fi de 9:

Acesta este un script care este destul de simplu să funcționeze ca un exemplu, dar are destul de pași pe care am putea fi interesat în unele logare. Desigur, scripturile PowerShell din viața reală vor fi mult mai complexe, garantând nevoia de logare și mai mult.

cel mai simplu mod de a vă conecta PowerShell

să scriem rezultatul fiecărui pas în consolă. Deja scriem ceva la consolă folosind Declarația de scriere-ieșire, astfel încât să putem folosi cu ușurință asta din nou., Când o executați acum, ar trebui să puteți vedea o ieșire ca aceasta:

asta e grozav! Avem unele logare întâmplă. Cu toate acestea, aceste declarații de jurnal vor fi întotdeauna vizibile. Într-un program mai complex, ar putea avea sens să nu arate nimic decât dacă utilizatorul dorește să vadă înregistrarea. Este, probabil, de asemenea, util pentru a oferi utilizatorului un anumit control asupra cantității de detalii pe care le văd. Aici intră nivelurile de jurnal.,

Jurnal Niveluri în PowerShell

PowerShell are unele Scrie-* declarații care arată hartă tradiționale log niveluri, cum ar fi:

• Scrie-Verbose
• Scrie-Debug
• Scrie-Informații
• Scrie-Avertizare
• Scrie-Eroare

Verbose

Să ne uităm la Scrie-Verbose în primul rând. Putem schimba mesajele noastre despre pașii intermediari pentru a utiliza scrierea-Verbose., Când vom rula script-ul nostru acum, nu vom vedea noastre de etape intermediare:

Dar dacă am adăuga -Verbose pavilion, jurnalele noastre apar din nou:

Debug, Informații, și de Avertizare

Debug, Informații și Avertizare log nivelurile de lucru un pic diferit decât ne-am obișnuit să tradiționale din exploatarea cadre în alte limbi., Să adăugăm mai întâi câteva declarații suplimentare:

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

Debug-ul de scriere va fi vizibil numai când adăugați steagul-Debug. Se va opri, de asemenea, script-ul de la rularea și cere confirmarea pentru a continua. Acest lucru este util pentru a rula prin script-uri pas cu pas.

Dar ai un anumit control asupra dacă sau nu pentru a afișa avertismente și mesaje de informare. Comenzile Write-Warning și Write-Information pot fi controlate folosind steagurile-WarningAction și-InformationAction.,se steaguri, doar sunt afișate mesaje de avertizare:

Dacă vrem să arătăm mesaje de informare, putem face acest lucru prin adăugarea -InformationAction Continua flag:

Și dacă vrem să ascundem avertismente, putem folosi -WarningAction SilentlyContinue opțiune:

Eroare

în cele din Urmă, să ne uităm la modul de a Scrie-Eroare de lucrări., Putem adăuga astfel o declarație a script-ul nostru:

Write-Error "Something went wrong"

atunci Când această afirmație este executat, PowerShell va opri executarea de script-ul nostru și de a scrie eroare la consola, împreună cu unele detalii care ar putea fi utile:

Ce Este Aplicație de Logare?

să facem acum un pas departe de scriptul nostru PowerShell și să ne uităm la ce logare a aplicațiilor este exact., Prima postare din seria noastră a definit-o bine:

logarea aplicațiilor implică înregistrarea informațiilor despre comportamentul de rulare al aplicației pe un mediu mai persistent.

facem deja prima parte: cu alte cuvinte, captarea informațiilor despre comportamentul de rulare al aplicației noastre. Arătăm rezultatele intermediare ale procesului nostru. Dar nu facem partea a doua. Nu înregistrăm aceste informații într-un mediu persistent. Când închidem sesiunea PowerShell, am pierdut aceste informații. Să facem asta mai întâi.,

logare într-un fișier

vom adăuga această funcție jurnal la fișierul nostru script:

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

pur și simplu ia într-un șir de caractere și apoi adaugă-l la un jurnal.fișier txt.,

Atunci ne putem schimba log declarație, astfel că nu mai folosește Scrie-Verbose, dar acest Jurnal funcție de loc:

Log "Intermediate result: $($sum)"

Acum putem rula script-ul nostru și se va crea un fișier care conține nostru etape intermediare:

Dar dacă vom rula script-ul nostru de mai multe ori, acesta va fi doar o listă lungă de declarații. Nu avem de unde să știm când au fost înregistrate liniile. Într—un scenariu mai complex, care conține mai multe scripturi, nu avem nici o modalitate de a ști de unde provine linia de jurnal-adică.,, din care fișier ps1. Există mai multe informații pe care le-am putea înregistra.din nou, să facem un pas înapoi și să ne uităm la ceea ce încercăm să realizăm cu logarea.

De ce ne conectăm?

PowerShell este adesea folosit pentru a automatiza și script anumite sarcini care altfel ar fi plictisitoare și predispuse la erori. Automatizarea începe cu adevărat să ofere valoare atunci când este aplicată unor sarcini mai complexe. Dar aceste scripturi complexe ar putea avea, de asemenea, mai multe șanse de rupere: este posibil ca serviciile să nu răspundă, configurațiile mașinii să se fi schimbat etc.,

fără logare, este greu de știut dacă scripturile au funcționat bine sau dacă ceva nu a mers bine. Dacă ceva nu a mers bine, logarea ne va ajuta să aflăm unde și de ce a făcut-o. Logarea aplicațiilor vă poate ajuta, de asemenea, să adunați informații în care bucăți din scripturile dvs. sunt utilizate cel mai mult sau unde se pot obține câștiguri de performanță.

de Ce n-ar Trebui să Vă Conectați?

când scrieți declarațiile de logare, asigurați-vă că lăsați în afara datelor sensibile sau personale., Exemplele includ:

• parole și token-uri de acces
• numere de card de credit sau numerele de cont bancar
• numărul de securitate socială
• adrese de e-mail
• adrese de stradă
• chei de criptare
• numărul de securitate socială

La OWASP foaie de ieftin pe logare are o secțiune despre date pentru a exclude faptul că este interesant de citit. Deși vizează aplicații cu drepturi depline, ar putea fi util și pentru scripturile PowerShell. Îmi pot imagina scenariul în care scripturile PowerShell gestionează adrese de e-mail sau anumite chei API.,

logare astfel de informații de identificare personală (sau PII) este periculos. Nu numai că aveți nevoie de consimțământul explicit al utilizatorului în majoritatea țărilor, dar dacă datele sunt scurgeri vreodată, dvs. sau compania dvs. puteți fi trași la răspundere. Dacă nu este cu adevărat necesar, este mai bine să lăsați aceste date afară.

ce ar trebui să vă conectați?

articolul nostru pe Noțiuni de bază cu logare Ruby face un punct de mare:

ar trebui să se gândească la o intrare jurnal ca un eveniment—ceva care este de interes pentru aplicația care sa întâmplat la un moment dat.,

aceasta înseamnă că, cel puțin, avem nevoie de o marcă de timp și o descriere a evenimentului. Descrierea ar putea include, de asemenea, date relevante. Acest lucru nu este întotdeauna ușor de determinat în avans. Gândiți-vă la ce ar trebui să depanați un script care nu a reușit să ruleze cu succes. Și dacă mai târziu întâlniți o situație în care ați fi cerut mai multe informații pentru a remedia o problemă, adăugați-o la logare pentru data viitoare.,

Mai puțin evident, dar foarte util, este să includeți un nivel de jurnal:

• la cel mai scăzut nivel, declarațiile de depanare pot fi utile pentru a urmări fluxul executat al scriptului PowerShell.
• a level up sunt mesaje informative despre partea funcțională a scriptului dvs.: ce a fost executat, de ce și cu ce date?
• apoi, există și nivelul avertismentelor: lucruri care nu sunt normale și potențial dăunătoare, dar care nu împiedică continuarea scriptului.
• în cele din urmă, mesajele la nivel de eroare sunt acolo pentru a înregistra Erorile care au făcut ca scriptul să se prăbușească.,puteți alege să conectați toate aceste niveluri sau doar un anumit nivel și în sus (de exemplu, avertismente și erori). Apoi, când aveți nevoie de mai multe informații, puteți configura scriptul pentru a înregistra și mai multe detalii despre următoarea execuție.

  funcția noastră simplă de logare nu include nivelurile jurnalului. Nici nu a adăugat o marcă de timp. Am putea adăuga această funcționalitate, desigur, dar, din fericire, alții au creat deja scripturi decente de logare.

  introduceți scriptul de logare

  există un script simplu, dar util pe Technet numit Write-Log., Dacă îl descărcăm, putem schimba scriptul nostru pentru a arăta astfel:

  am inclus fișierul Function-Write-Log.ps1, am eliminat funcția Log și am înlocuit apelul cu un apel la Write-Log. Putem trece într-un mesaj, un nivel, și o cale. Nivelul poate fi Info, Warn, sau eroare. Observați că acest script nu are un nivel de depanare, ceea ce este nefericit. Cu toate acestea, puteți să-l modificați cu ușurință pentru a-l include, deoarece scriptul este lansat sub licența MIT care permite modificarea.,

  când folosim acest script, jurnalul nostru va arăta astfel:

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

  acum avem linii de jurnal clare care includ o marcă de timp, nivelul jurnalului și mesajul nostru. Asta e mult mai bine decât ceea ce am avut anterior. Acest lucru poate fi suficient pentru nevoile dvs., dar să facem un pas mai departe și să analizăm o altă opțiune: PSFramework.

  introduceți Cadrul de logare

  PSFramework este un cadru PowerShell care include mai multe utilități utile. Ne vom uita doar la partea de exploatare forestieră.,pentru a începe cu PSFramework, va trebui mai întâi să îl instalați rulând Install-Module PSFramework în PowerShell. (S-ar putea să trebuiască să rulați consola PowerShell ca administrator). Apoi, puteți scrie în fișierele jurnal apelând scriptul Write-PSFMessage. În cazul nostru, ar arăta astfel:

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

  observați cum nu folosim un nivel de informații. În schimb, folosim ieșirea. Acest lucru este pentru că PSFramework utilizează nivele de jurnal, care se potrivesc mai bine cu acea ieșire diferite fluxuri care PowerShell are în mod implicit: Verbose, Gazdă, de Ieșire, de Avertizare, Eroare, etc.,

  fișierul jurnal va arăta, de asemenea, ușor diferit de ceea ce suntem obișnuiți:

  anteturile coloanelor lipsesc, dar acest lucru poate fi remediat cu ușurință setând mai întâi furnizorul de jurnalizare:

  acest fișier jurnal va include un marcaj de timp în numele fișierului și va include acum un rând de antet. Acest lucru este pentru că PSFramework implicit log provider nu va adăuga un antet de rând, dar logfile furnizorul va., Fișierul jurnal va arăta acum astfel:

  aceasta include acum o mulțime de informații utile, cum ar fi numele fișierului scriptului nostru, linia în care a avut loc înregistrarea și numele de utilizator al utilizatorului care rulează scriptul. Un alt mare avantaj al logării de către PSFramework este că se înregistrează asincron. Logarea nu va încetini scripturile. În cele din urmă, va curăța automat jurnalele. În mod implicit, va elimina fișierele jurnal după șapte zile sau când depășesc 100 megabytes.,

  

  O Comparație

  Funcția-Scrie-Log script potrivește mai mult cu ceea ce multe aplicații programatorii sunt utilizate pentru a. Acesta include nivelurile standard de jurnal (cu excepția Debug) și scrie un fișier jurnal ca multe cadre de logare fac: un marcaj de timp, nivelul jurnal, și mesajul.

  cu toate acestea, ratează unele funcționalități suplimentare care ar putea fi cruciale pentru dvs.: curățarea jurnalului; logare asincronă; și informații tehnice suplimentare, cum ar fi scriptul, numărul liniei și utilizatorul executant.,înregistrarea PSFramework oferă aceste caracteristici, deși necesită instalarea întregului cadru. Aceasta nu ar trebui să fie o problemă reală, dar este ceva de reținut. PSFramework folosește, de asemenea, diferite niveluri de logare decât suntem obișnuiți. Cu toate acestea, se potrivesc strâns cu fluxurile de ieșire PowerShell. Acest lucru se poate simți mai natural pentru utilizatorii PowerShell experimentați.

  ce urmează?

  am aruncat o privire la o modalitate simplă de a vă conecta la PowerShell. Am îmbunătățit, de asemenea, la propria noastră soluție prin utilizarea unui script mai bun (Function-Write-Log.ps1) și prin utilizarea de logare incluse în PSFramework.,

  un lucru care ma lovit a fost că logarea în PowerShell este încă destul de bază. Nu este că opțiunile pe care le-am privit sunt rele sau lipsesc. Dar nu am găsit un singur script de logare sau modul care include mai multe niveluri de jurnal, jurnal asincron, jurnal curat, și, cel mai important, mai multe destinații jurnal.ce se întâmplă dacă dorim să trimitem erori la o adresă de e-mail? Sau dacă vrem să ne conectăm la o bază de date? Din câte văd, PSFramework oferă cele mai multe opțiuni aici, dar e-mailul sau baza de date nu sunt incluse. Ar putea fi posibil să vă scrieți propriul dvs. și să îl înregistrați în PSFramework, totuși.,acest lucru s-ar putea datora faptului că lumea PowerShell este diferită de lumea dezvoltării aplicațiilor. Scripturile PowerShell pot fi mult mai personalizate, destinate unui scenariu specific și compuse din mai multe scripturi separate.cu toate acestea, logarea rămâne importantă, în special în cazul scripturilor care rulează regulat și au un anumit nivel de complexitate. PowerShell este un limbaj puternic pentru a automatiza o multitudine de sarcini. Când ceva nu merge bine cu o astfel de sarcină, vrei să știi ce a mers prost, ce a precedat-o și cum să o rezolvi. Jurnalele vă oferă aceste informații.,

  

  Ca un pas următor, s-ar putea dori să se uite la agregarea și gestionarea busteni. Scalyr este un instrument excelent pentru acest lucru. Au Uita-te la API Scalyr pentru diferitele opțiuni de a trimite evenimente jurnal la Scalyr. Acest lucru poate fi apelat cu ușurință de la PowerShell și vă va îmbunătăți capacitatea de monitorizare și depanare a scripturilor PowerShell.acest post a fost scris de Peter Morlion., Peter este un programator pasionat care ajută oamenii și companiile să îmbunătățească calitatea codului lor, în special în bazele de cod vechi. El crede cu tărie că cele mai bune practici din industrie sunt neprețuite atunci când lucrează pentru acest obiectiv, iar specialitățile sale includ TDD, DI și principii solide.