Häufig gestellte Fragen zu Network Watcher

Network Watcher bietet eine Sammlung von Tools zum Überwachen, Diagnostizieren und Anzeigen von Metriken sowie Aktivieren oder Deaktivieren von Protokollen für IaaS-Ressourcen (Infrastructure-as-a-Service). Dazu gehören virtuelle Maschinen, virtuelle Netzwerke, Anwendungsgateways, Lastenausgleichsmodule und andere Ressourcen in einem virtuellen Azure-Netzwerk. Dabei handelt es sich nicht um eine Lösung für die Überwachung der PaaS-Infrastruktur (Platform-as-a-Service) oder zum Abrufen von Analysen zu Web- oder Mobiltechnologien.

Network Watcher bietet drei große Gruppen von Funktionen:

• Überwachung
  • In der Topologieansicht sehen Sie die Ressourcen in Ihrem virtuellen Netzwerk und die Beziehungen zwischen ihnen.
  • Mit dem Verbindungsmonitor können Sie die Konnektivität und Latenz zwischen Endpunkten innerhalb und außerhalb von Azure überwachen.
• Netzwerkdiagnosetools
  • Mit der IP-Datenflussüberprüfung können Sie Probleme beim Filtern von Datenverkehr auf Ebene einer virtuellen Maschine erkennen.
  • Mit der NSG-Diagnose können Sie Probleme beim Filtern von Datenverkehr auf Ebene einer virtuellen Maschine, einer VM-Skalierungsgruppe oder eines Anwendungsgateways erkennen.
  • Nächster Hop unterstützt Sie beim Überprüfen von Datenverkehrsrouten und Erkennen von Routingproblemen.
  • Die Problembehandlung für Verbindungen ermöglicht eine einmalige Konnektivitäts- und Latenzüberprüfung zwischen einer virtuellen Maschine und einem Bastionhost, Anwendungsgateway oder einer anderen virtuellen Maschine.
  • Mit der Paketerfassung können Sie den Datenverkehr Ihrer virtuellen Maschine erfassen.
  • Die VPN-Problembehandlung führt mehrere Diagnoseprüfungen für VPN-Gateways und -Verbindungen aus, um beim Beheben von Problemen zu helfen.
• Verkehr
  • Mit Datenflussprotokollen für virtuelle Netzwerke (VNets) und Datenflussprotokollen für Netzwerksicherheitsgruppen (NSGs) können Sie den Netzwerkdatenverkehr protokollieren, der Ihre virtuellen Netzwerke und Netzwerksicherheitsgruppen durchläuft.
  • Traffic Analytics verarbeitet die Daten Ihrer Datenflussprotokolle für Netzwerksicherheitsgruppen, sodass Sie Ihren Netzwerkdatenverkehr visualisieren, abfragen, analysieren und verstehen können.

Weitere Informationen finden Sie in der Übersicht zu Network Watcher.

Preise zu verschiedenen Network Watcher-Komponenten finden Sie unter Network Watcher Preise.

Weitere Informationen zu den Regionen, die Network Watcher unterstützen, finden Sie unter Network Watcher Regionen.

Eine ausführliche Liste der erforderlichen Berechtigungen für die einzelnen Funktionen von Network Watcher finden Sie unter Erforderliche Berechtigungen der rollenbasierten Zugriffssteuerung von Azure zum Verwenden von Network Watcher-Funktionen.

Der Network Watcher-Dienst wird automatisch für jedes Abonnement aktiviert. Wenn Sie die automatische Aktivierung für Network Watcher deaktiviert haben, müssen Sie Network Watcher manuell aktivieren. Weitere Informationen finden Sie unter Aktivieren oder Deaktivieren von Azure Network Watcher.

Die übergeordnete Network Watcher-Ressource wird mit einer eindeutigen Instanz in den einzelnen Regionen bereitgestellt. Standardbenennungsformat: NetworkWatcher_RegionName. Beispiel: „NetworkWatcher_centralus“ ist die Network Watcher-Ressource für die Region „USA, Mitte“. Sie können den Namen der Network Watcher-Instanz mithilfe von PowerShell oder der REST-API anpassen.

Network Watcher muss lediglich einmal pro Region und Abonnement aktiviert werden, damit die zugehörigen Features funktionieren. Ein Network Watcher wird in einer Region aktiviert, indem in dieser Region eine Network Watcher-Instanz erstellt wird.

Die Network Watcher-Ressource stellt den Back-End-Dienst für Network Watcher dar, die vollständig von Azure verwaltet wird. Sie können jedoch die Network Watcher-Ressource erstellen oder löschen, um sie in einer bestimmten Region zu aktivieren oder zu deaktivieren. Weitere Informationen finden Sie unter Aktivieren oder Deaktivieren von Azure Network Watcher.

Nein, das Verschieben der Network Watcher-Ressource oder einer ihrer untergeordneten Ressourcen von einer Region in eine andere hinweg wird nicht unterstützt. Weitere Informationen finden Sie unter Unterstützung von Verschiebungsvorgängen für Netzwerkressourcen.

Ja, das Verschieben der Network Watcher-Ressource zwischen Ressourcengruppen wird unterstützt. Weitere Informationen finden Sie unter Unterstützung von Verschiebungsvorgängen für Netzwerkressourcen.

NetworkWatcherRG ist eine Ressourcengruppe, die automatisch für Network Watcher-Ressourcen erstellt wird. Beispielsweise werden regionale Network Watcher-Instanzen und die NSG-Datenflussprotokollressourcen in der Ressourcengruppe NetworkWatcherRG erstellt. Sie können den Namen der Network Watcher-Ressourcengruppe mithilfe von PowerShell, der Azure CLI oder der REST-API anpassen.

Azure Network Watcher speichert keine Kundendaten, außer für den Verbindungsmonitor. Der Verbindungsmonitor speichert Kundendaten, die automatisch von Network Watcher in einer einzelnen Region gespeichert werden, um die Anforderungen an die Datenresidenz in der Region zu erfüllen.

Network Watcher weist die folgenden Grenzwerte auf:

Ja, der Network Watcher-Dienst ist standardmäßig zonenresilient.

Es ist keine Konfiguration erforderlich, um Zonenresilienz zu ermöglichen. Zonenresilienz für Network Watcher-Ressourcen ist standardmäßig verfügbar und wird vom Dienst selbst verwaltet.

Der Network Watcher-Agent ist für alle Network Watcher-Features erforderlich, die Datenverkehr von einer VM generieren oder abfangen.

Die Network Watcher-Erweiterung wird für die Features Verbindungsmonitor und Paketerfassung sowie die Problembehandlung bei Verbindungen (Verbindungstests) benötigt.

Die aktuelle Version der Network Watcher-Erweiterung ist 1.4.3783.1. Weitere Informationen finden Sie unter Aktualisieren der Azure Network Watcher-Erweiterung auf die neueste Version.

• Linux: Der Network Watcher-Agent verwendet verfügbare Ports ab port 50000, bis er port 65535 erreicht.
• Windows: Der Network Watcher-Agent verwendet die Ports, mit denen das Betriebssystem antwortet, wenn nach verfügbaren Ports abgefragt wird.

Der Network Watcher-Agent erfordert ausgehende TCP-Konnektivität zu 169.254.169.254 über port 80 und zu 168.63.129.16 über port 8037. Der Agent verwendet diese IP-Adressen für die Kommunikation mit der Azure-Plattform.

Nein, klassische VMs werden vom Verbindungsmonitor nicht unterstützt. Weitere Informationen finden Sie unter Plattformgestützte Migration von IaaS-Ressourcen vom klassischen Bereitstellungsmodell zu Azure Resource Manager.

Die Topologie kann von Nicht-Azure zu Azure nur ergänzt werden, wenn sich die Azure-Zielressource und die Verbindungsmonitor-Ressource in derselben Region befinden.

Dieselbe Azure-VM kann nicht mit unterschiedlichen Konfigurationen in demselben Verbindungsmonitor verwendet werden. Beispielsweise wird die Verwendung derselben VM mit einem Filter und ohne einen Filter in demselben Verbindungsmonitor nicht unterstützt.

Die im Dashboard des Verbindungsmonitors angezeigten Probleme werden während der Topologieerkennung oder der Hoperkundung gefunden. Es kann Fälle geben, in denen der eingestellte Schwellenwert für % Verlust oder RTT erreicht wird, aber keine Probleme bei den Hops gefunden werden.

Im Verbindungsmonitor (klassisch) gibt es keine Option zur Protokollauswahl. Tests im Verbindungsmonitor (klassisch) verwenden nur das TCP-Protokoll. Aus diesem Grund erstellen wir bei der Migration eine TCP-Konfiguration in Tests im neuen Verbindungsmonitor.

Es gibt derzeit eine regionale Grenze, wenn ein Endpunkt Azure Monitor und Arc-Agents mit dem zugeordneten Log Analytics-Arbeitsbereich verwendet. Aufgrund dieser Einschränkung muss sich der zugeordnete Log Analytics-Arbeitsbereich in derselben Region wie der Arc-Endpunkt befinden. Daten, die in einzelne Arbeitsbereiche eingelesen werden, können für eine einzelne Ansicht zusammengefasst werden, siehe Abfragedaten in Log Analytics-Arbeitsbereichen, -Anwendungen und -Ressourcen in Azure Monitor.

Mit Datenflussprotokollen können Sie 5-Tupel-Flussinformationen zu Ihrem Azure-IP-Datenverkehr protokollieren, der über eine Netzwerksicherheitsgruppe oder ein virtuelles Azure-Netzwerk durchläuft. Die unbearbeiteten Datenflussprotokolle werden in ein Azure Storage-Konto geschrieben. Von dort aus können Sie sie nach Bedarf weiter verarbeiten, analysieren, abfragen oder exportieren.

Die Daten von Datenflussprotokollen werden außerhalb des Pfads Ihres Netzwerkdatenverkehrs erfasst und wirken sich daher nicht auf den Netzwerkdurchsatz oder die -latenz aus. Sie können Datenflussprotokolle erstellen oder löschen, ohne dass sich dies auf die Netzwerkleistung auswirkt.

Protokolle der Netzwerksicherheitsgruppe zeichnen den Datenverkehr auf, der durch eine Netzwerksicherheitsgruppe fließt. Andererseits gibt die NSG-Diagnose alle Netzwerksicherheitsgruppen zurück, die Ihr Datenverkehr durchläuft, sowie die Regeln jeder Netzwerksicherheitsgruppe, die auf diesen Datenverkehr angewandt werden. Mit der NSG-Diagnose können Sie sich vergewissern, dass Ihre Netzwerksicherheitsgruppen-Regeln wie erwartet angewandt werden.

Nein. Datenflussprotokolle für Netzwerksicherheitsgruppen unterstützen keine ESP- und AH-Protokolle.

Nein. Datenflussprotokolle für Netzwerksicherheitsgruppen unterstützen das Internet Control Message-Protokoll nicht.

Ja. Die zugeordnete Datenflussprotokoll-Ressource wird ebenfalls gelöscht. Datenflussprotokolldaten werden im Speicherkonto für den im Datenflussprotokoll konfigurierten Aufbewahrungszeitraum aufbewahrt.

Ja, aber Sie müssen die zugeordnete Datenflussprotokollressource löschen. Nachdem Sie die Netzwerksicherheitsgruppe migriert haben, können Sie die Datenflussprotokolle neu erstellen, um die Datenflussprotokollierung für sie zu aktivieren.

Ja, Sie können ein Speicherkonto aus einem anderen Abonnement verwenden, solange sich dieses Abonnement in derselben Region der Netzwerksicherheitsgruppe befindet und demselben Microsoft Entra-Mandanten der Netzwerksicherheitsgruppe oder des Abonnements des virtuellen Netzwerks zugeordnet ist.

Sie müssen mindestens ein Virtuelles Netzwerkflussprotokoll im Abonnement aktivieren. Datenverkehrsanalyse verarbeitet Daten nur aus aktivierten Flussprotokollen. Durch die Konfiguration eines Flussprotokolls wird sichergestellt, dass Traffic Analytics auf Netzwerkaktivitäten für die Ressourcen in diesem Abonnement zugreifen und diese analysieren kann.

Um ein Speicherkonto hinter einer Firewall zu verwenden, müssen Sie vertrauenswürdigen Azure-Diensten den Zugriff auf Ihr Speicherkonto gestatten:

1. Navigieren Sie zu dem Speicherkonto, indem Sie den Namen des Speicherkontos in das Suchfeld oben im Portal eingeben.
2. Wählen Sie unter Sicherheit + Netzwerk die Option Netzwerk aus und dann Firewalls und virtuelle Netzwerke.
3. Wählen Sie bei Öffentlicher Netzwerkzugang die Option Aktivierung von ausgewählten virtuellen Netzwerken und IP-Adressen aus. Aktivieren Sie unter Ausnahmen das Kontrollkästchen neben Azure-Dienste auf der Liste der vertrauenswürdigen Dienste für den Zugriff auf dieses Speicherkonto zulassen.
4. Aktivieren Sie Datenflussprotokolle, indem Sie mithilfe des Speicherkontos ein Datenflussprotokoll für Ihre Zielressource erstellen. Weitere Informationen finden Sie unter Erstellen eines Datenflussprotokolls.

Sie können die Speicherprotokolle nach einigen Minuten überprüfen. Es sollte ein aktualisierter Zeitstempel oder eine neue JSON-Datei vorhanden sein.

Derzeit unterstützt ein Speicherkonto 100 Regeln, und jede Regel kann 10 Blobpräfixe enthalten. Wenn Sie den Grenzwert erreichen, können Sie die Aufbewahrungsrichtlinie auf 0 festlegen, wenn Sie neue Protokolle für den virtuellen Netzwerkfluss aktivieren und dann manuell eine Aufbewahrungsregel für das Abonnement hinzufügen.

Führen Sie die folgenden Schritte aus, um eine Regel zum Abonnieren von Aufbewahrungsrichtlinien zu erstellen:

1. Navigieren Sie zu dem Speicherkonto, indem Sie den Namen des Speicherkontos in das Suchfeld oben im Portal eingeben.
2. Wählen Sie unter "Datenverwaltung" die Option "Lebenszyklusverwaltung" aus.
3. Wählen Sie +Regel hinzufügen aus.
4. Wählen Sie im Abschnitt "Details" die folgenden Einstellungen aus: Regelbereich:Blobs mit Filtern beschränken, Blobtyp:Block-Blobs und Blob-Untertyp:Base-Blobs.
5. Konfigurieren Sie im Abschnitt "Base blobs" Ihre Aufbewahrungseinstellungen .
6. Formatieren Sie im Abschnitt "Filtersatz " das Blob-Präfix wie folgt: "insights-logs-flowlogflowevent/flowLogResourceID=/<yourSubscriptionId>_NETWORKWATCHERRG"
7. Wählen Sie Hinzufügen aus.

Die Regel mit kürzerer Aufbewahrungsdauer hat Vorrang.

Die Netzwerküberwachung verfügt über einen integrierten Fallbackmechanismus, der beim Herstellen einer Verbindung mit einem Speicherkonto hinter einer Firewall verwendet wird (Firewall aktiviert). Es versucht, mithilfe eines Schlüssels eine Verbindung mit dem Speicherkonto herzustellen, und wenn dies fehlschlägt, wechselt es zu einem Token. In diesem Fall wird ein 403-Fehler im Speicherkontoaktivitätsprotokoll protokolliert.

Ja, Network Watcher unterstützt das Senden von Datenflussprotokolldaten an ein Speicherkonto, das mit einem privaten Endpunkt aktiviert ist.

Datenflussprotokolle sind ohne weitere Konfiguration mit Dienstendpunkten kompatibel. Weitere Informationen finden Sie unter Aktivieren eines Dienstendpunkts.

In Version 2 der Datenflussprotokolle wurde das Konzept des Flowstatus eingeführt, gemäß dem Informationen zu übertragenen Bytes und Paketen gespeichert werden. Weitere Informationen finden Sie unter „Datenflussprotokollierung für Netzwerksicherheitsgruppen“ im Abschnitt Protokollformat.

Nein. Eine Schreibschutzsperre für eine Netzwerksicherheitsgruppe verhindert das Erstellen des entsprechenden Datenflussprotokolls für Netzwerksicherheitsgruppen.

Ja. Eine Löschschutzsperre für eine Netzwerksicherheitsgruppe verhindert das Erstellen oder Ändern des entsprechenden Datenflussprotokolls für Netzwerksicherheitsgruppen nicht.

Ja. Sie können Datenflussprotokolle für Netzwerksicherheitsgruppen über Azure Resource Manager-Vorlagen (ARM-Vorlagen) automatisieren. Weitere Informationen finden Sie unter Konfigurieren von NSG-Datenflussprotokollen mithilfe einer ARM-Vorlage (Azure Resource Manager).

Ja, virtuelle Netzwerke und Netzwerksicherheitsgruppen können sich in unterschiedlichen Regionen als in Ihrer Log Analytics-Arbeitsbereichsregion befinden.

Ja.

In der Dropdownliste für die Ressourcenauswahl im Datenverkehrsanalysedashboard muss die Ressourcengruppe der Virtual Network-Ressource ausgewählt werden, nicht die Ressourcengruppe des virtuellen Computers oder der Netzwerksicherheitsgruppe.

Die Datenverkehrsanalyse führt alle 6 Stunden einen Ressourcenermittlungsscan durch, um neue VMs, NICs, virtuelle Netzwerke und Subnetze zu identifizieren. Wenn nach dem letzten Ermittlungszyklus eine neue VM oder NIC erstellt wird und Ablaufdaten vor der nächsten Ermittlung gesammelt werden, kann die Datenverkehrsanalyse den Datenverkehr noch nicht einer bekannten Ressource zuordnen. Daher werden diese Ressourcen vorübergehend als unbekannt in der Analyseansicht bezeichnet.

Ja, Sie können den öffentlichen Zugriff auf die Datensammlungsendpunktressource (DCE) deaktivieren, um den öffentlichen eingehenden Datenverkehr zu blockieren. Die Erfassung funktioniert weiterhin, ohne die DCE-Ressource einem Private Link-Bereich in Azure Monitor zuzuordnen.

Ja. Wenn Sie einen vorhandenen Arbeitsbereich auswählen, stellen Sie sicher, dass er in die neue Abfragesprache migriert wurde. Wenn Sie den Arbeitsbereich nicht aktualisieren möchten, müssen Sie einen neuen Arbeitsbereich erstellen. Weitere Informationen zur Kusto Query Language (KQL) finden Sie unter Protokollabfragen in Azure Monitor.

Ja, Ihr Azure-Speicherkonto kann in einem Abonnement vorhanden sein, und Ihr Log Analytics-Arbeitsbereich kann sich in einem anderen Abonnement befindet.

Ja. Sie können Ablaufprotokolle so konfigurieren, dass sie an ein Speicherkonto gesendet werden, das sich in einem anderen Abonnement befindet, vorausgesetzt, Sie verfügen über die entsprechenden Berechtigungen und dass sich das Speicherkonto in derselben Region wie die Netzwerksicherheitsgruppe (Netzwerksicherheitsgruppenflussprotokolle) oder virtuelles Netzwerk (Virtuelle Netzwerkflussprotokolle) befindet. Das Zielspeicherkonto muss demselben Microsoft Entra-Mandanten angehören wie die Netzwerksicherheitsgruppe bzw. das virtuelle Netzwerk.

Nein. Alle Ressourcen müssen sich im selben Mandanten befinden, einschließlich Netzwerksicherheitsgruppen (Flussprotokolle für Netzwerksicherheitsgruppen), virtuelle Netzwerke (Flussprotokolle für virtuelle Netzwerke), Flussprotokolle, Speicherkonten und Log Analytics-Arbeitsbereiche (wenn die Datenverkehrsanalyse aktiviert ist).

Ja.

Datenverkehrsanalyse-Arbeitsmappen werden von Log Analytics-Abfragen unterstützt. Wenn die Abfrage die Grenzwerte für die Protokollanalyse überschreitet, kann die Arbeitsmappe Fehler aufgrund von geringem Arbeitsspeicher aufweisen. Um die Leistung zu verbessern und speicherarme Fehler zu reduzieren, können Benutzer dedizierte Log Analytics-Cluster verwenden.

Nein. Wenn Sie das Speicherkonto löschen, das für Flussprotokolle verwendet wird, sind die im Log Analytics-Arbeitsbereich gespeicherten Daten nicht betroffen. Sie können weiterhin historische Daten im Log Analytics-Arbeitsbereich anzeigen (einige Metriken werden betroffen sein), aber die Datenverkehrsanalyse verarbeitet keine neuen Flussprotokolle mehr, bis Sie die Ablaufprotokolle aktualisieren, um ein anderes Speicherkonto zu verwenden.

Wählen Sie eine unterstützte Region aus. Wenn Sie einen nicht unterstützten Bereich auswählen, wird ein Fehler "Nicht gefunden" angezeigt. Weitere Informationen finden Sie unter "Unterstützte Regionen der Datenverkehrsanalyse".

Der Microsoft.Insights Anbieter muss für die Ablaufprotokollierung registriert sein, damit er ordnungsgemäß funktioniert. Wenn Sie sich nicht sicher sind, ob der Microsoft.Insights Anbieter für Ihr Abonnement registriert ist, lesen Sie die Anweisungen unter Verwalten von NSG-Flussprotokollen zur Registrierung.

Das Dashboard kann bis zu 30 Minuten dauern, um Berichte zum ersten Mal anzuzeigen. Die Lösung muss zunächst genügend Daten aggregieren, damit sie aussagekräftige Erkenntnisse ableiten und dann Berichte generiert.

Probieren Sie die folgenden Optionen aus:

• Ändern Sie das Zeitintervall in der oberen Leiste.
• Wählen Sie in der oberen Leiste einen anderen Log Analytics-Arbeitsbereich aus.
• Versuchen Sie, nach 30 Minuten auf Datenverkehrsanalysen zuzugreifen, wenn sie kürzlich aktiviert wurde.

Möglicherweise wird diese Meldung angezeigt, weil:

• Die Datenverkehrsanalyse wurde kürzlich aktiviert und hat möglicherweise noch nicht genügend Daten aggregiert, um aussagekräftige Erkenntnisse abzuleiten.
• Sie verwenden die kostenlose Version des Log Analytics-Arbeitsbereichs und haben die Kontingentgrenzwerte überschritten. Möglicherweise müssen Sie einen Arbeitsbereich mit einer größeren Kapazität verwenden.

Probieren Sie die vorgeschlagenen Lösungen für die vorherige Frage aus. Wenn Probleme bestehen, lösen Sie Bedenken in Microsoft Q&A aus.

Sie sehen die Ressourceninformationen im Dashboard; Es sind jedoch keine flussbezogenen Statistiken vorhanden. Daten sind möglicherweise nicht vorhanden, weil keine Kommunikationsflüsse zwischen den Ressourcen vorhanden sind. Warten Sie 60 Minuten, und überprüfen Sie den Status erneut. Wenn das Problem weiterhin besteht und Sie sicher sind, dass Kommunikationsflüsse zwischen Ressourcen vorhanden sind, lösen Sie Bedenken in Microsoft Q&A aus.

Traffic Analytics ist getaktet. Die Messung basiert auf der Verarbeitung von Rohflussprotokolldaten durch den Dienst. Weitere Informationen finden Sie unter Network Watcher – Preise.
Erweiterte Protokolle, die im Log Analytics-Arbeitsbereich aufgenommen werden, können bis zu 31 Tage (oder 90 Tage, wenn Microsoft Sentinel im Arbeitsbereich aktiviert ist) kostenlos aufbewahrt werden. Weitere Informationen finden Sie unter Azure Monitor-Preise.

Das Standardmäßige Verarbeitungsintervall der Datenverkehrsanalyse beträgt 60 Minuten, Sie können jedoch eine beschleunigte Verarbeitung in 10 Minuten Intervalle auswählen. Weitere Informationen finden Sie unter "Datenaggregation in der Datenverkehrsanalyse".

Die Datenverkehrsanalyse erstellt und verwaltet DCR-Ressourcen (Data Collection Rule, Datensammlungsregel) und DCE-Ressourcen (Data Collection Endpoint, Datensammlungsendpunkt) in derselben Ressourcengruppe wie der Arbeitsbereich, mit dem Präfix NWTA. Wenn Sie einen Vorgang für diese Ressourcen ausführen, funktioniert die Datenverkehrsanalyse möglicherweise nicht wie erwartet. Weitere Informationen finden Sie unter "Datenaggregation in der Datenverkehrsanalyse". Weitere Informationen finden Sie unter Datensammlungsregeln in Azure Monitor - und Datensammlungsendpunkten in Azure Monitor.

Es wird nicht empfohlen, Sperren auf DCR- und DCE-Ressourcen anzuwenden, die von der Datenverkehrsanalyse erstellt werden, da diese Ressourcen vom Dienst verwaltet werden. Gesperrte Ressourcen werden beim Löschen der zugehörigen Ablaufprotokolle nicht bereinigt. Wenn Sie einen Vorgang für diese Ressourcen ausführen, funktioniert die Datenverkehrsanalyse möglicherweise nicht wie erwartet. Weitere Informationen finden Sie unter "Datenaggregation in der Datenverkehrsanalyse".

Die Datenverkehrsanalyse basiert auf internen Bedrohungserkennungssystemen von Microsoft, um eine IP als böswillig zu erachen. Diese Systeme verwenden verschiedene Telemetriequellen wie Microsoft-Produkte und -Dienste, die Microsoft Digital Crimes Unit (DCU), das Microsoft Security Response Center (MSRC) und externe Feeds und bauen darauf Informationen auf. Einige dieser Daten sind vertraulich und nur für Microsoft-Interna bestimmt. Wenn eine bekannte IP als böswillig gekennzeichnet wird, erstellen Sie ein Supportticket, um die Details zu kennen.

Die Datenverkehrsanalyse bietet keine integrierte Unterstützung für Warnungen. Da Daten zur Datenverkehrsanalyse jedoch in Log Analytics gespeichert werden, können Sie benutzerdefinierte Abfragen schreiben und Benachrichtigungen darauf festlegen. Folgen Sie diesen Schritten:

• Sie können den Log Analytics-Link in der Datenverkehrsanalyse verwenden.
• Verwenden Sie das Datenverkehrsanalyseschema , um Ihre Abfragen zu schreiben.
• Wählen Sie "Neue Warnungsregel" aus, um die Warnung zu erstellen.
• Siehe Erstellen einer neuen Warnungsregel zum Erstellen der Warnung.

Nein, es wird derzeit nicht unterstützt. Wenn ein Log Analytics-Arbeitsbereich hinter einem Netzwerksicherheitsperimeter bereitgestellt wird, können Datenverkehrsanalysen keine Daten daraus aufnehmen.

Ja. Die Problembehandlung für Verbindungen und die NSG-Diagnose unterstützen keine privaten Application Gateway-Bereitstellungen. Weitere Informationen finden Sie unter Bereitstellung eines privaten Anwendungsgateways.