Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Von Bedeutung
Hinweis zur Einstellung: Dieser Artikel ist veraltet und wird nicht mehr aktualisiert. Um sicherzustellen, dass nur die besten Anleitungen angezeigt werden, wird dieser Artikel im Mai 2026 gelöscht.
Alternative Anleitungen finden Sie unter Integrationsarchitektur Anleitung im Azure Architecture Center.
Wenn Sie diese Anleitung speichern möchten, können Sie Download a PDF unten links auf dieser Seite auswählen oder die Dateien aus GitHub herunterladen.
Dieser Artikel enthält Überlegungen und Empfehlungen für die Betriebsverwaltung und -überwachung bei Verwendung der AIS-Angebote.
Die meisten Empfehlungen in diesem Abschnitt gelten für die Standardversion (Single-Tenant) von Logic Apps, die selbst Teil des Azure App Service Angebots ist und viele der gleichen Verwaltungsfunktionen teilt.
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 (diese Ressourcen umfassen Speicherkonten, Event Hubs und andere).
Wir können diese Informationen nutzen, um die Gesamtintegrität unserer Ressourcen zu visualisieren und die entsprechenden Verwaltungsaktionen zu ergreifen.
Definitionen
Azure Monitor Logs sammelt und organisiert Protokoll- und Leistungsdaten aus überwachten Ressourcen. Tools wie Log Analytics können diese Protokollinformationen dann abfragen oder visualisieren oder sie benachrichtigen lassen, wenn bestimmte Bedingungen erfüllt sind.
Azure Metrikprotokolle sammelt numerische Daten von überwachten Ressourcen und speichert sie in einer Zeitreihendatenbank. Tools wie Application Insights können diese Daten dann visualisieren, um Leistungs- und Laufzeitprobleme zu identifizieren.
Log Analytics ist ein Azure Monitoring-Angebot, das einen Speicherort zum Speichern von Protokoll- und Leistungsdaten bietet, einen Mechanismus und eine Sprache zum Abfragen dieser Protokolle (Kusto) und bietet die Möglichkeit, Warnungen und Dashboards basierend auf diesen Protokollen (unter anderem Funktionen) zu erstellen.
Application Insights ist ein Azure Monitoring-Angebot, das die Möglichkeit bietet, Leistungsdaten, die von überwachten Ressourcen ausgegeben werden, visualisieren und warnen zu können.
Kusto Query Language (KQL) ist eine leistungsstarke Abfragesprache, die für Abfragen und Formatierungsdaten optimiert ist. Beispielsweise ist es die primäre Abfragesprache für Log Analytics.
Entwurfsüberlegungen
Betrachten Sie Ihre Überwachungslösung als Ganzes:
Welche Ressourcen müssen Sie überwachen?
Wie verfolgen Sie Nachrichten, die zwischen Ressourcen fließen?
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 als erwartet dauert? Oder wenn Sie einen einzelnen Fehler im Vergleich zu einem Cluster von Fehlern erhalten?
Welche Ebene der Nachverfolgung benötigen Sie? Wenn beispielsweise eine Nachricht von einem Drittanbieter eingeht, müssen Sie diese Nachricht über alle zugehörigen Ressourcen nachverfolgen?
Welche Verwaltungsaufgaben müssen Sie ausführen? Müssen Sie Nachrichten oder Dateien erneut übermitteln?
Der Verlauf der Logik-App-Ausführung wird standardmäßig in Azure Storage gespeichert, Sie können jedoch auch Metriken und Protokolldateien in andere Quellen exportieren (z. B. Log Analytics oder ein externes Speicherkonto). Überlegen Sie, wie Sie Ihre Protokollierungsinformationen verwenden, und wenn Sie einen zentralen Protokollspeicher verwenden.
Application Insights wird verwendet, um anwendungsleistungsüberwachung bereitzustellen. Dazu sammeln Sie Metriken aus den Ressourcen, aus denen Ihre Lösung besteht.
Log Analytics werden verwendet, um Protokolle abzufragen und Warnungen einzurichten, sodass Sie den Status Ihrer Ressourcen sehen und Probleme verstehen können, die auftreten können. Protokolldaten können benutzerdefinierte Eigenschaften enthalten (siehe nachverfolgte Eigenschaften unten).
Weitere Überlegungen und Empfehlungen für App Services finden Sie im Artikel zur Verwaltung der App Service Landing Zone Accelerator.
Designempfehlungen
Richten Sie Application Insights so ein, dass es einen Log Analytics Workspace als Datenquelle verwendet (bekannt als eine workspace-basierte Ressource). Auf diese Weise können Protokollierungs- und Leistungsdaten an einem konsolidierten Speicherort gespeichert werden.
Richten Sie Benachrichtigungen für alle Ressourcen ein, um geeignete Teams über Ereignisse im Zusammenhang mit einzelnen Ressourcen oder mit der Workload zu benachrichtigen.
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 Laufzeitdaten und Metriken für die Abfrage verfügbar sind. Ein Beispiel finden Sie hier.
Verwenden Sie die clientTrackingId-Funktion von Logik-Apps, um eine benutzerdefinierte Nachverfolgungs-ID bereitzustellen, sodass Sie Ereignisse über Ausführungen der Logik-Apps korrelieren zu können. Sie können den x-ms-client-tracking-id-Header verwenden, um dieses Ergebnis mit den Triggern "Request", "HTTP" oder "HTTP+WebHook" zu erzielen.
Verwenden Sie das Feature "Nachverfolgte Eigenschaften " von Logik-Apps, um andere Daten (Eingabe oder Ausgabe) aus einer Aktion in den Protokolldateien zu protokollieren. Diese Eigenschaften sind dann für die Verwendung beim Abfragen von Protokollen mit KQL mit Log Analytics oder einer anderen Lösung verfügbar.
Erwägen Sie die Verwendung von Ressourcentags. Ressourcentags können Ihnen beim Verwalten und Organisieren von Ressourcen auf Azure helfen. Sie können sie verwenden, um Ressourcen Metadaten zuzuweisen. Sie können diese Metadaten für verschiedene Zwecke verwenden, z. B. das Kategorisieren von Ressourcen nach Anwendung oder Geschäftseinheit, das Nachverfolgen der Ressourcenkosten und das Identifizieren von Ressourcen für die Compliance.
Kusto-Beispielabfragen
Die folgenden Abfragen zeigen, wie sie die drei Haupttabellen 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 wichtigsten Abfragetabellen sind:
Ausnahmen
Diese Tabelle enthält alle von Ihrer Ressource protokollierten Ausnahmen, z. B. Ausnahmen, die von der Logic App-Laufzeit ausgelöst werden. Es kann verwendet werden, um nach der zugrunde liegenden Ursache von Problemen zu suchen, die Sie sehen, entweder im Portal oder während der Ausführung Ihres Codes.Aufforderungen
In dieser Tabelle werden alle Anforderungen der Logik-App-Laufzeit an eine andere Ressource ODER an bestimmte Aktionen innerhalb Ihres Workflows protokolliert.traces
Diese Tabelle enthält den Großteil der Logik-Apps-Laufzeitprotokolle, Protokollierungsdetails zur Triggerausführung, Workflowstart und -beendigung sowie Aktionsausführung. Wenn Sie nachverfolgte Eigenschaften aus Ihren Aktionen protokolliert haben, finden Sie die Daten im Bereich "customDimensions". Anschließend können Sie die Erweiterungsklausel in einer Abfrage verwenden, um die Daten als Spalten in der 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 in allen Workflows:
> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions\["EventName"\] == "WorkflowActionStart"
>
> \| where timestamp \> ago(1d)
>
> \| count
Erfolgsquote, im Zeitverlauf dargestellt
> 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 Entwurfsbereiche, um vollständige Überlegungen und Empfehlungen für Ihre Architektur zu treffen.