Telemetrija u PowerShellu: varijable, privatnost i prijenos podataka

Ako svakodnevno radite s PowerShellom i počnete čuti o telemetriji u skriptama i sesijama , normalno je da imate pitanja: koji se podaci šalju, kamo idu, kako ih onemogućiti ili čak kako sami koristiti tu telemetriju za otklanjanje pogrešaka ili praćenje vlastitih skripti. Sve to postaje još važnije kada radite u korporativnom okruženju ili rukujete osjetljivim informacijama.

U sljedećim retcima vidjet ćete, prilično detaljno i najjednostavnijim mogućim jezikom, kako funkcionira telemetrija povezana s PowerShellom , kakvu ulogu igraju varijable okruženja, kako se možete isključiti iz sudjelovanja, kako ručno slati telemetriju (na primjer u Application Insights) pomoću PowerShella ili Curla te koji tipični problemi s mrežom, TLS-om ili autentifikacijom mogu uzrokovati nedostatak podataka na vašim nadzornim pločama.

Koju telemetriju PowerShell šalje izvorno?

PowerShell, u svojim modernim verzijama, uključuje vlastiti mehanizam za slanje osnovnih podataka o korištenju tvrtki Microsoft putem Application Insightsa. Ne govorimo o kodu koji pišete, već o samom PowerShell mehanizmu kada se binarna datoteka izvršava. pwsh.

Ova telemetrija pomaže Microsoftu da bolje razumije kako se PowerShell koristi (verzije, platforme, moduli itd.) i da odredi prioritete za nove značajke ili ispravke programskih pogrešaka. Prije slanja, informacije se anonimiziraju i agregiraju tako da se korisnik ne može izravno identificirati.

Postoje dva ključna trenutka kada se podaci prikupljaju: na početku sesije i periodično tijekom izvršavanja . Razumijevanje ovog ponašanja ključno je ako želite maksimalnu kontrolu nad onim što se dijeli iz vaših okruženja.

Nadalje, motor šalje ovu telemetriju samo kada pokrenete pwsh standardno; ako je PowerShell ugrađen kao mehanizam u drugu host aplikacijuTa početna telemetrija se ne generira.

Podaci poslani prilikom pokretanja pwsh-a

Kada sesija započne s pwshMotor prikuplja mali, ali vrlo specifičan skup informacija o okolišu koje se šalju samo jednom čizmaIzmeđu ostalog, zabilježeno je sljedeće: operativni sustav i detalji instalacije iz PowerShell-a.

Ovo pokretanje uključuje podatke kao što su proizvođač operativnog sustava, naziv i verzija platforme, kao i specifična verzija PowerShella koju trenutno koristite, što pomaže u razumijevanju kombinacije sustava na kojima se koristi.

Još jedna ključna informacija koja se šalje je vrijednost varijabla okoline POWERSHELL_DISTRIBUTION_CHANNELOvo označava kanal putem kojeg je PowerShell instaliran (npr. službeni paket, repozitorij itd.). Ovu vrijednost postavljaju instalateri, a korisnicima se savjetuje da je ne mijenjaju kako bi izbjegli iskrivljavanje metrike.

Također je uključeno Verzija Application Insights SDK-a koje koristi sam PowerShell, približno geografsko područje hosta na temelju IP adrese, parametri proslijeđeni pwsh bez njihovih vrijednosti (tj. nazivi parametara, ali ne i sadržaj) i efektivna politika izvršavanja početne sesije.

Konačno, mehanizam generira dva anonimna identifikatora: slučajni GUID po korisniku i još jedan GUID po sesiji . To nisu izravni osobni podaci, već tehnički identifikatori koji se koriste za grupiranje sesija i ponašanja bez otkrivanja stvarnog identiteta.

Telemetrija poslana tijekom sesije

Nakon što je sesija u tijeku, PowerShell periodički šalje agregirane podatke o korištenju kako bi razumio koje se značajke koriste i kako . To se odnosi i na interaktivnu konzolu i na druge hostove koji pokreću mehanizam.

Ti podaci uključuju, na primjer, broj poziva API-ja PowerShell.Create(), popis uvezenih Microsoftovih modula zajedno s njihovim verzijama ili broj modula koji nose oznaku CrescendoBuiltšto pomaže u prepoznavanju upotrebe određenih alata.

Također se izvještava o sljedećem: nazivi uključenih i isključenih eksperimentalnih značajkiOvo je vrlo korisno za saznanje koje eksperimente zajednica zapravo ima u produkciji; osim toga, šalje se i vrijednost preferencije. $PSNativeCommandUseErrorActionPreference (true, false ili nije postavljeno) i broj otvorenih udaljenih sesija.

Još jedan zanimljiv dio je katalog registrirani podsustaviPowerShell označava nazive koji se koriste za podsustave automatskog dovršavanja (Completion) ili općenito (general), ali ako ime nije na tom popisu, šalje se kao anonymous radi očuvanja privatnosti.

Konačno, brojači su uključeni prijedloge generirane od strane CommandNotFound i statistike korištenja PowerShellUnsafeAssemblyLoad (uključujući je li učitavanje uspješno završeno ili ne), ključni aspekti za poboljšanje dijagnostike i sigurnosti.

Kako onemogućiti izvornu PowerShell telemetriju

Ako vaša organizacija ima stroge politike privatnosti, možete odrediti da ne želite da se ova telemetrija šalje. PowerShell to čini izlaganjem varijable okruženja. POWERSHELL_TELEMETRY_OPTOUT, što morate postaviti prije početka bilo koje sesije.

Prepoznata vrijednost za onemogućavanje telemetrije može biti true, yes o 1Bilo koja od ovih varijanti govori engineu da ne šalje podatke o korištenju Microsoftu iz tog procesa ili iz podređenih procesa koji nasljeđuju okruženje.

Važno je razumjeti da se ova konfiguracija temelji na varijablama okruženja , pa ako želite da bude trajna, morate je definirati u odgovarajućem opsegu (korisnik, računalo ili skripte za pokretanje) prije pokretanja PowerShella, a ne nakon toga.

Ako imate bilo kakvih pitanja o tome kako upravljati tim varijablama, dokumentacija o about_Environment_Variables i vodič za varijable okruženja PowerShella pomoći će vam da odaberete pravi pristup ovisno o vašem operativnom sustavu.

Također, imajte na umu da instalacijski paketi koji distribuiraju PowerShell automatski konfiguriraju POWERSHELL_DISTRIBUTION_CHANNEL kako bi se razlikovao instalacijski kanal. Ova varijabla je također uključena u telemetriju, stoga se ne smije ručno manipulirati.

Ključne varijable okruženja koje utječu na PowerShell

PowerShell tretira varijable okruženja kao poseban tip podataka, uvijek u obliku tekstualnih nizova koje nasljeđuju podređeni procesi . To ih čini idealnim za kontrolu globalnih opcija kao što su privatnost, ažuriranja ili putanje modula.

Sam motor definira niz specifičnih varijabli, među kojima se ističu sljedeće: POWERSHELL_TELEMETRY_OPTOUT, POWERSHELL_DISTRIBUTION_CHANNEL, POWERSHELL_UPDATECHECK, PSExecutionPolicyPreference, PSModulePath, PSModuleAnalysisCachePath y PSDisableModuleAnalysisCacheCleanup.

U sustavu Windows , ove varijable mogu se nalaziti na stroju (sustavu), korisniku ili u opsegu procesa . Trenutni proces automatski kombinira definicije stroja i korisnika, a sve promjene koje napravite u sesiji utječu samo na taj proces osim ako ih ne učinite trajnima na drugi način.

Za izmjenu vrijednosti na razini računala ili korisnika iz PowerShella, morat ćete koristiti .NET klasa System.Environment, što otkriva metode za čitanje i pisanje varijabli u tim opsegima, pod uvjetom da imate dovoljna dopuštenja za to.

Imajte na umu da se, budući da su stringovi, varijable okruženja mogu prilično lako spajati, prazniti ili brisati , što je vrlo korisno za složene konfiguracijske skripte ili automatizaciju implementacije.

Načini pristupa i izmjene varijabli okruženja u PowerShellu

PowerShell nudi nekoliko načina za upite i izmjenu varijabli okruženja . Ovisno o tome što radite ( brzi skript , složeni modul, administrativni zadatak), htjet ćete koristiti jedan ili drugi.

Najizravniji način je sintaksa varijable s prefiksom $Env:što vam omogućuje čitanje vrijednosti varijable ili dodjeljivanje nove vrijednosti kao da je riječ o bilo kojoj drugoj PowerShell varijabli, na primjer $Env:windir o $Env:Foo = "Algo".

Osim toga, možete koristiti pružatelj usluga okruženja (Env:) sa standardnim cmdletima elemenata (Get-Item, New-Item, Set-Item, Remove-Itemitd.), što daje vrlo dosljedan pristup obradi jedinica datotečnog sustava.

U scenarijima gdje želite raditi na razini stroja ili korisnika ili se integrirati s .NET kodom, imate metode [Environment]::GetEnvironmentVariable() y [Environment]::SetEnvironmentVariable()Ove metode vam omogućuju eksplicitan odabir opsega (Process, User o Machine) u Windows sustavima.

Od verzije PowerShella 7.5, postoji i specifično ponašanje: možete postaviti varijablu na prazan niz ili na $null isprazniti ili ukloniti iz sesije, koristeći sintaksu $Env: kao kroz Set-Item ili metode System.Environment.

Varijable okruženja PowerShella povezane s telemetrijom i ponašanjem

Nekoliko internih značajki PowerShella oslanja se na varijable okruženja koje djeluju kao nasljedne zastavice preferencija . To vam omogućuje fino podešavanje ponašanja ljuske ili telemetrije bez potrebe za promjenom koda u svakoj skripti.

Najočitiji je POWERSHELL_TELEMETRY_OPTOUTšto, kao što smo već vidjeli, služi za onemogućavanje izvorne telemetrije motora kada je postavljena na true, yes o 1Da bi ovo stupilo na snagu, mora postojati prije pokretanja PowerShell procesa.

Još jedna vrlo važna je POWERSHELL_DISTRIBUTION_CHANNELOvo polje, koje instalateri automatski popunjavaju od verzije PowerShell 7.2 kako bi naznačili kako je proizvod instaliran, uključeno je u telemetrijske podatke, stoga se ne preporučuje ručna izmjena.

varijabla POWERSHELL_UPDATECHECK Kontrolira kako i kada se prikazuju obavijesti o ažuriranjima. Prihvaća vrijednosti kao što su Off Za onemogućavanje funkcije, Default za standardno ponašanje ili LTS primati obavijesti samo za verzije s proširenom podrškom.

Nadalje, PSExecutionPolicyPreference odražava aktivnu politiku izvršavanja u trenutnoj sesiji kada je konfigurirana pomoću parametra -ExecutionPolicy, cmdlet Set-ExecutionPolicy s opsegom Processili izravnim uređivanjem varijable. Ova postavka posebno utječe na preuzete ili nepotpisane skripte u sustavu Windows.

I, naravno, put pretraživanja modula kontrolira se pomoću PSModulePath, koji pohranjuje popis odvojen točka-zarezom u Windowsima ili popis odvojen dvotočkama na *nix platformama, s lokacijama sustava i korisnika, pa čak i putanjama koje dodaju vanjski instalateri.

Analiza predmemorije i modula: fino podešavanje

PowerShell održava predmemoriju za analizu modula kako bi ubrzao pretraživanje naredbi i izbjegao stalnu provjeru svih dostupnih modula pri svakom pokretanju ili pretraživanju.

Varijabla okoline PSModuleAnalysisCachePath Definirajte gdje se pohranjuje ta datoteka predmemorije. Prema zadanim postavkama, ona pokazuje na putanje ispod $Env:LOCALAPPDATA na Windows ili ~/.cache/powershell Na sustavima koji nisu Windows, s različitim nazivom datoteke za svaku instalaciju.

Ako želite promijeniti tu lokaciju, morate postaviti ovu varijablu prije pokretanja PowerShella , pokazujući na punu putanju (uključujući naziv datoteke) gdje proces ima dozvole za pisanje. Promjene stupaju na snagu samo za procese koji se pokreću nakon promjene.

Ako vam je cilj potpuno onemogućiti keširanje modula, možete usmjeriti put do odredišta u koje se ne može pisati, kao što je NUL na Windows ili /dev/null en LinuxPowerShell će pokušati tamo zapisati predmemoriju, neće uspjeti, ali također neće generirati nikakve vidljive pogreške u sesiji.

To nadopunjuje varijabla PSDisableModuleAnalysisCacheCleanupAko ga postavite na 1Onemogućuje automatsko čišćenje koje uklanja unose modula koji više ne postoje, što je korisno u određenim scenarijima gdje ne želite dirati tu predmemoriju.

Ostale varijable okruženja korisne za skripte i telemetriju

Osim onih specifičnih za PowerShell, postoji skup varijabli sistemskog okruženja koje izravno utječu na način izvođenja skripti i ponašanje terminala , posebno u okruženjima s više platformi.

varijabla PATH Ovo određuje u kojim direktorijima treba tražiti izvršne datoteke, što je ključno ako ćete pokretati vanjske binarne datoteke iz svojih PowerShell skripti. U sustavu Windows, direktoriji su odvojeni... ;dok se u Linuxu ili macOS-u koristi :.

Windows također postoji PATHEXTOvdje su navedena proširenja koja se smatraju izravno izvršnima. Ako želite da se skriptni jezik izvršava u istoj konzoli (na primjer, skriptne datoteke), možete upotrijebiti odgovarajuću naredbu. .py), morat ćete ovdje uključiti ekstenziju i registrirati je u sustavu pomoću alata kao što su assoc y ftype od CMD.

Na platformama koje nisu Windows, PowerShell se prilagođava XDG konvenciji koristeći varijable. XDG_CONFIG_HOME, XDG_DATA_HOME y XDG_CACHE_HOME za konfiguracijske staze, podatke i predmemoriju, što olakšava integraciju s ostatkom sustava.

Za značajke ispisa boja i kontrolu terminala, poštuju se PowerShell 7.2 i noviji TERM y NO_COLORPrema vrijednosti TERM ANSI sekvence su onemogućene ili prilagođene, a ako postoji NO_COLORIzlazni stil je prisiljen na običan tekst bez boje.

Zapisnici i izlazi skripti utječu na izgled zapisnika i izlaza skripti, što utječe i na iskustvo konzole i na čitljivost snimljene telemetrije kada preusmjerite izlaz u datoteke.

Praktični primjer: Sophia Script i postavke privatnosti i telemetrije

Jedan od najpoznatijih primjera u zajednici za podešavanje Windowsa 10 pomoću PowerShella je Windows 10 Sophia Script , skup funkcija usmjerenih na automatizaciju konfiguracije, privatnosti i deinstalacije nepotrebnih komponenti.

Među svojim opcijama, Sophia Script uključuje mogućnost prilagodite privatnost sustava i telemetriju, onemogućiti zakazane dijagnostičke zadatke, deinstalirati OneDrive, promijeniti putanju %TEMP% ili premjestiti korisničke mape kao što su Radna površina, Dokumenti, PreuzimanjaGlazba, slike ili videozapisi putem interaktivnih izbornika.

Također nudi značajke za deinstalaciju UWP aplikacija za sve račune uz poštivanje konfiguriranog popisa izuzeća putem WPF obrazaca, kao i onemogućavanje značajki sustava Windows ili uklanjanje sistemskih mogućnosti pomoću vizualnih čarobnjaka.

Još jedna zanimljiva značajka je da možete stvarati zadatke u Rasporedu zadataka za periodično čišćenje, prilagođavati izbornik Start (prikvačivanjem ili otkvačivanjem stavki), manipulirati sigurnosnim opcijama Microsoft Defendera kao što su kontrolirani pristup mapama ili izuzeća te osvježavati ikone, varijable okruženja i traku zadataka bez ponovnog pokretanja Explorera.

Ukratko, ova vrsta skripte pokazuje kako se, kombiniranjem PowerShella s konfiguracijama telemetrije, varijablama okruženja i automatizacijom, ponašanje Windows sustava može u potpunosti modelirati kako bi se prilagodilo pravilima organizacije ili osobnim preferencijama.

Slanje telemetrije iz PowerShella u Application Insights

Osim izvorne telemetrije PowerShella, mnoge aplikacije šalju vlastite podatke praćenja u Azure Monitor Application Insights . Međutim, ponekad se, kada otvorite Azure portal, grafikoni čine praznima ili im nedostaju ključni zapisi.

Tipični uzroci su obično pogreške u konfiguraciji SDK-a ili Application Insights agenta, mrežne blokade točka gutanja, ograničenje ili isključenje telemetrije u cjevovodu, specifični incidenti Log Analyticsa ili problemi s upitima API-ju api.applicationinsights.io.

Vrlo praktičan pristup izoliranju izvora problema je ručno slanje jednog testnog telemetrijskog zapisnika iz PowerShella ili Curla. Ako taj zapisnik uspješno stigne do tablice zapisnika resursa Application Insights, znate da veliki dio cjevovoda radi.

Kada testirate s istog računala ili okruženja u kojem se vaša aplikacija izvodi (na primjer, virtualni stroj ili usluga aplikacija), također provjeravate da DNS, vatrozid, TLS i dozvole ne blokiraju put do unosa.

U scenarijima gdje je točka unosa zaštićena Microsoft Entra ID-om (ranije Azure AD), morate osigurati da se aplikacija ili skripta ispravno autentificira s Entra ID-om; u suprotnom će telemetrija biti odbijena čak i ako ostatak instrumentacije izgleda ispravno.

PowerShell skripta za testiranje telemetrije dostupnosti

Da biste provjerili radi li cijeli krug od vašeg računala do Application Insightsa, možete koristiti PowerShell skriptu koja šalje rezultat testa dostupnosti . Ova vrsta telemetrije idealna je jer nije podložna mehanizmima uzorkovanja.

Ideja je jednostavna: vi pružate lanac za povezivanje ili ključ za instrumentacijuSkripta ga rastavlja kako bi izdvojila točku unosa i InstrumentationKey, generira JSON s AvailabilityData kao primjer i šalje ga s Invoke-WebRequest do odgovarajuće REST krajnje točke.

Ako proslijedite samo ključ instrumentacije, skripta gradi niz za povezivanje s globalna krajnja točka https://dc.services.visualstudio.com/Ako proslijedite cijeli niz za povezivanje, koristit će se regionalna točka unosa definirana u njemu, a ako proslijedite obje, prevladava ona definirana u nizu za povezivanje.

Tijekom izvršenja, a Vremenska oznaka u UTC ISO 8601 formatuJSON tijelo se popunjava testnim podacima (trajanje, lokacija, poruka, dodatna svojstva) i šalje se POST zahtjev. HTTP 200 odgovor s itemsReceived jednak itemsAccepted označava da je mjesto prijema primilo i prihvatilo zapis.

Zatim jednostavno idite na karticu Zapisnici resursa Application Insights na Azure portalu, pokrenite upit za relevantnu vrstu i provjerite pojavljuje li se primjer zapisnika. Ako se pojavi, znate da je problem najvjerojatnije u SDK -u ili agentu kojeg vaša stvarna aplikacija koristi.

Testiranje telemetrije s Curlom na Linuxu ili Windowsima

Ako je okruženje iz kojeg želite testirati Linux ili macOS ili ako radije koristite standardne alate umjesto PowerShella, isti test možete provesti s curlom slanjem POST zahtjeva s JSON sadržajem krajnjoj točki Application Insights.

U tim slučajevima kreirate slično JSON tijelo, s baseType jednak AvailabilityDataIdentifikator izvršenja, naziv testa, trajanje, indikator uspjeha, lokacija, poruka i opcionalna svojstva. Ne zaboravite uvijek prilagoditi polje time za nedavni brendjer Application Insights unosi podatke starije od 48 sati.

Za Linux ili macOS, naredba obično uključuje glava Content-Type: application/json, POST metoda, ugrađeni JSON i URL točke unosa (na primjer https://dc.applicationinsights.azure.com/v2.1/track). U sustavu Windows, sintaksa se malo mijenja jer morate izbjeći navodnike u JSON-u kada ga prosljeđujete kao argument.

Nakon što je to učinjeno, ponovno provjeravate HTTP odgovor i, ako je točan, idete u zapisnike Application Insights kako biste potvrdili da je vaša testna telemetrija sada pohranjena i da se može upitati, baš kao što je bilo s PowerShell skriptom.

Ovaj pristup vam omogućuje brzo isključivanje problema s konfiguracijom SDK-a, fokusirajući se na mrežu, DNS, TLS, autentifikaciju krajnjih točaka ili pravila uzorkovanja na temelju simptoma koje vidite u odgovoru.

PowerShell skripta za testiranje telemetrije zahtjeva

Osim testiranja dostupnosti, često će vas zanimati i provjera telemetrije HTTP zahtjeva , posebno kada se vaše nadzorne ploče temelje na metrikama dolaznih zahtjeva iz API-ja ili web aplikacije.

Za to možete koristiti drugu PowerShell skriptu vrlo sličnu onoj za dostupnost, ali ovaj put generirajući JSON s baseType jednak RequestDataObično su uključena polja kao što su identifikator zahtjeva i naziv operacije (na primjer). GET /ruta/prueba/), vrijeme početka, trajanje, URL, kod odgovora i HTTP metoda.

Skripta slijedi istu mehaniku: rastavlja niz za povezivanje ili ključ instrumentacije, konstruira URL za unos (v2/track), izračunava trenutno vrijeme u UTC-u, sastavlja JSON i izvršava Invoke-WebRequest korištenjem POST metodeAko dobijete kod 200 i očekivani sadržaj u odgovoru, dio za unos radi.

Evo važne točke: na zahtjeve doista mogu utjecati mehanizmi uzorkovanja na strani poslužitelja . Ako ste konfigurirali uzorkovanje za smanjenje količine podataka, možda nećete vidjeti sve zahtjeve za testiranje osim ako ga privremeno ne onemogućite ili ne prilagodite postotke.

Nakon što se vaš testni zapisnik pojavi u Application Insights, sljedeći je korak usredotočiti se na to kako je vaš kod instrumentaliziran (SDK, filtri, uzorkovanje, izuzeća itd.) kako biste shvatili zašto se stvarni zahtjevi ne zapisuju tako lako kao ručni testovi.

Uobičajeni problemi s SSL/TLS-om prilikom slanja telemetrije

Nije neuobičajeno naići na pogreške povezane s SSL-om ili TLS-om tijekom rukovanja prilikom pokretanja ovih testnih skripti , posebno u ograničenim okruženjima ili kada korporativni proxyji pregledavaju promet.

Mnoge Azure usluge, uključujući Application Insights, zahtijevaju barem TLS 1.2 i određene pakete šifriranja za prihvaćanje veza. Ako vaš sustav ili aplikacija nastavi koristiti TLS 1.0 ili 1.1 prema zadanim postavkama, veza može propasti čak i prije nego što poslužitelj obradi JSON.

PowerShell vam omogućuje prisilno korištenje podržanih protokola postavljanjem [System.Net.ServicePointManager]::SecurityProtocol prije izvršenja Invoke-WebRequestMožete isprobati SSL3, TLS, TLS 1.1, TLS 1.2 ili TLS 1.3 kako biste vidjeli što funkcionira u vašem okruženju, iako se u produkciji preporučuje pridržavanje sigurnosnih smjernica.

Ako imate i proxyje ili vatrozidove koji vrše SSL inspekciju, provjera valjanosti certifikata može propasti. Provjeru certifikata možete onemogućiti stvaranjem prilagođene politike koja uvijek vraća vrijednost "true", ali to bi se trebalo koristiti samo u dijagnostičke svrhe, a ne kao trajno rješenje.

Kada trebate promijeniti zadane TLS verzije koje koriste .NET aplikacije na Windowsima, najbolje je slijediti službene preporuke za konfiguraciju TLS-a u Registru i samom okviru, umjesto uvođenja raštrkanih hakova u skripte.

Pogreške autentifikacije s Microsoftom. Unesite ID u Application Insights.

Ako je vaš resurs Application Insights konfiguriran da prihvaća samo autentifikaciju putem Microsoft Entra ID-a (prije Azure AD), telemetrija poslana s instrumentacijskim ključem bez valjanih vjerodajnica bit će odbijena s jasnim HTTP pogreškama.

HTTP 400 greška s porukom da klasična autentifikacija nije podržana obično znači da je resurs označen samo kao Entra ID, ali SDK ili skript poziva stari API. U tom slučaju trebali biste provjeriti konfiguraciju SDK-a i korišteni niz za povezivanje.

HTTP 401 greška "Potrebna autorizacija" označava da SDK pokušava koristiti Entra ID, ali ne može dobiti valjani token; to može biti zato što upravljani identitet nije omogućen, jer nedostaju vjerodajnice ili zbog problema s Azure Identity na klijentu.

HTTP 403 kod "Neovlašteno" označava da je dobiven token, ali korišteni identitet nema dovoljna dopuštenja za resurs ili pretplatu Application Insights. U tom slučaju trebali biste pregledati kontrolu pristupa i osigurati da identitet ima barem ulogu Izdavač metrika praćenja.

Ovisno o jeziku (Node.js, Python itd.), preporučljivo je omogućiti interno SDK zapisivanje ili zapisivanje Azure Identityja kako biste točno vidjeli koja faza autentifikacije ne uspijeva i s kojom porukom.

Telemetrija, skripte i najbolje prakse u stvarnim okruženjima

Sve navedeno znači da, kada želite dodati telemetriju skriptama u PowerShellu , imate dvije razine za upravljanje: s jedne strane, automatsku telemetriju samog enginea, a s druge strane, eksplicitnu telemetriju koju šaljete sustavima kao što su Application Insights ili druga odredišta.

Na izvornoj razini, ključno je znati kako funkcionira POWERSHELL_TELEMETRY_OPTOUT, koji se podaci prikupljaju na početku i tijekom sesije te kako se varijable poput POWERSHELL_DISTRIBUTION_CHANNEL o POWERSHELL_UPDATECHECK kontrolirati globalno ponašanje.

Što se tiče vaših skripti, možete iskoristiti varijable okruženja, pružatelja usluga Env:, metode System.Environment i alate poput Sophia Script za Prilagodite pravila privatnosti, ruta, predmemorije i izvršavanja, dok implementirate svoje procese za slanje metrika i zapisnika vanjskim servisima.

Kombiniranjem ručnog telemetrijskog testiranja s PowerShellom i Curlom, praćenjem TLS protokola i finim podešavanjem autentifikacije s Microsoft Entra ID-om, moguće je imati robustan i pouzdan telemetrijski cjevovod čak i u visoko kontroliranim korporativnim okruženjima.

Kada shvatite kako je cijeli ovaj telemetrijski sloj orkestriran, od varijabli okruženja do unosa u oblak, postaje puno lakše odlučiti koje poluge povući ako se jednog dana vaši Azure grafikoni ili zapisnici misteriozno prestanu ažurirati.