Dela via

Azure Blob Storage-utlösare för Azure Functions

  • Artikel

Blob Storage-utlösaren startar en funktion när en ny eller uppdaterad blob identifieras. Blobinnehållet tillhandahålls som indata till funktionen.

Dricks

Det finns flera sätt att köra funktionskoden baserat på ändringar i blobar i en lagringscontainer. Om du väljer att använda bloblagringsutlösaren bör du tänka på att det finns två implementeringar: en avsökningsbaserad (refererad i den här artikeln) och en händelsebaserad. Vi rekommenderar att du använder den händelsebaserade implementeringen eftersom den har lägre svarstid än den andra. Dessutom stöder Flex Consumption-planen endast den händelsebaserade Blob Storage-utlösaren.

Mer information om skillnaderna mellan de två implementeringarna av Blob Storage-utlösaren samt andra utlösande alternativ finns i Arbeta med blobar.

Information om konfiguration och konfigurationsinformation finns i översikten.

Viktigt!

Den här artikeln använder flikar för att stödja flera versioner av Node.js programmeringsmodellen. V4-modellen är allmänt tillgänglig och är utformad för att ha en mer flexibel och intuitiv upplevelse för JavaScript- och TypeScript-utvecklare. Mer information om hur v4-modellen fungerar finns i utvecklarguiden för Azure Functions Node.js. Mer information om skillnaderna mellan v3 och v4 finns i migreringsguiden.

Azure Functions stöder två programmeringsmodeller för Python. Hur du definierar dina bindningar beror på din valda programmeringsmodell.

Med programmeringsmodellen Python v2 kan du definiera bindningar med hjälp av dekoratörer direkt i python-funktionskoden. Mer information finns i utvecklarguiden för Python.

Den här artikeln stöder båda programmeringsmodellerna.

Exempel

En C#-funktion kan skapas med något av följande C#-lägen:

  • Isolerad arbetsmodell: Kompilerad C#-funktion som körs i en arbetsprocess som är isolerad från körningen. Isolerad arbetsprocess krävs för att stödja C#-funktioner som körs på LTS- och icke-LTS-versioner .NET och .NET Framework. Tillägg för isolerade arbetsprocessfunktioner använder Microsoft.Azure.Functions.Worker.Extensions.* namnområden.
  • Processmodell: Kompilerad C#-funktion som körs i samma process som Functions-körningen. I en variant av den här modellen kan Functions köras med C#-skript, vilket främst stöds för redigering av C#-portalen. Tillägg för in-process-funktioner använder Microsoft.Azure.WebJobs.Extensions.* namnområden.

Viktigt!

Supporten upphör för den pågående modellen den 10 november 2026. Vi rekommenderar starkt att du migrerar dina appar till den isolerade arbetsmodellen för fullt stöd.

Följande exempel är en C#-funktion som körs i en isolerad arbetsprocess och använder en blobutlösare med både blobindata- och blobutdatablobbindningar. Funktionen utlöses när en blob skapas i containern test-samples-trigger . Den läser en textfil från containern test-samples-input och skapar en ny textfil i en utdatacontainer baserat på namnet på den utlösta filen.

public static class BlobFunction
{
    [Function(nameof(BlobFunction))]
    [BlobOutput("test-samples-output/{name}-output.txt")]
    public static string Run(
        [BlobTrigger("test-samples-trigger/{name}")] string myTriggerItem,
        [BlobInput("test-samples-input/sample1.txt")] string myBlob,
        FunctionContext context)
    {
        var logger = context.GetLogger("BlobFunction");
        logger.LogInformation("Triggered Item = {myTriggerItem}", myTriggerItem);
        logger.LogInformation("Input Item = {myBlob}", myBlob);

        // Blob Output
        return "blob-output content";
    }
}

Den här funktionen skriver en logg när en blob läggs till eller uppdateras i containern myblob .

@FunctionName("blobprocessor")
public void run(
  @BlobTrigger(name = "file",
               dataType = "binary",
               path = "myblob/{name}",
               connection = "MyStorageAccountAppSetting") byte[] content,
  @BindingName("name") String filename,
  final ExecutionContext context
) {
  context.getLogger().info("Name: " + filename + " Size: " + content.length + " bytes");
}

I följande exempel visas en TypeScript-kod för blobutlösare. Funktionen skriver en logg när en blob läggs till eller uppdateras i containern samples-workitems .

Strängen {name} i blobutlösarsökvägen samples-workitems/{name} skapar ett bindningsuttryck som du kan använda i funktionskoden för att komma åt filnamnet för den utlösande bloben. Mer information finns i Mönster för blobnamn senare i den här artikeln.

import { app, InvocationContext } from '@azure/functions';

export async function storageBlobTrigger1(blob: Buffer, context: InvocationContext): Promise<void> {
    context.log(
        `Storage blob function processed blob "${context.triggerMetadata.name}" with size ${blob.length} bytes`
    );
}

app.storageBlob('storageBlobTrigger1', {
    path: 'samples-workitems/{name}',
    connection: 'MyStorageAccountAppSetting',
    handler: storageBlobTrigger1,
});

I följande exempel visas en JavaScript-kod för blobutlösare. Funktionen skriver en logg när en blob läggs till eller uppdateras i containern samples-workitems .

Strängen {name} i blobutlösarsökvägen samples-workitems/{name} skapar ett bindningsuttryck som du kan använda i funktionskoden för att komma åt filnamnet för den utlösande bloben. Mer information finns i Mönster för blobnamn senare i den här artikeln.

const { app } = require('@azure/functions');

app.storageBlob('storageBlobTrigger1', {
    path: 'samples-workitems/{name}',
    connection: 'MyStorageAccountAppSetting',
    handler: (blob, context) => {
        context.log(
            `Storage blob function processed blob "${context.triggerMetadata.name}" with size ${blob.length} bytes`
        );
    },
});

I följande exempel visas hur du skapar en funktion som körs när en fil läggs till source i bloblagringscontainern.

Funktionskonfigurationsfilen (function.json) innehåller en bindning med type av blobTrigger och direction inställd på in.

{
  "bindings": [
    {
      "name": "InputBlob",
      "type": "blobTrigger",
      "direction": "in",
      "path": "source/{name}",
      "connection": "MyStorageAccountConnectionString"
    }
  ]
}

Här är den associerade koden för filen run.ps1 .

param([byte[]] $InputBlob, $TriggerMetadata)

Write-Host "PowerShell Blob trigger: Name: $($TriggerMetadata.Name) Size: $($InputBlob.Length) bytes"

I det här exemplet används SDK-typer för direkt åtkomst till det underliggande BlobClient objektet som tillhandahålls av Blob Storage-utlösaren:

import logging

import azure.functions as func
import azurefunctions.extensions.bindings.blob as blob

app = func.FunctionApp(http_auth_level=func.AuthLevel.ANONYMOUS)
@app.blob_trigger(
    arg_name="client", path="PATH/TO/BLOB", connection="AzureWebJobsStorage"
)
def blob_trigger(client: blob.BlobClient):
    logging.info(
        f"Python blob trigger function processed blob \n"
        f"Properties: {client.get_blob_properties()}\n"
        f"Blob content head: {client.download_blob().read(size=1)}"
    )

Exempel på hur du använder andra SDK-typer finns i exemplen ContainerClient och StorageStreamDownloader .

Mer information, inklusive hur du aktiverar SDK-typbindningar i projektet, finns i SDK-typbindningar.

Det här exemplet loggar information från inkommande blobmetadata.

import logging
import azure.functions as func

app = func.FunctionApp()

@app.function_name(name="BlobTrigger1")
@app.blob_trigger(arg_name="myblob", 
                  path="PATH/TO/BLOB",
                  connection="CONNECTION_SETTING")
def test_function(myblob: func.InputStream):
   logging.info(f"Python blob trigger function processed blob \n"
                f"Name: {myblob.name}\n"
                f"Blob Size: {myblob.length} bytes")

Attribut

C#-bibliotek i både processprocess och isolerad arbetsprocess använder attributet BlobAttribute för att definiera funktionen. C#-skriptet använder i stället en function.json konfigurationsfil enligt beskrivningen i C#-skriptguiden.

Attributets konstruktor tar följande parametrar:

Parameter Description
BlobPath Sökvägen till bloben.
Anslutning Namnet på en appinställning eller inställningssamling som anger hur du ansluter till Azure Blobs. Se Anslutningar.
Åtkomst Anger om du ska läsa eller skriva.
Source Anger källan för utlösande händelsen. Används BlobTriggerSource.EventGrid för en Event Grid-baserad blobutlösare, vilket ger mycket lägre svarstid. Standardvärdet är BlobTriggerSource.LogsAndContainerScan, som använder standardavsökningsmekanismen för att identifiera ändringar i containern.

Här är ett BlobTrigger attribut i en metodsignatur:

[Function(nameof(BlobFunction))]
[BlobOutput("test-samples-output/{name}-output.txt")]
public static string Run(
    [BlobTrigger("test-samples-trigger/{name}")] string myTriggerItem,
    [BlobInput("test-samples-input/sample1.txt")] string myBlob,
    FunctionContext context)

När du utvecklar lokalt lägger du till dina programinställningar i den local.settings.json filen i Values samlingen.

Dekoratörer

Gäller endast för python v2-programmeringsmodellen.

För Python v2-funktioner som definierats med hjälp av dekoratörer definierar följande egenskaper på blob_trigger dekoratören bloblagringsutlösaren:

Property beskrivning
arg_name Deklarerar parameternamnet i funktionssignaturen. När funktionen utlöses innehåller den här parameterns värde innehållet i kömeddelandet.
path Containern som ska övervakas. Kan vara ett mönster för blobnamn.
connection Anslutningssträngen för lagringskontot.
source Anger källan för utlösande händelsen. Används EventGrid för en Event Grid-baserad blobutlösare, vilket ger mycket lägre svarstid. Standardvärdet är LogsAndContainerScan, som använder standardavsökningsmekanismen för att identifiera ändringar i containern.

Information om Python-funktioner som definierats med hjälp av function.json finns i avsnittet Konfiguration .

Kommentarer

Attributet @BlobTrigger används för att ge dig åtkomst till den blob som utlöste funktionen. Mer information finns i utlösarexemplet. Använd egenskapen source för att ange källan för utlösande händelsen. Används EventGrid för en Event Grid-baserad blobutlösare, vilket ger mycket lägre svarstid. Standardvärdet är LogsAndContainerScan, som använder standardavsökningsmekanismen för att identifiera ändringar i containern. |

Konfiguration

Gäller endast programmeringsmodellen Python v1.

I följande tabell förklaras de egenskaper som du kan ange för objektet options som skickas app.storageBlob() till metoden.

Property beskrivning
sökväg Containern som ska övervakas. Kan vara ett mönster för blobnamn.
samband Namnet på en appinställning eller inställningssamling som anger hur du ansluter till Azure Blobs. Se Anslutningar.
källa Anger källan för utlösande händelsen. Används EventGrid för en Event Grid-baserad blobutlösare, vilket ger mycket lägre svarstid. Standardvärdet är LogsAndContainerScan, som använder standardavsökningsmekanismen för att identifiera ändringar i containern.

I följande tabell förklaras de bindningskonfigurationsegenskaper som du anger i filen function.json .

function.json egenskap beskrivning
typ Måste anges till blobTrigger. Den här egenskapen anges automatiskt när du skapar utlösaren i Azure Portal.
riktning Måste anges till in. Den här egenskapen anges automatiskt när du skapar utlösaren i Azure Portal. Undantag anges i användningsavsnittet.
Namn Namnet på variabeln som representerar bloben i funktionskoden.
sökväg Containern som ska övervakas. Kan vara ett mönster för blobnamn.
samband Namnet på en appinställning eller inställningssamling som anger hur du ansluter till Azure Blobs. Se Anslutningar.
källa Anger källan för utlösande händelsen. Används EventGrid för en Event Grid-baserad blobutlösare, vilket ger mycket lägre svarstid. Standardvärdet är LogsAndContainerScan, som använder standardavsökningsmekanismen för att identifiera ändringar i containern.

Se avsnittet Exempel för fullständiga exempel.

Metadata

Blobutlösaren innehåller flera metadataegenskaper. Dessa egenskaper kan användas som en del av bindningsuttryck i andra bindningar eller som parametrar i koden. Dessa värden har samma semantik som CloudBlob-typen .

Property Type Beskrivning
BlobTrigger string Sökvägen till den utlösande bloben.
Uri System.Uri Blobbens URI för den primära platsen.
Properties BlobEgenskaper Blobens systemegenskaper.
Metadata IDictionary<string,string> Användardefinierade metadata för blobben.

I följande exempel loggas sökvägen till den utlösande bloben, inklusive containern:

public static void Run(string myBlob, string blobTrigger, ILogger log)
{
    log.LogInformation($"Full blob path: {blobTrigger}");
}

Metadata

Blobutlösaren innehåller flera metadataegenskaper. Dessa egenskaper kan användas som en del av bindningsuttryck i andra bindningar eller som parametrar i koden.

Property beskrivning
blobTrigger Sökvägen till den utlösande bloben.
uri Blobbens URI för den primära platsen.
properties Blobens systemegenskaper.
metadata Användardefinierade metadata för blobben.

Metadata kan hämtas från triggerMetadata egenskapen för det angivna context objektet, enligt följande exempel, som loggar sökvägen till den utlösande bloben (blobTrigger), inklusive containern:

context.log(`Full blob path: ${context.triggerMetadata.blobTrigger}`);

Metadata

Metadata är tillgängliga via parametern $TriggerMetadata .

Förbrukning

Vilka bindningstyper som stöds av Blob-utlösaren beror på tilläggspaketversionen och den C#-modalitet som används i funktionsappen.

Blobutlösaren kan binda till följande typer:

Typ Beskrivning
string Blobinnehållet som en sträng. Använd när blobinnehållet är enkel text.
byte[] Byte för blobinnehållet.
JSON-serialiserbara typer När en blob innehåller JSON-data försöker Functions deserialisera JSON-data till en vanlig CLR-objekttyp (POCO).
Stream1 En indataström av blobinnehållet.
BlobClient1,
BlockBlobClient1,
PageBlobClient1,
AppendBlobClient1,
BlobBaseClient1		 En klient som är ansluten till bloben. Den här uppsättningen typer ger mest kontroll för bearbetning av bloben och kan användas för att skriva tillbaka till bloben om anslutningen har tillräcklig behörighet.

1 Om du vill använda dessa typer måste du referera till Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs 6.0.0 eller senare och de vanliga beroendena för SDK-typbindningar.

Bindning till string, eller Byte[] rekommenderas endast när blobstorleken är liten. Detta rekommenderas eftersom hela blobinnehållet läses in i minnet. Använd en Stream eller BlobClient typ för de flesta blobar. Mer information finns i Samtidighet och minnesanvändning.

Om du får ett felmeddelande när du försöker binda till någon av Storage SDK-typerna kontrollerar du att du har en referens till rätt Storage SDK-version.

Du kan också använda StorageAccountAttribute för att ange vilket lagringskonto som ska användas. Du kan göra detta när du behöver använda ett annat lagringskonto än andra funktioner i biblioteket. Konstruktorn tar namnet på en appinställning som innehåller en lagrings-anslutningssträng. Attributet kan användas på parameter-, metod- eller klassnivå. I följande exempel visas klassnivå och metodnivå:

[StorageAccount("ClassLevelStorageAppSetting")]
public static class AzureFunctions
{
    [FunctionName("BlobTrigger")]
    [StorageAccount("FunctionLevelStorageAppSetting")]
    public static void Run( //...
{
    ....
}

Lagringskontot som ska användas bestäms i följande ordning:

  • Attributets BlobTrigger Connection egenskap.
  • Attributet StorageAccount som tillämpas på samma parameter som attributet BlobTrigger .
  • Attributet StorageAccount som tillämpas på funktionen.
  • Attributet StorageAccount som tillämpas på klassen.
  • Standardlagringskontot för funktionsappen, som definieras i programinställningen AzureWebJobsStorage .

Attributet @BlobTrigger används för att ge dig åtkomst till den blob som utlöste funktionen. Mer information finns i utlösarexemplet.

Få åtkomst till blobdata som det första argumentet till din funktion.

Få åtkomst till blobdata via en parameter som matchar namnet som anges av bindningens namnparameter i filen function.json .

Få åtkomst till blobdata via parametern som anges som InputStream. Mer information finns i utlösarexemplet.

Functions stöder även Python SDK-typbindningar för Azure Blob Storage, vilket gör att du kan arbeta med blobdata med hjälp av dessa underliggande SDK-typer:

Viktigt!

Stöd för SDK-typer för Python är för närvarande i förhandsversion och stöds endast för python v2-programmeringsmodellen. Mer information finns i SDK-typer i Python.

anslutningar

Egenskapen connection är en referens till miljökonfigurationen som anger hur appen ska ansluta till Azure Blobs. Den kan ange:

Om det konfigurerade värdet både är en exakt matchning för en enskild inställning och en prefixmatchning för andra inställningar används den exakta matchningen.

Connection string

För att få en anslutningssträng följer du stegen som visas i Hantera åtkomstnycklar för lagringskonto. Anslutningssträng måste vara för ett allmänt lagringskonto, inte för ett Blob Storage-konto.

Den här anslutningssträng ska lagras i en programinställning med ett namn som matchar det värde som anges av connection egenskapen för bindningskonfigurationen.

Om namnet på appinställningen börjar med "AzureWebJobs" kan du bara ange resten av namnet här. Om du till exempel anger connection "MyStorage" letar Functions-körningen efter en appinställning med namnet "AzureWebJobsMyStorage". Om du lämnar connection tomt använder Functions-körningen standardinställningen Storage anslutningssträng i appinställningen med namnet AzureWebJobsStorage.

Identitetsbaserade anslutningar

Om du använder version 5.x eller senare av tillägget (paket 3.x eller senare för non-.NET språkstackar) i stället för att använda en anslutningssträng med en hemlighet kan du låta appen använda en Microsoft Entra-identitet. Om du vill använda en identitet definierar du inställningar under ett vanligt prefix som mappar till connection egenskapen i utlösar- och bindningskonfigurationen.

Om du anger connection "AzureWebJobsStorage" läser du Ansluta till värdlagring med en identitet. För alla andra anslutningar kräver tillägget följande egenskaper:

Property Miljövariabelmall beskrivning Exempelvärde
Blob Service URI <CONNECTION_NAME_PREFIX>__serviceUri1 Dataplanets URI för blobtjänsten som du ansluter till med hjälp av HTTPS-schemat. <https:// storage_account_name.blob.core.windows.net>

1 <CONNECTION_NAME_PREFIX>__blobServiceUri kan användas som ett alias. Om anslutningskonfigurationen ska användas av en blobutlösare blobServiceUri måste även åtföljas av queueServiceUri. Se nedan.

Formuläret serviceUri kan inte användas när den övergripande anslutningskonfigurationen ska användas mellan blobar, köer och/eller tabeller. URI:n kan bara ange blobtjänsten. Alternativt kan du ange en URI specifikt för varje tjänst, vilket gör att en enda anslutning kan användas. Om båda versionerna tillhandahålls används formuläret för flera tjänster. Om du vill konfigurera anslutningen för flera tjänster i stället för <CONNECTION_NAME_PREFIX>__serviceUrianger du:

Property Miljövariabelmall beskrivning Exempelvärde
Blob Service URI <CONNECTION_NAME_PREFIX>__blobServiceUri Dataplanets URI för blobtjänsten som du ansluter till med hjälp av HTTPS-schemat. <https:// storage_account_name.blob.core.windows.net>
Kötjänst-URI (krävs för blobutlösare2) <CONNECTION_NAME_PREFIX>__queueServiceUri Dataplanets URI för en kötjänst med hjälp av HTTPS-schemat. Det här värdet behövs bara för blobutlösare. <https:// storage_account_name.queue.core.windows.net>

2 Blobutlösaren hanterar fel i flera återförsök genom att skriva giftblobar till en kö. I formuläret serviceUri AzureWebJobsStorage används anslutningen. Men när du blobServiceUrianger måste en kötjänst-URI också anges med queueServiceUri. Vi rekommenderar att du använder tjänsten från samma lagringskonto som blobtjänsten. Du måste också se till att utlösaren kan läsa och skriva meddelanden i den konfigurerade kötjänsten genom att tilldela en roll som Lagringsködatadeltagare.

Andra egenskaper kan anges för att anpassa anslutningen. Se Vanliga egenskaper för identitetsbaserade anslutningar.

När identitetsbaserade anslutningar finns i Azure Functions-tjänsten använder de en hanterad identitet. Den systemtilldelade identiteten används som standard, även om en användartilldelad identitet kan anges med credential egenskaperna och clientID . Observera att det inte går att konfigurera en användartilldelad identitet med ett resurs-ID. När den körs i andra sammanhang, till exempel lokal utveckling, används utvecklaridentiteten i stället, även om den kan anpassas. Se Lokal utveckling med identitetsbaserade anslutningar.

Bevilja behörighet till identiteten

Den identitet som används måste ha behörighet att utföra de avsedda åtgärderna. För de flesta Azure-tjänster innebär det att du måste tilldela en roll i Azure RBAC med hjälp av antingen inbyggda eller anpassade roller som ger dessa behörigheter.

Viktigt!

Vissa behörigheter kan exponeras av måltjänsten som inte är nödvändiga för alla kontexter. Om möjligt följer du principen om minsta behörighet och beviljar identiteten endast nödvändiga privilegier. Om appen till exempel bara behöver kunna läsa från en datakälla använder du en roll som bara har behörighet att läsa. Det skulle vara olämpligt att tilldela en roll som också tillåter skrivning till tjänsten, eftersom detta skulle vara överdriven behörighet för en läsåtgärd. På samma sätt vill du se till att rolltilldelningen endast är begränsad till de resurser som behöver läsas.

Du måste skapa en rolltilldelning som ger åtkomst till din blobcontainer vid körning. Hanteringsroller som Ägare räcker inte. I följande tabell visas inbyggda roller som rekommenderas när du använder Blob Storage-tillägget i normal drift. Ditt program kan kräva ytterligare behörigheter baserat på den kod du skriver.

Bindningstyp Exempel på inbyggda roller
Utlösare Lagringsblobdataägare och lagringsködatadeltagare1

Extra behörigheter måste också beviljas till AzureWebJobsStorage-anslutningen.2
Indatabindning Storage Blob Data-läsare
Utdatabindning Storage Blob Data-ägare

1 Blobutlösaren hanterar fel i flera återförsök genom att skriva giftblobar till en kö på det lagringskonto som anges av anslutningen.

2 AzureWebJobsStorage-anslutningen används internt för blobar och köer som aktiverar utlösaren. Om den har konfigurerats för att använda en identitetsbaserad anslutning behöver den extra behörigheter utöver standardkravet. De behörigheter som krävs omfattas av rollerna Storage Blob Data Owner, Storage Queue Data Contributor och Storage Account Contributor . Mer information finns i Ansluta till värdlagring med en identitet.

Blobnamnmönster

Du kan ange ett blobnamnmönster i path egenskapen i function.json eller i BlobTrigger attributkonstruktorn. Namnmönstret kan vara ett filter- eller bindningsuttryck. Följande avsnitt tillhandahåller exempel.

Dricks

Ett containernamn får inte innehålla en matchare i namnmönstret.

Hämta filnamn och filnamnstillägg

I följande exempel visas hur du binder till blobfilnamnet och tillägget separat:

"path": "input/{blobname}.{blobextension}",

Om bloben heter original-Blob1.txt är värdena för variablerna och blobextension i funktionskoden original-Blob1 och txt.blobname

Filtrera efter blobnamn

I följande exempel utlöses endast på blobar i containern input som börjar med strängen "original-":

"path": "input/original-{name}",

Om blobnamnet är original-Blob1.txt är Blob1.txtvärdet för variabeln name i funktionskoden .

Filtrera efter filtyp

I följande exempel utlöses endast på .png filer:

"path": "samples/{name}.png",

Filtrera på klammerparenteser i filnamn

Om du vill söka efter klammerparenteser i filnamn kan du undvika klammerparenteserna med hjälp av två klammerparenteser. Följande exempelfilter för blobar som har klammerparenteser i namnet:

"path": "images/{{20140101}}-{name}",

Om blobben heter {20140101}-soundfile.mp3name är variabelvärdet i funktionskoden soundfile.mp3.

Avsökning och svarstid

Avsökning fungerar som en hybrid mellan att inspektera loggar och köra periodiska containergenomsökningar. Blobar genomsöks i grupper om 10 000 åt gången med en fortsättningstoken som används mellan intervallen. Om din funktionsapp finns i förbrukningsplanen kan det uppstå upp till 10 minuters fördröjning i bearbetningen av nya blobar om en funktionsapp har gått inaktiv.

Varning

Lagringsloggar skapas på bästa sätt . Det finns ingen garanti för att alla händelser registreras. Under vissa förhållanden kan loggar missas.

Om du behöver snabbare eller mer tillförlitlig blobbearbetning bör du överväga att byta värd för att använda en App Service-plan med Always On aktiverat, vilket kan leda till ökade kostnader. Du kan också överväga att använda en annan utlösare än den klassiska avsökningsblobutlösaren. Mer information och en jämförelse av de olika utlösande alternativen för bloblagringscontainrar finns i Utlösare för en blobcontainer.

Blobkvitton

Azure Functions-körningen säkerställer att ingen blobutlösarfunktion anropas mer än en gång för samma nya eller uppdaterade blob. För att avgöra om en viss blobversion har bearbetats behåller den blobkvitton.

Azure Functions lagrar blobkvitton i en container med namnet azure-webjobs-hosts i Azure Storage-kontot för funktionsappen (definieras av appinställningen AzureWebJobsStorage). Ett blobkvitto har följande information:

  • Den utlösta funktionen (<FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>till exempel: MyFunctionApp.Functions.CopyBlob)
  • Containernamnet
  • Blobtypen (BlockBlob eller PageBlob)
  • Blobnamnet
  • ETag (en blobversionsidentifierare, till exempel: 0x8D1DC6E70A277EF)

Om du vill tvinga fram ombearbetning av en blob tar du bort blobkvittot för den bloben från containern azure-webjobs-hosts manuellt. Ombearbetning kanske inte sker omedelbart, men det kommer garanterat att ske vid en senare tidpunkt. Om du vill bearbeta om omedelbart kan scaninfo-bloben i azure-webjobs-hosts/blobscaninfo uppdateras. Alla blobar med en senast ändrad tidsstämpel efter att egenskapen LatestScan genomsöks igen.

Giftblobar

När en blobutlösarfunktion misslyckas för en viss blob försöker Azure Functions att fungera totalt fem gånger som standard.

Om alla fem försök misslyckas lägger Azure Functions till ett meddelande i en lagringskö med namnet webjobs-blobtrigger-poison. Det maximala antalet återförsök kan konfigureras. Samma MaxDequeueCount-inställning används för hantering av giftblobar och meddelandehantering av giftköer. Kömeddelandet för giftblobar är ett JSON-objekt som innehåller följande egenskaper:

  • FunctionId (i formatet <FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>)
  • BlobType (BlockBlob eller PageBlob)
  • ContainerName
  • BlobName
  • ETag (en blobversionsidentifierare, till exempel: 0x8D1DC6E70A277EF)

Minnesanvändning och samtidighet

När du binder till en utdatatyp som inte stöder strömning, till exempel string, eller Byte[], måste körningen läsa in hela bloben i minnet mer än en gång under bearbetningen. Detta kan resultera i högre minnesanvändning än förväntat vid bearbetning av blobar. Använd när det är möjligt en typ som stöder ström. Typstöd beror på C#-läge och tilläggsversion. Mer information finns i Bindningstyper.

För närvarande måste körningen läsa in hela bloben i minnet mer än en gång under bearbetningen. Detta kan resultera i högre minnesanvändning än förväntat vid bearbetning av blobar.

Minnesanvändning kan påverkas ytterligare när flera funktionsinstanser bearbetar blobdata samtidigt. Om du har minnesproblem med en Blob-utlösare kan du minska antalet samtidiga körningar som tillåts. Att minska samtidigheten kan naturligtvis ha sidoeffekten att öka kvarvarande blobar som väntar på att bearbetas. Minnesgränserna för funktionsappen beror på planen. Mer information finns i Tjänstbegränsningar.

Hur du kan styra antalet samtidiga körningar beror på vilken version av lagringstillägget du använder.

När du använder version 5.0.0 av lagringstillägget eller en senare version kontrollerar du samtidighet för utlösare med hjälp maxDegreeOfParallelism av inställningen i blobkonfigurationen i host.json.

Gränserna gäller separat för varje funktion som använder en blobutlösare.

host.json egenskaper

Filen host.json innehåller inställningar som styr beteendet för blobutlösare. Mer information om tillgängliga inställningar finns i avsnittet host.json inställningar .

Nästa steg