Überlegungen zur Vorgangsverwaltung für den AIS Services-Zielzonenbeschleuniger
Dieser Artikel enthält Überlegungen und Empfehlungen für die Betriebsverwaltung und -überwachung bei der Verwendung der AIS-Angebote.
Die meisten Empfehlungen in diesem Abschnitt gelten für die Standardversion (einzelinstanzenfähig) des Logic Apps-Diensts, der selbst Teil des Azure App Service-Angebots ist und viele der gleichen Verwaltungsfunktionen nutzt.
Viele Ressourcen, aus denen AIS besteht, können so konfiguriert werden, dass Protokoll-, Telemetrie- und Metrikdaten in Log Analytics/Application Insights oder an benutzerdefinierten Speicherorten gespeichert werden (zu diesen Ressourcen gehören Speicherkonten, Event Hubs und andere).
Wir können diese Informationen nutzen, um die allgemeine Integrität unserer Ressourcen zu visualisieren und die entsprechenden Verwaltungsaktionen zu ergreifen.
Definitionen
Azure Monitor-Protokolle sammelt und organisiert Protokoll- und Leistungsdaten von überwachten Ressourcen. Tools wie Log Analytics können diese Protokollinformationen dann abfragen oder visualisieren oder sie ermöglichen es Ihnen, zu warnen, wenn bestimmte Bedingungen erfüllt sind.
Azure Metric-Protokolle sammelt numerische Daten aus überwachten Ressourcen in einer Zeitreihendatenbank. Tools wie Application Insights können diese Daten dann visualisieren und Ihnen helfen, Leistungs- und Laufzeitprobleme zu identifizieren.
Log Analytics ist ein Azure-Überwachungsangebot, das einen Ort zum Speichern von Protokoll- und Leistungsdaten und einen Mechanismus und eine Sprache zum Abfragen dieser Protokolle (Kusto) bereitstellt. Es bietet außerdem die Möglichkeit, Warnungen und Dashboards basierend auf diesen Protokollen (und anderen Funktionen) zu erstellen.
Application Insights ist ein Azure-Überwachungsangebot, das die Möglichkeit bietet, Leistungsdaten, die von überwachten Ressourcen ausgegeben werden, zu visualisieren und zu warnen.
Kusto-Abfragesprache (KQL) ist eine leistungsstarke Abfragesprache, die für die Abfrage und das Formatieren von Daten optimiert ist. Sie ist beispielsweise die primäre Abfragesprache für Log Analytics.
Entwurfsaspekte
Betrachten Sie Ihre Überwachungslösung als Ganzes:
Welche Ressourcen müssen überwacht werden?
Wie werden Nachrichten zwischen Ressourcen nachverfolgt?
Mit welchen externen Systemen werden Sie eine Verbindung herstellen?
Welche Arten von Warnungen benötigen Sie?
Überlegen Sie, welche Abfragen Sie ausführen müssen. Müssen Sie beispielsweise wissen, ob eine bestimmte Anforderung länger dauert als erwartet? Oder wenn Sie einen einzelnen Fehler oder mehrere Fehler erhalten?
Welche Ebene der Nachverfolgung benötigen Sie? Wenn beispielsweise eine Nachricht von einem Drittanbieter eingeht, müssen Sie diese Nachricht über alle zugeordneten Ressourcen nachverfolgen?
Welche Verwaltungsaufgaben müssen Sie ausführen? Müssen Sie Nachrichten oder Dateien erneut übermitteln?
Der Ausführungsverlauf der Logik-App wird standardmäßig in Azure Storage gespeichert. Sie können Metriken und Protokolldateien jedoch auch in andere Quellen (z. B. Log Analytics oder ein externes Speicherkonto) exportieren. Überlegen Sie, wie Sie Ihre Protokollierungsinformationen verwenden und ob Sie einen zentralen Protokollspeicher bevorzugen.
Application Insights wird verwendet, um die Anwendungsleistungsüberwachung (APM) bereitzustellen. Dazu werden Metriken aus den Ressourcen gesammelt, aus denen Ihre Lösung besteht.
Log Analytics wird verwendet, um Protokolle abzufragen und Warnungen einzurichten, sodass Sie die Integrität Ihrer Ressourcen anzeigen und Probleme, die auftreten, verstehen können. Protokolldaten können benutzerdefinierte Eigenschaften enthalten (siehe Nachverfolgte Eigenschaften unten).
Weitere Überlegungen und Empfehlungen, die speziell für App Services gelten, finden Sie im Verwaltungsartikel App Service-Zielzonenbeschleuniger.
Entwurfsempfehlungen
Richten Sie Application Insights so ein, dass ein Log Analytics-Arbeitsbereich als Datenquelle verwendet wird (arbeitsbereichsbasierte Ressource genannt). Dadurch können Protokollierungs- und Leistungsdaten an einem konsolidierten Speicherort aufbewahrt werden.
Richten Sie Warnungen für alle Ressourcen ein, um die entsprechenden Teams über Ereignisse zu informieren, die sich auf einzelne Ressourcen oder die Workload beziehen.
Verknüpfen Sie die Ressourcen in Ihrer Lösung mit Application Insights, falls unterstützt. Beispielsweise kann eine Logik-App mit Application Insights verknüpft werden, sodass Runtimedaten und Metriken für Abfragen verfügbar sind. Hier finden Sie ein Beispiel.
Verwenden Sie die Funktion ClientTrackingId von Logic Apps, um eine benutzerdefinierte Nachverfolgungs-ID anzugeben, mit der Sie Ereignisse über Logik-App-Ausführungen hinweg korrelieren können. Sie können den Header „x-ms-client-tracking-id“ verwenden, um dieses Ergebnis mit den Triggern „Anforderung“, „HTTP“ oder „HTTP+WebHook“ zu erzielen.
Verwenden Sie die Funktion Nachverfolgte Eigenschaften von Logic Apps, um andere Daten (Eingabe oder Ausgabe) aus einer Aktion in den Protokolldateien zu protokollieren. Diese Eigenschaften können dann beim Abfragen von Protokollen mithilfe von KQL mit Log Analytics oder einer anderen Lösung verwendet werden.
Erwägen Sie die Verwendung von Ressourcentags. Ressourcentags können Ihnen beim Verwalten und Organisieren von Ressourcen in Azure helfen. Sie können sie verwenden, um Ressourcen Metadaten zuzuweisen. Sie können diese Metadaten für verschiedene Zwecke verwenden, etwa die Kategorisierung von Ressourcen nach Anwendung oder Geschäftseinheit, die Nachverfolgung der Ressourcenkosten und die Identifizierung von Ressourcen für Compliance.
Kusto-Beispielabfragen
Die folgenden Abfragen zeigen, wie sie die drei Standardtabellen abfragen, die für AIS-Protokolldaten verwendet werden. Auf jede dieser Tabellen kann über die Option „Protokolle“ im Abschnitt „Überwachung“ Ihrer Logik-App zugegriffen werden.
Die Standardabfragetabellen sind:
exceptions
Diese Tabelle enthält alle Ausnahmen, die von Ihrer Ressource protokolliert werden, z. B. Ausnahmen, die von der Logik-App-Runtime ausgelöst werden. Sie kann verwendet werden, um nach der zugrunde liegenden Ursache für alle Probleme zu suchen, die Sie entweder im Portal oder während der Ausführung Ihres Codes sehen.requests
In dieser Tabelle werden alle Anforderungen protokolliert, die von der Logik-App-Runtime an eine andere Ressource oder an bestimmte Aktionen innerhalb Ihres Workflows gesendet werden.traces
Diese Tabelle enthält den Großteil der Logic Apps-Runtimeprotokolle, Protokollierungsdetails zur Triggerausführung, Workflowstart und -ende sowie Aktionsausführung. Wenn Sie nachverfolgte Eigenschaften ihrer Aktionen protokolliert haben, finden Sie diese Daten im Abschnitt customDimensions. Anschließend können Sie die extend-Klausel in einer Abfrage verwenden, um die Daten als Spalten Ihrer Abfrageantwort hinzuzufügen.
Workflows mit Fehlern:
> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions.LogLevel == "Error"
Anzahl der Workflowausführungen in den letzten 24 Stunden für alle Workflows:
> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions\["EventName"\] == "WorkflowActionStart"
>
> \| where timestamp \> ago(1d)
>
> \| count
Triggererfolgsrate im Zeitverlauf
> traces
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
> \| where customDimensions\["EventName"\] == "WorkflowTriggerEnd"
> \|summarize
>
> success = countif(customDimensions\["prop\_\_status"\] ==
> "Succeeded"),
>
> failures = countif(customDimensions\["prop\_\_status"\] == "Failed")
>
> by bin(timestamp, 1m)
> \| render timechart
Nächster Schritt
Überprüfen Sie die kritischen Designbereiche, um umfassende Überlegungen hinsichtlich Ihrer Architektur anzustellen und Empfehlungen zu geben.