Teilen über

E/A-Leistungsanalyse (Vorschau) – SQL Server auf virtuellen Azure-Computern

  • Artikel

Gilt für:SQL Server auf Azure-VM

In diesem Artikel erfahren Sie, wie Sie die E/A-Leistung für SQL Server auf virtuellen Azure-Computern (VMs) analysieren, um Probleme zu finden, die sich aus einer Überschreitung der Grenzwerte für virtuelle Computer und Datenträger ergeben.

Hinweis

Die E/A-Analyse für SQL Server auf Azure-VMs in der Azure-Portal befindet sich derzeit in der Vorschau.

Übersicht

Obwohl Ihnen verschiedene Tools bei der Fehlerbehebung von SQL Server-Leistungsproblemen helfen, ist es für eine effektive Fehlerbehebung auf einer Azure-VM wichtig zu verstehen, was sowohl auf Host-Ebene als auch auf Ihrer SQL Server-Instanz passiert. SQL Server auf Azure-VMs erleichtern die Identifizierung von Leistungsproblemen, die von IOPS (Eingabe/Ausgabe pro Sekunde) und Durchsatzeinschränkungen verursacht werden, die durch überschreitende Grenzwerte für virtuelle Computer und Datenträger verursacht werden.

Leistungsmetriken, die das Problem und mögliche Schritte zu seiner Behebung aufzeigen, sind im Azure-Portal verfügbar und können mit der Azure-Befehlszeile abgefragt werden.

Der Speicherbereich Ihrer virtuellen SQL-Maschine-Ressource in der Azure-Portal hilft Ihnen dabei:

Grundlegendes zu den Metriken

Die Registerkarte E/A-Analyse stützt sich auf Azure Metrics, um Festplattenlatenz und VM- oder Festplatten-E/A-Drosselung zu ermitteln. Azure Metrics werden alle 30 Sekunden abgerufen und auf eine Minute aggregiert.

Das System überwacht die Drosselung und Datenträgerlatenz. Einige Drosselungen werden erwartet und ignoriert, es sei denn, es gibt auch Datenträgerlatenz. Wenn mehr als 500 Millisekunden Datenträgerlatenz in einem aufeinander folgenden 5-Minuten-Zeitraum beobachtet werden, dann tut das System Folgendes:

  • Vertiefung der Leistungsmetriken
  • Identifiziert die gedrosselte Ressource
  • Stellt potenzielle Grundursachen und Gegenmaßnahmen bereit

In der folgenden Tabelle werden die Azure-Metriken erläutert, die zum Identifizieren problematischer Drosselungsprobleme verwendet werden:

Azure Metric Beschreibung der Metrik Problematische Bedingung E/A-Drosselungsschlussfolgerungen
Datenträgerlatenz (Vorschau) Die durchschnittliche Zeit bis zum Abschluss von E/As für die Datenfestplatte während des überwachten Zeitraums. Die Werte werden in Millisekunden angegeben. > 500 Millisekunden in einem aufeinander folgenden 5-Minuten-Zeitraum Es gibt ein Latenzproblem für das System, um potenzielle Drosselungspotentiale weiter zu untersuchen.
Beanspruchte zwischengespeicherte VM-IOPS in Prozent Der Prozentsatz der gesamten abgeschlossenen IOPS gemessen am oberen Grenzwert für zwischengespeicherte IOPS auf dem virtuellen Computer. >= 95 % in einem aufeinander folgenden 5-Minuten-Zeitraum Es gibt eine VM-Drosselung. Die auf der virtuellen SQL-Maschine ausgeführte Anwendung nutzt die der virtuellen Maschine zur Verfügung stehende maximale IOPS-Kapazität im Cache voll aus – die Speicheranforderungen der Anwendung übersteigen die von der zugrunde liegenden Speicherkonfiguration der virtuellen Maschine bereitgestellten IOPS im Cache.
Prozentsatz der von der VM beanspruchten zwischengespeicherten Bandbreite Der Prozentsatz des gesamten abgeschlossenen Durchsatzes gemessen am oberen Grenzwert für zwischengespeicherten Durchsatz auf dem virtuellen Computer. >= 95 % in einem aufeinander folgenden 5-Minuten-Zeitraum Es gibt eine VM-Drosselung. Die auf der virtuellen SQL-Maschine ausgeführte Anwendung nutzt die maximal verfügbare gecachte Festplattenbandbreite für die Datenübertragung – die Datenübertragungsanforderungen der Anwendung übersteigen die gecachten Bandbreitenressourcen, die von der zugrunde liegenden Speicherkonfiguration der virtuellen Maschine bereitgestellt werden. 
Beanspruchte nicht zwischengespeicherte VM-IOPS in Prozent Der Prozentsatz der gesamten abgeschlossenen IOPS auf einem virtuellen Computer gemessen am oberen Grenzwert für nicht zwischengespeicherte IOPS auf dem virtuellen Computer. >= 95 % in einem aufeinander folgenden 5-Minuten-Zeitraum Es gibt eine VM-Drosselung. Die Anwendung, die auf der virtuellen SQL-Maschine ausgeführt wird, nutzt die maximal zulässige, nicht zwischengespeicherte IOPS-Kapazität, die der virtuellen Maschine zur Verfügung steht.
Prozentsatz der von der VM beanspruchten nicht zwischengespeicherten Bandbreite Der Prozentsatz des gesamten abgeschlossenen Durchsatzes auf einem virtuellen Computer gemessen am oberen Grenzwert für bereitgestellten Durchsatz auf dem virtuellen Computer. >= 95 % in einem aufeinander folgenden 5-Minuten-Zeitraum Es gibt eine VM-Drosselung. Die auf der virtuellen SQL-Maschine ausgeführte Anwendung nutzt die maximal zulässige nicht zwischengespeicherte Festplattenbandbreite für die Datenübertragung – die Datenübertragungsanforderungen der Anwendung übersteigen die nicht zwischengespeicherten Bandbreitenressourcen, die von der zugrunde liegenden Speicherkonfiguration der virtuellen Maschine bereitgestellt werden.
Beanspruchte Datenträger-IOPS in Prozent Der Prozentsatz, der über die abgeschlossenen Datenträger-IOPS im Vergleich zu den bereitgestellten Datenträger-IOPs berechnet wird. >= 95 % in einem aufeinander folgenden 5-Minuten-Zeitraum Es gibt eine Datenträgerdrosselung. Die auf der virtuellen SQL-Maschine ausgeführte Anwendung stößt an die IOPS-Grenze für die bereitgestellte Datenfestplatte – die Speicheranforderungen der Anwendung übersteigen die Leistungsfähigkeit der gewählten Festplattenkonfiguration.
Beanspruchte Datenträgerbandbreite in Prozent Der Prozentsatz, der über den abgeschlossenen Datenträgerdurchsatz im Vergleich zum bereitgestellten Datenträgerdurchsatz berechnet wird. >= 95 % in einem aufeinander folgenden 5-Minuten-Zeitraum Es gibt eine Datenträgerdrosselung. Die auf der virtuellen SQL-Maschine ausgeführte Anwendung stößt an die IOPS-Grenze für die bereitgestellte Datenfestplatte – die Speicheranforderungen der Anwendung übersteigen die Leistungsfähigkeit der gewählten Festplattenkonfiguration.

Ergebnisse der E/A-Analyse

Basierend auf der Analyse der Leistungsmetriken aus den letzten 24 Stunden wird bei der E/A-Analyse Folgendes festgestellt:

  • No throttling
  • E/A-Drosselung auf VM-Ebene
  • E/A-Drosselung auf Disk-Ebene

Kein E/A-Einschränkungsproblem

Wenn ein Leistungsproblem auftritt, es aber keine Datenträgerlatenz gibt, liegt das Leistungsproblem nicht aufgrund eines E/A-Drosselungsproblems vor. Sie müssen andere Bereiche untersuchen. Sie können die Checkliste für bewährte Verfahren für SQL Server auf Azure-VMs verwenden, um sicherzustellen, dass Ihr System effizient konfiguriert ist, oder nützliche Links zur Problembehandlung bei der SQL Server-Leistung finden. Wenn Sie das SQL-Best-Practices-Bewertungs-Feature aktivieren, finden Sie die vollständige Liste der Empfehlungen für Ihre SQL Server-VM.

Problem der E/A-Drosselung auf VM-Ebene

Azure Virtual Machines sind cloudbasierte Computing-Ressourcen, die es in verschiedenen Serien und Größen für unterschiedliche Workloads gibt, jeweils mit unterschiedlichen Fähigkeiten und Leistungsmerkmalen. Bei SQL Server-Workloads sind im Allgemeinen die empfohlenen Reihen für SQL Server-Workloads die speicheroptimierten, z. B. die Ebdsv5-, M- und Mv2-Serie.

Die Größe der VM bestimmt die Anzahl der vCPUs, des Arbeitsspeichers und des für die SQL Server-Instanz verfügbaren Speichers. Im Vergleich zum Speicher ist es für Kunden relativ einfach, die Größe ihrer virtuellen Maschinen zu ändern und ihre VM je nach Bedarf an Anwendungsressourcen hoch- oder runterzuskalieren. Da es möglich ist, dass IOPS und Durchsatz auf VM-Ebene gedrosselt werden, wählen Sie eine geeignete VM-Größe auf der Grundlage der Leistungsanforderungen und der Kosten des Workloads.

Wenn Sie zu Azure migrieren, können Sie Tools wie den Datenmigrations-Assistenten und SKU-Empfehlungen verwenden, um Ihre aktuelle SQL Server-Konfiguration und -Nutzung zu analysieren und die beste VM-Größe für Ihren Workload in Azure vorzuschlagen.

Die folgenden Azure-Metriken werden verwendet, um zu bestimmen, ob die Workload von den von der VM auferlegten Grenzwerten gedrosselt wird:

  • Verbrauchte von der VM zwischengespeicherte IOPS in Prozent
  • Prozentsatz der von der VM beanspruchten zwischengespeicherten Bandbreite
  • Verbrauchte von der VM nicht zwischengespeicherte IOPS in Prozent
  • Prozentsatz der von der VM beanspruchten nicht zwischengespeicherten Bandbreite

Beachten Sie die folgenden wichtigen Punkte zur VM-Drosselung:

  • Sie können Arbeitsspeicher, vCores, Durchsatz und IOPS erhöhen, indem Sie die Größe Ihres virtuellen Computers innerhalb einer VM-Serie ändern.
  • Sie können die VM-Größe nicht auf eine Ebene reduzieren, auf der die Anzahl der Datenträger die maximale Datenträgergrenze für die Größe der Ziel-VM überschreitet.
  • Es ist wichtig, das Drosselungsmuster zu bestimmen. Beispielsweise können seltene Drosselungsspitzen wahrscheinlich durch Optimieren der Workload behoben werden, während anhaltende Spitzen darauf hindeuten könnten, dass der zugrunde liegende Speicher nicht in der Lage ist, die Workload zu verarbeiten.

Problem der E/A-Drosselung auf Disk-Ebene

Für Kunden von virtuellen SQL-Maschinen ist der Speicher der kritischste Aspekt, der für eine optimierte Leistung entsprechend konfiguriert werden muss, da die Änderung des Speichers eine größere Herausforderung darstellt als die Größenänderung einer virtuellen Maschine. Wenn Sie beispielsweise Änderungen vornehmen, um IOPS oder Durchsatz für Premium-SSD-Datenträger zu erhöhen, müssen Sie einen neuen Speicherpool erstellen. Daher ist es wichtig, die Speicherkonfiguration für Preis und Leistung während der Planungsphase zu optimieren, um Leistungsprobleme nach der Bereitstellung zu vermeiden.

Die folgenden Azure-Metriken werden verwendet, um zu bestimmen, ob die Workload von den vom Datenträger auferlegten Grenzwerten gedrosselt wird:

  • Beanspruchte Datenträger-IOPS in Prozent

  • Beanspruchte Datenträgerbandbreite in Prozent Beachten Sie die folgenden wichtigen Punkte zur E/A-Drosselung der Datenträgerebene:

  • Der Datenträger ist für die SQL Server-Leistung von entscheidender Bedeutung. Das Platzieren von SQL Server-Datendateien (.mdf) und Protokolldateien (DF) auf dem Datenträger wird empfohlen.

  • Aktivieren Sie für die Drosselung auf der Ebene der Datenfestplatte die Lesezwischenspeicherung, sofern diese verfügbar ist.

Beanspruchte Datenträger-IOPS in Prozent

Die Metrik Verbrauchter Prozentsatz der Datenträgerdatenträger misst den IOPS-Verbrauch auf Datenträgerebene. Im Allgemeinen sind hohe IOPS-Anforderungen mit stark transaktionsbasierten, OLTP-basierten Anwendungen und Workloads verknüpft.   Die folgenden Szenarien oder Bedingungen können die IOPS-Grenzwerte für Datenträger möglicherweise überschreiten:

  • Hohe Transaktions-Workload (IOPS): Wenn die Anwendung ein hohes Volumen von Datenbanktransaktionen verarbeitet, die häufige Lese- und Schreibvorgänge umfassen, kann sie schnell die zugeordneten IOPS nutzen. 
  • Ineffiziente Abfragen: Schlecht optimierte SQL-Abfragen oder Datenabrufvorgänge können zu übermäßiger E/A-Aktivität führen und mehr IOPS verbrauchen als erwartet. 
  • Gleichzeitige Benutzer: Wenn mehrere Benutzer oder Sitzungen gleichzeitig auf die Datenbank zugreifen und E/A-Anforderungen generieren, kann der kumulative Effekt dazu führen, dass der IOPS-Grenzwert erreicht wird. 
  • Konkurrierende Ressourcen: Wenn die zugrunde liegende physische Infrastruktur stark mit anderen Mandanten oder Workloads geteilt wird, kann sie sich auf die verfügbaren IOPS für Ihre virtuelle Maschine auswirken. 
  • Temporäre Spitzen: Temporäre Spitzen beim Workload, z. B. Stapelverarbeitung oder Datenmigrationen, können zu plötzlichen Anstiegen der E/A-Nachfrage führen, die die zugeordneten IOPS überschreiten. 
  • Kleine Datenträgergröße: Wenn die bereitgestellte Datenträgergröße relativ klein ist, ist die IOPS-Kapazität möglicherweise begrenzt. Einzelne kleinere Datenträger weisen niedrigere IOPS-Grenzwerte auf, und wenn die Anforderungen der Anwendung diesen Grenzwert überschreiten, erreicht der „Verbrauchte Prozentsatz der Datenträger-IOPS“ 100 %. 
  • Unzureichender Datenträgertyp: Die Auswahl eines Datenträgertyps mit niedrigerer Leistung (z. B. eine Standard-HDD) für eine E/A-intensive Anwendung kann zu IOPS-Einschränkungen führen. 
  • Nicht optimierte Datenträgerstreifengröße: Wenn die Speicherkonfiguration für die Workload nicht optimiert ist, kann dies zu einer suboptimalen IOPS-Leistung führen. 

Beachten Sie die folgenden Schritte, um die Überschreitung des IOPS-Grenzwerts des Datenträgers zu vermeiden:

  • Optimieren Sie SQL-Abfragen und den Datenbankentwurf, um unnötige E/A-Vorgänge zu minimieren. 
  • Wählen Sie einen geeigneten Datenträgertyp (SSD Standard oder SSD Premium) aus, der den IOPS-Anforderungen Ihrer Anwendung entspricht. 
  • Verwenden Sie größere Datenträgergrößen, um die verfügbare IOPS-Kapazität zu erhöhen. 
  • Verteilen Sie E/A über mehrere Datenträger mithilfe von RAID-Konfigurationen. 

Beanspruchte Datenträgerbandbreite in Prozent

Die Metrik Datendatenträgerbandbreite verbrauchter Prozentsatz von Azure misst die Bandbreitenauslastung auf Datenträgerebene. Im Allgemeinen sind hohe Durchsatzanforderungen mit Datenspeicherung, Data Mart, Berichte, ETL und anderen Datenanalyseworkloads verknüpft.

Die folgenden Szenarien oder Bedingungen können die Bandbreitenbeschränkungen der Datendatenträger möglicherweise überschreiten:

  • Große Datenübertragungen: Häufige, umfangreiche Anwendungsdatenübertragungen zwischen dem Datenträger und der SQL-Datenbank können schnell die verfügbare Datenträgerbandbreite verbrauchen. 
  • Massendatenladevorgang: Datentransferaktivitäten, die mit dem Einfügen, Aktualisieren oder Importieren von Massendaten verbunden sind, können zu einem hohen Bandbreitenverbrauch führen. 
  • Datenspeicherung oder Analysen: Anwendungen, die umfangreiche Datenspeicherungs-, Analyse- oder Berichtsfunktionen beinhalten, können erhebliche Datenbewegungen erzeugen, die zu einer Überschreitung der Bandbreitengrenzen führen können.
  • Hohe Datenredundanztechnologie/-replikation: Das Kopieren von Daten im Zusammenhang mit der Verwendung von plattenbasierter Replikation, Datenspiegelung oder anderen Redundanzmechanismen kann zur Sättigung der Bandbreite beitragen. 
  • Datensicherung und -wiederherstellung: Häufige Datensicherungen, Momentaufnahmen oder Wiederherstellungsprozesse können erhebliche Datenträgerbandbreite verbrauchen. 
  • Parallele Abfrageausführung: Parallele Abfragen, die große Datenscans oder Joins beinhalten, können zu erheblichen Datenverschiebungen führen, die eine hohe Bandbreitennutzung zur Folge haben. 
  • Erhöhter Netzwerkauslastung: Hohe Netzwerkaktivitäten, wie z. B. Datenübertragungen zwischen der virtuellen Maschine und anderen Ressourcen, können sich indirekt auf die Verfügbarkeit der Festplattenbandbreite auswirken. 
  • Unzureichender Datenträgertyp: Die Auswahl eines Datenträgertyps mit geringerer Leistung für eine Anwendung mit hohen Anforderungen an die Datenübertragung kann dazu führen, dass der Bandbreitengrenzwert überschritten wird. 
  • Gleichzeitige datenintensive Vorgänge: Die kombinierte Auswirkung mehrerer gleichzeitiger Prozesse oder Sitzungen, die auf Daten auf demselben Datenträger zugreifen und diese übertragen, kann dazu führen, dass die Bandbreitengrenze erreicht wird. 
  • Nicht optimierte Abfragen oder ETL-Prozesse: Schlecht optimierte SQL-Abfragen oder Extract-, Transform-, Load-, ETL-Prozesse können zu übermäßiger Datenverschiebung führen, die zu einem übermäßigen Bandbreitenverbrauch führt. 

Beachten Sie die folgenden Schritte, um zu vermeiden, dass der Grenzwert für die Datenträgerbandbreite überschritten wird:

  • Optimieren Sie Datenübertragungsvorgänge, um unnötige Datenverschiebungen zu minimieren. 
  • Erwägen Sie die Verwendung von Datenträgertypen mit höherer Leistung, die eine höhere Bandbreitenkapazität bieten, z. B. SSD Premium oder SSD Premium v2.
  • Verteilen Sie Daten über mehrere Festplatten mit Techniken wie Partitionierung oder Sharding.
  • Optimieren und parallelisieren Sie Abfragen und Datenverarbeitung, um die Datenverschiebung zu reduzieren.
  • Verwenden Sie Komprimierungs- und effiziente Datenspeichermechanismen, um die Menge der übertragenen Daten zu reduzieren.
  • Überwachen Sie Leistungsmetriken, und skalieren Sie Ihre Speicherkonfigurationen nach Bedarf. SSD Premium v2 ermöglicht es Kunden, ihre IOPS und den Durchsatz nach Bedarf zu skalieren.
  • Es ist wichtig, Leistungsmetriken regelmäßig zu überwachen und zu analysieren, um die Ursache von IOPS-Einschränkungen zu identifizieren und geeignete Maßnahmen zu ergreifen, um die Speicherleistung für Ihre virtuelle SQL-Maschine zu optimieren.

Tipp

Durch die regelmäßige Überwachung der Leistungsmetriken, die Abstimmung der Datenübertragungsvorgänge und die Optimierung der Festplattenkonfigurationen wird sichergestellt, dass die Leistung Ihrer Datendiskette für Ihre virtuelle SQL-Maschine optimal bleibt, ohne die Grenzen zu überschreiten.

Da schlecht konfigurierte Speichersysteme zu Leistungsproblemen führen können, können Sie den Speicherbereich im Azure-Portal verwenden, um eine datenträgerspezifische Teilmenge der SQL-Best-Practices-Bewertungs-Regeln auszuführen, um Speicherkonfigurationsprobleme mit SQL Server auf Azure-VMs zu identifizieren. Das Feature für bewährte SQL-Methoden basiert auf der SQL-Bewertungs-API.

Sie können eine vollständige Liste der Empfehlungen auf GitHub anzeigen. Durch Filtern nach der ID-Spalte in den Regeln auf GitHub können Sie die SQL VM-Datenträgerkonfigurationsregeln sehen, die auf der Registerkarte Bewährte Methoden für die E/A-Konfiguration des Speicherbereichs für Ihre Ressourcen für virtuelle SQL-Computer im Azure-Portal überprüft werden.

  • AzSqlVmSize
  • AzDataDiskCache
  • AzDataDiskStriping
  • AzDataOnDataDisks
  • AzDbDefaultLocation
  • AzDiskColumnCount
  • AzErrorLogLocation
  • AzPremSsdDataFiles
  • AzTempDbFileLocation
  • AzTranLogDiskCache
  • NtfsBlockSizeNotFormatted
  • LockedPagesInMemory

Verwenden Sie auf der Registerkarte E/A-bezogene Best Practices die Option Bewertung ausführen, um eine Bewertung Ihrer Konfiguration zu starten, die nur wenige Minuten in Anspruch nehmen sollte (es sei denn, es gibt eine große Anzahl von Datenbanken und Objekten). Alternativ können Sie, wenn ein Zeitstempel für die neuesten verfügbaren Ergebnisse angezeigt wird, die neuesten Ergebnisse abrufen, um Ergebnisse aus früheren Bewertungen zu überprüfen.

Analysieren von E/A mit PowerShell

Die E/A-Leistung Ihrer SQL Server-VM können Sie auch mit dem PowerShell-Skript E/A-Analyse analysieren:

# Enter parameters
$subscriptionId = Read-Host "<Subscription ID>"
$resourceGroup = Read-Host "<Resource Group>"
$vmName = Read-Host "<Virtual machine name>"

# Set resource details
$resourceType = "Microsoft.Compute/virtualMachines"
$resourceId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/$resourceType/$vmName"

# Get Azure access token
$accessToken = az account get-access-token --query accessToken -o tsv

# Invoke Azure Monitor Metrics API
function Get-Metrics {
    [CmdletBinding()]
    param (
        [string]$accessToken,
        [string]$resourceId,
        [string]$metricNames,
        [string]$apiVersion = "2023-10-01"
    )
    try {
        $startTime = (Get-Date).AddHours(-24).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
        $endTime = (Get-Date).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
        $timespan = "$startTime/$endTime"
        Write-Verbose "Evaluating timespan: $timespan"
        $uri = "https://management.azure.com$resourceId/providers/Microsoft.Insights/metrics?api-version=$apiVersion&metricnames=$metricNames&aggregation=maximum&interval=PT1M&timespan=$timespan"
        $headers = @{ "Authorization" = "Bearer $accessToken"; "Content-Type" = "application/json" }
        
        $response = Invoke-RestMethod -Uri $uri -Headers $headers -Method Get
        if ($response) {
            Write-Verbose "API response successfully retrieved."
            return $response
        } else {
            Write-Error "No response from API."
        }
    } catch {
        Write-Error "Error retrieving metrics: $_"
    }
}

# Check if data disk latency violates thresholds
function Check-Latency {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Object]$metrics,

        [Parameter()]
        [int]$latencyThreshold = 500,

        [Parameter()]
        [int]$consecutiveCount = 5
    )
    $violationTimes = @()
    foreach ($metric in $metrics.value) {
        if ($metric.name.value -eq "Data Disk Latency") {
            $count = 0
            foreach ($dataPoint in $metric.timeseries[0].data) {
                if ($dataPoint.maximum -gt $latencyThreshold) {
                    $count++
                    if ($count -ge $consecutiveCount) {
                        $violationTimes += $dataPoint.timeStamp
                        $count = 0  # Reset count after recording a violation
                    }
                } else {
                    $count = 0  # Reset count if the sequence is broken
                }
            }
        }
    }
    if ($violationTimes.Count -gt 0) {
        Write-Verbose "Latency violations detected."
        return @{ "Flag" = $true; "Times" = $violationTimes }
    } else {
        Write-Verbose "No latency violations detected."
        return @{ "Flag" = $false }
    }
}

# Check metrics other than latency to evaluate for throttling
function Check-OtherMetricsThrottled {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Object]$metrics,

        [Parameter()]
        [int]$PercentageThreshold = 90,

        [Parameter()]
        [int]$consecutiveCount = 5
    )
    $violatedMetrics = @()
    foreach ($metric in $metrics.value) {
        $count = 0
        foreach ($dataPoint in $metric.timeseries[0].data) {
            if ($dataPoint.maximum -gt $PercentageThreshold) {
                $count++
                if ($count -ge $consecutiveCount) {
                    $violatedMetrics += @{ "Metric" = $metric.name.localizedValue; "Time" = $dataPoint.timeStamp; "Value" = $dataPoint.maximum }
                    break
                }
            } else {
                $count = 0
            }
        }
    }
    if ($violatedMetrics.Count -gt 0) {
        Write-Verbose "Other metrics violations detected."
    } else {
        Write-Verbose "No other metrics violations detected."
    }
    return $violatedMetrics
}

# Compare times for latency & other throttled metrics. Logs the volations with values & timestamps
function CompareTimes {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Hashtable]$latencyResult,
        
        [Parameter(Mandatory = $true)]
        [Array]$otherMetrics
    )
    foreach ($metric in $otherMetrics) {
        $otherDateTime = [DateTime]$metric["Time"]
        $isWithinFiveMinutes = $false
        $closestLatencyTime = $null
        $closestTimeDifference = [int]::MaxValue

        foreach ($latencyTime in $latencyResult.Times) {
            $latencyDateTime = [DateTime]$latencyTime
            $timeDifference = [Math]::Abs(($otherDateTime - $latencyDateTime).TotalMinutes)
            
            if ($timeDifference -le 5) {
                $isWithinFiveMinutes = $true
                if ($timeDifference -lt $closestTimeDifference) {
                    $closestTimeDifference = $timeDifference
                    $closestLatencyTime = $latencyTime
                }
            }
        }

        if ($isWithinFiveMinutes) {
            if ($otherDateTime -lt $closestLatencyTime) {
                Write-Host "`n $($metric["Metric"]) limit was hit before latency spiked at $closestLatencyTime with value $($metric["Value"]). `n"
            } else {
                Write-Host "`n $($metric["Metric"]) hit its limit with value $($metric["Value"]) at $($metric["Time"])."
                Write-Host "Latency spiked at $closestLatencyTime before $($metric["Metric"]) hit its limit `n"
            }
        } else {
            Write-Host "`n Metric: $($metric["Metric"]) exceeded its threshold with a value of $($metric["Value"]) at $($metric["Time"]), but this was not within 5 minutes of any latency spikes."
        }
    }
}

# Prompt user for latency threshold
$latencyThreshold = Read-Host "Enter Latency Threshold (default is 500)"
if (-not [int]::TryParse($latencyThreshold, [ref]0)) {
    $latencyThreshold = 500 # Use default if invalid input
    Write-Host "No valid input provided. Using Default 500ms for disk latency threshold"
}

# Execute main logic
$latencyMetrics = Get-Metrics -accessToken $accessToken -resourceId $resourceId -metricNames "Data Disk Latency"
$latencyResult = Check-Latency -metrics $latencyMetrics -latencyThreshold $latencyThreshold

if ($latencyResult.Flag) {
    
    # If latency is flagged, check for other metrics. If there is no disk latency, machine is likely not throttled but only at high consumption
    Write-Verbose "Checking the following metrics: Data Disk Bandwidth Consumed Percentage,Data Disk IOPS Consumed Percentage,VM Cached Bandwidth Consumed Percentage,VM Cached IOPS Consumed Percentage,VM Uncached Bandwidth Consumed Percentage,VM Uncached IOPS Consumed Percentage"
    
    $DiskVMMetrics = Get-Metrics -accessToken $accessToken -resourceId $resourceId -metricNames "Data Disk Bandwidth Consumed Percentage,Data Disk IOPS Consumed Percentage,VM Cached Bandwidth Consumed Percentage,VM Cached IOPS Consumed Percentage,VM Uncached Bandwidth Consumed Percentage,VM Uncached IOPS Consumed Percentage"
    
    $additionalMetrics = Check-OtherMetricsThrottled -metrics $DiskVMMetrics
    
    if ($additionalMetrics.Count -gt 0) {
        CompareTimes $latencyResult $additionalMetrics
    } else {
        Write-Host "No metrics violations detected besides latency."
    }
} else {
    Write-Host "No latency issues detected."
}

Nächste Schritte