Azure Monitor-Diensteinschränkungen
In diesem Artikel werden Einschränkungen in verschiedenen Bereichen von Azure Monitor aufgeführt.
Alerts
| Resource | Standardlimit | Maximales Limit |
|---|---|---|
| Metrikwarnungen (klassisch) | 100 aktive Warnungsregeln pro Abonnement. Klassische Warnungen werden für Benutzer der öffentlichen Cloud eingestellt. Klassische Warnungen für die Azure Government-Cloud und Microsoft Azure des Betreibers 21ViaNet werden am 29. Februar 2024 eingestellt. |
Wenden Sie sich an den Support. |
| Metrikwarnungen | 5.000 aktive Warnungsregeln pro Abonnement in öffentlichen Azure, sowie in Microsoft Azure betrieben von 21Vianet- und Azure Government Clouds. Wird dieser Grenzwert erreicht, versuchen Sie, ob Sie Warnungen mit mehreren Ressourcen desselben Typs verwenden können. 5\.000 metrische Zeitreihen pro Warnungsregel. |
Wenden Sie sich an den Support. |
| Aktivitätsprotokollwarnungen | 100 aktive Warnungsregeln pro Abonnement (der Wert kann nicht erhöht werden). Da dieser Grenzwert nicht erhöht werden kann, sollten Sie Ihre Aktivitätsprotokolle an einen Log Analytics-Arbeitsbereich senden und stattdessen Protokollsuchwarnungen erstellen, wenn Sie eine größere Anzahl von Regeln pro Abonnement benötigen. |
Wie Standard. |
| Protokollwarnungen | 5.000 aktive Warnungsregeln pro Abonnement. Davon 100 aktive Warnungsregeln im 1-Minuten-Takt. 1.000 aktive Warnungsregeln pro Ressource. Jede zustandslose Warnungsregel kann pro Auswertung bis zu 6.000 Warnungen auslösen. Jede zustandsbehaftete Warnungsregel kann pro Auswertung bis zu 300 Warnungen auslösen. Bis zu 5.000 ausgelöste zustandsbehaftete Warnungen gleichzeitig. Die kombinierte Größe aller Daten in den Eigenschaften der Protokollbenachrichtigungsregel darf 64 KB nicht überschreiten. Die Kusto-Abfrageergebnisse dürfen 20 MB nicht überschreiten. |
Wenden Sie sich an den Support. |
| Warnungsverarbeitungsregeln | 1.000 aktive Regeln pro Abonnement. | Wenden Sie sich an den Support. |
| Länge der Beschreibungen von Warnungsregeln und Warnungsverarbeitungsregeln | Protokollsuchwarnungen: 4.096 Zeichen. Alle anderen: 2.048 Zeichen. |
Wie Standard. |
Warnungs-API
In Azure Monitor-Warnungen gelten mehrere Drosselungsgrenzwerte zum Schutz vor einer übermäßige Anzahl von Aufrufen. Dieses Verhalten kann die System-Back-End-Ressourcen überlasten und die Reaktionsfähigkeit des Diensts gefährden. Die folgenden Grenzwerte sind darauf ausgelegt, Kunden vor Unterbrechungen zu schützen und eine konsistente Dienstebene zu gewährleisten. Die Einschränkungen und Grenzwerte für Benutzer sind so ausgelegt, dass sie nur extreme Verwendungsszenarios betreffen. Sie sollten für die typische Verwendung nicht relevant sein.
Hinweis
Es gibt ein Limit für API-Aufrufe pro Instanz. Die genaue Grenzwertanzahl wird auf die Anzahl der Instanzen festgelegt.
| Resource | Standardlimit | Maximales Limit |
|---|---|---|
| Warnungen – Zusammenfassung abrufen | 50 Aufrufe pro Minute pro Abonnement | Wie Standard. |
| Warnungen – Alle abrufen (nicht „Nach ID abrufen“) | 100 Aufrufe pro Minute pro Abonnement | Wie Standard. |
| Alle anderen Warnungsaufrufe | 1.000 Aufrufe pro Minute pro Abonnement. | Wie Standard. |
Aktionsgruppen
Sie können über eine unbegrenzte Anzahl von Aktionsgruppen in einem Abonnement verfügen.
| Resource | Standardlimit | Maximales Limit |
|---|---|---|
| Azure-App-Push | 10 Azure-App-Aktionen pro Aktionsgruppe. | Wie Standard |
| 1\.000 E-Mail-Aktionen in einer Aktionsgruppe. Nicht mehr als 100 E-Mails pro Stunde pro E-Mail-Adresse pro Region Die Anzahl der Zeichen in einer E-Mail-Adresse ist auf 64 begrenzt. Das Zeichenlimit einer E-Mail beträgt 55296. Weitere Informationen finden Sie in den Informationen zu Ratenbegrenzungen. |
Wie Standard | |
| E-Mail an Azure Resource Manager-Rolle senden | 10 E-Mail-ARM-Rollenaktionen pro Aktionsgruppe. In Produktion: Nicht mehr als 100 E-Mails in einer Stunde pro Region. In einer Testaktionsgruppe: Nicht mehr als zwei E-Mails pro (1) Minute. |
Wie Standard |
| Event Hubs | 10 Event Hub-Aktionen pro Aktionsgruppe. | Wie Standard |
| ITSM | 10 ITSM-Aktionen in einer Aktionsgruppe. | Wie Standard |
| Logik-App | 10 Logik-App-Aktionen in einer Aktionsgruppe. | Wie Standard |
| Runbook | 10 Runbook-Aktionen in einer Aktionsgruppe. | Wie Standard |
| Sicherer Webhook | 10 sichere Webhookaktionen in einer Aktionsgruppe. Maximale Anzahl von Webhookaufrufen ist 1500 pro Minute pro Abonnement. | Wie Standard |
| sms | 10 SMS-Aktionen in einer Aktionsgruppe. In Produktion: Maximal eine SMS alle fünf Minuten. In einer Testaktionsgruppe: Nicht mehr als eine SMS pro Minute. |
Wie Standard |
| Sprache | 10 Sprachaktionen in einer Aktionsgruppe. In Produktion: Maximal ein Sprachanruf alle fünf Minuten. In einer Testaktionsgruppe: Nicht mehr als ein Sprachanruf pro Minute. |
Wie Standard |
| Webhook | 10 Webhookaktionen in einer Aktionsgruppe. Maximale Anzahl von Webhookaufrufen ist 1500 pro Minute pro Abonnement. | Wie Standard |
Autoscale
| Resource | Standardlimit | Maximales Limit |
|---|---|---|
| Einstellungen für automatische Skalierung | 100 pro Region und Abonnement. | Wie Standard. |
| Profile für die automatische Skalierung | 20 Profile pro Einstellung für die Autoskalierung. | Wie Standard. |
Prometheus-Metriken
Erfassung
Von Azure verwaltetes Prometheus ist ein System, bei dem die Groß-/Kleinschreibung nicht beachtet wird. Es behandelt Zeichenfolgen (z. B. Metriknamen, Bezeichnungsnamen oder Bezeichnungswerte) als die gleiche Zeitreihe, wenn sie sich nur durch die Groß-/Kleinschreibung der Zeichenfolge von einer anderen Zeitreihe unterscheiden. Weitere Informationen finden Sie unter Übersicht über Prometheus-Metriken.
Die folgenden Grenzwerte gelten für den Azure Monitor-Arbeitsbereich, der Ihre Prometheus-Metriken erfasst.
| Begrenzung | Wert |
|---|---|
| Aktive Zeitreihe mit Metriken, die in den letzten ~12 Stunden gemeldet wurden. | 1\.000.000 Sie können eine Erhöhung anfordern. |
| Erfasste Ereignisse pro Minute. | 1\.000.000 Sie können eine Erhöhung anfordern. |
Die folgenden Grenzwerte gelten für die Datensammlungsregel (DCR) und den Datensammlungsendpunkt (DCE), die Prometheus-Metrikdaten an Ihren Azure Monitor-Arbeitsbereich senden.
| Begrenzung | Wert |
|---|---|
| Aufnahmeanforderungen pro Minute an einen Datensammlungsendpunkt | 15.000 Dieser Grenzwert kann nicht erhöht werden. |
| Datenerfassung pro Minute zu einem Datensammlungsendpunkt | 50 GB Dieser Grenzwert kann nicht erhöht werden. |
Abfragen
Prometheus-Abfragen werden mithilfe von PromQL erstellt und können entweder in Azure Managed Grafana oder in selbstverwaltetem Grafana erstellt werden.
| Begrenzung | Wert |
|---|---|
| Beibehaltung von Daten | 18 Monate. Dieser Grenzwert kann nicht erhöht werden. |
| Abfragezeitbereich | 32 Tage zwischen der Start- und Endzeit Ihrer PromQL-Abfrage. Dieser Grenzwert kann nicht erhöht werden. |
| Abfragezeitreihen pro Metrik | 500,000 Zeitreihe |
| Zurückgegebene Abfragebeispiele | 50.000.000 Stichproben pro Abfrage. |
| Mindestgröße der Abfrageschritte mit Zeitbereich von >= 48 Stunden |
60 Sekunden. |
Abfragedatengrenzwerte
Für Clientdatenverkehr:
| Begrenzung | Wert |
|---|---|
| Länge der Drosselungsfenstersuche | 30 Sekunden |
| Pro Azure Monitor-Arbeitsbereich zurückgegebene Daten | 0,5 GB |
Für den Datenverkehr mit Aufzeichnungsregeln:
| Begrenzung | Wert |
|---|---|
| Länge der Drosselungsfenstersuche | 3 Minuten |
| Pro Azure Monitor-Arbeitsbereich zurückgegebene Daten | 1 GB |
Grenzwerte für Pre-Parsing-Abfragen
Basierend auf dem Abfragezeitraum und dem Anforderungstyp über ein 30-Sekunden-Fenster (für Clientdatenverkehr):
| Begrenzung | Wert |
|---|---|
| Abfragestunden pro Benutzer (Microsoft Entra ID, verwaltete Identität, Azure Managed Grafana-Arbeitsbereich) | 30.000 |
| Abfragestunden pro Azure Monitor-Arbeitsbereich | 60.000 |
| Abfragestunden pro Azure-Mandanten | 600.000 |
Basierend auf dem Abfragezeitbereich und dem Anforderungstyp über ein 3-Minuten-Fenster (zum Aufzeichnen von Regeldatenverkehr):
| Begrenzung | Wert |
|---|---|
| Abfragestunden pro Azure Monitor-Arbeitsbereich | 60.000 |
| Abfragestunden pro Azure-Mandanten | 600.000 |
Grenzwerte für Post-Parsing-Abfragen
Basierend auf dem Abfragezeitraum und den Bereichsvektoren in der Abfrage über ein 30-Sekunden-Fenster (für Clientdatenverkehr).
| Begrenzung | Wert |
|---|---|
| Abfragestunden pro Benutzer (Microsoft Entra ID, verwaltete Identität, Azure Managed Grafana-Arbeitsbereich) | 2\.000.000 |
| Abfragestunden pro Azure Monitor-Arbeitsbereich | 2\.000.000 |
| Abfragestunden pro Azure-Mandanten | 20.000.000 |
Basierend auf Abfragezeitbereich und Bereichsvektoren in der Abfrage über ein 3-Minuten-Fenster (für die Aufzeichnung von Regeldatenverkehr):
| Begrenzung | Wert |
|---|---|
| Abfragestunden pro Azure Monitor-Arbeitsbereich | 2\.000.000 |
| Abfragestunden pro Azure-Mandanten | 20.000.000 |
Grenzwerte für die Abfragekosteneinschränkung
| Begrenzung | Wert |
|---|---|
| Maximale Abfragekosten pro Abfrage | 15000 |
| Maximale Abfragekosten für die Abfrage von Aufzeichnungsregeln | 3000 |
Die Berechnung der Abfragekosten erfolgt wie folgt:
Abfragekosten = (Anzahl der angeforderten Zeitreihen * (abgefragte Zeitdauer in Sekunden / Abgeleitete Zeitauflösung der abgefragten Daten)) / 5000
Abgeleitete Zeitauflösung der abgefragten Daten = Anzahl der gespeicherten Datenpunkte in einem zufällig ausgewählten Zeitreihenschlüssel der abgefragten Metrik / abgefragte Zeitdauer in Sekunden
Warnungs- und Aufzeichnungsregeln
Warnungsregeln und Aufzeichnungsregeln von Prometheus sind in PromQL definiert. Sie werden im verwalteten Ruler-Dienst als Teil des verwalteten Azure Monitor-Dienstes für Prometheus ausgeführt.
| Begrenzung | Wert: |
|---|---|
| Regelgruppen pro Azure Monitor-Arbeitsbereich in einem Azure-Abonnement | 500 Sie können eine Erhöhung anfordern. |
| Regeln pro Regelgruppe | 20 Dieser Grenzwert kann nicht erhöht werden. |
| Auswertungsintervall der Regelgruppe | Zwischen 1 Minute und 24 Stunden. Standardwert ist 1 Minute. |
| Aktive Warnungen | Derzeit kein Grenzwert vorhanden. |
Remote-Schreibzugriff
Berechnungen wurden mit einer Remote-Batchgröße von 500 (Standardeinstellung) durchgeführt.
| Begrenzung | Wert |
|---|---|
| CPU-Auslastung | 0,25 x (Anzahl der Metriken) + 1,25 x (durchschnittliche Anzahl von Reihen pro Metrik) |
| CPU-Anforderung | 0,75 x (CPU-Auslastung) |
| CPU-Grenzwert | 2 x (CPU-Anforderung) |
| Arbeitsspeicheranforderung | 150 MB |
| Arbeitsspeicherlimit | 200 MB |
| Maximaler Durchsatz | Remote-Schreibcontainer kann bis zu 150.000 eindeutige Zeitreihen verarbeiten. Der Container kann aufgrund der hohen Anzahl gleichzeitiger Verbindungen Fehler bei der Bearbeitung von Anforderungen über 150.000 auslösen. Dieses Problem kann verringert werden, indem die Remote-Batchgröße von 500 auf 1.000 erhöht wird. Durch diese Änderung wird die Anzahl der geöffneten Verbindungen reduziert. |
Protokollerfassungs-API
| Begrenzung | Wert | Kommentare |
|---|---|---|
| Maximale Größe des API-Aufrufs | 1 MB | Komprimierte und nicht komprimierte Daten. |
| Maximale Größe für Feldwerte | 64 KB | Felder mit einer Länge von mehr als 64 KB werden abgeschnitten. |
| Maximale Daten/Minute pro DCR | 2 GB | Komprimierte und nicht komprimierte Daten. Wiederholen Sie den Vorgang nach der Dauer, die im Header Retry-After in der Antwort aufgeführt ist. |
| Maximale Anzahl von Anforderungen/Minute pro DCR | 12.000 | Wiederholen Sie den Vorgang nach der Dauer, die im Header Retry-After in der Antwort aufgeführt ist. |
Regeln für die Datensammlung
| Begrenzung | Wert |
|---|---|
| Maximale Anzahl von Datenquellen | 10 |
| Maximale Anzahl von Indikatorwerten für den Leistungsindikator | 100 |
| Maximale Anzahl von Umgebungsnamen in Syslog | 20 |
| Maximale Anzahl von XPath-Abfragen im Ereignisprotokoll | 100 |
| Maximale Anzahl von Datenflüssen | 10 |
| Maximale Anzahl von Datenströmen | 10 |
| Maximale Anzahl von Erweiterungen | 10 |
| Maximale Größe von Erweiterungseinstellungen | 32 KB |
| Maximale Anzahl von Log Analytics-Arbeitsbereichen | 10 |
| Maximale Anzahl von Zeichen in einer Transformation | 15.360 |
Diagnoseeinstellungen
| Resource | Standardlimit | Maximales Limit |
|---|---|---|
| Maximale Anzahl von Diagnoseeinstellungen pro Ressource | 5 | Wie Standard. |
Protokollieren von Abfragen und Sprache
Allgemeine Abfragegrenzwerte
| Begrenzung | BESCHREIBUNG |
|---|---|
| Abfragesprache | Azure Monitor verwendet dieselbe Kusto-Abfragesprache (KQL) wie Azure Data Explorer. Weitere Informationen finden Sie unter Azure Monitor – Unterschiede in der Protokollabfragesprache für KQL-Sprachelemente, die in Azure Monitor nicht unterstützt werden. |
| Azure-Regionen | Protokollabfragen können zu einem übermäßigen Aufwand führen, wenn sich die Daten über Log Analytics-Arbeitsbereiche in mehreren Azure-Regionen erstrecken. Weitere Informationen finden Sie unter Abfragegrenzwerte. |
| Ressourcenübergreifende Abfragen | Die maximale Anzahl von Application Insights-Ressourcen und Log Analytics-Arbeitsbereichen in einer einzelnen Abfrage ist auf 100 beschränkt. Ressourcenübergreifende Abfragen werden im Ansichts-Designer nicht unterstützt. Eine ressourcenübergreifende Abfrage in Protokollwarnungen wird in der neuen scheduledQueryRules-API unterstützt. Ausführliche Informationen finden Sie unter Ressourcenübergreifende Abfragelimits. |
| Log Analytics-Dashboardabfragen | Die maximale Anzahl von Datensätzen, die in einer einzelnen Log Analytics Dashboard-Abfrage zurückgegeben werden, beträgt 2.000. |
Drosselung von Benutzerabfragen
In Azure Monitor gelten mehrere Drosselungsgrenzwerte zum Schutz vor einer übermäßige Anzahl von Abfragen. Dieses Verhalten kann die System-Back-End-Ressourcen überlasten und die Reaktionsfähigkeit des Diensts gefährden. Die folgenden Grenzwerte sind darauf ausgelegt, Kunden vor Unterbrechungen zu schützen und eine konsistente Dienstebene zu gewährleisten. Die Drosselung und die Grenzwerte für Benutzer betreffen nur Szenarien mit übermäßigem Verbrauch und sind bei normaler Verwendung in der Regel nicht relevant.
| "Measure" | Grenzwert pro Benutzer | BESCHREIBUNG |
|---|---|---|
| Gleichzeitige Abfragen | 5 | Ein Benutzer kann bis zu fünf gleichzeitige Abfragen ausführen. Jede weitere Abfrage wird zu einer Warteschlange hinzugefügt. Sobald eine der laufenden Abfragen abgeschlossen ist, wird die erste wartende Abfrage aus der Warteschlange abgerufen und ausgeführt. Dieser Grenzwert gilt nicht für Warnungsabfragen. |
| Zeit in der Parallelitätswarteschlange | 3 Minuten | Wenn sich eine Abfrage länger als 3 Minuten in der Warteschlange befindet, ohne zu starten, wird sie mit einer HTTP-Fehlerantwort mit dem Code 429 beendet. |
| Gesamtanzahl von Abfragen in der Parallelitätswarteschlange | 200 | Wenn die Anzahl von Abfragen in der Warteschlange 200 erreicht, wird die nächste Abfrage mit dem HTTP-Fehlercode 429 abgelehnt. Diese Zahl gilt zusätzlich zu den 5 Abfragen, die gleichzeitig ausgeführt werden können. |
| Abfragerate | 200 Abfragen pro 30 Sekunden | Dies ist die Gesamtrate, mit der Abfragen von einem einzelnen Benutzer an alle Arbeitsbereiche übermittelt werden können. Dieser Grenzwert gilt für programmgesteuerte Abfragen und für Abfragen, die von Visualisierungskomponenten wie Azure-Dashboards und der Zusammenfassungsseite (veraltet) für den Log Analytics-Arbeitsbereich initiiert wurden. |
- Optimieren Sie Ihre Abfragen wie unter Optimieren von Protokollabfragen in Azure Monitor beschrieben.
- Dashboards und Arbeitsmappen können mehrere Abfragen in einer einzelnen Ansicht enthalten, die bei jedem Laden oder Aktualisieren einen Burst von Abfragen generieren. Zerlegen Sie sie ggf. in mehrere Ansichten, die bedarfsgesteuert geladen werden.
- Erwägen Sie, in Power BI anstelle von unformatierten Protokollen nur aggregierte Ergebnisse zu extrahieren.
Log Analytics-Arbeitsbereiche
Umfang und Aufbewahrung der Datensammlung
| Tarif | Grenzwert pro Tag | Beibehaltung von Daten | Comment |
|---|---|---|---|
| Nutzungsbasierte Bezahlung (Einführung: April 2018) |
Keine Begrenzung | bis zu 730 Tage interaktive Aufbewahrung/ bis zu 12 Jahre Datenarchiv |
Für eine Datenaufbewahrung von mehr als 31 Tagen fallen zusätzliche Gebühren an. Erfahren Sie mehr über die Preise für Azure Monitor. |
| Mindestabnahmen (eingeführt im November 2019) |
Keine Begrenzung | bis zu 730 Tage interaktive Aufbewahrung/ bis zu 12 Jahre Datenarchiv |
Für eine Datenaufbewahrung von mehr als 31 Tagen fallen zusätzliche Gebühren an. Erfahren Sie mehr über die Preise für Azure Monitor. |
| Legacy Per Node (OMS) (Einführung: April 2016) |
Keine Begrenzung | 30 bis 730 Tage | Für eine Datenaufbewahrung von mehr als 31 Tagen fallen zusätzliche Gebühren an. Erfahren Sie mehr über die Preise für Azure Monitor. Der Zugriff auf die Nutzungsebene ist auf Abonnements beschränkt, die am 2. April 2018 einen Log Analytics-Arbeitsbereich oder eine Application Insights-Ressource enthielten oder mit einem Enterprise Agreement verbunden sind, das vor dem 1. Februar 2019 begann und noch aktiv ist. |
| Eigenständiger Legacytarif (Einführung: April 2016) |
Keine Begrenzung | 30 bis 730 Tage | Für eine Datenaufbewahrung von mehr als 31 Tagen fallen zusätzliche Gebühren an. Erfahren Sie mehr über die Preise für Azure Monitor. Der Zugriff auf die Nutzungsebene ist auf Abonnements beschränkt, die am 2. April 2018 einen Log Analytics-Arbeitsbereich oder eine Application Insights-Ressource enthielten oder mit einem Enterprise Agreement verbunden sind, das vor dem 1. Februar 2019 begann und noch aktiv ist. |
| Free-Legacytarif (Einführung: April 2016) |
500 MB | 7 Tage | Wenn Ihr Arbeitsbereich das Tageslimit von 500 MB erreicht, wird die Datenerfassung beendet und am nächsten Morgen fortgesetzt. Ein Tag wird in UTC-Zeit ausgegeben. Daten, die von Microsoft Defender for Cloud erfasst werden, sind nicht im Tageslimit von 500 MB enthalten und werden auch noch darüber hinaus weiter erfasst. Das Erstellen neuer Arbeitsbereiche innerhalb des Tarifs „Kostenlose Testversion“ oder die Einstufung vorhandener Arbeitsbereiche in diesen Tarif ist bis zum 1. Juli 2022 möglich. |
| Legacy Standard-Tarif | Keine Begrenzung | 30 Tage | Die Aufbewahrungsdauer kann nicht angepasst werden Dieser Tarif ist seit dem 1. Oktober 2016 nicht mehr für neue Arbeitsbereiche verfügbar. |
| Legacy Premium-Tarif | Keine Begrenzung | 365 Tage | Die Aufbewahrungsdauer kann nicht angepasst werden Dieser Tarif ist seit dem 1. Oktober 2016 nicht mehr für neue Arbeitsbereiche verfügbar. |
Anzahl von Arbeitsbereichen pro Abonnement
| Tarif | Arbeitsbereichsbegrenzung | Kommentare |
|---|---|---|
| Free-Legacytarif | 10 | Dieser Grenzwert kann nicht erhöht werden. Das Erstellen neuer Arbeitsbereiche innerhalb des Tarifs „Kostenlose Testversion“ oder die Einstufung vorhandener Arbeitsbereiche in diesen Tarif ist bis zum 1. Juli 2022 möglich. |
| Alle anderen Tarife | Keine Begrenzung | Sie sind durch die Anzahl der Ressourcen innerhalb einer Ressourcengruppe und die Anzahl der Ressourcengruppen pro Abonnement eingeschränkt. |
Azure portal
| Category | Begrenzung | Kommentare |
|---|---|---|
| Maximale Anzahl von Datensätzen, die von einer Protokollabfrage zurückgegebenen werden | 30.000 | Reduziert die Ergebnisse durch die Verwendung eines Abfragebereichs, eines Zeitbereichs und von Filtern in der Abfrage. |
Datensammler-API
| Category | Begrenzung | Kommentare |
|---|---|---|
| Maximale Größe für einen einzelnen Beitrag | 30 MB | Teilen Sie größere Volumen auf mehrere Beiträge auf. |
| Maximale Größe für Feldwerte | 32 KB | Felder mit einer Länge von mehr als 32 KB werden abgeschnitten. |
Abfrage-API
| Category | Begrenzung | Kommentare |
|---|---|---|
| Maximale Anzahl von Datensätzen, die bei einer einzelnen Abfrage zurückgegeben werden | 500.000 | |
| Maximale Größe der zurückgegebenen Daten | ~104 MB (~100 MiB) | Die API gibt bis zu 64 MB an komprimierten Daten zurück, was bis zu 100 MB Rohdaten entspricht. |
| Maximale Ausführungszeit der Abfrage | 10 Minuten | Weitere Informationen finden Sie unter Timeouts (Zeitlimit). |
| Maximale Anforderungsrate | 200 Anforderungen pro 30 Sekunden und Microsoft Entra-Benutzer oder Client-IP-Adresse | Weitere Informationen finden Sie unter Protokollieren von Abfragen und Sprache. |
Connector für Azure Monitor-Protokolle
| Category | Begrenzung | Kommentare |
|---|---|---|
| Maximale Datengröße | ~16,7 MB (~16 MiB) | Aufgrund der Connectorinfrastruktur muss dieser Grenzwert niedriger sein als der Grenzwert für die Abfrage-API. |
| Maximale Anzahl von Datensätzen | 500.000 | |
| Maximales Connectortimeout | 110 Sekunden | |
| Maximales Abfragetimeout | 100 Sekunden | |
| Diagramme | Die Seite „Protokolle“ und der Connector verwenden verschiedene Diagrammbibliotheken für die Visualisierung. Einige Funktionen sind derzeit nicht im Connector verfügbar. |
Zusammenfassungsregeln
| Kategorie | Begrenzung |
|---|---|
| Maximale Anzahl aktiver Regeln in einem Arbeitsbereich | 30 |
| Maximale Anzahl der Ergebnisse pro Intervall | 500.000 |
| Maximale Ergebnismenge | 100 MB |
| Abfragetimeout für die Intervallverarbeitung | 10 Minuten |
Allgemeine Grenzwerte für Arbeitsbereiche
| Category | Begrenzung | Kommentare |
|---|---|---|
| Maximale Anzahl von Spalten in einer Tabelle | 500 | AzureDiagnostics – Spalten oberhalb des Grenzwerts werden der dynamischen Spalte „AdditionalFields“ hinzugefügt. Von der Datensammler-API erstelltes benutzerdefinierte Protokoll – Spalten oberhalb des Grenzwerts werden der dynamischen Spalte „AdditionalFields“ hinzugefügt. Benutzerdefiniertes Protokoll – Wenden Sie sich an den Support, um weitere Informationen zu erhalten. |
| Maximale Anzahl benutzerdefinierter Protokolltabellen | 500 | Wenden Sie sich an den Support, um weitere Informationen zu erhalten |
| Maximale Anzahl an Zeichen für einen Spaltennamen | 45 |
Rate für Datenerfassungsvolumen
Azure Monitor ist ein Hochleistungs-Datendienst, der Tausende Kunden bedient, die jeweils mit zunehmender Tendenz täglich Terabytes von Daten senden. Mit einer weichen Volumenratenbegrenzung sollen Azure Monitor-Kunden vor plötzlichen Erfassungsspitzen in einer mehrinstanzenfähigen Umgebung isoliert werden. Der Standardschwellenwert für die Erfassungsvolumenrate in Arbeitsbereichen beträgt 500 MB (komprimiert), was in etwa 6 GB/min unkomprimiert entspricht.
Das Ratenlimit für Volumen gilt für Daten, die über Diagnoseeinstellungen und der Datensammler-API aus Azure-Ressourcen erfasst werden. Wird der Grenzwert für die Volumenrate erreicht, versucht ein Wiederholungsmechanismus, die Daten viermal in einem Zeitraum von 12 Stunden zu erfassen. Die Daten werden verworfen, wenn der Vorgang fehlschlägt. Der Grenzwert gilt nicht für Daten, die von Agents oder über DCR erfasst wurden.
Wenn Daten an einen Arbeitsbereich mit einer Volumenrate gesendet werden, die mehr als 80 Prozent des im Arbeitsbereich konfigurierten Schwellenwerts beträgt, wird alle sechs Stunden ein Ereignis an die Tabelle Operation im Arbeitsbereich gesendet, während der Schwellenwert weiterhin überschritten wird. Wenn die erfasste Volumenrate höher ist als der Schwellenwert, werden einige Daten gelöscht und es wird alle sechs Stunden ein Ereignis an die Tabelle Operation in Ihrem Arbeitsbereich gesendet, während der Schwellenwert weiterhin überschritten wird.
Wenn die Erfassungsvolumenrate weiterhin den Schwellenwert überschreitet oder der Schwellenwert wahrscheinlich in Kürze erreicht wird, können Sie eine Erhöhung dieses Grenzwerts anfordern, indem Sie eine Supportanfrage öffnen.
Es wird auch empfohlen, eine Warnungsregel zu erstellen, um proaktiv zu benachrichtigen, wenn Sie Grenzwerte für die Erfassung erreichen. Weitere Informationen finden Sie unter Überwachen der Integrität des Log Analytics-Arbeitsbereichs in Azure Monitor.
Hinweis
Abhängig von Ihrer Log Analytics-Nutzungsdauer haben Sie ggf. Zugang zu Legacytarifen. Weitere Informationen zu Legacytarifen von Log Analytics finden Sie hier.
Application Insights
Es gibt einige Grenzwerte hinsichtlich der Anzahl von Metriken und Ereignissen pro Anwendung (d. h. pro Instrumentationsschlüssel). Die Beschränkungen hängen von dem von Ihnen ausgewählten Tarif ab.
| Resource | Standardlimit | Maximales Limit | Hinweise |
|---|---|---|---|
| Gesamtdaten pro Tag | 100 GB | Wenden Sie sich an den Support. | Sie können eine Obergrenze festlegen, um Daten zu reduzieren. Wird eine höhere Datenmenge benötigt, können Sie den Grenzwert im Portal auf bis zu 1.000 GB erhöhen. Bei Kapazitäten über 1.000 GB senden Sie eine E-Mail an AIDataCap@microsoft.com. |
| Drosselung | 32.000 Ereignisse/s | Wenden Sie sich an den Support. | Das Limit wird eine Minute lang gemessen. |
| Datenaufbewahrungsprotokolle | 30 bis 730 Tage | Nach 730 Tagen | Diese Ressource ist für Protokolle vorgesehen. |
| Datenaufbewahrungsmetriken | 90 Tage | 90 Tage | Diese Ressource ist für den Metrik-Explorer vorgesehen. |
| Aufbewahrung ausführlicher Ergebnisse von Verfügbarkeitstests mit mehreren Schritten | 90 Tage | 90 Tage | Diese Ressource liefert detaillierte Ergebnisse der einzelnen Schritte. |
| Maximale Größe von Telemetrieelementen | 64 KB | 64 KB | |
| Maximale Anzahl von Telemetrieelementen pro Batch | 64.000 | 64.000 | |
| Eingenschaft und Länge der Namen von Metriken | 150 | 150 | Siehe Typschemas. |
| Zeichenfolgenlänge des Eigenschaftswerts | 8\.192 | 8\.192 | Siehe Typschemas. |
| Länge von Ablaufverfolgungs- und Ausnahmebenachrichtigungen | 32,768 | 32,768 | Siehe Typschemas. |
| Anzahl der Verfügbarkeitstests pro Application Insights-Ressource | 100 | 100 | |
| Anzahl der Verfügbarkeitstests pro Ressourcengruppe | 800 | 800 | Weitere Informationen finden Sie unter Azure Resource Manager. |
| In Verfügbarkeitstests maximale Anzahl der Umleitungen pro Test | 10 | 10 | |
| Minimale Testhäufigkeit bei Verfügbarkeitstests | 300 Sekunden | Benutzerdefinierte Testhäufigkeiten oder Häufigkeiten von weniger als fünf Minuten erfordern benutzerdefinierte TrackAvailability-Implementierungen. | |
| Profiler und Momentaufnahmedatenaufbewahrung | Zwei Wochen | Wenden Sie sich an den Support. Die maximale Aufbewahrungszeit beträgt sechs Monate. | |
| Pro Tag gesendete Profiler-Daten | Keine Begrenzung | Keine Begrenzung | |
| Pro Tag gesendete Momentaufnahmedaten | 30 Momentaufnahmen pro Tag pro überwachte App | Keine Begrenzung | Die Anzahl der pro Anwendung erfassten Momentaufnahmen kann über die Konfiguration geändert werden. |
Weitere Informationen zu Preisen und Kontingenten finden Sie unter Abrechnung für Application Insights.
Verwenden des Azure Monitor Private Link-Bereichs (AMPLS)
AMPLS-Objekte weisen die folgenden Grenzwerte auf:
- Ein virtuelles Netzwerk kann eine Verbindung nur mit einem AMPLS-Objekt herstellen. Dies bedeutet, dass das AMPLS-Objekt Zugriff auf alle Azure Monitor-Ressourcen bieten muss, auf die das virtuelle Netzwerk Zugriff haben soll.
- Ein AMPLS-Objekt kann eine Verbindung mit bis zu 300 Log Analytics-Arbeitsbereichen und bis zu 1000 Application Insights-Komponenten herstellen.
- Eine Azure Monitor-Ressource kann eine Verbindung mit bis zu fünf AMPLS herstellen.
- Ein AMPLS-Objekt kann eine Verbindung mit bis zu zehn privaten Endpunkten herstellen.