Telemetrie in PowerShell: Variablen, Datenschutz und Datenübertragung

Wenn Sie täglich mit PowerShell arbeiten und anfangen, davon zu hören Telemetrie in Skripten und SitzungenEs ist normal, Fragen zu haben: Welche Daten werden gesendet, wohin gehen sie, wie kann man sie deaktivieren oder wie kann man diese Telemetriedaten selbst nutzen, um eigene Skripte zu debuggen oder zu überwachen? All das gewinnt noch mehr an Bedeutung, wenn man mit Unternehmensumgebungen oder sensiblen Informationen arbeitet.

In den folgenden Zeilen werden Sie, in ausführlicher Form und in möglichst einfacher Sprache, sehen, Wie funktioniert die mit PowerShell verknüpfte Telemetrie?Welche Rolle spielen Umgebungsvariablen, wie kann man sich abmelden, wie sendet man Telemetriedaten manuell (z. B. an Application Insights) mit PowerShell oder curl, und welche typischen Netzwerk-, TLS- oder Authentifizierungsprobleme können dazu führen, dass Daten in Ihren Dashboards fehlen?

Welche Telemetriedaten sendet PowerShell nativ?

PowerShell enthält in seinen modernen Versionen einen eigenen Mechanismus für grundlegende Nutzungsdaten an Microsoft senden durch Application Insights. Wir sprechen nicht von dem von Ihnen geschriebenen Code, sondern von der PowerShell-Engine selbst, wenn die Binärdatei ausgeführt wird. pwsh.

Diese Telemetriedaten helfen Microsoft dabei, besser verstehen, wie man PowerShell benutzt (Versionen, Plattformen, Module usw.) und priorisieren neue Funktionen oder Fehlerbehebungen. Bevor die Informationen versendet werden, anonymisiert und fügt hinzu so dass der Benutzer nicht direkt identifiziert wird.

Es gibt zwei entscheidende Zeitpunkte, zu denen Daten erhoben werden: zu Beginn der Sitzung y periodisch während der AusführungEs ist wichtig, dieses Verhalten zu verstehen, wenn Sie maximale Kontrolle darüber haben möchten, was aus Ihren Umgebungen geteilt wird.

Außerdem sendet der Motor diese Telemetriedaten nur, wenn Sie ihn laufen lassen. pwsh Standard; wenn PowerShell eingebettet als Engine in einer anderen Host-AnwendungDiese anfänglichen Telemetriedaten werden nicht generiert.

Daten, die beim Starten von pwsh gesendet werden

Wenn eine Sitzung beginnt mit pwshDie Engine sammelt eine kleine, aber sehr spezifische Menge an Umgebungsinformationen, die nur einmal pro Tag gesendet wird. StartenUnter anderem wurden folgende Daten erfasst: Betriebssystem und Installationsdetails von PowerShell.

Diese erste Phase umfasst Daten wie beispielsweise Hersteller, Name und Version des Betriebssystems der Plattform sowie der spezifischen Version von PowerShell, die Sie aktuell ausführen, was hilft, die Zusammensetzung der Systeme zu verstehen, auf denen sie verwendet wird.

Eine weitere wichtige Information, die übermittelt wird, ist der Wert des/der Umgebungsvariable POWERSHELL_DISTRIBUTION_CHANNELDies gibt den Kanal an, über den PowerShell installiert wurde (z. B. offizielles Paket, Repository usw.). Dieser Wert wird von den Installationsprogrammen festgelegt, und Benutzern wird empfohlen, ihn nicht zu ändern, um die Metriken nicht zu verfälschen.

Ebenfalls enthalten ist die Application Insights SDK-Version Die von PowerShell selbst verwendete ungefähre geografische Region des Hosts basierend auf der IP-Adresse, die Parameter, die an pwsh ohne ihre Werte (d.h. Parameternamen, aber nicht deren Inhalt) und die effektive Ausführungsrichtlinie der Startsitzung.

Schließlich generiert die Engine zwei anonyme Kennungen: eine Zufällige GUID pro Benutzer und andere GUID pro SitzungHierbei handelt es sich nicht um direkte personenbezogene Daten, sondern um technische Kennungen zur Gruppierung von Sitzungen und Verhaltensweisen, ohne die wahre Identität preiszugeben.

Während der Sitzung gesendete Telemetriedaten

Sobald die Sitzung läuft, sendet PowerShell regelmäßig aggregierte Nutzungsinformationen, um zu verstehen welche Funktionen verwendet werden und wieDies gilt sowohl für die interaktive Konsole als auch für andere Hosts, auf denen die Engine ausgeführt wird.

Diese Daten umfassen beispielsweise die Anzahl der API-Aufrufe PowerShell.Create(), die Liste der importierten Microsoft-Module zusammen mit ihren Versionen oder die Anzahl der Module, die das Label tragen CrescendoBuiltwas dabei hilft, die Verwendung bestimmter Werkzeuge zu identifizieren.

Folgendes wird ebenfalls berichtet: Namen der aktivierten und deaktivierten experimentellen FunktionenDies ist sehr nützlich, um zu erfahren, welche Experimente die Community tatsächlich in der Produktion hat; außerdem wird der Präferenzwert übermittelt. $PSNativeCommandUseErrorActionPreference (wahr, falsch oder nicht festgelegt) und die Anzahl der offenen Remote-Sitzungen.

Ein weiterer interessanter Aspekt ist der Katalog von registrierte SubsystemePowerShell gibt die Namen an, die für die Autovervollständigungs-Subsysteme verwendet werden (Completion) oder allgemein (general), aber wenn der Name nicht auf dieser Liste steht, wird er gesendet als anonymous um die Privatsphäre zu schützen.

Schließlich sind auch Zähler enthalten. Vorschläge generiert von CommandNotFound und Nutzungsstatistiken PowerShellUnsafeAssemblyLoad (einschließlich der Frage, ob der Ladevorgang erfolgreich war oder nicht), wichtige Aspekte zur Verbesserung der Diagnostik und Sicherheit.

So deaktivieren Sie die native PowerShell-Telemetrie

Wenn Ihre Organisation strenge Datenschutzrichtlinien hat, können Sie festlegen, dass diese Telemetriedaten nicht gesendet werden sollen. PowerShell ermöglicht dies durch die Bereitstellung der entsprechenden Umgebungsvariablen. POWERSHELL_TELEMETRY_OPTOUT, die Sie vor Beginn jeder Sitzung einstellen müssen.

Der anerkannte Wert für die Deaktivierung der Telemetrie kann sein true, yes o 1Jede dieser Varianten weist die Engine an, keine Nutzungsdaten von diesem Prozess oder von untergeordneten Prozessen, die die Umgebung erben, an Microsoft zu senden.

Es ist wichtig zu verstehen, dass diese Konfiguration auf Folgendem basiert: UmgebungsvariablenWenn Sie also möchten, dass die Einstellung dauerhaft ist, müssen Sie sie im entsprechenden Bereich (Benutzer, Computer oder Startskripte) vor dem Starten von PowerShell definieren, nicht danach.

Sollten Sie Fragen zur Verwaltung dieser Variablen haben, finden Sie weitere Informationen in der Dokumentation unter [Link einfügen]. about_Environment_Variables Der Leitfaden zu PowerShell-Umgebungsvariablen hilft Ihnen dabei, je nach Betriebssystem die richtige Vorgehensweise auszuwählen.

Denken Sie außerdem daran, dass die Installationspakete, die PowerShell verteilen, die Konfiguration automatisch vornehmen. POWERSHELL_DISTRIBUTION_CHANNEL Um den Installationskanal zu identifizieren, wird diese Variable benötigt. Sie ist auch in den Telemetriedaten enthalten und sollte daher nicht manuell verändert werden.

Wichtige Umgebungsvariablen, die PowerShell beeinflussen

PowerShell behandelt Umgebungsvariablen als einen speziellen Datentyp, immer in der Form von von Kindprozessen vererbbare TextzeichenfolgenDadurch eignen sie sich ideal zur Steuerung globaler Optionen wie Datenschutz, Updates oder Modulpfade.

Die Engine selbst definiert eine Reihe spezifischer Variablen, unter denen die folgenden besonders hervorzuheben sind: POWERSHELL_TELEMETRY_OPTOUT, POWERSHELL_DISTRIBUTION_CHANNEL, POWERSHELL_UPDATECHECK, PSExecutionPolicyPreference, PSModulePath, PSModuleAnalysisCachePath y PSDisableModuleAnalysisCacheCleanup.

En WindowsDiese Variablen können in der Maschinen- (System-), Benutzer- oder ProzessbereichDer aktuelle Prozess kombiniert automatisch Maschinen- und Benutzerdefinitionen, und alle Änderungen, die Sie in einer Sitzung vornehmen, wirken sich nur auf diesen Prozess aus, es sei denn, Sie machen sie auf andere Weise dauerhaft.

Um Werte auf Maschinen- oder Benutzerebene über PowerShell zu ändern, müssen Sie Folgendes verwenden: .NET-Klasse System.Environment, wodurch Methoden zum Lesen und Schreiben von Variablen in diesen Bereichen bereitgestellt werden, vorausgesetzt, Sie verfügen über ausreichende Berechtigungen hierfür.

Beachten Sie, dass Umgebungsvariablen, da sie Zeichenketten sind, verkettet, geleert oder entfernt werden ganz einfach, was für komplexe Konfigurationsskripte oder die Automatisierung der Bereitstellung sehr nützlich ist.

Möglichkeiten zum Zugriff auf und Ändern von Umgebungsvariablen in PowerShell

PowerShell bietet mehrere Möglichkeiten Umgebungsvariablen abfragen und ändernJe nachdem, was Sie tun (Skript (schnelles, komplexes Modul, administrative Aufgabe) Sie werden daran interessiert sein, das eine oder das andere zu verwenden.

Der direkteste Weg ist Variablensyntax mit dem Präfix $Env:Dies ermöglicht es Ihnen, den Wert einer Variablen auszulesen oder ihr einen neuen Wert zuzuweisen, als wäre sie jede andere PowerShell-Variable, zum Beispiel $Env:windir o $Env:Foo = "Algo".

Darüber hinaus können Sie die Umgebungsanbieter (Env:) mit den Standard-Cmdlets von Elementen (Get-Item, New-Item, Set-Item, Remove-Itemetc.), was einen sehr einheitlichen Ansatz für die Behandlung von Dateisystemeinheiten ermöglicht.

In Szenarien, in denen Sie auf Maschinen- oder Benutzerebene agieren oder .NET-Code integrieren möchten, stehen Ihnen die entsprechenden Methoden zur Verfügung. [Environment]::GetEnvironmentVariable() y [Environment]::SetEnvironmentVariable()Diese Methoden ermöglichen es Ihnen, den Gültigkeitsbereich explizit auszuwählen (Process, User o Machine) in Windows-Systemen.

Seit PowerShell 7.5 gibt es außerdem ein spezifisches Verhalten: Sie können Eine Variable auf einen leeren String oder auf einen anderen Wert setzen $null um es aus der Sitzung zu leeren oder zu entfernen, verwenden Sie entweder die Syntax $Env: wie durch Set-Item oder die Methoden von System.Environment.

PowerShell-Umgebungsvariablen im Zusammenhang mit Telemetrie und Verhalten

Mehrere interne Funktionen von PowerShell hängen von Umgebungsvariablen ab, die als solche fungieren vererbbare PräferenzflagsDies ermöglicht es Ihnen, das Verhalten der Shell oder der Telemetrie anzupassen, ohne den Code in jedem Skript ändern zu müssen.

Die offensichtlichste ist POWERSHELL_TELEMETRY_OPTOUTWie wir bereits gesehen haben, dient dies dazu, die native Telemetrie des Motors zu deaktivieren, wenn sie auf „“ eingestellt ist. true, yes o 1Damit dies wirksam wird, muss es vor dem Start des PowerShell-Prozesses vorhanden sein.

Ein weiterer sehr wichtiger Punkt ist POWERSHELL_DISTRIBUTION_CHANNELDieses Feld, das seit PowerShell 7.2 von Installationsprogrammen automatisch ausgefüllt wird, um anzuzeigen, wie das Produkt installiert wurde, ist in den Telemetriedaten enthalten, daher wird eine manuelle Änderung nicht empfohlen.

Variabel POWERSHELL_UPDATECHECK Steuert, wie und wann Aktualisierungsbenachrichtigungen angezeigt werden. Akzeptiert Werte wie z. B. Off Um die Funktion zu deaktivieren, Default für Standardverhalten oder LTS Benachrichtigungen nur für Versionen mit erweitertem Support erhalten.

Ferner PSExecutionPolicyPreference spiegelt die aktive Ausführungsrichtlinie in der aktuellen Sitzung wider, wenn diese über den Parameter konfiguriert wurde. -ExecutionPolicy, das Cmdlet Set-ExecutionPolicy mit Reichweite Processoder durch direktes Bearbeiten der Variablen. Diese Einstellung betrifft insbesondere heruntergeladene oder unsignierte Skripte unter Windows.

Und natürlich wird der Modulsuchpfad gesteuert durch PSModulePath, das unter Windows eine durch Semikolon getrennte Liste und unter *nix-Plattformen eine durch Doppelpunkt getrennte Liste speichert, wobei sowohl System- als auch Benutzerverzeichnisse und sogar Pfade von externen Installationsprogrammen hinzugefügt werden.

Cache- und Modulanalyse: Feinabstimmung

PowerShell pflegt eine Modulanalyse-Cache um die Suchvorgänge zu beschleunigen Befehle und vermeiden, bei jedem Start oder jeder Suche ständig alle verfügbaren Module überprüfen zu müssen.

Die Umgebungsvariable PSModuleAnalysisCachePath Legen Sie fest, wo die Cache-Datei gespeichert wird. Standardmäßig verweist sie auf Pfade unter $Env:LOCALAPPDATA unter Windows oder ~/.cache/powershell Auf Nicht-Windows-Systemen wird für jede Installation ein anderer Dateiname verwendet.

Wenn Sie diesen Standort ändern möchten, müssen Sie diese Variable festlegen. vor dem Starten von PowerShellDer vollständige Pfad (einschließlich Dateiname) wird angegeben, unter dem der Prozess Schreibrechte besitzt. Die Änderungen werden nur für Prozesse wirksam, die nach der Änderung gestartet werden.

Wenn Sie das Modul-Caching vollständig deaktivieren möchten, können Sie den Pfad zu einem nicht beschreibbaren Ziel umleiten, z. B. NUL unter Windows oder /dev/null en LinuxPowerShell wird versuchen, den Cache dort zu schreiben, was nicht gelingen wird, aber es werden auch keine sichtbaren Fehler in der Sitzung erzeugt.

Ergänzend dazu gibt es die Variable PSDisableModuleAnalysisCacheCleanupWenn Sie es einstellen auf 1Es deaktiviert automatische Bereinigungen, die nicht mehr existierende Moduleinträge entfernen, was in bestimmten Szenarien nützlich ist, in denen man diesen Cache nicht anfassen möchte.

Weitere Umgebungsvariablen, die für Skripte und Telemetrie nützlich sind

Abgesehen von den PowerShell-spezifischen Variablen gibt es eine Reihe von Systemumgebungsvariablen, die sich direkt auswirken. wie die Skripte ausgeführt werden und wie sich das System verhält Terminalinsbesondere in Multiplattform-Umgebungen.

Variabel PATH Dies legt fest, in welchen Verzeichnissen nach ausführbaren Dateien gesucht wird. Dies ist unerlässlich, wenn Sie externe Binärdateien aus Ihren PowerShell-Skripten starten möchten. Unter Windows werden Verzeichnisse durch … getrennt. ;Unter Linux oder macOS wird es verwendet :.

Windows existiert ebenfalls. PATHEXTDiese Liste enthält die Dateierweiterungen, die als direkt ausführbar gelten. Wenn Sie eine Skriptsprache in derselben Konsole ausführen möchten (z. B. Skriptdateien), können Sie den entsprechenden Befehl verwenden. .pySie müssen die Erweiterung hier einfügen und sie mithilfe von Tools wie z. B. im System registrieren. assoc y ftype von CMD.

Auf Nicht-Windows-Plattformen passt sich PowerShell mithilfe von Variablen an die XDG-Konvention an. XDG_CONFIG_HOME, XDG_DATA_HOME y XDG_CACHE_HOME für Konfigurationspfade, Daten und Cache, was die Integration mit dem Rest des Systems erleichtert.

Für Farbausgabefunktionen und Terminalsteuerung berücksichtigen PowerShell 7.2 und höher dies. TERM y NO_COLORDem Wert von TERM ANSI-Sequenzen werden deaktiviert oder angepasst, und wenn es NO_COLORDer Ausgabestil ist auf Klartext ohne Farbe festgelegt.

Logs und die Ausgabe Ihrer Skripte Sie beeinflussen das Aussehen Ihrer Skriptprotokolle und -ausgaben, was sich sowohl auf die Konsolenbedienung als auch auf die Lesbarkeit der erfassten Telemetriedaten auswirkt, wenn Sie die Ausgabe in Dateien umleiten.

Praktisches Beispiel: Sophia Script und Datenschutz- und Telemetrieeinstellungen

Eines der bekanntesten Beispiele in der Community für die Anpassung von Windows 10 mit PowerShell ist Windows 10 Sophia-Skript, eine Reihe von Funktionen zur Automatisierung der Konfiguration, des Datenschutzes und der Deinstallation unnötiger Komponenten.

Zu den Optionen von Sophia Script gehört unter anderem die Möglichkeit, Systemdatenschutz und Telemetrie anpassen, geplante Diagnoseaufgaben deaktivieren, OneDrive deinstallieren, Pfad ändern von %TEMP% oder Benutzerordner wie Desktop, Dokumente, verschieben DownloadsMusik, Bilder oder Videos über interaktive Menüs.

Es bietet außerdem Funktionen für Deinstallieren Sie UWP-Apps für alle Konten, die eine über WPF-Formulare konfigurierbare Ausschlussliste berücksichtigen, sowie die Deaktivierung von Windows-Funktionen oder das Entfernen von Systemfunktionen mithilfe visueller Assistenten.

Ein weiterer interessanter Aspekt ist, dass es kann Aufgaben im Aufgabenplaner erstellen für die regelmäßige Reinigung, die Anpassung des Startmenüs (Anheften oder Lösen von Elementen), die Manipulation von Microsoft Defender-Sicherheitsoptionen wie kontrollierter Ordnerzugriff oder Ausnahmen sowie das Aktualisieren von Symbolen, Umgebungsvariablen und der Taskleiste ohne Neustart des Explorers.

Kurz gesagt, demonstriert diese Art von Skript, wie man durch die Kombination von PowerShell mit Telemetriekonfigurationen, Umgebungsvariablen und Automatisierung Folgendes erreichen kann um das Verhalten eines Windows-Systems vollständig zu modellieren um es an die Richtlinien einer Organisation oder an persönliche Vorlieben anzupassen.

Telemetriedaten von PowerShell an Application Insights senden

Über die native Telemetrie von PowerShell hinaus senden viele Anwendungen ihre eigenen Überwachungsdaten an Azure Monitor Application InsightsManchmal öffnet man jedoch das Azure-Portal und die Diagramme erscheinen leer oder es fehlen wichtige Datensätze.

Typische Ursachen sind in der Regel Konfigurationsfehler des SDK oder des Application Insights-Agenten sowie Netzwerkblockaden. Zeitpunkt der EinnahmeEinschränkungen oder Ausschlüsse von Telemetriedaten in der Pipeline, spezifische Log Analytics-Vorfälle oder Probleme bei der Abfrage der API api.applicationinsights.io.

Ein sehr praktischer Ansatz zur Eingrenzung der Problemursache besteht darin, manuell ein einzelnes Test-Telemetrieprotokoll senden von PowerShell oder curl. Wenn dieser Datensatz erfolgreich in der Protokolltabelle der Application Insights-Ressource landet, wissen Sie, dass ein Großteil der Pipeline funktioniert.

Wenn Sie von demselben Rechner oder derselben Umgebung aus testen, in der Ihre Anwendung ausgeführt wird (z. B. der VM oder dem App Service), überprüfen Sie auch, ob DNS, Firewall, TLS und Berechtigungen blockieren nicht den Weg zur Datenaufnahme.

In Szenarien, in denen der Erfassungspunkt mit einer Microsoft Entra ID (ehemals Azure AD) geschützt ist, müssen Sie sicherstellen, dass sich die Anwendung oder das Skript ordnungsgemäß mit der Entra ID authentifiziert; andernfalls werden die Telemetriedaten zurückgewiesen, selbst wenn der Rest der Instrumentierung korrekt erscheint.

PowerShell-Skript zum Testen der Verfügbarkeitstelemetrie

Um zu überprüfen, ob die gesamte Verbindung von Ihrem Rechner zu Application Insights funktioniert, können Sie Folgendes verwenden: PowerShell-Skript, das ein Verfügbarkeitstestergebnis sendetDiese Art der Telemetrie ist ideal, da sie nicht den Ansaugprobenahmemechanismen unterliegt.

Die Idee ist einfach: Sie stellen ein Verbindungskette oder InstrumentierungsschlüsselDas Skript zerlegt den Datenfluss, um den Aufnahmepunkt und den InstrumentationKey, generiert ein JSON mit einem AvailabilityData als Beispiel und sendet es mit Invoke-WebRequest zum entsprechenden REST-Endpunkt.

Wenn Sie nur den Instrumentierungsschlüssel übergeben, erstellt das Skript eine Verbindungszeichenfolge mit dem globaler Endpunkt https://dc.services.visualstudio.com/Wenn Sie die gesamte Verbindungszeichenfolge angeben, wird der darin definierte regionale Aufnahmepunkt verwendet; wenn Sie beide angeben, hat der in der Verbindungszeichenfolge definierte Vorrang.

Während der Ausführung Zeitstempel im UTC-ISO-8601-FormatDer JSON-Body wird mit den Testdaten (Dauer, Ort, Nachricht, zusätzliche Eigenschaften) gefüllt und die POST-Anfrage wird gesendet. Die HTTP-200-Antwort mit itemsReceived gleich itemsAccepted zeigt an, dass die Annahmestelle die Akte erhalten und akzeptiert hat.

Gehen Sie anschließend einfach im Azure-Portal auf die Registerkarte „Protokolle“ der Application Insights-Ressource, führen Sie eine Abfrage für den entsprechenden Typ aus und prüfen Sie, ob das Beispielprotokoll angezeigt wird. Wenn ja, wissen Sie, dass das Problem höchstwahrscheinlich in der Ressource liegt. SDK oder Agent, den Ihre eigentliche Anwendung verwendet.

Telemetrie mit curl unter Linux oder Windows testen

Wenn Sie in einer Linux- oder macOS-Umgebung testen möchten oder wenn Sie Standardtools anstelle von PowerShell bevorzugen, können Sie denselben Test mit folgenden Tools durchführen: curl sendet eine POST-Anfrage mit JSON-Inhalten an den Application Insights-Endpunkt.

In diesen Fällen erstellen Sie einen ähnlichen JSON-Body, mit baseType gleich AvailabilityDataAusführungskennung, Testname, Dauer, Erfolgsindikator, Ort, Meldung und optionale Eigenschaften. Denken Sie daran, die Feld time zu einer aktuellen Markeweil Application Insights Daten verarbeitet, die älter als 48 Stunden sind.

Für Linux oder macOS umfasst der Befehl üblicherweise Folgendes: cabecera Content-Type: application/json, die POST-Methode, das Inline-JSON und die URL des Aufnahmepunkts (zum Beispiel https://dc.applicationinsights.azure.com/v2.1/trackUnter Windows ändert sich die Syntax geringfügig, da die Anführungszeichen im JSON-Code maskiert werden müssen, wenn dieser als Argument übergeben wird.

Sobald dies abgeschlossen ist, überprüfen Sie die HTTP-Antwort erneut und, falls diese korrekt ist, gehen Sie zu den Application Insights-Protokollen, um zu bestätigen, dass Ihre Testtelemetrie nun gespeichert und abfragbar ist, genau wie beim PowerShell-Skript.

Dieser Ansatz ermöglicht es Ihnen, SDK-Konfigurationsprobleme auf einen Blick auszuschließen und sich dabei auf Folgendes zu konzentrieren: Netzwerk-, DNS-, TLS-, Endpunktauthentifizierungs- oder Stichprobenrichtlinien basierend auf den Symptomen, die Sie in der Antwort sehen.

PowerShell-Skript zum Testen der Anforderungstelemetrie

Zusätzlich zu Verfügbarkeitstests sind Sie oft daran interessiert, die folgenden Punkte zu überprüfen: HTTP-Anfrage-Telemetrieinsbesondere dann, wenn Ihre Dashboards auf eingehenden Anfragemetriken einer API oder Webanwendung basieren.

Dazu können Sie ein weiteres PowerShell-Skript verwenden, das dem Verfügbarkeitsskript sehr ähnlich ist, diesmal jedoch ein JSON-Objekt generiert mit baseType gleich RequestDataFelder wie die Anforderungskennung und der Operationsname (zum Beispiel) sind üblicherweise enthalten. GET /ruta/prueba/), Startzeit, Dauer, URL, Antwortcode und HTTP-Methode.

Das Skript folgt dem gleichen Mechanismus: Es zerlegt die Verbindungszeichenfolge oder den Instrumentierungsschlüssel und erstellt die Aufnahme-URL (v2/trackberechnet die aktuelle Zeit in UTC, stellt das JSON zusammen und führt es aus Invoke-WebRequest mit der POST-MethodeWenn Sie den Code 200 und den erwarteten Inhalt in der Antwort erhalten, funktioniert die Datenerfassung.

Ein wichtiger Punkt ist: Anwendungen können tatsächlich beeinflusst werden durch Aufnahmeprobenahmemechanismen Serverseitig. Wenn Sie die Stichprobenentnahme zur Reduzierung des Datenvolumens konfiguriert haben, werden möglicherweise nicht alle Testanfragen angezeigt, es sei denn, Sie deaktivieren die Stichprobenentnahme vorübergehend oder passen die Prozentsätze an.

Sobald Ihr Testprotokoll in Application Insights angezeigt wird, sollten Sie sich als Nächstes darauf konzentrieren, wie Ihr Code instrumentiert ist (SDK, Filter, Sampling, Ausschlüsse usw.), um herauszufinden, warum echte Anfragen nicht so einfach protokolliert werden wie manuelle Tests.

Häufige SSL/TLS-Probleme beim Senden von Telemetriedaten

Es ist nicht ungewöhnlich, dass beim Ausführen dieser Testskripte Fehler auftreten. SSL oder TLS während des Handshakesinsbesondere in eingeschränkten Umgebungen oder wenn Unternehmensproxys den Datenverkehr überwachen.

Viele Azure-Dienste, darunter Application Insights, benötigen mindestens TLS 1.2 und bestimmte Verschlüsselungssammlungen, um Verbindungen zu akzeptieren. Wenn das System oder die Anwendung weiterhin standardmäßig TLS 1.0 oder 1.1 verwendet, kann die Verbindung fehlschlagen, noch bevor der Server das JSON verarbeitet.

PowerShell ermöglicht es Ihnen, unterstützte Protokolle durch die Einstellung zu erzwingen. [System.Net.ServicePointManager]::SecurityProtocol vor der Ausführung Invoke-WebRequestSie können SSL3, TLS, TLS 1.1, TLS 1.2 oder TLS 1.3 ausprobieren, um zu sehen, was in Ihrer Umgebung funktioniert. Im Produktivbetrieb wird jedoch empfohlen, sich an die Sicherheitsrichtlinien zu halten.

Wenn Sie auch Proxys oder Firewalls verwenden, die SSL-Prüfungen durchführen, kann die Zertifikatsvalidierung fehlschlagen. Es gibt eine Option, um Zertifikatsprüfung deaktivieren Sie können eine benutzerdefinierte Richtlinie erstellen, die immer „true“ zurückgibt. Dies sollten Sie jedoch nur zu Diagnosezwecken und niemals als dauerhafte Lösung verwenden.

Wenn Sie die von .NET-Anwendungen unter Windows verwendeten Standard-TLS-Versionen ändern müssen, gehen Sie wie folgt vor: Offizielle TLS-Konfigurationsempfehlungen in der Registry und zwar im Framework selbst, anstatt verstreute Hacks in den Skripten einzuführen.

Authentifizierungsfehler bei Microsoft. Geben Sie die ID in Application Insights ein.

Wenn Ihre Application Insights-Ressource so konfiguriert ist, dass sie nur akzeptiert Authentifizierung mit Microsoft Enter ID (ehemals Azure AD), Telemetriedaten, die mit einem Instrumentierungsschlüssel ohne gültige Anmeldeinformationen gesendet werden, werden mit klaren HTTP-Fehlern zurückgewiesen.

Ein Code HTTP 400 mit einer Meldung, die darauf hinweist, dass die klassische Authentifizierung nicht unterstützt wird. Dies bedeutet in der Regel, dass die Ressource nur als Entra-ID gekennzeichnet ist, das SDK oder Skript aber die alte API aufruft. In diesem Fall müssen Sie die SDK-Konfiguration und die verwendete Verbindungszeichenfolge überprüfen.

Ein Fehler HTTP 401 „Autorisierung erforderlich“ Dies lässt darauf schließen, dass das SDK versucht, Entra ID zu verwenden, aber kein gültiges Token erhalten kann; dies könnte daran liegen, dass die verwaltete Identität nicht aktiviert ist, dass Anmeldeinformationen fehlen oder dass es Probleme mit Azure Identity auf dem Client gibt.

Der Code HTTP 403 "Nicht autorisiert" Dies deutet darauf hin, dass zwar ein Token abgerufen wurde, die verwendete Identität jedoch nicht über ausreichende Berechtigungen für die Application Insights-Ressource oder das Abonnement verfügt. Überprüfen Sie in diesem Fall die Zugriffskontrolle und stellen Sie sicher, dass die Identität mindestens die Rolle „Publisher für Überwachungsmetriken“ besitzt.

Abhängig von der Sprache (Node.js, Pythonusw.), ist es ratsam, die Aktivierung zu aktivieren. interne SDK-Protokolle oder in den Azure Identity-Protokollen nachzusehen, in welcher Phase der Authentifizierung genau ein Fehler auftritt und welche Fehlermeldung angezeigt wird.

Telemetrie, Skripte und bewährte Verfahren in realen Umgebungen

All das oben Genannte bedeutet, dass, wenn Sie wollen Fügen Sie Skripten in PowerShell Telemetriedaten hinzu.Sie müssen zwei Ebenen verwalten: zum einen die automatische Telemetrie der Engine selbst und zum anderen die explizite Telemetrie, die Sie an Systeme wie Application Insights oder andere Ziele senden.

Auf der nativen Ebene ist es entscheidend zu wissen, wie es funktioniert. POWERSHELL_TELEMETRY_OPTOUTwelche Daten zu Beginn und während der Sitzung erfasst werden und wie Variablen wie POWERSHELL_DISTRIBUTION_CHANNEL o POWERSHELL_UPDATECHECK um das globale Verhalten zu kontrollieren.

Im Hinblick auf Ihre Skripte können Sie Umgebungsvariablen und den Anbieter nutzen. Env:, die Methoden von System.Environment und Tools wie Sophia Script für Datenschutz-, Routen-, Cache- und Ausführungsrichtlinien anpassen, während Sie Ihre Prozesse implementieren, um Metriken und Protokolle an externe Dienste zu senden.

Durch die Kombination von manuellen Telemetrietests mit PowerShell und curl, der Überwachung von TLS-Protokollen und der korrekten Konfiguration der Authentifizierung mit Microsoft Entra ID ist es möglich, eine robuste und zuverlässige Telemetrie-Pipeline selbst in streng kontrollierten Unternehmensumgebungen.

Wenn man versteht, wie diese gesamte Telemetrieebene orchestriert wird, von Umgebungsvariablen bis hin zur Cloud-Datenaufnahme, wird die Entscheidung viel einfacher. welche Hebel drücken Wenn Ihre Azure-Diagramme oder -Protokolle eines Tages auf mysteriöse Weise nicht mehr aktualisiert werden.