Diagnose in Durable Functions in Azure

Es gibt mehrere Möglichkeiten, um Probleme mithilfe von Durable Functions zu diagnostizieren. Einige dieser Optionen sind für reguläre Funktionen identisch, und andere gelten nur für Durable Functions.

Application Insights

Es wird empfohlen, Application Insights zum Durchführen der Diagnose und Überwachung in Azure Functions zu verwenden. Dasselbe gilt für Durable Functions. Eine Übersicht darüber, wie Sie Application Insights in Ihrer Funktionen-App nutzen, finden Sie unter Überwachen von Azure Functions.

Die Erweiterung „Durable Functions“ von Azure Functions gibt auch Nachverfolgungsereignisse aus, mit denen Sie die End-to-End-Ausführung einer Orchestrierung verfolgen können. Diese Nachverfolgungsereignisse können Sie ermitteln und abfragen, indem Sie im Azure-Portal das Tool Application Insights Analytics verwenden.

Nachverfolgungsdaten

Jedes Lebenszyklusereignis einer Orchestrierungsinstanz bewirkt, dass in Application Insights ein Nachverfolgungsereignis in die Sammlung traces geschrieben wird. Dieses Ereignis enthält die Nutzlast customDimensions mit mehreren Feldern. Feldnamen wird immer prop__ vorangestellt.

• hubName: Der Name des Aufgabenhubs, unter dem Ihre Orchestrierungen ausgeführt werden.
• appName: Der Name der Funktions-App Dieses Feld ist nützlich, wenn mehrere Funktions-Apps dieselbe Application Insights-Instanz gemeinsam nutzen.
• slotName: Der Bereitstellungsslot, in dem die aktuelle Funktions-App ausgeführt wird. Dieses Feld ist nützlich, wenn Sie Bereitstellungsslots nutzen, um Ihre Orchestrierungen mit einer Version zu versehen.
• functionName: Der Name der Orchestrator- oder Aktivitätsfunktion.
• functionType: Der Typ der Funktion, z. B. Orchestrator oder Activity.
• instanceId: Die eindeutige ID der Orchestrierungsinstanz.
• state: Der Lebenszyklus-Ausführungsstatus der Instanz. Gültige Werte:
  • Scheduled: Die Ausführung der Funktion wurde geplant, aber noch nicht gestartet.
  • Started: Die Ausführung der Funktion wurde gestartet, sie wurde aber noch nicht erwartet oder abgeschlossen.
  • Awaited: Der Orchestrator hat Arbeit geplant und wartet darauf, dass sie abgeschlossen wird.
  • Listening: Der Orchestrator lauscht auf eine externe Ereignisbenachrichtigung.
  • Completed: Die Funktion wurde erfolgreich abgeschlossen.
  • Fehler: Bei der Funktion ist ein Fehler aufgetreten.
• reason: Zusätzliche Daten zum Nachverfolgungsereignis. Wenn eine Instanz beispielsweise auf eine externe Ereignisbenachrichtigung wartet, wird in diesem Feld der Name des Ereignisses angegeben, auf das gewartet wird. Wenn eine Funktion fehlgeschlagen ist, enthält dieses Feld die Fehlerdetails.
• isReplay: Ein boolescher Wert, der angibt, ob das Nachverfolgungsereignis für die wiedergegebene Ausführung bestimmt ist.
• extensionVersion: Die Version der Durable Task-Erweiterung. Diese Versionsinformationen sind besonders wichtig, wenn mögliche Fehler der Erweiterung gemeldet werden. Instanzen mit langer Ausführungsdauer melden unter Umständen mehrere Versionen, wenn während der Ausführung ein Update durchgeführt wird.
• sequenceNumber: Die Ausführungssequenznummer für ein Ereignis. In Kombination mit dem Zeitstempel können die Ereignisse dadurch nach Ausführungszeit sortiert werden. Beachten Sie, dass diese Zahl auf null zurückgesetzt wird, wenn der Host neu gestartet wird, während die Instanz ausgeführt wird. Daher ist es wichtig, immer zuerst nach dem Zeitstempel zu sortieren, dann nach „sequenceNumber“.

Der Ausführlichkeitsgrad der Nachverfolgungsdaten, die an Application Insights ausgegeben werden, kann im Abschnitt logger (Functions 1.x) oder logging (Functions 2.0) der Datei host.json konfiguriert werden.

Functions 1.0

{
    "logger": {
        "categoryFilter": {
            "categoryLevels": {
                "Host.Triggers.DurableTask": "Information"
            }
        }
    }
}

Functions 2.0

{
    "logging": {
        "logLevel": {
            "Host.Triggers.DurableTask": "Information",
        },
    }
}

Standardmäßig werden alle ohne Wiedergabe definierten Nachverfolgungsereignisse ausgegeben. Die Datenmenge kann reduziert werden, indem Host.Triggers.DurableTask auf "Warning" oder "Error" festgelegt wird. In diesem Fall werden Nachverfolgungsereignisse nur für außergewöhnliche Situationen ausgegeben. Zum Aktivieren der Ausgabe der Wiedergabeereignisse mit ausführlicher Orchestrierung legen Sie logReplayEvents in der Konfigurationsdatei host.json auf true fest.

Eingaben und Ausgaben von Orchestrator-, Aktivitäts- und Entitätsfunktionen werden standardmäßig nicht protokolliert. Dieses Standardverhalten wird empfohlen, da die Protokollierung von Eingaben und Ausgaben die Application Insights-Kosten erhöhen kann. Eingabe- und Ausgabenutzdaten von Funktionen können außerdem vertrauliche Informationen enthalten. Anstelle der tatsächlichen Nutzdaten wird stattdessen die Anzahl von Bytes für Funktionseingaben und -ausgaben protokolliert. Wenn von der Durable Functions-Erweiterung die vollständigen Eingabe- und Ausgabenutzdaten protokolliert werden sollen, legen Sie die Eigenschaft traceInputsAndOutputs in der Konfigurationsdatei host.json auf true fest.

Abfrage für einzelne Instanzen

Mit der folgenden Abfrage werden Verlaufsdaten für die Nachverfolgung einer Einzelinstanz der Hello Sequence-Funktionsorchestrierung angezeigt. Es ist mit der Kusto-Abfragesprache geschrieben. Die Wiedergabeausführung wird herausgefiltert, sodass nur der logische Ausführungspfad angezeigt wird. Ereignisse können angeordnet werden, indem nach timestamp und sequenceNumber sortiert wird, wie in der folgenden Abfrage gezeigt:

let targetInstanceId = "ddd1aaa685034059b545eb004b15d4eb";
let start = datetime(2018-03-25T09:20:00);
traces
| where timestamp > start and timestamp < start + 30m
| where customDimensions.Category == "Host.Triggers.DurableTask"
| extend functionName = customDimensions["prop__functionName"]
| extend instanceId = customDimensions["prop__instanceId"]
| extend state = customDimensions["prop__state"]
| extend isReplay = tobool(tolower(customDimensions["prop__isReplay"]))
| extend sequenceNumber = tolong(customDimensions["prop__sequenceNumber"])
| where isReplay != true
| where instanceId == targetInstanceId
| sort by timestamp asc, sequenceNumber asc
| project timestamp, functionName, state, instanceId, sequenceNumber, appName = cloud_RoleName

Das Ergebnis ist eine Liste mit Nachverfolgungsereignissen, die den Ausführungspfad der Orchestrierung anzeigt, z.B. alle Aktivitätsfunktionen, in aufsteigender Reihenfolge nach Ausführungszeit sortiert.

Instanz-Zusammenfassungsabfrage

Mit der folgenden Abfrage wird der Status aller Orchestrierungsinstanzen angezeigt, die in einem angegebenen Zeitraum ausgeführt wurden.

let start = datetime(2017-09-30T04:30:00);
traces
| where timestamp > start and timestamp < start + 1h
| where customDimensions.Category == "Host.Triggers.DurableTask"
| extend functionName = tostring(customDimensions["prop__functionName"])
| extend instanceId = tostring(customDimensions["prop__instanceId"])
| extend state = tostring(customDimensions["prop__state"])
| extend isReplay = tobool(tolower(customDimensions["prop__isReplay"]))
| extend output = tostring(customDimensions["prop__output"])
| where isReplay != true
| summarize arg_max(timestamp, *) by instanceId
| project timestamp, instanceId, functionName, state, output, appName = cloud_RoleName
| order by timestamp asc

Das Ergebnis ist eine Liste mit Instanz-IDs und dem aktuellen Laufzeitstatus.

Durable Task Framework-Protokollierung

Die Durable-Erweiterungsprotokolle sind nützlich, um das Verhalten Ihrer Orchestrierungslogik zu verstehen. Diese Protokolle enthalten jedoch nicht immer genügend Informationen, um Probleme hinsichtlich Leistung und Zuverlässigkeit auf Frameworkebene zu debuggen. Ab v2.3.0 der Durable-Erweiterung stehen auch Protokolle, die vom zugrunde liegenden Durable Task Framework (DTFx) ausgegeben werden, zur Erfassung bereit.

Beim Betrachten der vom DTFx ausgegebenen Protokolle ist es wichtig zu verstehen, dass sich die DTFx-Engine aus zwei Komponenten zusammensetzt: aus der Kern-Dispatch-Engine (DurableTask.Core) und aus einem von vielen unterstützten Speicheranbietern (Durable Functions verwendet standardmäßig DurableTask.AzureStorage, es sind jedoch auch andere Optionen verfügbar).

• DurableTask.Core: zentrale Orchestrierungsausführung und Planungsprotokolle sowie Telemetrie auf niedriger Ebene
• DurableTask.AzureStorage: Back-End-Protokolle des jeweiligen Azure Storage-Zustandsanbieters. Diese Protokolle enthalten ausführliche Informationen mit den internen Warteschlangen, Blobs und Speichertabellen, die zum Speichern und Abrufen des internen Orchestrierungszustands verwendet wurden.
• DurableTask.Netherite: Back-End-Protokolle des jeweiligen Netherite-Speicheranbieters, sofern aktiviert
• DurableTask.SqlServer: Back-End-Protokolle des jeweiligen Microsoft SQL-Speicheranbieters (MSSQL), sofern aktiviert

Sie können diese Protokolle aktivieren, indem Sie den Abschnitt logging/logLevel in der Datei host.json Ihrer Funktions-App aktualisieren. Das folgende Beispiel zeigt, wie Warn- und Fehlerprotokolle sowohl von DurableTask.Core als auch von DurableTask.AzureStorage aktiviert werden können:

{
  "version": "2.0",
  "logging": {
    "logLevel": {
      "DurableTask.AzureStorage": "Warning",
      "DurableTask.Core": "Warning"
    }
  }
}

Wenn Sie Application Insights aktiviert haben, werden diese Protokolle automatisch der trace-Sammlung hinzugefügt. Sie können sie auf dieselbe Weise durchsuchen wie andere trace-Protokolle mit Kusto-Abfragen.

Die folgende Kusto-Abfrage zeigt, wie DTFx-Protokolle abgefragt werden. Der wichtigste Teil der Abfrage ist where customerDimensions.Category startswith "DurableTask", da dies die Ergebnisse nach Protokollen in den Kategorien DurableTask.Core und DurableTask.AzureStorage filtert.

traces
| where customDimensions.Category startswith "DurableTask"
| project
    timestamp,
    severityLevel,
    Category = customDimensions.Category,
    EventId = customDimensions.EventId,
    message,
    customDimensions
| order by timestamp asc 

Das Ergebnis ist eine Reihe von Protokollen, die von den Anbietern von Durable Task Framework-Protokollen geschrieben wurden.

Weitere Informationen über die verfügbaren Protokollereignisse finden Sie in der Durable Task Framework-Dokumentation zur strukturierten Protokollierung auf GitHub.

App-Protokollierung

Es ist wichtig, das Wiedergabeverhalten von Orchestratoren zu beachten, wenn Protokolle direkt über eine Orchestratorfunktion geschrieben werden. Sehen Sie sich beispielsweise die folgende Orchestratorfunktion an:

[FunctionName("FunctionChain")]
public static async Task Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context,
    ILogger log)
{
    log.LogInformation("Calling F1.");
    await context.CallActivityAsync("F1");
    log.LogInformation("Calling F2.");
    await context.CallActivityAsync("F2");
    log.LogInformation("Calling F3");
    await context.CallActivityAsync("F3");
    log.LogInformation("Done!");
}

[Function("FunctionChain")]
public static async Task Run(
    [OrchestrationTrigger] TaskOrchestrationContext context,
    FunctionContext executionContext)
{
    ILogger log = executionContext.GetLogger("FunctionChain");
    log.LogInformation("Calling F1.");
    await context.CallActivityAsync("F1");
    log.LogInformation("Calling F2.");
    await context.CallActivityAsync("F2");
    log.LogInformation("Calling F3");
    await context.CallActivityAsync("F3");
    log.LogInformation("Done!");
}

const df = require("durable-functions");

module.exports = df.orchestrator(function*(context){
    context.log("Calling F1.");
    yield context.df.callActivity("F1");
    context.log("Calling F2.");
    yield context.df.callActivity("F2");
    context.log("Calling F3.");
    yield context.df.callActivity("F3");
    context.log("Done!");
});

import logging
import azure.functions as func
import azure.durable_functions as df

def orchestrator_function(context: df.DurableOrchestrationContext):
    logging.info("Calling F1.")
    yield context.call_activity("F1")
    logging.info("Calling F2.")
    yield context.call_activity("F2")
    logging.info("Calling F3.")
    yield context.call_activity("F3")
    return None

main = df.Orchestrator.create(orchestrator_function)

@FunctionName("FunctionChain")
public void functionChain(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx,
        ExecutionContext functionContext) {
    Logger log = functionContext.getLogger();
    log.info("Calling F1.");
    ctx.callActivity("F1").await();
    log.info("Calling F2.");
    ctx.callActivity("F2").await();
    log.info("Calling F3.");
    ctx.callActivity("F3").await();
    log.info("Done!");
}

Die sich ergebenden Protokolldaten sehen dann in etwa wie die folgende Beispielausgabe aus:

Calling F1.
Calling F1.
Calling F2.
Calling F1.
Calling F2.
Calling F3.
Calling F1.
Calling F2.
Calling F3.
Done!

Wenn Sie nur bei der Ausführung ohne Wiedergabe Protokolle schreiben möchten, können Sie einen bedingten Ausdruck zum Protokollieren nur dann schreiben, wenn das Flag „Wird wiedergegeben“ den Wert false aufweist. Hier ist das obige Beispiel angegeben, aber es enthält jetzt Wiedergabeprüfungen.

[FunctionName("FunctionChain")]
public static async Task Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context,
    ILogger log)
{
    if (!context.IsReplaying) log.LogInformation("Calling F1.");
    await context.CallActivityAsync("F1");
    if (!context.IsReplaying) log.LogInformation("Calling F2.");
    await context.CallActivityAsync("F2");
    if (!context.IsReplaying) log.LogInformation("Calling F3");
    await context.CallActivityAsync("F3");
    log.LogInformation("Done!");
}

[FunctionName("FunctionChain")]
public static async Task Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context,
    ILogger log)
{
    log = context.CreateReplaySafeLogger(log);
    log.LogInformation("Calling F1.");
    await context.CallActivityAsync("F1");
    log.LogInformation("Calling F2.");
    await context.CallActivityAsync("F2");
    log.LogInformation("Calling F3");
    await context.CallActivityAsync("F3");
    log.LogInformation("Done!");
}

[Function("FunctionChain")]
public static async Task Run([OrchestrationTrigger] TaskOrchestrationContext context)
{
    ILogger log = context.CreateReplaySafeLogger("FunctionChain");
    log.LogInformation("Calling F1.");
    await context.CallActivityAsync("F1");
    log.LogInformation("Calling F2.");
    await context.CallActivityAsync("F2");
    log.LogInformation("Calling F3");
    await context.CallActivityAsync("F3");
    log.LogInformation("Done!");
}

const df = require("durable-functions");

module.exports = df.orchestrator(function*(context){
    if (!context.df.isReplaying) context.log("Calling F1.");
    yield context.df.callActivity("F1");
    if (!context.df.isReplaying) context.log("Calling F2.");
    yield context.df.callActivity("F2");
    if (!context.df.isReplaying) context.log("Calling F3.");
    yield context.df.callActivity("F3");
    context.log("Done!");
});

import logging
import azure.functions as func
import azure.durable_functions as df

def orchestrator_function(context: df.DurableOrchestrationContext):
    if not context.is_replaying:
        logging.info("Calling F1.")
    yield context.call_activity("F1")
    if not context.is_replaying:
        logging.info("Calling F2.")
    yield context.call_activity("F2")
    if not context.is_replaying:
        logging.info("Calling F3.")
    yield context.call_activity("F3")
    logging.info("Done!")
    return None

main = df.Orchestrator.create(orchestrator_function)

@FunctionName("FunctionChain")
public void functionChain(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx,
        ExecutionContext functionContext) {
    Logger log = functionContext.getLogger();
    if (!ctx.getIsReplaying()) log.info("Calling F1.");
    ctx.callActivity("F1").await();
    if (!ctx.getIsReplaying()) log.info("Calling F2.");
    ctx.callActivity("F2").await();
    if (!ctx.getIsReplaying()) log.info("Calling F3.");
    ctx.callActivity("F3").await();
    log.info("Done!");
}

Mit den zuvor erwähnten Änderungen sieht die Protokollausgabe wie folgt aus:

Calling F1.
Calling F2.
Calling F3.
Done!

Benutzerdefinierter Status

Mit dem benutzerdefinierten Orchestrierungsstatus können Sie einen benutzerdefinierten Statuswert für Ihre Orchestratorfunktion festlegen. Dieser benutzerdefinierte Status ist dann für externe Clients über die HTTP-Statusabfrage-API oder über sprachspezifische API-Aufrufe sichtbar. Der benutzerdefinierte Orchestrierungsstatus ermöglicht eine umfassendere Überwachung für Orchestratorfunktionen. Beispielsweise kann der Funktionscode des Orchestrators die API „Set Custom Status“ (Benutzerdefinierten Status festlegen) aufrufen, um den Fortschritt einer zeitintensiven Operation zu aktualisieren. Ein Client, z.B. eine Webseite oder ein anderes externes System, kann dann für die HTTP-Statusabfrage-APIs in regelmäßigen Abständen eine Abfrage nach umfangreicheren Statusinformationen durchführen. Nachstehend finden Sie Beispielcode für das Festlegen eines benutzerdefinierten Statuswerts in einer Orchestratorfunktion:

[FunctionName("SetStatusTest")]
public static async Task SetStatusTest([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    // ...do work...

    // update the status of the orchestration with some arbitrary data
    var customStatus = new { completionPercentage = 90.0, status = "Updating database records" };
    context.SetCustomStatus(customStatus);

    // ...do more work...
}

[Function("SetStatusTest")]
public static async Task SetStatusTest([OrchestrationTrigger] TaskOrchestrationContext context)
{
    // ...do work...

    // update the status of the orchestration with some arbitrary data
    var customStatus = new { completionPercentage = 90.0, status = "Updating database records" };
    context.SetCustomStatus(customStatus);

    // ...do more work...
}

const df = require("durable-functions");

module.exports = df.orchestrator(function*(context) {
    // ...do work...

    // update the status of the orchestration with some arbitrary data
    const customStatus = { completionPercentage: 90.0, status: "Updating database records", };
    context.df.setCustomStatus(customStatus);

    // ...do more work...
});

import logging
import azure.functions as func
import azure.durable_functions as df

def orchestrator_function(context: df.DurableOrchestrationContext):
    # ...do work...

    # update the status of the orchestration with some arbitrary data
    custom_status = {'completionPercentage': 90.0, 'status': 'Updating database records'}
    context.set_custom_status(custom_status)
    # ...do more work...

    return None

main = df.Orchestrator.create(orchestrator_function)

@FunctionName("SetStatusTest")
public void setStatusTest(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    // ...do work...

    // update the status of the orchestration with some arbitrary data
    ctx.setCustomStatus(new Object() {
        public final double completionPercentage = 90.0;
        public final String status = "Updating database records";
    });

    // ...do more work...
}

Während der Ausführung der Orchestrierung können externe Clients diesen benutzerdefinierten Status abrufen:

GET /runtime/webhooks/durabletask/instances/instance123?code=XYZ

Clients erhalten folgende Antwort:

{
  "runtimeStatus": "Running",
  "input": null,
  "customStatus": { "completionPercentage": 90.0, "status": "Updating database records" },
  "output": null,
  "createdTime": "2017-10-06T18:30:24Z",
  "lastUpdatedTime": "2017-10-06T19:40:30Z"
}

Verteilte Ablaufverfolgung

Verteilte Ablaufverfolgung verfolgt Anforderungen und zeigt, wie verschiedene Dienste miteinander interagieren. In Durable Functions korreliert sie auch Orchestrierungen und Aktivitäten zusammen. Dies ist hilfreich, um zu verstehen, wie viel Zeit die Orchestrierung im Verhältnis zur gesamten Orchestrierung benötigt. Es ist auch hilfreich zu verstehen, wo eine Anwendung ein Problem hat oder wo eine Ausnahme ausgelöst wurde. Dieses Feature wird für alle Sprachen und Speicheranbieter unterstützt.

Einrichten der verteilten Ablaufverfolgung

Um die verteilte Ablaufverfolgung einzurichten, aktualisieren Sie die host.json, und richten Sie eine Application Insights-Ressource ein.

host.json

"durableTask": {
  "tracing": {
    "distributedTracingEnabled": true,
    "Version": "V2"
  }
}

Application Insights

Wenn die Funktions-App nicht mit einer Application Insights-Ressource konfiguriert ist, konfigurieren Sie sie nach der Anleitung hier.

Überprüfen der Ablaufverfolgungen

Navigieren Sie in der Application Insights-Ressource zur Transaktionssuche. Suchen Sie in den Ergebnissen nach Request- und Dependency-Ereignissen, die mit bestimmten Präfixen für dauerhafte Funktionen beginnen (z. B. orchestration:, activity:usw.). Wenn Sie eines dieser Ereignisse auswählen, wird ein Gantt-Diagramm geöffnet, welches das Ende der verteilten Ablaufverfolgung anzeigt.

Problembehandlung

Wenn die Ablaufverfolgungen in Application Insights nicht angezeigt werden, stellen Sie sicher, dass Sie bis ungefähr fünf Minuten nach dem Ausführen der Anwendung warten, um sicherzustellen, dass alle Daten an die Application Insights-Ressource weitergegeben werden.

Debuggen

Azure Functions unterstützt das direkte Debuggen des Funktionscodes, und diese Unterstützung gilt auch für Durable Functions – unabhängig davon, ob die Ausführung in Azure oder lokal erfolgt. Beim Debuggen sollten aber einige Verhaltensweisen beachtet werden:

• Wiedergabe: Für Orchestratorfunktionen wird regelmäßig ein Replay ausgeführt, wenn neue Eingaben empfangen werden. Dieses Verhalten bedeutet Folgendes: Eine einzelne logische Ausführung einer Orchestratorfunktion kann dazu führen, dass derselbe Breakpoint mehrfach erreicht wird. Dies gilt vor allem, wenn er sich im Anfangsbereich des Funktionscodes befindet.
• Await: Bei jedem await-Ausdruck in einer Orchestratorfunktion wird die Steuerung an den Durable Task Framework-Verteiler zurückgegeben. Wenn es das erste Mal ist, dass ein bestimmtes await-Element auftritt, wird die zugeordnete Aufgabe nie fortgesetzt. Aus diesem Grund ist das Überspringen des Wartezustands (F10 in Visual Studio) nicht möglich. Das Überspringen funktioniert nur, wenn eine Aufgabe wiedergegeben wird.
• Messagingtimeouts: In Durable Functions werden intern Warteschlangennachrichten für die Ausführung von Orchestrator-, Aktivitäts- und Entitätsfunktionen verwendet. In einer Umgebung mit mehreren VMs kann das Unterbrechen des Debuggens über längere Zeiträume dazu führen, dass eine andere VM die Nachricht aufnimmt. Das Ergebnis wäre dann eine doppelte Ausführung. Dieses Verhalten tritt auch für reguläre Warteschlangentriggerfunktionen auf, aber es ist wichtig, dies in diesem Zusammenhang zu erwähnen, da es sich bei den Warteschlangen um ein Implementierungsdetail handelt.
• Beenden und Starten: Nachrichten in Durable Functions werden zwischen Debugsitzungen persistent gespeichert. Wenn Sie das Debuggen beenden und den lokalen Hostprozess beenden, während eine permanente Funktion ausgeführt wird, kann diese Funktion in einer zukünftigen Debugsitzung automatisch erneut ausgeführt werden. Dieses Verhalten kann verwirrend sein, wenn es nicht erwartet wird. Die Verwendung eines neuen Aufgabenhubs oder das Löschen des Aufgabenhubinhalts zwischen Debugsitzungen ist eine Methode, um dieses Verhalten zu vermeiden.

Storage

Durable Functions speichert den Status standardmäßig in Azure Storage. Dieses Verhalten bedeutet, dass Sie den Status Ihrer Orchestrierungen mit Tools wie Microsoft Azure Storage-Explorer untersuchen können.

Dies ist hilfreich beim Debuggen, da Sie genau sehen, in welchem Zustand sich eine Orchestrierung befindet. Nachrichten in den Warteschlangen können ebenfalls untersucht werden, um zu ermitteln, welche Arbeitsschritte ausstehen (oder ggf. hängen).

Durable Functions Monitor

Durable Functions Monitor ist ein grafisches Tool zum Überwachen, Verwalten und Debuggen von Orchestrierungs- und Entitätsinstanzen. Es ist als Visual Studio Code-Erweiterung und als eigenständige App verfügbar. Informationen zur Einrichtung sowie eine Featureliste finden Sie in diesem Wiki.

Durable Functions: Leitfaden zur Problembehandlung

Informationen zur Behandlung gängiger Problemsymptome, wie z. B. hängende Orchestrierungen, Fehler beim Start, langsame Ausführung, finden Sie in diesem Leitfaden zur Problembehandlung.

Nächste Schritte