Telemetria në PowerShell: variablat, privatësia dhe transmetimi i të dhënave

Nëse punoni me PowerShell çdo ditë dhe filloni të dëgjoni për telemetrinë në skripte dhe seanca , është normale të keni pyetje: çfarë të dhënash po dërgohen, ku shkojnë, si t'i çaktivizoni ato, apo edhe si ta përdorni vetë atë telemetri për të debuguar ose monitoruar skriptet tuaja. E gjithë kjo bëhet edhe më e rëndësishme kur punoni në mjedise të korporatave ose kur trajtoni informacione të ndjeshme.

Në rreshtat e mëposhtëm do të shihni, me hollësi të konsiderueshme dhe me gjuhën më të thjeshtë të mundshme, se si funksionon telemetria e lidhur me PowerShell , çfarë roli luajnë variablat e mjedisit, si mund të zgjidhni të mos merrni pjesë, si të dërgoni manualisht telemetrinë (për shembull te Application Insights) me PowerShell ose curl, dhe cilat probleme tipike të rrjetit, TLS ose vërtetimit mund të shkaktojnë mungesën e të dhënave nga panelet tuaja.

Çfarë telemetrie dërgon PowerShell në mënyrë native?

PowerShell, në versionet e tij moderne, përfshin mekanizmin e vet për dërgoni të dhëna bazë të përdorimit te Microsoft përmes Application Insights. Nuk po flasim për kodin që shkruani, por për vetë motorin PowerShell kur ekzekutohet skedari binar. pwsh.

Kjo telemetri e ndihmon Microsoft-in të kuptojë më mirë se si përdoret PowerShell (versionet, platformat, modulet, etj.) dhe të përparësojë veçoritë e reja ose rregullimet e gabimeve. Përpara se të dërgohet, informacioni anonimizohet dhe grumbullohet në mënyrë që përdoruesi të mos identifikohet drejtpërdrejt.

Ka dy momente kyçe kur mblidhen të dhënat: në fillim të seancës dhe periodikisht gjatë ekzekutimit . Të kuptuarit e kësaj sjelljeje është thelbësore nëse dëshironi kontroll maksimal mbi atë që ndahet nga mjediset tuaja.

Për më tepër, motori e dërgon këtë telemetri vetëm kur e përdorni pwsh standard; nëse PowerShell është i integruar si një motor në një aplikacion tjetër pritësAjo telemetri fillestare nuk gjenerohet.

Të dhënat e dërguara gjatë nisjes së pwsh

Kur një seancë fillon me pwshMotori mbledh një grup të vogël, por shumë specifik informacionesh mjedisore që dërgohen vetëm një herë në bootNdër të tjera, janë regjistruar sa vijon: detajet e sistemit operativ dhe instalimit nga PowerShell.

Ky startup përfshin të dhëna të tilla si prodhuesi i sistemit operativ, emri dhe versioni i platformës, si dhe versioni specifik i PowerShell që po përdorni aktualisht, gjë që ndihmon për të kuptuar kombinimin e sistemeve në të cilat përdoret.

Një tjetër informacion kyç që dërgohet është vlera e variabli i mjedisit POWERSHELL_DISTRIBUTION_CHANNELKjo tregon kanalin përmes të cilit është instaluar PowerShell (p.sh., paketa zyrtare, depoja, etj.). Kjo vlerë vendoset nga instaluesit dhe përdoruesve u këshillohet të mos e ndryshojnë atë për të shmangur shtrembërimin e metrikave.

Gjithashtu përfshihet Versioni i SDK-së së Informacionit të Aplikacionit e përdorur nga vetë PowerShell, zona e përafërt gjeografike e hostit bazuar në adresën IP, parametrat e kaluar te pwsh pa vlerat e tyre (p.sh., emrat e parametrave, por jo përmbajtjen) dhe politikën efektive të ekzekutimit të seancës fillestare.

Së fundmi, motori gjeneron dy identifikues anonimë: një GUID të rastësishëm për përdorues dhe një GUID tjetër për seancë . Këto nuk janë të dhëna personale të drejtpërdrejta, por identifikues teknikë të përdorur për të grupuar seancat dhe sjelljet pa ekspozuar identitetin e vërtetë.

Telemetria e dërguar gjatë seancës

Pasi seanca të ketë filluar, PowerShell dërgon periodikisht informacion të përgjithshëm të përdorimit për të kuptuar se cilat veçori po përdoren dhe si . Kjo vlen si për konsolën interaktive ashtu edhe për hostet e tjerë që përdorin motorin.

Këto të dhëna përfshijnë, për shembull, numri i herëve që thirret API-ja PowerShell.Create(), lista e moduleve të importuara të Microsoft-it së bashku me versionet e tyre ose numri i moduleve që mbajnë etiketën CrescendoBuiltgjë që ndihmon në identifikimin e përdorimit të mjeteve të caktuara.

Raportohen edhe këto: emrat e veçorive eksperimentale të aktivizuara dhe të çaktivizuaraKjo është shumë e dobishme për të ditur se cilat eksperimente ka në të vërtetë komuniteti në prodhim; përveç kësaj, dërgohet vlera e preferencës. $PSNativeCommandUseErrorActionPreference (e vërtetë, e gabuar ose e pacaktuar) dhe numri i seancave të hapura në distancë.

Një pjesë tjetër interesante është katalogu i nënsisteme të regjistruaraPowerShell tregon emrat e përdorur për nënsistemet e plotësimit automatik (Completion) ose të përgjithshme (general), por nëse emri nuk është në atë listë, ai dërgohet si anonymous për të ruajtur privatësinë.

Së fundmi, numëruesit janë përfshirë në sugjerime të gjeneruara nga CommandNotFound dhe statistikat e përdorimit PowerShellUnsafeAssemblyLoad (duke përfshirë nëse ngarkimi është përfunduar me sukses apo jo), aspekte kyçe për përmirësimin e diagnostikimit dhe sigurisë.

Si të çaktivizoni telemetrinë native të PowerShell

Nëse organizata juaj ka politika të rrepta privatësie, mund të specifikoni që nuk dëshironi që kjo telemetri të dërgohet. PowerShell e bën këtë duke ekspozuar variablin e mjedisit. POWERSHELL_TELEMETRY_OPTOUT, të cilën duhet ta caktoni përpara se të filloni ndonjë seancë.

Vlera e njohur për çaktivizimin e telemetrisë mund të jetë true, yes o 1Çdonjëri prej këtyre varianteve i tregon motorit të mos dërgojë të dhëna përdorimi te Microsoft nga ai proces ose nga proceset fëmijë që trashëgojnë mjedisin.

Është e rëndësishme të kuptoni që ky konfigurim bazohet në variablat e mjedisit , kështu që nëse doni që të jetë i përhershëm, duhet ta përcaktoni atë në fushëveprimin e duhur (përdorues, makinë ose skripte fillimi) para se të nisni PowerShell, jo pas tij.

Nëse keni ndonjë pyetje se si t'i menaxhoni këto variabla, dokumentacioni mbi about_Environment_Variables dhe udhëzuesi i variablave të mjedisit PowerShell do t'ju ndihmojë të zgjidhni qasjen e duhur në varësi të sistemit tuaj operativ.

Gjithashtu, mbani mend se paketat e instaluesit që shpërndajnë PowerShell konfigurojnë automatikisht POWERSHELL_DISTRIBUTION_CHANNEL në mënyrë që të dallohet kanali i instalimit. Kjo variabël përfshihet gjithashtu në telemetri, kështu që nuk duhet të manipulohet manualisht.

Variablat kryesore të mjedisit që ndikojnë në PowerShell

PowerShell i trajton variablat e mjedisit si një lloj të veçantë të dhënash, gjithmonë në formën e vargjeve të tekstit të trashëgueshme nga proceset fëmijë . Kjo i bën ato ideale për kontrollin e opsioneve globale siç janë privatësia, përditësimet ose shtigjet e moduleve.

Vetë motori përcakton një sërë variablash specifike, ndër të cilat dallohen këto: POWERSHELL_TELEMETRY_OPTOUT, POWERSHELL_DISTRIBUTION_CHANNEL, POWERSHELL_UPDATECHECK, PSExecutionPolicyPreference, PSModulePath, PSModuleAnalysisCachePath y PSDisableModuleAnalysisCacheCleanup.

Në Windows , këto variabla mund të vendosen në makinë (sistem), përdorues ose fushëveprimin e procesit . Procesi aktual kombinon automatikisht përkufizimet e makinës dhe përdoruesit, dhe çdo ndryshim që bëni në një seancë ndikon vetëm në atë proces, përveç nëse i bëni ato të përhershme me mjete të tjera.

Për të modifikuar vlerat e nivelit të makinës ose përdoruesit nga PowerShell, do t'ju duhet të përdorni Klasa .NET System.Environment, i cili ekspozon metoda për leximin dhe shkrimin e variablave në ato fusha, me kusht që të keni leje të mjaftueshme për ta bërë këtë.

Mbani në mend se, duke qenë vargje, variablat e mjedisit mund të bashkohen, zbrazen ose fshihen mjaft lehtë, gjë që është shumë e dobishme për skripte komplekse konfigurimi ose automatizim të vendosjes.

Mënyrat për të aksesuar dhe modifikuar variablat e mjedisit në PowerShell

PowerShell ofron disa mënyra për të pyetur dhe modifikuar variablat e mjedisit . Në varësi të asaj që po bëni ( skript i shpejtë , modul kompleks, detyrë administrative), do të dëshironi të përdorni njërën ose tjetrën.

Mënyra më e drejtpërdrejtë është sintaksë e ndryshueshme me parashtesën $Env:që ju lejon të lexoni vlerën e një variabli ose t'i caktoni asaj një vlerë të re sikur të ishte çdo variabël tjetër PowerShell, për shembull $Env:windir o $Env:Foo = "Algo".

Përveç kësaj, mund të përdorni ofruesi i mjedisit (Env:) me cmdlet-et standarde e elementeve (Get-Item, New-Item, Set-Item, Remove-Itemetj.), gjë që ofron një qasje shumë të qëndrueshme për trajtimin e njësive të sistemit të skedarëve.

Në skenarët ku dëshironi të operoni në nivelin e makinës ose përdoruesit, ose të integroheni me kodin .NET, keni metodat [Environment]::GetEnvironmentVariable() y [Environment]::SetEnvironmentVariable()Këto metoda ju lejojnë të zgjidhni në mënyrë të qartë fushëveprimin (Process, User o Machine) në sistemet Windows.

Që nga PowerShell 7.5, ekziston edhe një sjellje specifike: ju mundeni vendosni një variabël në një varg bosh ose në $null për ta zbrazur ose hequr atë nga seanca, duke përdorur ose sintaksën $Env: si përmes Set-Item ose metodat e System.Environment.

Variablat e mjedisit PowerShell që lidhen me telemetrinë dhe sjelljen

Disa veçori të brendshme të PowerShell mbështeten në variablat e mjedisit që veprojnë si flamuj preferencash të trashëgueshme . Kjo ju lejon të rregulloni me imtësi sjelljen e shell-it ose telemetrisë pa pasur nevojë të ndryshoni kodin në çdo skript.

Më i dukshmi është POWERSHELL_TELEMETRY_OPTOUTe cila, siç e kemi parë tashmë, shërben për të çaktivizuar telemetrinë vendase të motorit kur është vendosur në true, yes o 1Që kjo të hyjë në fuqi, duhet të ekzistojë përpara se të fillojë procesi PowerShell.

Një tjetër shumë e rëndësishme është POWERSHELL_DISTRIBUTION_CHANNELKjo fushë, të cilën instaluesit e kanë plotësuar automatikisht që nga PowerShell 7.2 për të treguar se si është instaluar produkti, përfshihet në të dhënat e telemetrisë, kështu që modifikimi manual nuk rekomandohet.

variabël POWERSHELL_UPDATECHECK Kontrollon se si dhe kur shfaqen njoftimet e përditësimit. Pranon vlera të tilla si Off Për të çaktivizuar funksionin, Default për sjellje standarde ose LTS për të marrë njoftime vetëm për versionet e mbështetjes së zgjeruar.

Për më tepër, PSExecutionPolicyPreference pasqyron politikën aktive të ekzekutimit në sesionin aktual kur konfigurohet duke përdorur parametrin -ExecutionPolicy, cmdlet-i Set-ExecutionPolicy me fushëveprim Processose duke e modifikuar drejtpërdrejt variablin. Ky cilësim ndikon veçanërisht te skriptet e shkarkuara ose të pafirmosura në Windows.

Dhe, sigurisht, rruga e kërkimit të modulit kontrollohet me PSModulePath, i cili ruan një listë të ndarë me pikëpresje në Windows ose një listë të ndarë me dy pika në platformat *nix, me vendndodhjet e sistemit dhe të përdoruesit, si dhe shtigjet e shtuara nga instalues ​​të jashtëm.

Analiza e memorjes së përkohshme dhe modulit: rregullim i imët

PowerShell mirëmban një memorje të përkohshme të analizës së moduleve për të shpejtuar kërkimet e komandave dhe për të shmangur inspektimin e vazhdueshëm të të gjitha moduleve të disponueshme në çdo nisje ose kërkim.

Variabli i mjedisit PSModuleAnalysisCachePath Përcaktoni se ku ruhet skedari i memorjes së përkohshme. Si parazgjedhje, ai tregon shtigjet nën $Env:LOCALAPPDATA në Windows ose ~/.cache/powershell Në sistemet jo-Windows, me një emër skedari të ndryshëm për secilin instalim.

Nëse doni ta ndryshoni atë vendndodhje, duhet ta vendosni këtë variabël përpara se të nisni PowerShell , duke treguar një shteg të plotë (duke përfshirë emrin e skedarit) ku procesi ka leje shkrimi. Ndryshimet hyjnë në fuqi vetëm për proceset që fillojnë pas ndryshimit.

Nëse qëllimi juaj është të çaktivizoni plotësisht ruajtjen në memorje të moduleve, mund ta drejtoni shtegun në një destinacion të pashkrueshëm, si p.sh. NUL në Windows ose /dev/null en LinuxPowerShell do të përpiqet të shkruajë memorjen e përkohshme atje, por nuk do të ketë sukses, por gjithashtu nuk do të gjenerojë gabime të dukshme në seancë.

Duke e plotësuar këtë është variabla PSDisableModuleAnalysisCacheCleanupNëse e vendosni në 1Çaktivizon pastrimet automatike që heqin hyrjet e modulit që nuk ekzistojnë më, gjë që është e dobishme në skenarë specifikë ku nuk doni ta prekni atë memorie të përkohshme.

Variabla të tjerë të mjedisit të dobishëm për skriptet dhe telemetrinë

Përtej atyre specifike për PowerShell, ekziston një sërë variablash të mjedisit të sistemit që ndikojnë drejtpërdrejt në mënyrën se si funksionojnë skriptet dhe si sillet terminali , veçanërisht në mjediset ndërplatformore.

variabël PATH Kjo përcakton se në cilat drejtori duhet të kërkohen skedarët ekzekutues, gjë që është thelbësore nëse do të nisni skedarë binare të jashtëm nga skriptet tuaja PowerShell. Në Windows, drejtoritë ndahen nga... ;ndërsa në Linux ose macOS përdoret :.

Ekziston edhe Windows PATHEXTKjo rendit zgjerimet që konsiderohen të ekzekutueshme drejtpërdrejt. Nëse dëshironi që një gjuhë skriptimi të ekzekutohet në të njëjtën konsolë (për shembull, skedarët e skriptimit), mund të përdorni komandën përkatëse. .py), do të duhet të përfshish shtesën këtu dhe ta regjistrosh atë në sistem duke përdorur mjete të tilla si assoc y ftype nga VKM.

Në platformat jo-Windows, PowerShell përshtatet me konventën XDG duke përdorur variabla. XDG_CONFIG_HOME, XDG_DATA_HOME y XDG_CACHE_HOME për shtigjet e konfigurimit, të dhënat dhe memorien e përkohshme, gjë që lehtëson integrimin me pjesën tjetër të sistemit.

Për veçoritë e daljes me ngjyra dhe kontrollin e terminalit, PowerShell 7.2 dhe versionet e mëvonshme respektojnë TERM y NO_COLORSipas vlerës së TERM Sekuencat ANSI çaktivizohen ose rregullohen, dhe nëse ka NO_COLORStili i daljes detyrohet të jetë tekst i thjeshtë pa ngjyra.

Logjet dhe rezultatet e skripteve ndikojnë në pamjen e log-eve dhe rezultateve të skripteve, gjë që ndikon si në përvojën e konsolës ashtu edhe në lexueshmërinë e telemetrisë së kapur kur e ridrejtoni rezultatin në skedarë.

Shembull praktik: Sophia Script dhe cilësimet e privatësisë dhe telemetrisë

Një nga shembujt më të njohur në komunitet për akordimin e Windows 10 me PowerShell është Windows 10 Sophia Script , një grup funksionesh që synojnë automatizimin e konfigurimit, privatësisë dhe çinstalimit të komponentëve të panevojshëm.

Ndër opsionet e saj, Sophia Script përfshin aftësinë për të rregullo privatësinë dhe telemetrinë e sistemit, çaktivizoni detyrat e planifikuara diagnostikuese, çinstaloni OneDrive, ndryshoni rrugën e %TEMP% ose zhvendosni dosjet e përdoruesve si Desktop, Dokumente, ShkarkimeMuzikë, Imazhe ose Video përmes menuve interaktive.

Gjithashtu ofron veçori për të çinstaluar aplikacionet UWP për të gjitha llogaritë duke respektuar një listë përjashtimesh të konfigurueshme përmes formularëve WPF, si dhe duke çaktivizuar veçoritë e Windows ose duke hequr aftësitë e sistemit me magjistarë vizualë.

Një tjetër veçori interesante është se mund të krijoni detyra në Planifikuesin e Detyrave për pastrim periodik, të rregulloni menynë Start (duke fiksuar ose hequr artikujt), të manipuloni opsionet e sigurisë së Microsoft Defender, siç janë qasja e kontrolluar ose përjashtimet e dosjeve, dhe të rifreskoni ikonat, variablat e mjedisit dhe shiritin e detyrave pa e rinisur Explorer-in.

Shkurt, ky lloj skripti tregon se si, duke kombinuar PowerShell me konfigurimet e telemetrisë, variablat e mjedisit dhe automatizimin, sjellja e një sistemi Windows mund të modelohet plotësisht për ta përshtatur atë me politikat ose preferencat personale të një organizate.

Dërgoni telemetrinë nga PowerShell te Application Insights

Përtej telemetrisë vendase të PowerShell, shumë aplikacione dërgojnë të dhënat e tyre të monitorimit te Azure Monitor Application Insights . Megjithatë, ndonjëherë, hapni portalin Azure dhe grafikët duken bosh ose u mungojnë të dhëna kyçe.

Shkaqet tipike janë zakonisht gabimet e konfigurimit të agjentit SDK ose Application Insights, bllokimet e rrjetit në pika e gëlltitjes, kufizim ose përjashtim i telemetrisë në proces, incidente specifike të Analitikës së Logut ose probleme me pyetjet në API api.applicationinsights.io.

Një qasje shumë praktike për të izoluar burimin e problemit është dërgimi manual i një regjistri të vetëm të telemetrisë së testimit nga PowerShell ose curl. Nëse ai regjistër arrin me sukses në tabelën e regjistrit të burimeve të Application Insights, ju e dini që një pjesë e madhe e tubacionit po funksionon.

Kur testoni nga e njëjta makinë ose nga i njëjti mjedis ku ekzekutohet aplikacioni juaj (për shembull, VM ose App Service), verifikoni gjithashtu që DNS, firewall, TLS dhe lejet nuk po bllokojnë rrugën drejt gëlltitjes.

Në skenarët ku pika e marrjes është e mbrojtur me një Microsoft Entra ID (më parë Azure AD), duhet të siguroheni që aplikacioni ose skripti të autentifikohet saktë me Entra ID; përndryshe, telemetria do të refuzohet edhe nëse pjesa tjetër e instrumenteve duket e saktë.

Skripti PowerShell për të testuar disponueshmërinë e telemetrisë

Për të verifikuar që i gjithë qarku nga makina juaj te Application Insights po funksionon, mund të përdorni një skript PowerShell që dërgon një rezultat testi të disponueshmërisë . Ky lloj telemetrie është ideal sepse nuk i nënshtrohet mekanizmave të marrjes së mostrave.

Ideja është e thjeshtë: ju ofroni një zinxhir lidhjeje ose një çelës instrumenteshSkripti e zbërthen atë për të nxjerrë pikën e marrjes dhe InstrumentationKey, gjeneron një JSON me një AvailabilityData si shembull dhe e dërgon atë me Invoke-WebRequest në pikën fundore përkatëse REST.

Nëse kaloni vetëm çelësin e instrumentimit, skripti ndërton një varg lidhjeje me pikë fundore globale https://dc.services.visualstudio.com/Nëse e kaloni të gjithë vargun e lidhjes, do të përdoret pika rajonale e gëlltitjes e përcaktuar në të, dhe nëse i kaloni të dyja, mbizotëron ajo e përcaktuar në vargun e lidhjes.

Gjatë ekzekutimit, një Vula kohore në formatin UTC ISO 8601Trupi i JSON-it mbushet me të dhënat e testimit (kohëzgjatja, vendndodhja, mesazhi, vetitë shtesë) dhe kërkesa POST dërgohet. Përgjigja HTTP 200 me itemsReceived e barabartë me itemsAccepted tregon se pika e marrjes e ka marrë dhe pranuar të dhënat.

Pastaj, thjesht shkoni te skeda Logs e burimit Application Insights në portalin Azure, ekzekutoni një pyetje për llojin përkatës dhe kontrolloni nëse shfaqet regjistri shembullor. Nëse shfaqet, e dini që problemi ka shumë të ngjarë të jetë me SDK-në ose agjentin që përdor aplikacioni juaj aktual.

Testoni telemetrinë me curl në Linux ose Windows

Nëse mjedisi nga i cili dëshironi të testoni është Linux ose macOS, ose nëse preferoni të përdorni mjete standarde në vend të PowerShell, mund të kryeni të njëjtin test me curl duke dërguar një kërkesë POST me përmbajtje JSON në pikën fundore të Application Insights.

Në këto raste, ju krijoni një trup të ngjashëm JSON, me baseType e barabartë me AvailabilityDataIdentifikuesi i ekzekutimit, emri i testit, kohëzgjatja, treguesi i suksesit, vendndodhja, mesazhi dhe vetitë opsionale. Mos harroni të rregulloni gjithmonë campo time te një markë e kohëve të funditsepse Application Insights përthith të dhëna më të vjetra se 48 orë.

Për Linux ose macOS, komanda zakonisht përfshin kokë Content-Type: application/json, metoda POST, JSON-i i integruar dhe URL-ja e pikës së marrjes (për shembull https://dc.applicationinsights.azure.com/v2.1/trackNë Windows, sintaksa ndryshon pak sepse duhet të përdorni thonjëza në JSON kur e kaloni atë si argument.

Pasi të keni mbaruar këtë, kontrolloni përsëri përgjigjen HTTP dhe, nëse është e saktë, shkoni te regjistrat e Application Insights për të vërtetuar që telemetria juaj e testimit tani është ruajtur dhe e pyetshme, njësoj siç ishte me skriptin PowerShell.

Kjo qasje ju lejon të përjashtoni shpejt problemet e konfigurimit të SDK-së, duke u përqendruar në politikat e rrjetit, DNS-it, TLS-së, vërtetimit të pikës fundore ose marrjes së mostrave bazuar në simptomat që shihni në përgjigje.

Skripti PowerShell për të testuar telemetrinë e kërkesës

Përveç testimit të disponueshmërisë, shpesh do të jeni të interesuar të kontrolloni telemetrinë e kërkesës HTTP , veçanërisht kur panelet tuaja bazohen në metrikat e kërkesave hyrëse nga një API ose aplikacion web.

Për ta bërë këtë, mund të përdorni një skript tjetër PowerShell shumë të ngjashëm me atë të disponueshmërisë, por këtë herë duke gjeneruar një JSON me baseType e barabartë me RequestDataZakonisht përfshihen fusha të tilla si identifikuesi i kërkesës dhe emri i operacionit (për shembull). GET /ruta/prueba/), koha e fillimit, kohëzgjatja, URL-ja, kodi i përgjigjes dhe metoda HTTP.

Skripti ndjek të njëjtën mekanikë: ai zbërthen vargun e lidhjes ose çelësin e instrumentimit, ndërton URL-në e gëlltitjes (v2/track), llogarit kohën aktuale në UTC, mbledh JSON-in dhe ekzekuton Invoke-WebRequest duke përdorur metodën POSTNëse merrni kodin 200 dhe përmbajtjen e pritur në përgjigje, pjesa e gëlltitjes po funksionon.

Ja një pikë e rëndësishme: kërkesat mund të ndikohen nga mekanizmat e marrjes së mostrave nga serveri . Nëse e keni konfiguruar marrjen e mostrave për të zvogëluar vëllimin e të dhënave, mund të mos i shihni të gjitha kërkesat e testimit përveç nëse e çaktivizoni përkohësisht ose rregulloni përqindjet.

Pasi të shfaqet regjistri i testimit në Application Insights, hapi tjetër është të përqendroheni në mënyrën se si instrumentohet kodi juaj (SDK, filtra, marrje mostrash, përjashtime, etj.) për të kuptuar pse kërkesat reale nuk regjistrohen aq lehtë sa testet manuale.

Probleme të zakonshme SSL/TLS gjatë dërgimit të telemetrisë

Nuk është e pazakontë të hasni gabime që lidhen me SSL ose TLS gjatë shtrëngimit të dorës kur ekzekutoni këto skripte testimi , veçanërisht në mjedise të kufizuara ose kur proksitë e korporatave po inspektojnë trafikun.

Shumë shërbime Azure, duke përfshirë Application Insights, kërkojnë të paktën TLS 1.2 dhe grupe specifike të shifrave për të pranuar lidhje. Nëse sistemi ose aplikacioni juaj vazhdon të përdorë TLS 1.0 ose 1.1 si parazgjedhje, lidhja mund të dështojë edhe para se serveri të përpunojë JSON-in.

PowerShell ju lejon të detyroni protokollet e mbështetura duke vendosur [System.Net.ServicePointManager]::SecurityProtocol para ekzekutimit Invoke-WebRequestMund të provoni SSL3, TLS, TLS 1.1, TLS 1.2 ose TLS 1.3 për të parë se çfarë funksionon në mjedisin tuaj, megjithëse në prodhim rekomandohet t'i përmbaheni asaj që përcaktojnë udhëzimet e sigurisë.

Nëse keni edhe proxy ose firewall-e që kryejnë inspektim SSL, validimi i certifikatës mund të dështojë. Mund ta çaktivizoni verifikimin e certifikatës duke krijuar një politikë të personalizuar që kthen gjithmonë vlerën e vërtetë, por kjo duhet të përdoret vetëm për diagnostikim dhe kurrë si një zgjidhje e përhershme.

Kur duhet të ndryshoni versionet parazgjedhur të TLS të përdorura nga aplikacionet .NET në Windows, është më mirë të ndiqni rekomandimet zyrtare të konfigurimit të TLS në Regjistër dhe në vetë framework-un, në vend që të futni ndërhyrje të shpërndara në skripte.

Gabime autentifikimi me Microsoft. Futni ID-në në Application Insights.

Nëse burimi juaj i Application Insights është konfiguruar për të pranuar vetëm autentifikim nëpërmjet Microsoft Entra ID (më parë Azure AD), telemetria e dërguar me një çelës instrumentesh pa kredenciale të vlefshme do të refuzohet me gabime të qarta HTTP.

Një gabim HTTP 400 me një mesazh që tregon se autentifikimi klasik nuk mbështetet zakonisht do të thotë që burimi është shënuar vetëm si Entra ID, por SDK ose skripti po thërret API-në e trashëguar. Në atë rast, duhet të kontrolloni konfigurimin e SDK-së dhe vargun e lidhjes së përdorur.

Një gabim HTTP 401 "Kërkohet autorizim" tregon se SDK po përpiqet të përdorë Entra ID, por nuk mund të marrë një token të vlefshëm; kjo mund të ndodhë sepse identiteti i menaxhuar nuk është aktivizuar, sepse mungojnë kredencialet ose për shkak të problemeve me Azure Identity në klient.

Kodi HTTP 403 "I paautorizuar" tregon se është marrë një token, por identiteti i përdorur nuk ka leje të mjaftueshme në burimin ose abonimin e Application Insights. Në këtë rast, duhet të rishikoni kontrollin e aksesit dhe të siguroheni që identiteti të ketë, të paktën, rolin e Publikuesit të Metrikave të Monitorimit.

Në varësi të gjuhës (Node.js, Python , etj.), këshillohet të aktivizoni regjistrimin e brendshëm të SDK-së ose regjistrimet e Azure Identity për të parë saktësisht se cila fazë e autentifikimit po dështon dhe me çfarë mesazhi.

Telemetria, skriptet dhe praktikat më të mira në mjedise të botës reale

Të gjitha sa më sipër nënkuptojnë që, kur doni të shtoni telemetri në skripte në PowerShell , keni dy nivele për të menaxhuar: nga njëra anë, telemetrinë automatike të vetë motorit, dhe nga ana tjetër, telemetrinë e qartë që ju dërgoni në sisteme të tilla si Application Insights ose destinacione të tjera.

Në nivelin vendas, është thelbësore të dish se si funksionon POWERSHELL_TELEMETRY_OPTOUT, çfarë të dhënash mblidhen në fillim dhe gjatë seancës, dhe si ndryshohen variabla të tilla si POWERSHELL_DISTRIBUTION_CHANNEL o POWERSHELL_UPDATECHECK për të kontrolluar sjelljen globale.

Për sa i përket skripteve tuaja, mund të përfitoni nga variablat e mjedisit, ofruesi Env:, metodat e System.Environment dhe mjete si Sophia Script për Rregulloni politikat e privatësisë, rrugëve, memorjes së përkohshme dhe ekzekutimit, ndërsa ju zbatoni proceset tuaja për të dërguar metrika dhe regjistra te shërbimet e jashtme.

Duke kombinuar testimin manual të telemetrisë me PowerShell dhe curl, monitorimin e protokolleve TLS dhe rregullimin e imët të autentifikimit me Microsoft Entra ID, është e mundur të keni një kanal telemetrie të fuqishëm dhe të besueshëm edhe në mjedise korporative shumë të kontrolluara.

Kur e kuptoni se si është orkestruar e gjithë kjo shtresë telemetrie, nga variablat e mjedisit deri te përthithja e reve kompjuterike, bëhet shumë më e lehtë të vendosni se cilat leva të përdorni nëse një ditë grafikët ose regjistrat tuaj të Azure ndalojnë në mënyrë misterioze përditësimin.