Udostępnij za pomocą


Samouczek: monitorowanie usługi Azure Functions przy użyciu funkcji OpenTelemetry rozproszonego śledzenia

W tym artykule przedstawiono obsługę biblioteki OpenTelemetry w funkcji platformy Azure, która umożliwia rozproszone śledzenie między wieloma wywołaniami funkcji przy użyciu zintegrowanej obsługi usługi Application Insights i biblioteki OpenTelemetry. Aby ułatwić rozpoczęcie pracy, używany jest szablon Azure Developer CLI (azd) do stworzenia projektu kodu oraz wdrożenia platformy Azure, w którym można uruchomić swoją aplikację.

W tym samouczku skorzystasz z narzędzia azd, aby:

  • Inicjowanie projektu obsługującego OpenTelemetry na podstawie szablonu.
  • Przejrzyj kod, który umożliwia integrację biblioteki OpenTelemetry.
  • Uruchom i zweryfikuj lokalnie aplikację z obsługą funkcji OpenTelemetry.
  • Tworzenie aplikacji funkcji i powiązanych zasobów na platformie Azure.
  • Wdróż projekt kodu w aplikacji funkcji na platformie Azure.
  • Sprawdź śledzenie rozproszone w usłudze Application Insights.

Wymagane zasoby platformy Azure utworzone przez ten szablon są zgodne z bieżącymi najlepszymi rozwiązaniami dotyczącymi bezpiecznych i skalowalnych wdrożeń aplikacji funkcji na platformie Azure. To samo polecenie azd wdraża również twój projekt kodu do nowej aplikacji funkcji na platformie Azure.

Domyślnie plan Flex Consumption jest zgodny z modelem rozliczeń z płatnością za rzeczywiste użycie, co oznacza, że ukończenie tego rozpoczęcia pracy wiąże się z niewielkim kosztem kilku centów amerykańskich lub mniej na koncie platformy Azure.

Ważne

Ten artykuł obsługuje obecnie tylko języki C#, Python i TypeScript. Aby ukończyć przewodnik wprowadzający, wybierz jeden z tych obsługiwanych języków na górze artykułu.

Wymagania wstępne

Inicjowanie projektu

Użyj polecenia azd init do utworzenia lokalnego projektu kodu Azure Functions na podstawie szablonu, który zawiera rozproszone śledzenie za pomocą OpenTelemetry.

  1. W lokalnym terminalu lub wierszu polecenia uruchom to azd init polecenie w pustym folderze:

    azd init --template functions-quickstart-python-azd-otel -e flexquickstart-otel
    

    To polecenie ściąga pliki projektu z repozytorium szablonów i inicjuje projekt w bieżącym folderze. Flaga -e ustawia nazwę bieżącego środowiska. W azd środowisko systemowe zapewnia unikatowy kontekst wdrażania dla twojej aplikacji i można zdefiniować więcej niż jeden z nich. Nazwa środowiska jest również wyświetlana w nazwie grupy zasobów utworzonej na platformie Azure.

  1. W lokalnym terminalu lub wierszu polecenia uruchom to azd init polecenie w pustym folderze:

    azd init --template functions-quickstart-typescript-azd-otel -e flexquickstart-otel
    

    To polecenie ściąga pliki projektu z repozytorium szablonów i inicjuje projekt w bieżącym folderze. Flaga -e ustawia nazwę bieżącego środowiska. W azd środowisko systemowe zapewnia unikatowy kontekst wdrażania dla twojej aplikacji i można zdefiniować więcej niż jeden z nich. Nazwa środowiska jest również wyświetlana w nazwie grupy zasobów utworzonej na platformie Azure.

  1. W lokalnym terminalu lub wierszu polecenia uruchom to azd init polecenie w pustym folderze:

    azd init --template functions-quickstart-dotnet-azd-otel -e flexquickstart-otel
    

    To polecenie ściąga pliki projektu z repozytorium szablonów i inicjuje projekt w bieżącym folderze. Flaga -e ustawia nazwę bieżącego środowiska. W azd środowisko systemowe zapewnia unikatowy kontekst wdrażania dla twojej aplikacji i można zdefiniować więcej niż jeden z nich. Nazwa środowiska jest również wyświetlana w nazwie grupy zasobów utworzonej na platformie Azure.

Przeglądanie kodu

Szablon tworzy kompletny scenariusz śledzenia rozproszonego z trzema funkcjami, które współpracują ze sobą. Przejrzyjmy kluczowe aspekty związane z usługą OpenTelemetry:

Konfiguracja openTelemetry

Plik src/otel-sample/host.json włącza funkcję OpenTelemetry dla hosta usługi Functions:

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

Ustawienie "telemetryMode": "OpenTelemetry" klucza umożliwia śledzenie rozproszone między wywołaniami funkcji.

Plik src/OTelSample/host.json włącza funkcję OpenTelemetry dla hosta usługi Functions:

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

Ustawienie "telemetryMode": "OpenTelemetry" klucza umożliwia śledzenie rozproszone między wywołaniami funkcji.

Zależności dla platformy OpenTelemetry

Plik src/otel-sample/requirements.txt zawiera niezbędne pakiety do integracji biblioteki OpenTelemetry:

azure-functions
azure-monitor-opentelemetry
requests

Pakiet azure-monitor-opentelemetry zapewnia integrację biblioteki OpenTelemetry z usługą Application Insights.

Plik src/otel-sample/package.json zawiera niezbędne pakiety do integracji biblioteki OpenTelemetry:

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

Pakiety @azure/functions-opentelemetry-instrumentation i @azure/monitor-opentelemetry-exporter zapewniają integrację biblioteki OpenTelemetry z usługą Application Insights.

Plik .csproj zawiera niezbędne pakiety do integracji biblioteki OpenTelemetry:

<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" />

Te pakiety zapewniają integrację biblioteki OpenTelemetry z usługą Application Insights i instrumentacją HTTP na potrzeby śledzenia rozproszonego.

Implementacja funkcji

Funkcje w programie src/otel-sample/function_app.py przedstawiają przepływ śledzenia rozproszonego:

Pierwsza funkcja HTTP

@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"
    )

Druga funkcja HTTP

@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
    )

Wyzwalacz kolejki w usłudze Service Bus

@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')

Konfiguracja openTelemetry jest skonfigurowana w programie 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()],
});

Funkcje są definiowane w folderze src/otel-sample/src/functions :

Pierwsza funkcja HTTP

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" }),
    };
  }
}

Druga funkcja HTTP

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,
  };
}

Wyzwalacz kolejki w usłudze Service Bus

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");
}

Konfiguracja openTelemetry jest skonfigurowana w programie src/OTelSample/Program.cs:

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();

Funkcje są definiowane w osobnych plikach klas:

Pierwsza funkcja HTTP

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}");
    }
}

Druga funkcja HTTP

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; }
}

Wyzwalacz kolejki w usłudze Service Bus

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);
    }
}

Przepływ śledzenia rozproszonego

Ta architektura tworzy kompletny scenariusz śledzenia rozproszonego z następującym zachowaniem:

  1. Pierwsza funkcja HTTP odbiera żądanie HTTP i wywołuje drugą funkcję HTTP
  2. Druga funkcja HTTP odpowiada i wysyła komunikat do usługi Service Bus
  3. Wyzwalacz usługi Service Bus przetwarza komunikat z opóźnieniem w celu symulowania pracy przetwarzania

Kluczowe aspekty implementacji OpenTelemetry:

  • Integracja biblioteki OpenTelemetry: host.json plik włącza funkcję OpenTelemetry za pomocą polecenia "telemetryMode": "OpenTelemetry"
  • Łańcuch funkcji: pierwsza funkcja wywołuje drugą przy użyciu żądań HTTP, tworząc skorelowane ślady
  • Integracja z usługą Service Bus: druga funkcja zwraca dane wyjściowe do usługi Service Bus, która wyzwala trzecią funkcję
  • Uwierzytelnianie anonimowe: funkcje HTTP używają auth_level=func.AuthLevel.ANONYMOUS, więc nie są wymagane żadne klucze funkcji

Pełny projekt szablonu można przejrzeć tutaj.

  • Integracja biblioteki OpenTelemetry: index.ts plik konfiguruje bibliotekę OpenTelemetry za pomocą eksporterów usługi Azure Monitor pod kątem śladów i dzienników
  • Łańcuch funkcji: pierwsza funkcja wywołuje drugą przy użyciu axios z automatyczną propagacją śledzenia
  • Integracja z usługą Service Bus: druga funkcja zwraca dane wyjściowe do usługi Service Bus przy użyciu powiązań wyjściowych, co wyzwala trzecią funkcję
  • Tożsamość zarządzana: wszystkie połączenia usługi Service Bus używają tożsamości zarządzanej zamiast parametrów połączenia
  • Symulacja przetwarzania: 5-sekundowe opóźnienie wyzwalacza usługi Service Bus symuluje pracę przetwarzania komunikatów

Pełny projekt szablonu można przejrzeć tutaj.

  • Integracja biblioteki OpenTelemetry: Program.cs plik konfiguruje bibliotekę OpenTelemetry za pomocą eksportera usługi Azure Monitor
  • Łańcuch funkcji: pierwsza funkcja wywołuje drugą przy użyciu elementu HttpClient z instrumentacją OpenTelemetry
  • Integracja z usługą Service Bus: druga funkcja zwraca dane wyjściowe do usługi Service Bus przy użyciu powiązań wyjściowych, co wyzwala trzecią funkcję
  • Tożsamość zarządzana: wszystkie połączenia usługi Service Bus używają tożsamości zarządzanej zamiast parametrów połączenia
  • Izolowany proces roboczy platformy .NET 8: używa najnowszego modelu izolowanego procesu roboczego usługi Azure Functions dla platformy .NET, aby uzyskać lepszą wydajność i elastyczność

Pełny projekt szablonu można przejrzeć tutaj.

Po zweryfikowaniu funkcji lokalnie nadszedł czas, aby opublikować je na platformie Azure.

Wdrażanie na platformie Azure

Ten projekt jest skonfigurowany do używania polecenia azd up w celu wdrożenia tego projektu w nowej aplikacji funkcyjnej w planie Flex Consumption na platformie Azure z obsługą OpenTelemetry.

Wskazówka

Ten projekt zawiera zestaw plików Bicep używanych azd do tworzenia bezpiecznego wdrożenia w planie zużycia Flex, który jest zgodny z najlepszymi rozwiązaniami, w tym połączeniami tożsamości zarządzanej.

  1. Uruchom to polecenie, aby azd utworzyć wymagane zasoby platformy Azure na platformie Azure i wdrożyć projekt kodu w nowej aplikacji funkcji:

    azd up
    

    Folder główny zawiera azure.yaml plik definicji wymagany przez azdprogram .

    Jeśli jeszcze nie zalogowano się, zostanie wyświetlony monit o uwierzytelnienie przy użyciu konta platformy Azure.

  2. Po wyświetleniu monitu podaj następujące wymagane parametry wdrożenia:

    Parameter Description
    Subskrypcja platformy Azure Subskrypcja, w której są tworzone zasoby.
    Lokalizacja platformy Azure Region platformy Azure, w którym ma zostać utworzona grupa zasobów zawierająca nowe zasoby platformy Azure. Wyświetlane są tylko regiony, które obecnie obsługują plan Flex Consumption.

    Polecenie azd up używa odpowiedzi na te monity z plikami konfiguracji Bicep, aby wykonać następujące zadania wdrażania:

    • Utwórz i skonfiguruj te wymagane zasoby platformy Azure (równoważne ):azd provision

      • Plan i aplikacja funkcji Flex Consumption usługi Azure Functions z włączoną funkcją OpenTelemetry
      • Azure Storage (wymagane) i Application Insights (zalecane)
      • Przestrzeń nazw i kolejka usługi Service Bus na potrzeby demonstracji śledzenia rozproszonego
      • Zasady dostępu i role dla twojego konta
      • Połączenia między usługami przy użyciu tożsamości zarządzanych (zamiast przechowywanych parametry połączenia)
    • Spakuj i wdróż kod w kontenerze wdrażania (odpowiednik azd deploy). Aplikacja jest następnie uruchamiana i uruchamiana w wdrożonym pakiecie.

    Po pomyślnym zakończeniu działania polecenia zobaczysz linki do utworzonych zasobów.

Testowanie rozproszonego śledzenia

Teraz możesz przetestować funkcję śledzenia rozproszonego OpenTelemetry, wywołując wdrożone funkcje i obserwując telemetrię w usłudze Application Insights.

Wywoływanie funkcji na platformie Azure

Punkty końcowe funkcji można wywołać na platformie Azure, wysyłając żądania HTTP do ich adresów URL. Ponieważ funkcje HTTP w tym szablonie są skonfigurowane z dostępem anonimowym, nie są wymagane żadne klucze funkcji.

  1. W lokalnym terminalu lub wierszu polecenia uruchom to polecenie, aby uzyskać nazwę aplikacji funkcji i skonstruować adres URL:

    APP_NAME=$(azd env get-value AZURE_FUNCTION_NAME)
    echo "Function URL: https://$APP_NAME.azurewebsites.net/api/first_http_function"
    

    Polecenie azd env get-value pobiera nazwę aplikacji funkcji ze środowiska lokalnego.

  2. Przetestuj funkcję w przeglądarce, przechodząc do adresu URL:

    https://your-function-app.azurewebsites.net/api/first_http_function
    

    Zastąp your-function-app rzeczywistą nazwę aplikacji funkcji z poprzedniego kroku. To pojedyncze żądanie tworzy rozproszony ślad, który przepływa przez wszystkie trzy funkcje.

Wyświetlanie śledzenia rozproszonego w usłudze Application Insights

Po wywołaniu funkcji możesz obserwować pełny ślad rozproszony w usłudze Application Insights:

Uwaga / Notatka

Wyświetlenie danych telemetrycznych w usłudze Application Insights po wywołaniu funkcji może potrwać kilka minut. Jeśli dane nie są widoczne natychmiast, zaczekaj kilka minut i odśwież widok.

  1. Przejdź do zasobu usługi Application Insights w witrynie Azure Portal (możesz go znaleźć w tej samej grupie zasobów co aplikacja funkcji).

  2. Otwórz mapę Aplikacji , aby wyświetlić rozproszony ślad we wszystkich trzech funkcjach. Powinieneś zobaczyć przepływ od żądania HTTP, przez funkcje, do usługi Service Bus.

  3. Sprawdź wyszukiwanie transakcji, aby znaleźć żądanie i wyświetlić pełną historię śledzenia. Wyszukaj transakcje z aplikacji funkcji.

  4. Wybierz określoną transakcję, aby wyświetlić kompleksowe śledzenie, które pokazuje:

    • Żądanie HTTP do first_http_function
    • Wewnętrzne wywołanie HTTP do second_http_function
    • Wysyłany komunikat usługi Service Bus
    • servicebus_queue_trigger Przetwarzanie komunikatu z usługi Service Bus
  5. W szczegółach śledzenia można zobaczyć:

    • Informacje o chronometrażu: jak długo trwał każdy krok
    • Zależności: połączenia między funkcjami
    • Dzienniki: dzienniki aplikacji skorelowane z trasowaniem
    • Metryki wydajności: czasy odpowiedzi i przepływność

W tym przykładzie pokazano kompleksowe rozproszone śledzenie w wielu usługach Azure Functions z integracją OpenTelemetry, zapewniając pełny wgląd w zachowanie i wydajność aplikacji.

Ponowne wdrażanie kodu

azd up Uruchom polecenie tyle razy, ile potrzebujesz, aby aprowizować zasoby platformy Azure i wdrażać aktualizacje kodu w aplikacji funkcji.

Uwaga / Notatka

Najnowszy pakiet wdrożeniowy zawsze zastępuje wdrożone pliki kodu.

Początkowe odpowiedzi na azd monity i wszystkie zmienne środowiskowe wygenerowane przez azd program są przechowywane lokalnie w nazwanym środowisku. Użyj polecenia , azd env get-values aby przejrzeć wszystkie zmienne w środowisku używane przez polecenie podczas tworzenia zasobów platformy Azure.

Uprzątnij zasoby

Po zakończeniu pracy z aplikacją funkcji i powiązanymi zasobami użyj tego polecenia, aby usunąć aplikację funkcji i powiązane z nią zasoby z platformy Azure i uniknąć ponoszenia dodatkowych kosztów:

azd down --no-prompt

Uwaga / Notatka

Opcja --no-prompt powoduje azd usunięcie grupy zasobów bez potwierdzenia.

To polecenie nie ma wpływu na lokalny projekt kodu.