Datensammlung, -aufbewahrung und -speicherung in Application Insights

Wenn Sie die Application Insights SDK in Ihrer App installieren, werden Telemetriedaten über Ihre App an die Cloud gesendet. Als verantwortungsbewusster Entwickler möchten Sie genau wissen, welche Daten gesendet werden, was mit den Daten geschieht und wie Sie die Kontrolle darüber behalten. Dabei ist insbesondere interessant, ob womöglich sensible Daten übermittelt werden, wo sie gespeichert werden und wie sicher die Daten sind.

Zunächst die kurze Antwort:

• Bei Verwendung der Standardtelemetriemodule in der vorkonfigurierten Form ist es äußerst unwahrscheinlich, dass sensible Daten an den Dienst übermittelt werden. Bei der Telemetrie dreht sich alles um Lade-, Leistungs- und Nutzungsmetriken sowie um Ausnahmeberichte und andere Diagnosedaten. Die wichtigsten in den Diagnoseberichten sichtbaren Benutzerdaten sind URLs. Ihre App sollte jedoch in keinem Fall sensible Daten im Nur-Text-Format in eine URL einfügen.
• Sie können Code schreiben, der zusätzliche benutzerdefinierte Telemetriedaten sendet, die Sie bei der Diagnose und Überwachung der Nutzung unterstützen. (Diese Erweiterbarkeit ist ein großartiges Feature von Application Insights.) Der Code kann theoretisch so geschrieben werden, dass versehentlich auch persönliche und andere sensible Daten einbezogen werden. Falls Ihre Anwendung mit solchen Daten arbeitet, müssen Sie sämtlichen Code, den Sie schreiben, einer gründlichen Prüfung unterziehen.
• Beim Entwickeln und Testen Ihrer App können Sie problemlos überprüfen, was vom SDK gesendet wird. Die Daten erscheinen in den Debugging-Ausgabefenstern von IDE und Browser.
• Sie können den Speicherort auswählen, wenn Sie eine neue Application Insights-Ressource erstellen. Weitere Informationen zur Verfügbarkeit von Application Insights pro Region finden Sie unter Verfügbare Produkte nach Region.
• Überprüfen Sie die gesammelten Daten, sie möglicherweise Daten enthalten, die in einigen Fällen zulässig sind, in anderen hingegen nicht. Ein gutes Beispiel dafür ist der Gerätename. Der Gerätename eines Servers wirkt sich nicht auf die Privatsphäre aus und ist nützlich. Ein Gerätename von einem Smartphone oder Laptop ist möglicherweise relevant für den Datenschutz und weniger nützlich. Ein SDK, das in erster Linie für Server entwickelt wurde, würde standardmäßig Gerätenamen sammeln. Diese Funktion muss möglicherweise sowohl für normale Ereignisse als auch in Ausnahmefällen außer Kraft gesetzt werden.

Der Rest dieses Artikels behandelt diese Punkte vollständiger. Der Artikel ist eigenständig, sodass Sie sie mit Kollegen teilen können, die nicht Teil Ihres unmittelbaren Teams sind.

Was ist Application Insights?

Azure Application Insights ist ein Dienst von Microsoft, der Sie beim Optimieren der Leistung und Benutzerfreundlichkeit Ihrer Liveanwendung unterstützt. Er überwacht Ihre Anwendung während der gesamten Ausführung – sowohl in der Testphase als auch nach der Veröffentlichung oder Bereitstellung. Application Insights erstellt Diagramme und Tabellen mit informativen Metriken. Diese beben Ihnen beispielsweise Aufschluss darüber, zu welchen Tageszeiten es am meisten Benutzer gibt, wie gut die App reagiert und wie gut sie von externen Diensten versorgt wird, von denen sie unter Umständen abhängig ist. Im Falle von Ausfällen oder Leistungsproblemen können Sie die Telemetriedaten durchsuchen, um die Fehlerursache zu ermitteln. Der Dienst informiert Sie per E-Mail, falls sich die Verfügbarkeit oder Leistung Ihrer App ändert.

Diese Funktionen erhalten Sie, indem Sie das Application Insights-SDK in Ihrer Anwendung installieren und es so in den Code integrieren. Wenn Ihre App ausgeführt wird, überwacht das SDK den Vorgang und sendet Telemetrie an Application Insights Log Analytics-Arbeitsbereich, welcher ein von Microsoft Azure gehosteter Clouddienst ist. Application Insights kann aber nicht nur für in Azure gehostete Anwendungen, sondern auch für jede beliebige Anwendung verwendet werden.

Application Insights speichert und analysiert die Telemetriedaten. Wenn Sie sich die Analyse ansehen oder die gespeicherten Telemetriedaten durchsuchen möchten, melden Sie sich bei Ihrem Azure-Konto an, und öffnen Sie die Application Insights-Ressource für Ihre Anwendung. Sie können auch anderen Mitgliedern Ihres Teams oder bestimmten Azure-Abonnenten Zugriff auf die Daten gewähren.

Sie können Daten aus Application Insights exportieren (etwa in eine Datenbank oder in externe Tools). Für jedes Tool muss ein spezieller Schlüssel angegeben werden, den Sie über den Dienst erhalten. Der Schlüssel kann bei Bedarf widerrufen werden.

Application Insights-SDKs sind für eine Reihe von Anwendungstypen verfügbar:

• Webdienste, die auf Ihren eigenen Java EE- oder ASP.NET-Servern oder in Azure gehostet werden
• Webclients, das heißt, der Code, der auf einer Webseite ausgeführt wird
• Desktop-Apps und -Dienste
• Geräte-Apps wie etwa für Windows Phone, iOS und Android

Alle diese Anwendungen senden Telemetriedaten an den gleichen Dienst.

Hinweis

Am 31. März 2025 wird der Support für die auf Instrumentierungsschlüsseln basierende Erfassung eingestellt. Die Erfassung von Instrumentierungsschlüsseln funktioniert zwar weiterhin, wir stellen jedoch keine Updates und keinen Support mehr für das Feature bereit. Wechseln Sie zu Verbindungszeichenfolgen, damit Sie neue Funktionen nutzen können.

Welche Daten werden dabei gesammelt?

Es werden drei Datenquellen verwendet:

• Das SDK, das Sie entweder bei der Entwicklung oder zur Laufzeit in Ihre App integrieren. Für die unterschiedlichen Anwendungstypen stehen jeweils unterschiedliche SDKs zur Verfügung. Darunter ist auch ein SDK für Webseiten, das zusammen mit der Seite in den Browser des Benutzers geladen wird.

  • Jedes SDK verfügt über eine Reihe von Modulen, die mithilfe unterschiedlicher Techniken verschiedene Arten von Telemetriedaten erfassen.
  • Wenn Sie das SDK während der Entwicklung installieren, können Sie zusätzlich zu den Standardmodulen die API des SDK verwenden, um Ihre eigenen Telemetriedaten zu senden. Diese benutzerdefinierten Telemetriedaten können beliebige Daten enthalten, die Sie senden möchten.

• Einige Webserver verfügen auch über Agents, die gemeinsam mit der App ausgeführt werden und Telemetriedaten zu CPU-, Arbeitsspeicher- und Netzwerkauslastung senden. Solche Agents können etwa bei Azure-VMs, Docker-Hosts und Java-Anwendungsservern vorhanden sein.

• Verfügbarkeitsübersicht sind Prozesse, die von Microsoft in ausgeführt werden und in regelmäßigen Abständen Anforderungen an Ihre Web-App senden. Die Ergebnisse werden dann an Application Insights gesendet.

Welche Art von Daten wird gesammelt?

Die gesammelten Daten lassen sich in folgende Hauptkategorien unterteilen:

• Webserver-Telemetrie: HTTP-Anforderungen. URI, Anforderungsverarbeitungsdauer, Antwortcode, Client-IP-Adresse. Session id.
• Webseiten: Seiten-, Benutzer- und Sitzungszähler. Seitenladezeiten. Ausnahmen. AJAX-Aufrufe.
• Leistungsindikatoren: Arbeitsspeicher-, CPU-, E/A- und Netzwerkauslastung.
• Client- und Serverkontext: Betriebssystem, Gebietsschema, Gerätetyp, Browser, Bildschirmauflösung.
• Ausnahmen und Abstürze: Stapelabbilder, build id CPU-Typ.
• Abhängigkeiten : Aufrufe an externe Dienste wie etwa REST, SQL und AJAX. URI oder Verbindungszeichenfolge, Dauer, Erfolg und Befehl.
• Verfügbarkeitstests: Test- und Schrittdauer und Antworten.
• Ablaufverfolgungsprotokolle und benutzerdefinierte Telemetriedaten: alles, was Sie in Ihre Protokolle oder Telemetrie programmieren.

Weitere Informationen finden Sie im Abschnitt Von Application Insights gesendete Daten.

Wie kann ich überprüfen, was gesammelt wird?

Wenn Sie eine App mit Visual Studio entwickeln, führen Sie sie im Debugmodus aus (F5). Die Telemetriedaten werden im Fenster Ausgabe angezeigt. Dort können Sie sie kopieren und zur einfachen Überprüfung als JSON formatieren.

Es gibt auch eine lesbarere Ansicht im Fenster Diagnose.

Öffnen Sie bei Webseiten das Debuggingfenster Ihres Browsers. Drücken Sie F12, und öffnen Sie die Registerkarte Netzwerk.

Kann ich Code schreiben, der die Telemetriedaten vor dem Senden filtert?

Sie müssen dafür ein Telemetrieprozessor-Plug-In schreiben.

Wie lange werden Daten aufbewahrt?

Rohdatenpunkte (also Elemente, die Sie in Analytics abfragen und in Search überprüfen können) werden bis zu 730 Tage lang aufbewahrt. Sie können eine Aufbewahrungsdauer von 30, 60, 90, 120, 180, 270, 365, 550 oder 730 Tagen auswählen. Wenn Sie Daten länger als 730 Tage behalten müssen, können Sie die Diagnoseeinstellungen verwenden.

Für Daten, die länger als 90 Tage aufbewahrt werden, fallen zusätzliche Gebühren an. Weitere Informationen zu Application Insights-Preisen finden Sie in der Preisübersicht für Azure Monitor.

Aggregierte Daten (d.h. Zählungen, Mittelwerte und andere statistische Daten, die im Metrik-Explorer angezeigt werden) werden für 90 Tage (minutengenau berechnet) aufbewahrt.

Debugmomentaufnahmen werden 15 Tage lang gespeichert. Diese Aufbewahrungsrichtlinie wird für jede Anwendung separat festgelegt. Wenn Sie diesen Wert erhöhen möchten, können Sie eine Erhöhung anfordern, indem Sie einen Supportfall im Azure-Portal eröffnen.

Wer kann auf die Daten zugreifen?

Die Daten sind für Sie und, wenn Sie über ein Unternehmenskonto verfügen, für die Teammitglieder sichtbar.

Sie und Ihre Teammitglieder können die Daten exportieren und an andere Speicherorte kopieren oder Sie an andere Personen weiterleiten.

Wie verwendet Microsoft die Daten, die meine App an Application Insights sendet?

Microsoft verwendet die Daten nur dazu, Ihnen den Dienst bereitzustellen.

Wo werden die Daten gespeichert?

Sie können den Speicherort auswählen, wenn Sie eine neue Application Insights-Ressource erstellen. Weitere Informationen zur Verfügbarkeit von Application Insights finden Sie unter Verfügbare Produkte nach Region.

Wie sicher sind meine Daten?

Application Insights ist ein Azure-Dienst. Sicherheitsrichtlinien werden im Whitepaper Azure Security, Privacy, and Compliance (Azure-Sicherheit, -Datenschutz und -Kompatibilität) beschrieben.

Die Daten werden auf Microsoft Azure-Servern gespeichert. Für Konten im Azure-Portal sind die Kontobeschränkungen im Dokument Trusted Cloud: Microsoft Azure Security, Privacy, and Compliance(in englischer Sprache) beschrieben.

Der Zugriff auf Ihre Daten durch Microsoft-Mitarbeiter ist eingeschränkt. Wir werden nur mit Ihrer Erlaubnis und ausschließlich dann auf Ihre Daten zugreifen, wenn es erforderlich ist, Sie bei der Verwendung von Application Insights zu unterstützen.

Aggregierte Daten in den Anwendungen unserer Kunden (z. B. Datenraten und die durchschnittliche Größe von Ablaufverfolgungen) werden zur Verbesserung von Application Insights verwendet.

Könnte die Telemetrie eines anderen Benutzers meine Application Insights-Daten beeinträchtigen?

Jemand könnte mithilfe des Instrumentierungsschlüssels mehr Telemetrie an Ihr Konto senden. Dieser Schlüssel findet sich im Code Ihrer Webseiten. Bei genügend zusätzlichen Daten würden Ihre Metriken die Leistung und Nutzung Ihrer App nicht mehr ordnungsgemäß wiedergeben.

Wenn Sie Code für andere Projekte freigeben, sollten Sie Ihren Instrumentationsschlüssel entfernen.

Werden die Daten verschlüsselt?

Alle Daten sind im Ruhezustand und während der Übertragung zwischen Rechenzentren verschlüsselt.

Werden die Daten während der Übertragung von meiner Anwendung zu Application Insights-Servern verschlüsselt?

Ja. Wir verwenden HTTPS zum Senden von Daten an das Portal aus nahezu allen SDKs, darunter Webserver, Geräte und HTTPS-Webseiten.

Erstellt das SDK einen temporären lokalen Speicher?

Ja. Bestimmte Telemetriekanäle speichern Daten dauerhaft lokal, wenn ein Endpunkt nicht erreicht werden kann. In den folgenden Absätzen wird beschrieben, welche Frameworks und Telemetriekanäle betroffen sind:

• Telemetriekanäle, die lokalen Speicher nutzen, erstellen temporäre Dateien in den Verzeichnissen TEMP oder APPDATA, die auf das Konto beschränkt sind, in dem Ihre Anwendung ausgeführt wird. Dieser Fall kann eintreten, wenn ein Endpunkt vorübergehend nicht verfügbar war oder das Drosselungslimit erreicht wurde. Nachdem das Problem gelöst wurde, setzt der Telemetriekanal das Senden aller neuen und dauerhaft gespeicherten Daten fort.
• Diese dauerhaft gespeicherten Daten werden nicht lokal verschlüsselt. Falls dies ein Problem darstellt, überprüfen Sie die Daten, und schränken Sie die Sammlung von privaten Daten ein. Weitere Informationen finden Sie unter Exportieren und Löschen personenbezogener Daten.
• Wenn ein Kunde dieses Verzeichnis mit bestimmten Sicherheitsanforderungen konfigurieren muss, kann diese Konfiguration pro Framework erfolgen. Stellen Sie sicher, dass der Prozess, der Ihre Anwendung ausführt, Schreibzugriff auf dieses Verzeichnis hat. Stellen Sie außerdem sicher, dass dieses Verzeichnis geschützt ist, um zu vermeiden, dass Telemetrie von unbefugten Benutzern gelesen wird.

Java

Der Ordner C:\Users\username\AppData\Local\Temp wird für das dauerhafte Speichern von Daten verwendet. Dieser Speicherort kann nicht über das config-Verzeichnis konfiguriert werden, und die Zugriffsberechtigungen für diesen Ordner sind auf einen bestimmten Benutzer mit den erforderlichen Anmeldeinformationen beschränkt. Weitere Informationen finden Sie unter Implementierung.

.NET

Standardmäßig verwendet ServerTelemetryChannel den lokalen Anwendungsdaten-Ordner des aktuellen Benutzers (%localAppData%\Microsoft\ApplicationInsights) oder den Temp-Ordner (%TMP%). Weitere Informationen finden Sie unter Implementierung.

Per Konfigurationsdatei:

<TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel,   Microsoft.AI.ServerTelemetryChannel">
    <StorageFolder>D:\NewTestFolder</StorageFolder>
</TelemetryChannel>

Per Code:

• Entfernen Sie ServerTelemetryChannel aus der Konfigurationsdatei.

• Fügen Sie diesen Codeausschnitt zu Ihrer Konfiguration hinzu:

  ServerTelemetryChannel channel = new ServerTelemetryChannel();
  channel.StorageFolder = @"D:\NewTestFolder";
  channel.Initialize(TelemetryConfiguration.Active);
  TelemetryConfiguration.Active.TelemetryChannel = channel;
  

NetCore

Standardmäßig verwendet ServerTelemetryChannel den lokalen Anwendungsdaten-Ordner des aktuellen Benutzers (%localAppData%\Microsoft\ApplicationInsights) oder den Temp-Ordner (%TMP%). Weitere Informationen finden Sie unter Implementierung.

In einer Linux-Umgebung ist der lokale Speicher deaktiviert, sofern kein Speicherordner angegeben wird.

Hinweis

Ab Version 2.15.0-beta3 wird nun automatisch lokaler Speicher für Linux, Mac und Windows erstellt. Für Nicht-Windows-Systeme erstellt das SDK automatisch einen lokalen Speicherordner auf Grundlage der folgenden Logik:

• ${TMPDIR}: Wenn die Umgebungsvariable ${TMPDIR} festgelegt ist, wird dieser Speicherort verwendet.
• /var/tmp: Wenn der vorherige Speicherort nicht vorhanden ist, versuchen wir /var/tmp.
• /tmp: Wenn beide vorherige Speicherorte nicht vorhanden sind, versuchen wir tmp.
• Wenn keiner dieser Speicherorte vorhanden ist, wird kein lokaler Speicher erstellt, wodurch eine manuelle Konfiguration weiterhin erforderlich ist.

Ausführliche Informationen zur Implementierung finden Sie unter ServerTelemetryChannel speichert Telemetriedaten im Standardordner während vorübergehender Fehler in Nicht-Windows-Umgebungen.

Der folgende Codeausschnitt zeigt, wie Sie ServerTelemetryChannel.StorageFolder in der ConfigureServices()-Methode Ihrer Startup.cs-Klasse festlegen:

services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});

Weitere Informationen finden Sie unter Benutzerdefinierte Konfiguration von AspNetCore.

Node.js

Standardmäßig wird %TEMP%/appInsights-node{INSTRUMENTATION KEY} für die dauerhafte Speicherung von Daten verwendet. Die Berechtigungen für den Zugriff auf diesen Ordner sind auf den aktuellen Benutzer und Administratoren beschränkt. Weitere Informationen finden Sie unter Implementierung.

Das Ordnerpräfix appInsights-node kann überschrieben werden, indem der Laufzeitwert der statischen Variablen Sender.TEMPDIR_PREFIX geändert wird, die sich in Sender.ts befindet.

JavaScript (Browser)

Der HTML5-Sitzungsspeicher wird verwendet, um Daten dauerhaft zu speichern. Es werden zwei separate Puffer verwendet: AI_buffer und AI_sent_buffer. Telemetriedaten, die als Batch gesammelt werden und darauf warten, gesendet zu werden, werden in AI_buffer gespeichert. Die soeben gesendeten Telemetriedaten werden in AI_sent_buffer abgelegt, bis der Erfassungsserver antwortet, dass sie erfolgreich empfangen wurden.

Wurden die Telemetriedaten erfolgreich empfangen, werden sie aus allen Puffern entfernt. Bei vorübergehenden Fehlern (z. B. wenn ein Benutzer die Netzwerkkonnektivität verliert) verbleiben die Telemetriedaten in AI_buffer, bis sie erfolgreich empfangen wurden oder der Erfassungsserver antwortet, dass sie ungültig sind (z. B. ein ungültiges Schema aufweisen oder zu alt sind).

Telemetriepuffer können deaktiviert werden, indem enableSessionStorageBuffer auf false festgelegt wird. Wenn der Sitzungsspeicher ausgeschaltet ist, wird stattdessen ein lokales Array als dauerhafter Speicher verwendet. Da das JavaScript SDK auf einem Clientgerät ausgeführt wird, kann der Benutzer über die Entwicklertools des Browsers auf diesen Speicherort zugreifen.

OpenCensus Python

Das OpenCensus Python-SDK verwendet standardmäßig den aktuellen Benutzerordner %username%/.opencensus/.azure/. Die Berechtigungen für den Zugriff auf diesen Ordner sind auf den aktuellen Benutzer und Administratoren beschränkt. Weitere Informationen finden Sie unter Implementierung. Der Ordner mit Ihren beibehaltenen Daten wird nach der Python-Datei benannt, die die Telemetriedaten generiert hat.

Sie können den Speicherort Ihrer Speicherdatei ändern, indem Sie den Parameter storage_path an den Konstruktor des Exporters übergeben, den Sie verwenden.

AzureLogHandler(
  connection_string='InstrumentationKey=00000000-0000-0000-0000-000000000000',
  storage_path='<your-path-here>',
)

Wie sende ich mit TLS 1.2 Daten an Application Insights?

Um die Sicherheit von Daten bei der Übertragung an die Application Insights-Endpunkte sicherzustellen, wird Kunden dringend empfohlen, ihre Anwendung so zu konfigurieren, dass mindestens Transport Layer Security (TLS) 1.2 verwendet wird. Ältere Versionen von TLS/Secure Sockets Layer (SSL) wurden als gefährdet eingestuft. Sie funktionieren derzeit zwar noch, um Abwärtskompatibilität zu gewährleisten, werden aber nicht empfohlen. Die IT-Branche ist bemüht, die Unterstützung dieser älteren Protokolle baldmöglichst zu beenden.

Das PCI Security Standards Council hat den 30. Juni 2018 als Termin für die Deaktivierung älterer Versionen von TLS/SSL und das Upgrade auf sicherere Protokolle festgelegt. Wenn Azure keine Legacyunterstützung mehr anbietet und Ihre Anwendung/Clients nicht mindestens über TLS 1.2 kommunizieren können, können Sie so keine Daten mehr an Application Insights senden. Welche Methode Sie verwenden, um die TLS-Unterstützung Ihrer Anwendung zu testen und zu überprüfen, hängt vom Betriebssystem bzw. von der Plattform sowie von der Sprache bzw. vom Framework ab, die von Ihrer Anwendung verwendet werden.

Es wird nicht empfohlen, Ihre Anwendung explizit auf die ausschließliche Verwendung von TLS 1.2 festzulegen, sofern nicht erforderlich. Dadurch werden möglicherweise Sicherheitsfeatures auf Plattformebene deaktiviert, mit deren Hilfe neuere, sicherere Protokolle wie TLS 1.3 automatisch erkannt und genutzt werden können, sobald diese verfügbar sind. Es wird empfohlen, gründlich zu überprüfen, ob der Code einer Anwendung Hartcodierungen bestimmter TLS/SSL-Versionen enthält.

Plattform-/sprachspezifischer Leitfaden

Plattform/Sprache	Support	Weitere Informationen
Azure App Services	Wird unterstützt, Konfiguration möglicherweise erforderlich	Unterstützung wurde im April 2018 angekündigt. Informationen zur Ankündigung finden Sie in den Konfigurationsdetails.
Azure Function-Apps	Wird unterstützt, Konfiguration möglicherweise erforderlich	Unterstützung wurde im April 2018 angekündigt. Informationen zur Ankündigung finden Sie in den Konfigurationsdetails.
.NET	Wird langfristig unterstützt (LTS, Long Term Support)	Ausführliche Konfigurationsinformationen finden Sie in diesen Anweisungen.
Application Insights-Agent	Wird unterstützt, Konfiguration erforderlich	Der Application Insights-Agent greift zur Unterstützung von TLS 1.2 auf die Betriebssystemkonfiguration + .NET-Konfiguration zurück.
Node.js	Wird in Version 10.5.0 unterstützt, Konfiguration möglicherweise erforderlich	Informationen zu anwendungsspezifischen Konfigurationen finden Sie in der offiziellen Dokumentation zu TLS/SSL bei Node.js.
Java	Wird unterstützt, JDK-Unterstützung für TLS 1.2 seit JDK 6 Update 121 und JDK 7.	Bei JDK 8 wird standardmäßig TLS 1.2 verwendet.
Linux	Linux-Distributionen greifen zur Unterstützung von TLS 1.2 tendenziell auf OpenSSL zurück.	Überprüfen Sie anhand des OpenSSL-Änderungsprotokolls, ob Ihre Version von OpenSSL unterstützt wird.
Windows 8.0 bis 10	Wird unterstützt und ist standardmäßig aktiviert.	Zur Bestätigung, dass Sie weiterhin die Standardeinstellungen verwenden.
Windows Server 2012 bis 2016	Wird unterstützt und ist standardmäßig aktiviert.	Zur Bestätigung, dass Sie weiterhin die Standardeinstellungen verwenden.
Windows 7 SP1 und Windows Server 2008 R2 SP1	Wird unterstützt, ist jedoch standardmäßig deaktiviert.	Details zur Aktivierung finden Sie auf der Seite Transport Layer Security (TLS) registry settings (Registrierungseinstellungen für Transport Layer Security (TLS)).
Windows Server 2008 SP2	Unterstützung für TLS 1.2 muss aktualisiert werden.	Informationen hierzu finden Sie unter Update zum Hinzufügen der Unterstützung von TLS 1.1 und TLS 1.2 in Windows Server 2008 SP2.
Windows Vista	Wird nicht unterstützt.	–

Prüfen, welche Version von OpenSSL von Ihrer Linux-Distribution ausgeführt wird

Zum Prüfen, welche Version von OpenSSL installiert ist, öffnen Sie das Terminal und führen Sie folgenden Befehl aus:

openssl version -a

Ausführen einer TLS-1.2-Testtransaktion unter Linux

Zum Ausführen eines vorläufigen Tests, um festzustellen, ob Ihr Linux-System über TLS 1.2 kommunizieren kann, öffnen Sie das Terminal und führen Sie folgenden Befehl aus:

openssl s_client -connect bing.com:443 -tls1_2

Personenbezogene Daten, die in Application Insights gespeichert sind

Eine ausführliche Behandlung dieses Thema finden Sie unter Verwalten personenbezogener Daten in Log Analytics und Application Insights.

Können meine Benutzer Application Insights abschalten?

Nicht direkt. Wir bieten keinen Schalter, mit dem Ihre Benutzer Application Insights abschalten können.

Sie können eine solche Funktion in Ihrer Anwendung implementieren. Alle SDKs enthalten eine API-Einstellung, mit der die Telemetrie-Erfassung deaktiviert wird.

Von Application Insights gesendete Daten

Die SDKs sind je nach Plattform unterschiedlich, und es gibt verschiedene Komponenten, die Sie installieren können. Weitere Informationen finden Sie unter Übersicht über Application Insights. Jede Komponente sendet unterschiedliche Daten.

Klassen von in verschiedenen Szenarien gesendeten Daten

Aktion	Gesammelte Datenklassen (siehe nächste Tabelle)
Hinzufügen des Application Insights SDK zu einem .NET-Webprojekt	ServerContext Inferred Perf counters Requests Ausnahmen Sitzung users
Application Insights-Agent unter IIS installieren	Abhängigkeiten ServerContext Inferred Perf counters
Hinzufügen des Application Insights SDK zu einer Java-Web-App	ServerContext Inferred Anforderung Sitzung users
Hinzufügen des JavaScript-SDK zu einer Webseite	ClientContext Inferred Seite ClientPerf Ajax
Definieren von Standardeigenschaften	Properties für alle standardmäßigen und benutzerdefinierten Ereignisse
Aufrufen von TrackMetric	Numerische Werte Eigenschaften
Aufrufen von Track*	Ereignisname Eigenschaften
Aufrufen von TrackException	Ausnahmen Stapelabbild Eigenschaften
SDK kann keine Daten sammeln. Beispiel: – auf Leistungsindikatoren kann nicht zugegriffen werden – Ausnahme beim Telemetrieinitialisierer	SDK-Diagnose

Weitere Informationen zu SDKs für andere Plattformen finden Sie in den entsprechenden Dokumenten.

Die Klassen der gesammelten Daten

Gesammelte Datenklasse	Umfasst (keine vollständige Liste)
Eigenschaften	Alle Daten – bestimmt durch Code
DeviceContext	Id, IP, Gebietsschema, Gerätemodell, Netzwerk, Netzwerktyp, OEM-Name, Bildschirmauflösung, Rolleninstanz, Rollenname, Gerätetyp
ClientContext	Betriebssystem, Gebietsschema, Sprache, Netzwerk, Fensterauflösung
Sitzung	session id
ServerContext	Computername, Gebietsschema, Betriebssystem, Gerät, Benutzersitzung, Benutzerkontext, Vorgang
Inferred	Geolocation anhand IP-Adresse, Zeitstempel, Betriebssystem, Browser
Metriken	Metrikname und -wert
Events	Ereignisname und -wert
PageViews	URL und Seitenname oder Bildschirmname
Client perf	URL-/Seitenname, Browserladezeit
Ajax	HTTP-Aufrufe von der Webseite an den Server
Requests	URL, Dauer, Antwortcode
Abhängigkeiten	Typ (SQL, HTTP,...), Verbindungszeichenfolge oder URI Sync/Async, Dauer, Erfolg, SQL-Anweisung (mit Application Insights-Agent)
Ausnahmen	Typ, Meldung, Aufrufliste, Quelldatei, Zeilennummer, thread id
Crashes	Process id, parent process id, crash thread id; Anwendungspatch, id, Build; Typ der Ausnahme, Adresse, Ursache; abgeblendete Symbole und Registerkarten, binäre Start- und Endadressen, binärer Name und Pfad, CPU-Typ
Trace	Meldung und Schweregrad
Perf counters	Prozessorzeit, verfügbarer Speicher, Anforderungsrate, Ausnahmerate, private Bytes verarbeiten, E/A-Rate, Anforderungsdauer, Länge der Anforderungswarteschlange
Verfügbarkeit	Webtestantwortcode, Dauer der einzelnen Testschritte, Testname, Zeitstempel, Erfolg, Antwortzeit, Testverzeichnis
SDK-Diagnose	Ablaufverfolgungsmeldung oder -ausnahme

Sie können einige der Daten durch Bearbeiten von „ApplicationInsights.config“ abschalten.

Hinweis

Die Client-IP-Adresse wird zum Ableiten des geografischen Standorts verwendet. Die IP-Daten werden jedoch standardmäßig nicht mehr gespeichert, und es werden ausschließlich Nullen in das entsprechende Feld geschrieben. Weitere Informationen zur Verarbeitung personenbezogener Daten finden Sie unter Verwalten personenbezogener Daten in Log Analytics und Application Insights. Wenn Sie IP-Adressdaten speichern müssen, finden Sie unter Geolocation und Verarbeitung von IP-Adressen Informationen zu den jeweiligen Optionen.

Kann ich Daten ändern oder aktualisieren, nachdem Sie gesammelt wurden?

Nein. Daten sind schreibgeschützt und können nur über die Bereinigungsfunktion gelöscht werden. Weitere Informationen finden Sie im Leitfaden für personenbezogene Daten, die in Log Analytics und Application Insights gespeichert sind.

Häufig gestellte Fragen

Dieser Abschnitt enthält Antworten auf häufig gestellte Fragen.

Was geschieht mit den Telemetriedaten von Application Insight, wenn ein Server oder Gerät die Verbindung mit Azure verliert?

Alle unsere SDKs, einschließlich des Web-SDKs, beinhalten zuverlässigen Transport oder stabilen Transport. Wenn der Server oder das Gerät die Verbindung mit Azure verliert, werden die Telemetriedaten lokal im Dateisystem gespeichert (Server-SDKs) oder im HTML5-Sitzungsspeicher (Web-SDK). Das SDK versucht regelmäßig, diese Telemetriedaten zu senden, bis unser Erfassungsdienst diese als „veraltet“ erachtet (48 Stunden für Protokolle, 30 Minuten für Metriken). Veraltete Telemetriedaten werden gelöscht. In einigen Fällen, z. B. wenn der lokale Speicher voll ist, wird kein Wiederholungsversuch unternommen.

Werden beim Senden von Telemetriedaten auch personenbezogene Daten übertragen?

Sie können personenbezogene Daten senden, wenn Ihr Code solche Daten sendet. Es kann auch vorkommen, wenn Variablen in den Stapelüberwachungen personenbezogene Daten enthalten. Ihr Entwicklungsteam sollte Risikobewertungen durchführen, um sicherzustellen, dass personenbezogene Daten ordnungsgemäß behandelt werden. Weitere Informationen zu Datenaufbewahrung und Datenschutz.

Alle Oktette der Clientwebadresse werden immer auf 0 festgelegt, nachdem die Golocationattribute nachgeschlagen wurden.

Das Application Insights JavaScript SDK fügt beim automatischen Vervollständigen standardmäßig keine personenbezogenen Daten ein. Es kann aber sein, dass personenbezogene Daten, die in Ihrer Anwendung genutzt werden, vom SDK übernommen werden (z. B. vollständige Namen in window.title oder Konto-IDs in XHR-URL-Abfrageparametern). Fügen Sie für die Datenmaskierung benutzerdefinierter Daten einen Telemetrieinitialisierer hinzu.