Lernprogramm: Überwachen von Azure-Funktionen mit verteilter OpenTelemetry-Ablaufverfolgung

In diesem Artikel wird die Unterstützung von OpenTelemetry in Azure Function veranschaulicht, die die verteilte Ablaufverfolgung über mehrere Funktionsaufrufe mithilfe integrierter Application Insights- und OpenTelemetry-Unterstützung ermöglicht. Um Ihnen den Einstieg zu erleichtern, wird eine Azure Developer CLI(azd)-Vorlage verwendet, um Ihr Codeprojekt sowie die Azure-Bereitstellung zu erstellen, in der Ihre App ausgeführt werden soll.

In diesem Lernprogramm verwenden Sie das azd Tool für Folgendes:

Initialisieren Sie ein OpenTelemetry-fähiges Projekt aus einer Vorlage.
Überprüfen Sie den Code, der die OpenTelemetry-Integration ermöglicht.
Führen Sie Ihre openTelemetry-fähige App lokal aus, und überprüfen Sie sie.
Erstellen Sie eine Funktions-App und zugehörige Ressourcen in Azure.
Stellen Sie Ihr Codeprojekt in der Funktions-App in Azure bereit.
Überprüfen Sie die verteilte Ablaufverfolgung in Application Insights.

Die von dieser Vorlage erstellten erforderlichen Azure-Ressourcen folgen den aktuellen bewährten Methoden für sichere und skalierbare Funktions-App-Bereitstellungen in Azure. Derselbe azd Befehl stellt auch Ihr Codeprojekt in Ihrer neuen Funktions-App in Azure bereit.

Standardmäßig folgt der Flex-Verbrauchsplan einem Abrechnungsmodell nach dem Prinzip 'Bezahlen nach Nutzung'. Dies bedeutet, dass bei diesem Quickstart ein kleiner Betrag von ein paar US-Cent oder weniger in Ihrem Azure-Konto anfallen wird.

Von Bedeutung

Dieser Artikel unterstützt derzeit nur C#, Python und TypeScript. Um die Schnellstartanleitung abzuschließen, wählen Sie oben im Artikel eine dieser unterstützten Sprachen aus.

Voraussetzungen

Ein Azure-Konto mit einem aktiven Abonnement. Kostenlos ein Konto erstellen.
Azure Developer CLI

Python 3.11 oder höher

Node.js 18.x oder höher

.NET 8.0 SDK

Initialisieren des Projekts

Verwenden Sie den azd init Befehl, um ein lokales Azure Functions-Codeprojekt aus einer Vorlage zu erstellen, die die verteilte Ablaufverfolgung von OpenTelemetry enthält.

Führen Sie in Ihrem lokalen Terminal oder in der Eingabeaufforderung diesen azd init-Befehl in einem leeren Ordner aus:
```
azd init --template functions-quickstart-python-azd-otel -e flexquickstart-otel
```
Mit diesem Befehl werden die Projektdateien aus dem Vorlagen-Repository abgerufen und das Projekt im aktuellen Ordner initialisiert. Das -e-Flag legt einen Namen für die aktuelle Umgebung fest. In azdder Umgebung wird ein eindeutiger Bereitstellungskontext für Ihre App verwaltet, und Sie können mehrere definieren. Der Umgebungsname wird auch im Namen der Ressourcengruppe angezeigt, die Sie in Azure erstellen.

Führen Sie in Ihrem lokalen Terminal oder in der Eingabeaufforderung diesen azd init-Befehl in einem leeren Ordner aus:
```
azd init --template functions-quickstart-typescript-azd-otel -e flexquickstart-otel
```
Mit diesem Befehl werden die Projektdateien aus dem Vorlagen-Repository abgerufen und das Projekt im aktuellen Ordner initialisiert. Das -e-Flag legt einen Namen für die aktuelle Umgebung fest. In azdder Umgebung wird ein eindeutiger Bereitstellungskontext für Ihre App verwaltet, und Sie können mehrere definieren. Der Umgebungsname wird auch im Namen der Ressourcengruppe angezeigt, die Sie in Azure erstellen.

Führen Sie in Ihrem lokalen Terminal oder in der Eingabeaufforderung diesen azd init-Befehl in einem leeren Ordner aus:
```
azd init --template functions-quickstart-dotnet-azd-otel -e flexquickstart-otel
```
Mit diesem Befehl werden die Projektdateien aus dem Vorlagen-Repository abgerufen und das Projekt im aktuellen Ordner initialisiert. Das -e-Flag legt einen Namen für die aktuelle Umgebung fest. In azdder Umgebung wird ein eindeutiger Bereitstellungskontext für Ihre App verwaltet, und Sie können mehrere definieren. Der Umgebungsname wird auch im Namen der Ressourcengruppe angezeigt, die Sie in Azure erstellen.

Überprüfen des Codes

Die Vorlage erstellt ein vollständiges verteiltes Ablaufverfolgungsszenario mit drei Funktionen, die zusammenarbeiten. Sehen wir uns die wichtigsten OpenTelemetry-bezogenen Aspekte an:

OpenTelemetry-Konfiguration

Die src/otel-sample/host.json Datei aktiviert OpenTelemetry für den Funktionenhost:

{
  "version": "2.0",
  "telemetryMode": "OpenTelemetry",
  "extensions": {
    "serviceBus": {
        "maxConcurrentCalls": 10
    }
  },
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.*, 5.0.0)"
  }
}

Die Schlüsseleinstellung "telemetryMode": "OpenTelemetry" ermöglicht verteiltes Tracing über Funktionsaufrufe hinweg.

Die src/OTelSample/host.json Datei aktiviert OpenTelemetry für den Funktionenhost:

{
  "version": "2.0",
  "telemetryMode": "OpenTelemetry",
  "logging": {
    "OpenTelemetry": {
      "logLevel": {
        "Host.General": "Warning"
      }
    }
  }
}

Die Schlüsseleinstellung "telemetryMode": "OpenTelemetry" ermöglicht die verteilte Ablaufverfolgung über Funktionsaufrufe hinweg.

Abhängigkeiten für OpenTelemetry

Die src/otel-sample/requirements.txt Datei enthält die erforderlichen Pakete für die OpenTelemetry-Integration:

azure-functions
azure-monitor-opentelemetry
requests

Das azure-monitor-opentelemetry Paket bietet die OpenTelemetry-Integration mit Application Insights.

Die src/otel-sample/package.json Datei enthält die erforderlichen Pakete für die OpenTelemetry-Integration:

{
  "dependencies": {
    "@azure/functions": "^4.0.0",
    "@azure/functions-opentelemetry-instrumentation": "^0.1.0",
    "@azure/monitor-opentelemetry-exporter": "^1.0.0",
    "axios": "^1.6.0"
  }
}

Die Pakete @azure/functions-opentelemetry-instrumentation und @azure/monitor-opentelemetry-exporter bieten die OpenTelemetry-Integration mit Application Insights.

Die .csproj Datei enthält die erforderlichen Pakete für die OpenTelemetry-Integration:

<PackageReference Include="Azure.Monitor.OpenTelemetry.Exporter" Version="1.4.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.OpenTelemetry" Version="1.4.0" />
<PackageReference Include="OpenTelemetry.Instrumentation.Http" Version="1.10.0" />

Diese Pakete bieten die Integration von OpenTelemetry mit Application Insights und HTTP-Instrumentierung für die verteilte Ablaufverfolgung.

Funktionsimplementierung

Die Funktionen in src/otel-sample/function_app.py demonstrieren einen verteilten Tracing-Vorgang:

Erste HTTP-Funktion

@app.function_name("first_http_function")
@app.route(route="first_http_function", auth_level=func.AuthLevel.ANONYMOUS)
def first_http_function(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Python HTTP trigger function (first) processed a request.')

    # Call the second function
    base_url = f"{req.url.split('/api/')[0]}/api"
    second_function_url = f"{base_url}/second_http_function"

    response = requests.get(second_function_url)
    second_function_result = response.text

    result = {
        "message": "Hello from the first function!",
        "second_function_response": second_function_result
    }

    return func.HttpResponse(
        json.dumps(result),
        status_code=200,
        mimetype="application/json"
    )

Zweite HTTP-Funktion

@app.function_name("second_http_function")
@app.route(route="second_http_function", auth_level=func.AuthLevel.ANONYMOUS)
@app.service_bus_queue_output(arg_name="outputsbmsg", queue_name="%ServiceBusQueueName%",
                              connection="ServiceBusConnection")
def second_http_function(req: func.HttpRequest, outputsbmsg: func.Out[str]) -> func.HttpResponse:
    logging.info('Python HTTP trigger function (second) processed a request.')

    message = "This is the second function responding."

    # Send a message to the Service Bus queue
    queue_message = "Message from second HTTP function to trigger ServiceBus queue processing"
    outputsbmsg.set(queue_message)
    logging.info('Sent message to ServiceBus queue: %s', queue_message)

    return func.HttpResponse(
        message,
        status_code=200
    )

Service Bus-Warteschlangentrigger

@app.service_bus_queue_trigger(arg_name="azservicebus", queue_name="%ServiceBusQueueName%",
                               connection="ServiceBusConnection") 
def servicebus_queue_trigger(azservicebus: func.ServiceBusMessage):
    logging.info('Python ServiceBus Queue trigger start processing a message: %s',
                azservicebus.get_body().decode('utf-8'))
    time.sleep(5)  # Simulate processing work
    logging.info('Python ServiceBus Queue trigger end processing a message')

Die OpenTelemetry-Konfiguration wird in src/otel-sample/index.ts:

import { AzureFunctionsInstrumentation } from '@azure/functions-opentelemetry-instrumentation';
import { AzureMonitorTraceExporter, AzureMonitorLogExporter } from '@azure/monitor-opentelemetry-exporter';
import { getNodeAutoInstrumentations, getResourceDetectors } from '@opentelemetry/auto-instrumentations-node';
import { registerInstrumentations } from '@opentelemetry/instrumentation';
import { detectResources } from '@opentelemetry/resources';
import { LoggerProvider, SimpleLogRecordProcessor } from '@opentelemetry/sdk-logs';
import { NodeTracerProvider, SimpleSpanProcessor } from '@opentelemetry/sdk-trace-node';

const resource = detectResources({ detectors: getResourceDetectors() });

const tracerProvider = new NodeTracerProvider({ 
  resource, 
  spanProcessors: [new SimpleSpanProcessor(new AzureMonitorTraceExporter())] 
});
tracerProvider.register();

const loggerProvider = new LoggerProvider({
  resource,
  processors: [new SimpleLogRecordProcessor(new AzureMonitorLogExporter())],
});

registerInstrumentations({
    tracerProvider,
    loggerProvider,
    instrumentations: [getNodeAutoInstrumentations(), new AzureFunctionsInstrumentation()],
});

Die Funktionen werden im src/otel-sample/src/functions Ordner definiert:

Erste HTTP-Funktion

export async function firstHttpFunction(
  request: HttpRequest,
  context: InvocationContext
): Promise<HttpResponseInit> {
  context.log("TypeScript HTTP trigger function (first) processed a request.");

  try {
    // Call the second function
    const baseUrl = request.url.split("/api/")[0];
    const secondFunctionUrl = `${baseUrl}/api/second_http_function`;

    const response = await axios.get(secondFunctionUrl);
    const secondFunctionResult = response.data;

    const result = {
      message: "Hello from the first function!",
      second_function_response: secondFunctionResult,
    };

    return {
      status: 200,
      body: JSON.stringify(result),
      headers: { "Content-Type": "application/json" },
    };
  } catch (error) {
    return {
      status: 500,
      body: JSON.stringify({ error: "Failed to process request" }),
    };
  }
}

Zweite HTTP-Funktion

export async function secondHttpFunction(
  request: HttpRequest,
  context: InvocationContext
): Promise<HttpResponseInit> {
  context.log("TypeScript HTTP trigger function (second) processed a request.");

  const message = "This is the second function responding.";

  // Send a message to the Service Bus queue
  const queueMessage =
    "Message from second HTTP function to trigger ServiceBus queue processing";

  context.extraOutputs.set(serviceBusOutput, queueMessage);
  context.log("Sent message to ServiceBus queue:", queueMessage);

  return {
    status: 200,
    body: message,
  };
}

Service Bus-Warteschlangentrigger

export async function serviceBusQueueTrigger(
  message: unknown,
  context: InvocationContext
): Promise<void> {
  context.log("TypeScript ServiceBus Queue trigger start processing a message:", message);

  // Simulate processing time
  await new Promise((resolve) => setTimeout(resolve, 5000));

  context.log("TypeScript ServiceBus Queue trigger end processing a message");
}

Die OpenTelemetry-Konfiguration ist in src/OTelSample/Program.cs eingerichtet.

using Azure.Monitor.OpenTelemetry.Exporter;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.OpenTelemetry;
using OpenTelemetry.Trace;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Logging.AddOpenTelemetry(logging =>
{
    logging.IncludeFormattedMessage = true;
    logging.IncludeScopes = true;
});

builder.Services.AddOpenTelemetry()    
    .WithTracing(tracing =>
    {
        tracing.AddHttpClientInstrumentation();
    });

builder.Services.AddOpenTelemetry().UseAzureMonitorExporter();
builder.Services.AddOpenTelemetry().UseFunctionsWorkerDefaults();

builder.Services.AddHttpClient();

builder.Build().Run();

Die Funktionen werden in separaten Klassendateien definiert:

Erste HTTP-Funktion

public class FirstHttpTrigger
{
    private readonly ILogger<FirstHttpTrigger> _logger;
    private readonly IHttpClientFactory _httpClientFactory;

    public FirstHttpTrigger(ILogger<FirstHttpTrigger> logger, IHttpClientFactory httpClientFactory)
    {
        _logger = logger;
        _httpClientFactory = httpClientFactory;
    }

    [Function("first_http_function")]
    public async Task<IActionResult> Run(
         [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req)
    {
        _logger.LogInformation("first_http_function function processed a request.");

        var baseUrl = $"{req.Url.AbsoluteUri.Split("/api/")[0]}/api";
        var targetUri = $"{baseUrl}/second_http_function";

        var client = _httpClientFactory.CreateClient();
        var response = await client.GetAsync(targetUri);
        var content = await response.Content.ReadAsStringAsync();

        return new OkObjectResult($"Called second_http_function, status: {response.StatusCode}, content: {content}");
    }
}

Zweite HTTP-Funktion

public class SecondHttpTrigger
{
    private readonly ILogger<SecondHttpTrigger> _logger;

    public SecondHttpTrigger(ILogger<SecondHttpTrigger> logger)
    {
        _logger = logger;
    }

    [Function("second_http_function")]
    public MultiResponse Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req)
    {
        _logger.LogInformation("second_http_function function processed a request.");

        return new MultiResponse
        {
            Messages = new string[] { "Hello" },
            HttpResponse = req.CreateResponse(System.Net.HttpStatusCode.OK)
        };
    }
}

public class MultiResponse
{
    [ServiceBusOutput("%ServiceBusQueueName%", Connection = "ServiceBusConnection")]
    public string[]? Messages { get; set; }

    [HttpResult]
    public HttpResponseData? HttpResponse { get; set; }
}

Service Bus-Warteschlangentrigger

public class ServiceBusQueueTrigger
{
    private readonly ILogger<ServiceBusQueueTrigger> _logger;

    public ServiceBusQueueTrigger(ILogger<ServiceBusQueueTrigger> logger)
    {
        _logger = logger;
    }

    [Function("servicebus_queue_trigger")]
    public async Task Run(
        [ServiceBusTrigger("%ServiceBusQueueName%", Connection = "ServiceBusConnection")]
        ServiceBusReceivedMessage message,
        ServiceBusMessageActions messageActions)
    {
        _logger.LogInformation("Message ID: {id}", message.MessageId);
        _logger.LogInformation("Message Body: {body}", message.Body);

        // Complete the message
        await messageActions.CompleteMessageAsync(message);
    }
}

Verteilte Ablaufverfolgungsfluss

Diese Architektur erstellt ein vollständiges verteiltes Ablaufverfolgungsszenario mit diesem Verhalten:

Die erste HTTP-Funktion empfängt eine HTTP-Anforderung und ruft die zweite HTTP-Funktion auf.
Zweite HTTP-Funktion antwortet und sendet eine Nachricht an den Service Bus
Service Bustrigger verarbeitet die Nachricht mit einer Verzögerung, um Verarbeitungsvorgänge zu simulieren

Wichtige Aspekte der OpenTelemetry-Implementierung:

OpenTelemetry-Integration: Die host.json Datei ermöglicht OpenTelemetry mit "telemetryMode": "OpenTelemetry"
Funktionskette: Die erste Funktion ruft die zweite mithilfe von HTTP-Anforderungen auf, wodurch korrelierte Ablaufverfolgungen erstellt werden.
Service Bus-Integration: Die zweite Funktion gibt an Service Bus aus, wodurch die dritte Funktion ausgelöst wird.
Anonyme Authentifizierung: Die HTTP-Funktionen verwenden auth_level=func.AuthLevel.ANONYMOUS, sodass keine Funktionsschlüssel erforderlich sind.

Hier können Sie das vollständige Vorlagenprojekt überprüfen.

OpenTelemetry-Integration: Die index.ts Datei konfiguriert OpenTelemetry mit Azure Monitor-Exportern für Traces und Logs.
Funktionsverkettung: Die erste Funktion ruft die zweite mithilfe von Axios mit automatischer Trace-Propagation auf
Service Bus-Integration: Die zweite Funktion wird mit Ausgabebindungen an Service Bus ausgegeben, wodurch die dritte Funktion ausgelöst wird.
Verwaltete Identität: Alle Dienstbusverbindungen verwenden verwaltete Identität anstelle von Verbindungszeichenfolgen.
Verarbeitungssimulation: Die 5-Sekunden-Verzögerung im Service Bus-Trigger simuliert Die Verarbeitung von Nachrichten

Hier können Sie das vollständige Vorlagenprojekt überprüfen.

OpenTelemetry-Integration: Die Program.cs Datei konfiguriert OpenTelemetry mit dem Azure Monitor-Exporter
Funktionskette: Die erste Funktion ruft die zweite mithilfe von HttpClient mit OpenTelemetry-Instrumentierung auf.
Service Bus-Integration: Die zweite Funktion wird mit Ausgabebindungen an Service Bus ausgegeben, wodurch die dritte Funktion ausgelöst wird.
Verwaltete Identität: Alle Dienstbusverbindungen verwenden verwaltete Identität anstelle von Verbindungszeichenfolgen.
.NET 8 Isolated Worker: Verwendet das neueste Azure Functions .NET Isolated Worker-Modell für eine bessere Leistung und Flexibilität.

Hier können Sie das vollständige Vorlagenprojekt überprüfen.

Nachdem Sie Ihre Funktionen lokal überprüft haben, ist es an der Zeit, sie in Azure zu veröffentlichen.

In Azure bereitstellen

Dieses Projekt ist so konfiguriert, dass es den azd up-Befehl verwendet, um das Projekt in einer neuen Funktions-App unter einem Flex-Verbrauchsplan in Azure mit Unterstützung für OpenTelemetry bereitzustellen.

Tipp

Dieses Projekt enthält eine Reihe von Bicep-Dateien, die azd verwendet, um eine sichere Bereitstellung für einen Flex-Verbrauchsplan, der den bewährten Methoden folgt, zu erstellen, einschließlich verwalteter Identitätsverbindungen.

Führen Sie diesen Befehl aus, damit azd die erforderlichen Azure-Ressourcen in Azure erstellt und Ihr Codeprojekt in der neuen Funktions-App bereitstellt:
```
azd up
```
Der Stammordner enthält die azure.yaml-Definitionsdatei, die azd erfordert.

Wenn Sie noch nicht angemeldet sind, werden Sie aufgefordert, sich mit Ihrem Azure-Konto zu authentifizieren.

Wenn Sie dazu aufgefordert werden, stellen Sie die folgenden erforderlichen Bereitstellungsparameter bereit:

Parameter	Description
Azure-Abonnement	Das Abonnement, in dem Ihre Ressourcen erstellt werden.
Azure-Standort	Die Azure-Region, in der die Ressourcengruppe erstellt werden soll, die die neuen Azure-Ressourcen enthält. Es werden nur Regionen angezeigt, die den Flex-Verbrauchsplan derzeit unterstützen.

Der azd up-Befehl verwendet Ihre Antwort auf diese Eingabeaufforderungen mit den Bicep-Konfigurationsdateien, um diese Bereitstellungsaufgaben auszuführen:

Erstellen und Konfigurieren dieser erforderlichen Azure-Ressourcen (entspricht azd provision):
- Azure Functions Flex Consumption Plan und Funktions-App mit aktiviertem OpenTelemetry
- Azure Storage (erforderlich) und Application Insights (empfohlen)
- Der Service Bus-Namespace und die Warteschlange zur Demonstration der verteilten Nachverfolgung
- Zugriffsrichtlinien und -rollen für Ihr Konto
- Dienst-zu-Dienst-Verbindungen mit verwalteten Identitäten (anstelle gespeicherter Verbindungszeichenfolgen)
Packen und Bereitstellen des Codes im Bereitstellungscontainer (entspricht azd deploy). Die App wird dann gestartet und im bereitgestellten Paket ausgeführt.

Nachdem der Befehl erfolgreich abgeschlossen wurde, werden Links zu den von Ihnen erstellten Ressourcen angezeigt.

Verteiltes Tracing testen

Jetzt können Sie die verteilte Ablaufverfolgungsfunktion von OpenTelemetry testen, indem Sie Ihre bereitgestellten Funktionen aufrufen und die Telemetrie in Application Insights beobachten.

Aufrufen der Funktion in Azure

Sie können Ihre Funktionsendpunkte in Azure aufrufen, indem Sie HTTP-Anforderungen an ihre URLs senden. Da die HTTP-Funktionen in dieser Vorlage mit anonymen Zugriff konfiguriert sind, sind keine Funktionsschlüssel erforderlich.

Führen Sie in Ihrer lokalen Terminal- oder Eingabeaufforderung diesen Befehl aus, um den Namen der Funktions-App abzurufen und die URL zu erstellen:
```
APP_NAME=$(azd env get-value AZURE_FUNCTION_NAME)
echo "Function URL: https://$APP_NAME.azurewebsites.net/api/first_http_function"
```
Der azd env get-value-Befehl ruft ihren Funktions-App-Namen aus der lokalen Umgebung ab.
Testen Sie die Funktion in Ihrem Browser, indem Sie zu der URL navigieren:
```
https://your-function-app.azurewebsites.net/api/first_http_function
```
Ersetzen Sie your-function-app mit dem tatsächlichen Namen der Funktions-App aus dem vorherigen Schritt. Diese einzelne Anforderung erstellt eine verteilte Nachverfolgung, die alle drei Funktionen durchläuft.

Anzeigen der verteilten Ablaufverfolgung in Application Insights

Nach dem Aufrufen der Funktion können Sie die vollständige verteilte Ablaufverfolgung in Application Insights beobachten:

Hinweis

Es kann einige Minuten dauern, bis Telemetriedaten nach dem Aufrufen Ihrer Funktion in Application Insights angezeigt werden. Wenn Daten nicht sofort angezeigt werden, warten Sie einige Minuten, und aktualisieren Sie die Ansicht.

Wechseln Sie im Azure-Portal zu Ihrer Application Insights-Ressource (Sie finden sie in derselben Ressourcengruppe wie Ihre Funktions-App).
Öffnen Sie die Anwendungskarte, um den verteilten Trace über alle drei Funktionen hinweg anzuzeigen. Sie sollten den Fluss von der HTTP-Anforderung über Ihre Funktionen und zu Service Bus sehen.
Überprüfen Sie die Transaktionssuche, um Ihre Anforderung zu finden und das vollständige Trace-Protokoll anzuzeigen. Suchen Sie nach Transaktionen aus Ihrer Funktions-App.
Wählen Sie eine bestimmte Transaktion aus, um die End-to-End-Ablaufverfolgung anzuzeigen, die Folgendes zeigt:
- Die HTTP-Anforderung an first_http_function
- Der interne HTTP-Aufruf an second_http_function
- Die gesendete Servicebus-Nachricht
- servicebus_queue_trigger verarbeitet die Nachricht von Service Bus
In den Ablaufverfolgungsdetails können Sie Folgendes sehen:
- Zeitinformationen: Wie lange jeder Schritt gedauert hat
- Abhängigkeiten: Die Verbindungen zwischen Funktionen
- Protokolle: Anwendungsprotokolle im Zusammenhang mit dem Trace
- Leistungsmetriken: Reaktionszeiten und Durchsatz

In diesem Beispiel wird die end-to-End-verteilte Ablaufverfolgung über mehrere Azure-Funktionen mit der OpenTelemetry-Integration veranschaulicht, wodurch vollständige Einblicke in das Verhalten und die Leistung Ihrer Anwendung bereitgestellt werden.

Erneutes Bereitstellen Ihres Codes

Führen Sie den azd up Befehl so oft aus, wie Sie ihre Azure-Ressourcen bereitstellen und Codeupdates für Ihre Funktions-App bereitstellen müssen.

Hinweis

Das neueste Bereitstellungspaket überschreibt immer bereitgestellte Codedateien.

Ihre anfänglichen Antworten auf azd-Eingabeaufforderungen und alle von Ihnen generierten azd-Umgebungsvariablen werden lokal in Ihrer benannten Umgebung gespeichert. Verwenden Sie den azd env get-values Befehl, um alle Variablen in Ihrer Umgebung zu überprüfen, die der Befehl beim Erstellen von Azure-Ressourcen verwendet.

Bereinigen von Ressourcen

Wenn Sie mit der Arbeit mit Ihrer Funktions-App und verwandten Ressourcen fertig sind, verwenden Sie diesen Befehl, um die Funktions-App und die zugehörigen Ressourcen aus Azure zu löschen und weitere Kosten zu vermeiden:

azd down --no-prompt

Hinweis

Die --no-prompt-Option weist azd an, Ihre Ressourcengruppe ohne Bestätigung von Ihnen zu löschen.

Dieser Befehl wirkt sich nicht auf Ihr lokales Codeprojekt aus.

Feedback

War diese Seite hilfreich?

Last updated on 2025-11-19

Freigeben über

Lernprogramm: Überwachen von Azure-Funktionen mit verteilter OpenTelemetry-Ablaufverfolgung

Voraussetzungen

Initialisieren des Projekts

Überprüfen des Codes

OpenTelemetry-Konfiguration

Abhängigkeiten für OpenTelemetry

Funktionsimplementierung

Erste HTTP-Funktion

Zweite HTTP-Funktion

Service Bus-Warteschlangentrigger

Erste HTTP-Funktion

Zweite HTTP-Funktion

Service Bus-Warteschlangentrigger

Erste HTTP-Funktion

Zweite HTTP-Funktion

Service Bus-Warteschlangentrigger

Verteilte Ablaufverfolgungsfluss

In Azure bereitstellen

Verteiltes Tracing testen

Aufrufen der Funktion in Azure

Anzeigen der verteilten Ablaufverfolgung in Application Insights

Erneutes Bereitstellen Ihres Codes

Bereinigen von Ressourcen

Verwandte Inhalte

Feedback

Zusätzliche Ressourcen