Überwachen von Abfrageanforderungen in Azure KI Search
In diesem Artikel erfahren Sie, wie Sie Abfrageleistung und -volumen mit integrierten Metriken und Ressourcenprotokollierung messen. Außerdem wird erläutert, wie die Abfragezeichenfolgen abgerufen werden, die von Anwendungsbenutzern eingegeben werden.
Im Azure-Portal werden grundlegende Metriken zur Abfragelatenz, Abfragelast (Queries Per Second, QPS) und Drosselung angezeigt. Auf historische Daten, die in diese Metriken einfließen, kann im Portal 30 Tage zugegriffen werden. Zur längeren Aufbewahrung oder zur Erstellung von Berichten für operative Daten und Abfragezeichenfolgen müssen Sie eine Diagnoseeinstellung hinzufügen, die eine Speicheroption für die Beibehaltung von protokollierten Vorgängen und Metriken festlegt. Es wird empfohlen, einen Log Analytics-Arbeitsbereich als Ziel für protokollierte Vorgänge zu verwenden. Kusto-Abfragen und die Datenuntersuchung verwenden einen Log Analytics-Arbeitsbereich als Ziel.
Zu den Bedingungen, die die Integrität der Datenmessung maximieren, gehören:
Verwenden Sie einen abrechenbaren Dienst (einen Dienst, der entweder im Basic- oder Standard-Tarif erstellt wurde). Der kostenlose Tarif (Free) wird von mehreren Abonnenten gemeinsam genutzt, wodurch eine gewisse Volatilität durch wechselnde Auslastungen entsteht.
Verwenden Sie, wenn möglich, ein einzelnes Replikat und eine Partition, um eine eigenständige und isolierte Umgebung zu erstellen. Wenn Sie mehrere Replikate verwenden, werden Abfragemetriken als Durchschnitt mehrerer Knoten angegeben, wodurch die Genauigkeit der Ergebnisse sinken kann. Gleichermaßen bedeuten mehrere Partitionen, dass Daten aufgeteilt werden, wodurch einige Partitionen möglicherweise unterschiedliche Daten aufweisen, wenn gleichzeitig die Indizierung ausgeführt wird. Wenn Sie die Abfrageleistung optimieren, bieten ein einzelner Knoten und eine Partition eine stabilere Umgebung für Tests.
Tipp
Mit zusätzlichem clientseitigem Code und Application Insights können Sie auch Durchklick-Daten (Clickthrough) erfassen, um einen tieferen Einblick in die Interessen Ihrer Anwendungsbenutzer zu erhalten. Weitere Informationen finden Sie unter Datenverkehrsanalyse durchsuchen.
Abfragevolumen (QPS)
Das Volumen wird als Suchabfragen pro Sekunde (QPS) gemessen, einer integrierten Metrik, die als Durchschnitt, Anzahl, Minimal- oder Maximalwerte für Abfragen angegeben werden kann, die innerhalb eines einminütigen Zeitfensters ausgeführt werden. Einminütige Intervalle (TimeGrain = „PT1M“) für Metriken sind im Systems festgelegt.
Da Abfragen häufig innerhalb von Millisekunden ausgeführt werden, werden nur in Sekunden gemessene Abfragen in Metriken angezeigt.
| Aggregationstyp | Beschreibung |
|---|---|
| Average | Die durchschnittliche Anzahl von Sekunden innerhalb einer Minute, in der die Abfrageausführung erfolgt ist. |
| Anzahl | Anzahl der Metriken, die innerhalb des Ein-Minuten-Intervalls an das Protokoll ausgegeben werden. |
| Maximum | Die höchste Anzahl von Suchabfragen pro Sekunde, die während einer Minute erfasst wurden. |
| Mindestanforderungen | Die niedrigste Anzahl von Suchabfragen pro Sekunde, die während einer Minute erfasst wurden. |
| Sum | Die Summe aller Abfragen, die innerhalb der Minute ausgeführt wurden. |
Innerhalb einer Minute kann beispielsweise folgendes Muster vorliegen: Für eine Sekunde tritt eine sehr hohe Last auf (dies ist der Höchstwert für „SearchQueriesPerSecond“), gefolgt von 58 Sekunden mit mittlerer Last sowie einer Sekunde mit nur einer Abfrage, was der Mindestwert ist.
Ein weiteres Beispiel: Wenn ein Knoten 100 Metriken ausgibt, bei denen der Wert jeder Metrik 40 beträgt, weist „Count“ den Wert „100“, „Sum“ den Wert „4000“, „Average“ den Wert „40“ und „Max“ den Wert „40“ auf.
Abfrageleistung
Die dienstweite Abfrageleistung wird als Suchlatenz (wie lange eine Abfrage dauert) und gedrosselte Abfragen, die aufgrund von Ressourcenkonflikten gelöscht wurden, gemessen.
Wartezeit bei Suchvorgängen
| Aggregationstyp | Latency |
|---|---|
| Average | Durchschnittliche Abfragedauer in Millisekunden. |
| Anzahl | Anzahl der Metriken, die innerhalb des Ein-Minuten-Intervalls an das Protokoll ausgegeben werden. |
| Maximum | Die Abfrage mit der längsten Ausführungszeit in der Stichprobe. |
| Mindestanforderungen | Die Abfrage mit der kürzesten Ausführungszeit in der Stichprobe. |
| Summe | Gesamtausführungszeit aller Abfragen in der Stichprobe, die innerhalb des Intervalls (eine Minute) ausgeführt werden. |
Betrachten Sie das folgende Beispiel für die Metrik Suchlatenz: Bei einer Stichprobe von 86 Abfragen betrug die durchschnittliche Dauer 23,26 Millisekunden. Ein Minimalwert von 0 gibt an, dass einige Abfragen gelöscht wurden. Die längste Abfrage hat 1000 Millisekunden gedauert. Die Gesamtausführungszeit betrug 2 Sekunden.
Gedrosselte Abfragen
Gedrosselte Abfragen sind Abfragen, die nicht verarbeitet, sondern gelöscht werden. In den meisten Fällen ist die Drosselung ein normaler Bestandteil der Dienstausführung. Sie weisen nicht unbedingt darauf hin, dass etwas nicht stimmt.
Eine Drosselung tritt auf, wenn die Anzahl von Anforderungen, die sich in Ausführung befinden, die Kapazität überschreitet. Wenn ein Replikat aus der Rotation herausgenommen wird, oder während der Indizierung kann es zu einer Erhöhung der gedrosselten Anforderungen kommen. Abfrage- und Indizierungsanforderungen werden vom selben Ressourcensatz verarbeitet.
Der Dienst bestimmt, ob Anforderungen basierend auf der Ressourcennutzung gelöscht werden. Der Prozentsatz der für Arbeitsspeicher, CPU und Datenträger-E/AE genutzten Ressourcen wird als Durchschnittswert über einen bestimmten Zeitraum berechnet. Wenn dieser Prozentsatz einen Schwellenwert überschreitet, werden alle Anforderungen an den Index gedrosselt, bis die Anzahl der Anforderungen reduziert wird.
Abhängig vom Client wird eine gedrosselte Anforderung wie folgt angezeigt:
- Ein Dienst gibt den Fehler
"You are sending too many requests. Please try again later."zurück. - Ein Dienst gibt einen 503-Fehlercode zurück, der angibt, dass der Dienst derzeit nicht verfügbar ist.
- Wenn Sie das Portal verwenden (z. B. den Suchexplorer), wird die Abfrage automatisch gelöscht, und Sie müssen erneut Suchen auswählen.
Um gedrosselte Abfragen zu bestätigen, verwenden Sie die Metrik Gedrosselte Suchabfragen. Sie können Metriken im Portal untersuchen oder eine Warnungsmetrik erstellen, wie in diesem Artikel beschrieben. Verwenden Sie für Abfragen, die innerhalb des Intervalls für die Stichprobenentnahme gelöscht wurden, die Option Gesamt, um den Prozentsatz nicht ausgeführter Abfragen zu erhalten.
| Aggregationstyp | Drosselung |
|---|---|
| Average | Prozentsatz der innerhalb des Intervalls gelöschten Abfragen. |
| Anzahl | Anzahl der Metriken, die innerhalb des Ein-Minuten-Intervalls an das Protokoll ausgegeben werden. |
| Maximum | Prozentsatz der innerhalb des Intervalls gelöschten Abfragen. |
| Mindestanforderungen | Prozentsatz der innerhalb des Intervalls gelöschten Abfragen. |
| Summe | Prozentsatz der innerhalb des Intervalls gelöschten Abfragen. |
Für Gedrosselte Suchabfragen in Prozent entsprechen der Mindest-, Höchst-, Durchschnitts- und Gesamtwert demselben Wert, nämlich dem Prozentsatz von Suchabfragen, die gedrosselt wurden, basierend auf der Gesamtanzahl von Suchabfragen während einer Minute.
Im folgenden Screenshot gibt die erste Zahl die Anzahl (bzw. die Anzahl der an das Protokoll gesendeten Metriken) an. Andere Aggregationen, die im oberen Bereich oder beim Zeigen auf die Metrik angezeigt werden, sind Durchschnitts-, Höchst- und Gesamtwert. In diesem Beispiel wurden keine Anforderungen gelöscht.
Untersuchen der Metriken im Portal
Um einen schnellen Überblick über die aktuellen Zahlen zu erhalten, werden auf der Registerkarte Überwachung auf der Seite „Übersicht“ des Diensts drei Metriken (Suchlatenz, Suchabfragen pro Sekunde (pro Sucheinheit), Gedrosselte Suchabfragen in Prozent) in bestimmten Intervallen angezeigt, gemessen in Stunden, Tagen und Wochen, mit der Option, den Aggregationstyp zu ändern.
Zur tiefer gehenden Untersuchung öffnen Sie den Metrik-Explorer aus dem Menü Überwachung, um Daten überlagern, vergrößern und visualisieren und so Trends oder Anomalien untersuchen zu können. Weitere Informationen zum Metrik-Explorer erhalten Sie in diesem Tutorial zum Erstellen eines Metrikdiagramms.
Wählen Sie im Abschnitt „Überwachung“ die Option Metriken aus, um den Metrik-Explorer mit dem auf Ihren Suchdienst festgelegt Bereich zu öffnen.
Wählen Sie unter „Metrik“ eine Metrik aus der Dropdownliste aus, und überprüfen Sie die Liste der verfügbaren Aggregationen für einen bevorzugten Typ. Die Aggregation definiert, wie Stichproben der Werte in den einzelnen Zeitintervallen genommen werden.
Legen Sie in der oberen rechten Ecke das Zeitintervall fest.
Wählen Sie eine Visualisierung aus. Der Standardwert ist ein Liniendiagramm.
Überlagern Sie mehrere Aggregationen, indem Sie Metrik hinzufügen und unterschiedliche Aggregationen auswählen.
Vergrößern Sie einen relevanten Bereich im Liniendiagramm. Platzieren Sie den Mauszeiger am Anfang des Bereichs, halten Sie die linke Maustaste gedrückt, ziehen Sie den Mauszeiger zur anderen Seite des Bereichs, und lassen Sie die Maustaste wieder los. Im Diagramm wird dieser Zeitbereich vergrößert.
Zurückgeben von Abfragezeichenfolgen, die von Benutzern eingegeben werden
Wenn Sie die Ressourcenprotokollierung aktivieren, erfasst das System Abfrageanforderungen in der Tabelle AzureDiagnostics. Voraussetzung hierfür ist, dass Sie bereits ein Ziel für protokollierte Vorgänge angegeben haben (entweder einen Log Analytics-Arbeitsbereich oder eine andere Speicheroption).
Wählen Sie im Abschnitt „Überwachung“ die Option Protokolle aus, um in Log Analytics ein leeres Abfragefenster zu öffnen.
Führen Sie den folgenden Ausdruck aus, um nach
Query.Search-Vorgängen zu suchen und ein tabellarisches Resultset zurückzugeben, das aus dem Vorgangsnamen, der Abfragezeichenfolge, dem abgefragten Index und der Anzahl gefundener Dokumente besteht. Die letzten beiden Anweisungen schließen aus einer leeren oder nicht angegebenen Suche bestehende Abfragezeichenfolgen über einen Beispielindex aus, wodurch unnötige Informationen in den Ergebnissen reduziert werden.AzureDiagnostics | project OperationName, Query_s, IndexName_s, Documents_d | where OperationName == "Query.Search" | where Query_s != "?api-version=2023-07-01-preview&search=*" | where IndexName_s != "realestate-us-sample-index"Legen Sie optional einen Spaltenfilter auf Query_s fest, um eine bestimmte Syntax oder Zeichenfolge zu durchsuchen. Beispielsweise können Sie nach ist gleich
?api-version=2023-11-01&search=*&%24filter=HotelNamefiltern.
Diese Technik funktioniert zwar für die Ad-hoc-Untersuchung, durch Erstellen eines Berichts können Sie die Abfragezeichenfolgen jedoch in einem Layout konsolidieren und darstellen, das für die Analyse besser geeignet ist.
Ermitteln von Abfragen mit langer Ausführungsdauer
Fügen Sie eine Spalte für die Dauer hinzu, um die Zahlen für alle Abfragen zu erhalten, nicht nur für die, die als Metrik abgefragt werden. Durch Sortieren dieser Daten können Sie erkennen, welche Abfragen am längsten dauern.
Wählen Sie im Abschnitt „Überwachung“ die Option Protokolle aus, um nach Protokollinformationen abzufragen.
Führen Sie die folgende grundlegende Abfrage aus, um Abfragen sortiert nach Dauer in Millisekunden zurückzugeben. Die längsten Abfragen stehen oben.
AzureDiagnostics | project OperationName, resultSignature_d, DurationMs, Query_s, Documents_d, IndexName_s | where OperationName == "Query.Search" | sort by DurationMs
Erstellen einer Metrikwarnung
Eine Metrikwarnung legt einen Schwellenwert für das Senden einer Benachrichtigung oder Auslösen einer vorab festgelegten Korrekturmaßnahme fest. Neben Warnungen im Zusammenhang mit der Abfrageausführung können Sie auch Warnungen für Ressourcenintegrität, Änderungen der Suchdienstkonfiguration, Skillausführung und Dokumentverarbeitung (Indizierung) erstellen.
Alle Schwellenwerte sind benutzerdefiniert. Sie sollten daher wissen, durch welche Aktivitätsebene die Warnung ausgelöst werden soll.
Bei der Abfrageüberwachung ist es üblich, eine Metrikwarnung für die Wartezeit bei Suchvorgängen und gedrosselte Abfragen zu erstellen. Wenn Sie wissen, wann Abfragen gelöscht werden, können Sie nach Abhilfemaßnahmen suchen, die die Last verringern oder die Kapazität erhöhen. Wenn z. B. gedrosselte Abfragen während der Indizierung zunehmen, können Sie diese verschieben, bis die Abfrageaktivität nachlässt.
Wenn Sie bis an die Grenzen einer bestimmten Replikat-/Partitionskonfiguration gehen, ist es auch hilfreich, Warnungen für Abfragevolumen-Schwellenwerte (Queries Per Second, QPS) einzurichten.
Wählen Sie unter Überwachung die Option Warnungen und dann Warnungsregel erstellen aus.
Wählen Sie unter „Bedingung“ die Option Hinzufügen aus.
Konfigurieren Sie die Signallogik. Wählen Sie als Signaltyp Metriken und dann das Signal aus.
Nachdem Sie das Signal ausgewählt haben, können Sie ein Diagramm zur Visualisierung von Verlaufsdaten verwenden, um eine fundierte Entscheidung über das weitere Vorgehen bei der Einrichtung von Bedingungen zu treffen.
Scrollen Sie als nächstes nach unten zur Warnungslogik. Als „Proof-of-Concept“ könnten Sie für Testzwecke einen künstlich niedrigen Wert angeben.
Geben Sie als nächstes eine Aktionsgruppe an, oder erstellen Sie eine. Dies ist die Antwort, die aufgerufen wird, wenn der Schwellenwert erreicht ist. Es kann eine Pushbenachrichtigung oder eine automatische Antwort sein.
Zuletzt geben Sie die Warnungsdetails an. Benennen und beschreiben Sie die Warnung, weisen Sie einen Schweregrad zu, und geben Sie an, ob die Regel in einem aktivierten oder deaktivierten Zustand erstellt werden soll.
Wenn Sie eine E-Mail-Benachrichtigung angegeben haben, erhalten Sie eine E-Mail von „Microsoft Azure“ mit der Betreffzeile „Azure: Aktivierter Schweregrad: 3 <your rule name>“.
Nächste Schritte
Fall noch nicht geschehen, überprüfen Sie die Grundlagen der Überwachung von Suchdiensten, um mehr über die gesamte Palette an Überwachungsfunktionen zu erfahren.