Trigger mit Timer für Azure Functions
Dieser Artikel erläutert das Arbeiten mit Triggern mit Timer in Azure Functions. Mit einem Trigger mit Timer können Sie eine Funktion nach einem Zeitplan ausführen.
Dies sind Referenzinformationen für Azure Functions-Entwickler. Falls Sie mit Azure Functions noch nicht vertraut sind, beginnen Sie mit den folgenden Ressourcen:
Referenzen für C#-Entwickler:
Informationen zum manuellen Ausführen einer per Timer ausgelösten Funktion finden Sie unter Manuelles Ausführen einer Funktion ohne HTTP-Trigger.
Unterstützung für diese Bindung wird automatisch in allen Entwicklungsumgebungen bereitgestellt. Sie müssen das Paket nicht manuell installieren oder die Erweiterung registrieren.
Den Quellcode für das Zeitgebererweiterungspaket finden Sie im GitHub-Repository azure-webjobs-sdk-extensions.
Wichtig
In diesem Artikel werden Registerkarten verwendet, um mehrere Versionen des Node.js-Programmiermodells zu unterstützen. Das v4-Modell ist allgemein verfügbar und bietet JavaScript- und TypeScript-Entwicklern eine flexiblere und intuitivere Erfahrung. Weitere Informationen zur Funktionsweise des v4-Modells finden Sie im Azure Functions Node.js-Entwicklerhandbuch. Weitere Informationen zu den Unterschieden zwischen v3 und v4 finden Sie im Migrationshandbuch.
Azure Functions unterstützt zwei Programmiermodelle für Python. Wie Sie Ihre Bindung definieren, hängt vom gewählten Python-Programmiermodell ab.
Mit dem Python v2-Programmiermodell können Sie Bindungen mithilfe von Decorators direkt im Python-Funktionscode definieren. Weitere Informationen finden Sie im Python Developer-Leitfaden.
In diesem Artikel werden beide Programmiermodelle unterstützt.
Beispiel
Dieses Beispiel zeigt eine C#-Funktion, die jedes Mal ausgeführt wird, wenn der Minutenwert durch fünf teilbar ist. Wenn die Funktion also beispielsweise um 18:55:00 Uhr beginnt, wird sie das nächste Mal um 19:00:00 Uhr ausgeführt. An die Funktion wird ein Objekt vom Typ TimerInfo
übergeben.
Eine C#-Funktion kann mit einem der folgenden C#-Modi erstellt werden:
- Isoliertes Workermodell: Kompilierte C#-Funktion, die in einem Workerprozess ausgeführt wird, der von der Runtime isoliert ist. Ein isolierter Workerprozess ist erforderlich, um C#-Funktionen zu unterstützen, die in LTS- und Nicht-LTS-Versionen von .NET und .NET Framework ausgeführt werden. Erweiterungen für isolierte Workerprozessfunktionen verwenden
Microsoft.Azure.Functions.Worker.Extensions.*
-Namespaces. - In-Process-Modell: Kompilierte C#-Funktion, die im gleichen Prozess wie die Functions-Runtime ausgeführt wird. In einer Variante dieses Modells kann Functions mithilfe von C#-Skripts ausgeführt werden. Dies wird hauptsächlich für die Bearbeitung im C#-Portal unterstützt. Erweiterungen für In-Process-Funktionen verwenden
Microsoft.Azure.WebJobs.Extensions.*
-Namespaces.
Wichtig
Die Unterstützung für das In-Process-Modell endet am 10. November 2026. Es wird dringend empfohlen, Ihre Apps zum isolierten Workermodell zu migrieren, um den vollständigen Support zu ermöglichen.
//<docsnippet_fixed_delay_retry_example>
[Function(nameof(TimerFunction))]
[FixedDelayRetry(5, "00:00:10")]
public static void Run([TimerTrigger("0 */5 * * * *")] TimerInfo timerInfo,
FunctionContext context)
{
var logger = context.GetLogger(nameof(TimerFunction));
Die folgende Beispielfunktion wird ausgelöst und alle fünf Minuten ausgeführt. Die @TimerTrigger
-Anmerkung für die Funktion definiert den Zeitplan mit dem gleichen Zeichenfolgeformat wie @TimerTrigger
.
@FunctionName("keepAlive")
public void keepAlive(
@TimerTrigger(name = "keepAliveTrigger", schedule = "0 */5 * * * *") String timerInfo,
ExecutionContext context
) {
// timeInfo is a JSON string, you can deserialize it to an object using your favorite JSON library
context.getLogger().info("Timer is triggered: " + timerInfo);
}
Das folgende Beispiel zeigt eine Timer-Trigger-Bindung und Funktionscode, der die Bindung verwendet, wobei eine Instanz, die den Timer darstellt, an die Funktion übergeben wird. Die Funktion schreibt ein Protokoll, das angibt, ob dieser Funktionsaufruf aufgrund eines versäumten Zeitplantermins erfolgt. Das Beispiel hängt davon ab, ob Sie das Python-Programmiermodell v1 oder v2 verwenden.
import datetime
import logging
import azure.functions as func
app = func.FunctionApp()
@app.function_name(name="mytimer")
@app.timer_trigger(schedule="0 */5 * * * *",
arg_name="mytimer",
run_on_startup=True)
def test_function(mytimer: func.TimerRequest) -> None:
utc_timestamp = datetime.datetime.utcnow().replace(
tzinfo=datetime.timezone.utc).isoformat()
if mytimer.past_due:
logging.info('The timer is past due!')
logging.info('Python timer trigger function ran at %s', utc_timestamp)
Das folgende Beispiel zeigt eine TypeScript-Funktion des Timertriggers.
import { app, InvocationContext, Timer } from '@azure/functions';
export async function timerTrigger1(myTimer: Timer, context: InvocationContext): Promise<void> {
context.log('Timer function processed request.');
}
app.timer('timerTrigger1', {
schedule: '0 */5 * * * *',
handler: timerTrigger1,
});
Das folgende Beispiel zeigt eine JavaScript-Funktion des Timertriggers.
Bindungsdaten in der Datei function.json:
{
"schedule": "0 */5 * * * *",
"name": "myTimer",
"type": "timerTrigger",
"direction": "in"
}
Hier sehen Sie den Zeitgeberfunktionscode in der Datei „run.ps1“:
# Input bindings are passed in via param block.
param($myTimer)
# Get the current universal time in the default string format.
$currentUTCtime = (Get-Date).ToUniversalTime()
# The 'IsPastDue' property is 'true' when the current function invocation is later than scheduled.
if ($myTimer.IsPastDue) {
Write-Host "PowerShell timer is running late!"
}
# Write an information log with the current time.
Write-Host "PowerShell timer trigger function ran! TIME: $currentUTCtime"
Attribute
In-Process-C#-Bibliothek verwendet TimerTriggerAttribute aus Microsoft.Azure.WebJobs.Extensions, während die C#-Bibliothek vom Typ Isolierter WorkerprozessTimerTriggerAttribute aus Microsoft.Azure.Functions.Worker.Extensions.Timer verwendet, um die Funktion zu definieren. Vom C#-Skript wird stattdessen die Konfigurationsdatei function.json verwendet.
Attributeigenschaft | BESCHREIBUNG |
---|---|
Zeitplan | Ein CRON-Ausdruck oder ein TimeSpan-Wert. TimeSpan kann nur für eine Funktionen-App verwendet werden, die in einem App Service-Plan ausgeführt wird. Sie können den Zeitplanausdruck in eine App-Einstellung einfügen und diese Eigenschaft auf den Namen der App-Einstellung festlegen – eingeschlossen in Prozentzeichen (%): %ScheduleAppSetting% . |
RunOnStartup | Wenn true , wird die Funktion beim Starten der Laufzeit aufgerufen. Die Laufzeit startet beispielsweise, wenn die Funktionen-App nach dem Leerlauf aufgrund von Inaktivität reaktiviert wird, wenn die Funktions-App aufgrund von Funktionsänderungen neu gestartet wird und wenn die Funktions-App verkleinern wird. Verwenden Sie vorsichtig. RunOnStartup sollte selten , insbesondere in der Produktion, festgelegt true werden. |
UseMonitor | Legen Sie diese Eigenschaft auf true oder false fest, um anzugeben, ob der Zeitplan überwacht werden soll. Durch die Überwachung des Zeitplans werden Zeitplantermine beibehalten, mit deren Hilfe sichergestellt werden kann, dass der Zeitplan richtig eingehalten wird, selbst wenn Instanzen der Funktionen-App neu gestartet werden. Wenn diese Eigenschaft nicht explizit festgelegt wird, lautet der Standardwert true für Zeitpläne mit einem Wiederholungsintervall von mehr als oder gleich einer Minute. Bei Zeitplänen, die mehr als einmal pro Minute ausgelöst werden, lautet der Standardwert false . |
Decorator-Elemente
Gilt nur für das Python v2-Programmiermodell.
Für Python v2-Funktionen, die mithilfe eines Decorators definiert wurden, gelten die folgenden Eigenschaften für schedule
:
Eigenschaft | BESCHREIBUNG |
---|---|
arg_name |
Der Name der Variablen, die das Timerobjekt im Funktionscode darstellt. |
schedule |
Ein NCRONTAB-Ausdruck oder ein TimeSpan-Wert. TimeSpan kann nur für eine Funktionen-App verwendet werden, die in einem App Service-Plan ausgeführt wird. Sie können den Zeitplanausdruck in eine App-Einstellung einfügen und diese Eigenschaft auf den Namen der App-Einstellung festlegen, der wie in diesem Beispiel % -Zeichen als Wrapper verwendet: „%ScheduleAppSetting%“. |
run_on_startup |
Wenn true , wird die Funktion beim Starten der Laufzeit aufgerufen. Die Laufzeit startet beispielsweise, wenn die Funktionen-App nach dem Leerlauf aufgrund von Inaktivität reaktiviert wird, wenn die Funktionen-App aufgrund von Funktionsänderungen neu gestartet wird und wenn die Funktionen-App horizontal hochskaliert wird. Vorsichtig verwenden. runOnStartup sollte insbesondere in der Produktionsumgebung selten, wenn überhaupt, auf true festgelegt werden. |
use_monitor |
Legen Sie diese Eigenschaft auf true oder false fest, um anzugeben, ob der Zeitplan überwacht werden soll. Durch die Überwachung des Zeitplans werden Zeitplantermine beibehalten, mit deren Hilfe sichergestellt werden kann, dass der Zeitplan richtig eingehalten wird, selbst wenn Instanzen der Funktionen-App neu gestartet werden. Wenn diese Eigenschaft nicht explizit festgelegt wird, lautet der Standardwert true für Zeitpläne mit einem Wiederholungsintervall von mehr als oder gleich einer Minute. Bei Zeitplänen, die mehr als einmal pro Minute ausgelöst werden, lautet der Standardwert false . |
Informationen zu Python-Funktionen, die mithilfe von function.json definiert wurden, finden Sie im Abschnitt Konfiguration.
Anmerkungen
Die Anmerkung @TimerTrigger
für die Funktion definiert den Zeitplan (schedule
) mit dem gleichen Zeichenfolgeformat wie CRON-Ausdrücke. Die Anmerkung unterstützt die folgenden Einstellungen:
Konfiguration
Gilt nur für das Python v1-Programmiermodell.
In der folgenden Tabelle werden die Eigenschaften erläutert, die Sie für das options
-Objekt festlegen können, das an die app.timer()
-Methode übergeben wurde.
Eigenschaft | Beschreibung |
---|---|
schedule | Ein NCRONTAB-Ausdruck oder ein TimeSpan-Wert. TimeSpan kann nur für eine Funktionen-App verwendet werden, die in einem App Service-Plan ausgeführt wird. Sie können den Zeitplanausdruck in eine App-Einstellung einfügen und diese Eigenschaft auf den Namen der App-Einstellung festlegen, der wie in diesem Beispiel % -Zeichen als Wrapper verwendet: „%ScheduleAppSetting%“. |
runOnStartup | Wenn true , wird die Funktion beim Starten der Laufzeit aufgerufen. Die Laufzeit startet beispielsweise, wenn die Funktionen-App nach dem Leerlauf aufgrund von Inaktivität reaktiviert wird, wenn die Funktionen-App aufgrund von Funktionsänderungen neu gestartet wird und wenn die Funktionen-App horizontal hochskaliert wird. Vorsichtig verwenden. runOnStartup sollte insbesondere in der Produktionsumgebung selten, wenn überhaupt, auf true festgelegt werden. |
useMonitor | Legen Sie diese Eigenschaft auf true oder false fest, um anzugeben, ob der Zeitplan überwacht werden soll. Durch die Überwachung des Zeitplans werden Zeitplantermine beibehalten, mit deren Hilfe sichergestellt werden kann, dass der Zeitplan richtig eingehalten wird, selbst wenn Instanzen der Funktionen-App neu gestartet werden. Wenn diese Eigenschaft nicht explizit festgelegt wird, lautet der Standardwert true für Zeitpläne mit einem Wiederholungsintervall von mehr als oder gleich einer Minute. Bei Zeitplänen, die mehr als einmal pro Minute ausgelöst werden, lautet der Standardwert false . |
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.
function.json-Eigenschaft | BESCHREIBUNG |
---|---|
type | Muss auf „timerTrigger“ festgelegt werden. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
direction | Muss auf „in“ festgelegt werden. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
name | Der Name der Variablen, die das Timerobjekt im Funktionscode darstellt. |
schedule | Ein NCRONTAB-Ausdruck oder ein TimeSpan-Wert. TimeSpan kann nur für eine Funktionen-App verwendet werden, die in einem App Service-Plan ausgeführt wird. Sie können den Zeitplanausdruck in eine App-Einstellung einfügen und diese Eigenschaft auf den Namen der App-Einstellung festlegen, der wie in diesem Beispiel % -Zeichen als Wrapper verwendet: „%ScheduleAppSetting%“. |
runOnStartup | Wenn true , wird die Funktion beim Starten der Laufzeit aufgerufen. Die Laufzeit startet beispielsweise, wenn die Funktionen-App nach dem Leerlauf aufgrund von Inaktivität reaktiviert wird, wenn die Funktionen-App aufgrund von Funktionsänderungen neu gestartet wird und wenn die Funktionen-App horizontal hochskaliert wird. Vorsichtig verwenden. runOnStartup sollte insbesondere in der Produktionsumgebung selten, wenn überhaupt, auf true festgelegt werden. |
useMonitor | Legen Sie diese Eigenschaft auf true oder false fest, um anzugeben, ob der Zeitplan überwacht werden soll. Durch die Überwachung des Zeitplans werden Zeitplantermine beibehalten, mit deren Hilfe sichergestellt werden kann, dass der Zeitplan richtig eingehalten wird, selbst wenn Instanzen der Funktionen-App neu gestartet werden. Wenn diese Eigenschaft nicht explizit festgelegt wird, lautet der Standardwert true für Zeitpläne mit einem Wiederholungsintervall von mehr als oder gleich einer Minute. Bei Zeitplänen, die mehr als einmal pro Minute ausgelöst werden, lautet der Standardwert false . |
Wenn Sie die Entwicklung lokal ausführen, fügen Sie Ihre Anwendungseinstellungen in der Datei local.settings.json in der Values
-Sammlung hinzu.
Achtung
Legen Sie runOnStartup in der Produktion nicht auf true
fest. Bei Verwendung dieser Einstellung wird der Code zu schwer vorhersehbaren Zeiten ausgeführt. In bestimmten Produktionsumgebungen können diese zusätzlichen Ausführungen zu deutlich höheren Kosten für Anwendungen führen, die in einem Verbrauchsplan gehostet werden. So wird z. B. der Trigger immer dann mit aktiviertem runOnStartup aufgerufen, wenn Ihre Funktions-App skaliert wird. Stellen Sie sicher, dass Sie das Produktionsverhalten Ihrer Funktionen vollständig verstehen, bevor Sie runOnStartup in der Produktionsumgebung aktivieren.
Vollständige Beispiele finden Sie im Abschnitt „Beispiele“.
Verwendung
Bei Aufruf einer Trigger-mit-Timer-Funktion wird ein Timerobjekt an die Funktion übergeben. Der folgende JSON-Code ist eine Beispieldarstellung des Timerobjekts.
{
"Schedule":{
"AdjustForDST": true
},
"ScheduleStatus": {
"Last":"2016-10-04T10:15:00+00:00",
"LastUpdated":"2016-10-04T10:16:00+00:00",
"Next":"2016-10-04T10:20:00+00:00"
},
"IsPastDue":false
}
{
"schedule":{
"adjustForDST": true
},
"scheduleStatus": {
"last":"2016-10-04T10:15:00+00:00",
"lastUpdated":"2016-10-04T10:16:00+00:00",
"next":"2016-10-04T10:20:00+00:00"
},
"isPastDue":false
}
Die Eigenschaft isPastDue
lautet true
, wenn der aktuelle Funktionsaufruf später als geplant erfolgt. Beispielsweise kann ein Neustart der Funktionen-App dazu führen, dass ein Aufruf nicht erkannt wird.
NCRONTAB-Ausdrücke
Azure Functions verwendet die Bibliothek NCronTab, um NCRONTAB-Ausdrücke zu interpretieren. Ein NCRONTAB-Ausdruck ähnelt einem CRON-Ausdruck, enthält jedoch am Anfang ein zusätzliches sechstes Feld für sekundengenaue Zeitangaben:
{second} {minute} {hour} {day} {month} {day-of-week}
Jedes Feld kann einen der folgenden Werttypen aufweisen:
type | Beispiel | Auslösung |
---|---|---|
Ein bestimmter Wert | 0 5 * * * * |
Ein Mal pro Stunde am Tag bei Minute 5 jeder Stunde |
Alle Werte (* ) |
0 * 5 * * * |
Jede Minute der Stunde, für 5 Stunden |
Ein Bereich (- -Operator) |
5-7 * * * * * |
Drei Mal pro Minute, bei den Sekunden 5 bis 7 pro Minute pro Stunde jeden Tag |
Eine Gruppe von Werten (, -Operator) |
5,8,10 * * * * * |
Drei Mal pro Minute, bei den Sekunden 5, 8 und 10 pro Minute pro Stunde jeden Tag |
Ein Intervallwert (/ -Operator) |
0 */5 * * * * |
12 Mal pro Stunde, bei Sekunde 0 jeder 5. Minute jeder Stunde jedes Tages |
Um Monate oder Tage anzugeben, können Sie numerische Werte, Namen oder Abkürzungen von Namen verwenden:
- Bei Tagen reichen die numerischen Werte von 0 bis 6, wobei die 0 für Sonntag steht.
- Die Namen werden auf Englisch angegeben. Beispiel:
Monday
,January
. - Bei Namen wird die Groß-/Kleinschreibung nicht berücksichtigt.
- Namen können abgekürzt werden. Es wird empfohlen, für Abkürzungen drei Buchstaben zu verwenden. Beispiel:
Mon
,Jan
.
NCRONTAB-Beispiele
Die folgenden Beispiele zeigen NCRONTAB-Ausdrücke, die Sie für den Trigger mit Timer in Azure Functions verwenden können:
Beispiel | Auslösung |
---|---|
0 */5 * * * * |
einmal alle fünf Minuten |
0 0 * * * * |
einmal zu jeder vollen Stunde |
0 0 */2 * * * |
einmal alle zwei Stunden |
0 0 9-17 * * * |
zwischen 9:00 und 17:00 Uhr jeweils einmal pro Stunde |
0 30 9 * * * |
täglich um 9:30 Uhr |
0 30 9 * * 1-5 |
werktags um 9:30 Uhr |
0 30 9 * Jan Mon |
jeden Montag im Januar um 9:30 |
Hinweis
Der Ausdruck NCRONTAB unterstützt sowohl das Fünffeld- als auch das Sechsfeldformat. Die sechste Feldposition ist ein Wert für Sekunden, der am Anfang des Ausdrucks platziert wird. Wenn der CRON-Ausdruck ungültig ist, zeigt der Azure Portal Function Test einen Fehler von 404 an, wenn Application Insights verbunden ist, werden dort weitere Details protokolliert.
NCRONTAB-Zeitzonen
Die Zahlen in einem NCRONTAB-Ausdruck beziehen sich auf eine Uhrzeit und ein Datum, nicht auf einen Zeitraum. Beispielsweise bezieht sich eine 5 im Feld hour
auf 5:00 Uhr, nicht auf alle 5 Stunden.
Als Standardzeitzone wird in Verbindung mit den CRON-Ausdrücken die Coordinated Universal Time (UTC) verwendet. Wenn Sie möchten, dass Ihr CRON-Ausdruck auf einer anderen Zeitzone basiert, erstellen Sie eine App-Einstellung für die Funktionen-App mit dem Namen WEBSITE_TIME_ZONE
.
Der Wert dieser Einstellung hängt davon ab, unter welchem Betriebssystem und Plan Ihre Funktions-App ausgeführt wird.
Betriebssystem | Plan | Wert |
---|---|---|
Windows | All | Legen Sie den Wert auf den Namen der gewünschten Zeitzone fest, wie in der zweiten Zeile des vom Windows-Befehl tzutil.exe /L ausgegebenen Wertepaars angegeben. |
Linux | Premium Dediziert |
Legen Sie den Wert auf den Namen der gewünschten Zeitzone fest (gemäß tz-Datenbank). |
Hinweis
WEBSITE_TIME_ZONE
und TZ
werden derzeit nicht unterstützt, wenn sie unter Linux in einem Verbrauchsplan ausgeführt werden. In diesem Fall kann das Festlegen von WEBSITE_TIME_ZONE
oder TZ
SSL-bezogene Probleme verursachen und dazu führen, dass Metriken für Ihre App nicht mehr funktionieren.
Ein Beispiel: Für die Zeitzone „Eastern Time“ in den USA (dargestellt durch Eastern Standard Time
unter Windows oder America/New_York
unter Linux) wird derzeit UTC-05:00 in der Standardzeit und UTC-04:00 in der Sommerzeit verwendet. Damit ein Timertrigger jeden Tag um 10:00 vormittags in der Zeitzone „Eastern Time“ ausgelöst wird, erstellen Sie eine App-Einstellung für Ihre Funktions-App mit dem Namen WEBSITE_TIME_ZONE
, legen den Wert auf Eastern Standard Time
(Windows) bzw. America/New_York
(Linux) fest, und verwenden dann den folgenden NCRONTAB-Ausdruck:
"0 0 10 * * *"
Wenn Sie WEBSITE_TIME_ZONE
verwenden, wird die Uhrzeit an Abweichungen in der jeweiligen Zeitzone angepasst, einschließlich Sommerzeit und Änderungen an der Standardzeit.
TimeSpan
TimeSpan
kann nur für eine Funktionen-App verwendet werden, die in einem App Service-Plan ausgeführt wird.
Im Gegensatz zu einem NCRONTAB-Ausdruck gibt ein TimeSpan
Wert das Zeitintervall zwischen den einzelnen Funktionsaufrufen an. Wenn eine Funktion abgeschlossen wird, nachdem sie länger als über das angegebene Intervall ausgeführt wurde, ruft der Timer die Funktion sofort erneut auf.
Dieser Wert wird als Zeichenfolge ausgedrückt, und das TimeSpan
-Format ist hh:mm:ss
, wenn hh
kleiner ist als 24. Wenn die ersten beiden Ziffern 24 oder höher sind, ist das Format dd:hh:mm
. Im Folgenden finden Sie einige Beispiele:
Beispiel | Auslösung |
---|---|
"01:00:00" | stündlich |
"00:01:00" | minütlich |
25:00:00:00 | Alle 25 Tage |
„1.00:00:00“ | täglich |
Horizontales Skalieren
Wenn eine Funktionen-App auf mehrere Instanzen horizontal hochskaliert wird, wird nur eine einzige Instanz einer per Timer ausgelösten Funktion für alle Instanzen ausgeführt. Es wird nicht erneut ausgelöst, wenn noch ein ausstehender Aufruf ausgeführt wird.
Funktionen-Apps mit gemeinsamer Nutzung von Speicher
Wenn Sie Speicherkonten für Funktions-Apps freigeben, die nicht für App Service bereitgestellt sind, müssen Sie möglicherweise jeder App explizit die Host-ID zuweisen.
Functions-Version | Einstellung |
---|---|
2.x (oder höher) | Umgebungsvariable AzureFunctionsWebHost__hostid |
1.x | id in id |
Sie können den identifizierenden Wert auslassen oder die identifizierende Konfiguration für jede Funktions-App manuell auf einen anderen Wert festlegen.
Der Trigger mit Timer verwendet eine Speichersperre, um sicherzustellen, dass nur eine Timerinstanz vorhanden ist, wenn eine Funktions-App auf mehrere Instanzen horizontal hochskaliert wird. Wenn zwei Funktions-Apps dieselbe identifizierende Konfiguration aufweisen und jede einen Trigger mit Timer verwendet, wird nur ein Timer ausgeführt.
Wiederholungsverhalten
Im Gegensatz zum Warteschlangentrigger führt der Trigger mit Timer nach dem Fehlschlagen einer Funktion keine Wiederholung aus. Wenn eine Funktion fehlerhaft ist, wird sie erst beim nächsten Termin im Zeitplan erneut aufgerufen.
Manuelles Aufrufen eines Triggers mit Timer
Der Trigger mit Timer für Azure Functions bietet einen HTTP-Webhook, der aufgerufen werden kann, um die Funktion manuell auszulösen. Dies kann in den folgenden Szenarios besonders hilfreich sein.
- Testen der Integration
- Slotaustausch im Rahmen einer Feuerprobe oder Aufwärmaktivität
- Anfängliche Bereitstellung einer Funktion zum sofortigen Auffüllen eines Caches oder einer Nachschlagetabelle in einer Datenbank
Details zum manuellen Aufrufen einer mit einem Timer ausgelösten Funktion finden Sie unter Manuelles Ausführen einer Funktion ohne HTTP-Trigger.
Problembehandlung
Informationen zur Behebung bei Problemen mit dem Zeitgebertrigger finden Sie unter Investigating and reporting issues with timer triggered functions not firing (Untersuchen und Melden von Problemen beim Auslösen zeitgesteuerter Triggerfunktionen).
Verbindungen
Timertrigger verfügen über eine implizite Abhängigkeit vom BLOB-Speicher, außer wenn sie lokal über die Azure Functions Core Tools ausgeführt werden. Das System verwendet BLOB-Speicher, um mehrere Instanzen zu koordinieren, wenn die App skaliert wird. Er greift mithilfe der Hostspeicherverbindung (AzureWebJobsStorage
) auf BLOB-Speicher zu. Wenn Sie den Hostspeicher für die Verwendung einer identitätsbasierten Verbindung konfigurieren, sollte die Identität über die Rolle "Besitzer von Speicher-BLOB-Daten" verfügen. Dies ist die Standardanforderung für den Hostspeicher.