Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Обработка ошибок в Azure Functions помогает избежать потери данных, избегать пропущенных событий и отслеживать работоспособность приложения. Это также важный способ помочь вам понять, как работают повторные попытки для триггеров на основе событий.
В этой статье описываются общие стратегии обработки ошибок и доступные стратегии повтора.
Внимание
Предварительная версия поддержки политики повторных попыток для определенных триггеров была удалена в декабре 2022 года. Политики повторных попыток для поддерживаемых триггеров теперь находятся в общедоступной версии. В разделе повторных попыток этой статьи перечислены расширения, которые в настоящее время поддерживают политики повторных попыток.
Обработка ошибок
Ошибки, возникающие в функции Azure, могут возникать из:
- Использование встроенных функций Azure триггеров и привязок.
- Вызовы API базовых служб Azure.
- Вызовы конечных точек REST.
- Вызовы клиентских библиотек, пакетов или интерфейсов API, отличных от Майкрософт.
Чтобы избежать потери данных или пропущенных сообщений, следует использовать хорошую обработку ошибок. В этой таблице описаны некоторые рекомендуемые методики обработки ошибок и ссылки на дополнительные сведения:
| Рекомендация | Сведения |
|---|---|
| Включить Application Insights | Azure Functions интегрируется с Application Insights для сбора данных об ошибках, данных производительности и журналов среды выполнения. Используйте Application Insights для обнаружения и улучшения понимания ошибок, возникающих в выполнении функций. Дополнительные сведения см. в статье Monitor executions in Azure Functions. |
| Использование структурированной обработки ошибок | Записывать и вносить в журнал ошибки крайне важно для мониторинга работоспособности приложения. Самый верхний уровень любого кода функции должен включать блок try/catch. В блоке catch можно записывать и вносить в журнал ошибки. Сведения о том, какие ошибки могут вызывать привязки, см. в разделе "Коды ошибок привязки " в этой статье. В зависимости от конкретной стратегии повторных попыток можно также вызвать новое исключение для повторного запуска функции. |
| Планирование стратегии повторных попыток | Несколько расширений привязки в Azure Functions обеспечивают встроенную поддержку повторных попыток. Другие позволяют определять политики повторных попыток, которые реализует среда выполнения Azure Functions. Для триггеров, которые не поддерживают функцию повторных попыток, рассмотрите возможность реализации собственной схемы повтора. Дополнительные сведения см. в разделе Повторные попытки в этой статье. |
| Проектирование с учетом идемпотентности | Возникновение ошибок при обработке данных может быть проблемой для ваших функций, особенно при обработке сообщений. Важно учитывать, что происходит при возникновении ошибки и как избежать дублирования обработки. Дополнительные сведения см. в разделе Designing Azure Functions для идентичных входных данных. |
Совет
При использовании выходных привязок невозможно обрабатывать ошибки, возникающие при доступе к удаленной службе. Из-за этого следует проверить все данные, передаваемые в выходные привязки, чтобы избежать возникновения известных исключений. Если вы должны иметь возможность обрабатывать такие исключения в коде функции, вы должны получить доступ к удаленной службе с помощью клиентского пакета SDK вместо того, чтобы полагаться на выходные привязки.
Повторные попытки
Для функций доступны два типа повторных попыток:
- Встроенное поведение повторных попыток отдельных расширений триггеров
- Политики повторных попыток, которые предоставляет среда выполнения Azure Functions
В следующей таблице показано, какие триггеры поддерживают повторы и где настраивается поведение для повтора. Он также ссылается на дополнительные сведения об ошибках, поступающих из базовых служб.
| Триггер/привязка | Источник повтора | Настройка |
|---|---|---|
| Azure Cosmos DB | Политики повторных попыток | функциональный уровень |
| Azure Blob Storage | Расширение привязки | host.json |
| Azure Event Grid | Расширение привязки | Подписка на события |
| Azure Event Hubs | Политики повторных попыток | функциональный уровень |
| Кафка | Политики повторных попыток | функциональный уровень |
| Хранилище очередей Azure (Azure Queue Storage) | Расширение привязки | host.json |
| RabbitMQ | Расширение привязки | Очередь недоставленных писем |
| Azure Service Bus | Расширение привязки | host.json* |
| Таймер | Политики повторных попыток | функциональный уровень |
* Требуется версия 5.x расширения Azure Service Bus. В более ранних версиях расширения Service Bus очередь недоставленных писем реализует поведение повторных попыток.
Политики повторных попыток
С помощью Azure Functions можно определить политики повторных попыток для определенных типов триггеров. Среда выполнения применяет эти политики повторных попыток. Следующие типы триггеров в настоящее время поддерживают политики повторных попыток:
Поддержка повторных попыток одинакова для моделей программирования версии 1 и 2 Python.
Политики повторных попыток не поддерживаются в версии 1.x среды выполнения Azure Functions.
Политика повтора сообщает среде выполнения о том, что при неудачном выполнении нужно повторять попытку, пока не получится добиться успеха или пока не будет достигнуто максимальное число повторов.
Политика повторных попыток оценивается, когда функция, вызванная поддерживаемым типом триггера, выбрасывает необработанное исключение. Рекомендуется перехватывать и обрабатывать все исключения в коде и вызывать новые исключения для любых ошибок, при которых требуется повторная попытка.
Внимание
Контрольные точки Центров событий записываются только после завершения выполнения политики повторов. Из-за этого ход выполнения определенного раздела приостановлен, пока текущий пакет не будет обработан. Дополнительные сведения см. в разделе Reliable event processing with Azure Functions and Event Hubs.
Версия 5.x расширения Центров событий поддерживает дополнительные возможности повторных попыток для взаимодействия между узлом Azure Functions и концентратором событий. Дополнительные сведения см. в clientRetryOptions.
Стратегия повторов
Вы можете настроить две стратегии повторных попыток, поддерживаемые политикой:
Между повторами должно пройти указанное время.
При использовании плана потребления плата взимается только за время выполнения кода функции. Плата за время ожидания между выполнениями в этих стратегиях повторных попыток не взимается.
Максимальное число повторных попыток
Можно настроить максимальное количество попыток выполнения функции до конечного сбоя. Текущее число повторных попыток хранится в памяти экземпляра.
Для экземпляра может возникнуть сбой между повторными попытками. При сбое экземпляра во время применения политики повтора число повторных попыток обнуляется. При возникновении сбоев экземпляров триггер Центров событий может возобновить обработку и выполнить пакет повторно на новом экземпляре, со сбросом счетчика повторных попыток до нуля. Триггер таймера не возобновляется в новом экземпляре.
Это поведение означает, что максимальное количество повторных попыток — это ориентировочное значение. В некоторых редких случаях выполнение может быть повторено более раз, чем это позволяет установленный максимум. Для триггеров таймера повторные попытки могут быть меньше запрошенного максимального числа.
Примеры повторов
Примеры приведены как для стратегий фиксированной задержки, так и для экспоненциальных стратегий обратной передачи. Чтобы просмотреть примеры конкретной стратегии, сначала необходимо выбрать эту стратегию на предыдущей вкладке.
Повторные попытки на уровне функций поддерживаются со следующими пакетами NuGet:
- Microsoft. Azure. Functions.Worker.Sdk версии 1.9.0 и более поздних версий
- Microsoft. Azure. Functions.Worker.Extensions.EventHubs версии 5.2.0 и более поздних версий
- Microsoft. Azure. Functions.Worker.Extensions.Kafka версии 3.8.0 и более поздних версий
- Microsoft.Azure.Functions.Worker.Extensions.Timer версии 4.2.0 и выше
[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));
logger.LogInformation($"Function Ran. Next timer schedule = {timerInfo.ScheduleStatus?.Next}");
}
| Свойство | Описание |
|---|---|
MaxRetryCount |
Обязательный. Максимальное количество повторных попыток для каждой функции. Значение -1 указывает на неограниченное число повторных попыток. |
DelayInterval |
Задержка, используемая между повторными попытками. Укажите его в виде строки с форматом HH:mm:ss. |
Ниже приведён пример политики повторных попыток, определённой в файле
{
"disabled": false,
"bindings": [
{
....
}
],
"retry": {
"strategy": "fixedDelay",
"maxRetryCount": 4,
"delayInterval": "00:00:10"
}
}
Эти свойства можно задать для определений политик повторных попыток:
| Свойство | Описание |
|---|---|
strategy |
Обязательный. Используемая стратегия повторных попыток. Допустимые значения — fixedDelay и exponentialBackoff. |
maxRetryCount |
Обязательный. Максимальное количество повторных попыток для каждой функции. Значение -1 указывает на неограниченное число повторных попыток. |
delayInterval |
Задержка, используемая между повторными попытками при использовании fixedDelay стратегии. Укажите его в виде строки с форматом HH:mm:ss. |
minimumInterval |
Минимальная задержка повторных попыток при использовании стратегии exponentialBackoff. Укажите его в виде строки с форматом HH:mm:ss. |
maximumInterval |
Максимальная задержка повторных попыток при использовании exponentialBackoff стратегии. Укажите его в виде строки с форматом HH:mm:ss. |
Способ определения политики повторных попыток для триггера зависит от версии Node.js:
Ниже приведен пример функции триггера таймера, которая использует стратегию повторных попыток с фиксированной задержкой:
const { app } = require('@azure/functions');
app.timer('timerTriggerWithRetry', {
schedule: '0 */5 * * * *',
retry: {
strategy: 'fixedDelay',
delayInterval: {
seconds: 10,
},
maxRetryCount: 4,
},
handler: (myTimer, context) => {
if (context.retryContext?.retryCount < 2) {
throw new Error('Retry!');
} else {
context.log('Timer function processed request.');
}
},
});
Способ определения политики повторных попыток для триггера зависит от версии Node.js:
Ниже приведен пример функции триггера таймера, которая использует стратегию повторных попыток с фиксированной задержкой:
import { app, InvocationContext, Timer } from '@azure/functions';
export async function timerTriggerWithRetry(myTimer: Timer, context: InvocationContext): Promise<void> {
if (context.retryContext?.retryCount < 2) {
throw new Error('Retry!');
} else {
context.log('Timer function processed request.');
}
}
app.timer('timerTriggerWithRetry', {
schedule: '0 */5 * * * *',
retry: {
strategy: 'fixedDelay',
delayInterval: {
seconds: 10,
},
maxRetryCount: 4,
},
handler: timerTriggerWithRetry,
});
Эти свойства можно задать для определений политик повторных попыток:
| Свойство | Описание |
|---|---|
strategy |
Обязательный. Используемая стратегия повторных попыток. Допустимые значения — fixedDelay и exponentialBackoff. |
maxRetryCount |
Обязательный. Максимальное количество повторных попыток для каждой функции. Значение -1 указывает на неограниченное число повторных попыток. |
delayInterval |
Задержка, используемая между повторными попытками при использовании fixedDelay стратегии. Укажите его в виде строки с форматом HH:mm:ss. |
minimumInterval |
Минимальная задержка повторных попыток при использовании стратегии exponentialBackoff. Укажите его в виде строки с форматом HH:mm:ss. |
maximumInterval |
Максимальная задержка повторных попыток при использовании exponentialBackoff стратегии. Укажите его в виде строки с форматом HH:mm:ss. |
- модель Python v2
- модель Python версия 1
Ниже приведен пример функции триггера таймера, которая использует стратегию повторных попыток с фиксированной задержкой:
import logging
from azure.functions import AuthLevel, Context, FunctionApp, TimerRequest
app = FunctionApp(http_auth_level=AuthLevel.ANONYMOUS)
@app.timer_trigger(schedule="*/1 * * * * *", arg_name="mytimer",
run_on_startup=False,
use_monitor=False)
@app.retry(strategy="fixed_delay", max_retry_count="3",
delay_interval="00:00:01")
def mytimer(mytimer: TimerRequest, context: Context) -> None:
logging.info(f'Current retry count: {context.retry_context.retry_count}')
if context.retry_context.retry_count == \
context.retry_context.max_retry_count:
logging.info(
f"Max retries of {context.retry_context.max_retry_count} for "
f"function {context.function_name} has been reached")
else:
raise Exception("This is a retryable exception")
Эти свойства можно задать для определений политик повторных попыток:
- модель Python v2
- модель Python версия 1
| Свойство | Описание |
|---|---|
strategy |
Обязательный. Используемая стратегия повторных попыток. Допустимые значения — fixed_delay и exponential_backoff. |
max_retry_count |
Обязательный. Максимальное количество повторных попыток для каждой функции. Значение -1 указывает на неограниченное число повторных попыток. |
delay_interval |
Задержка, используемая между повторными попытками при использовании fixed_delay стратегии. Укажите его в виде строки с форматом HH:mm:ss. |
minimum_interval |
Минимальная задержка повторных попыток при использовании стратегии exponential_backoff. Укажите его в виде строки с форматом HH:mm:ss. |
maximum_interval |
Максимальная задержка повторных попыток при использовании exponential_backoff стратегии. Укажите его в виде строки с форматом HH:mm:ss. |
@FunctionName("TimerTriggerJava1")
@FixedDelayRetry(maxRetryCount = 4, delayInterval = "00:00:10")
public void run(
@TimerTrigger(name = "timerInfo", schedule = "0 */5 * * * *") String timerInfo,
final ExecutionContext context
) {
context.getLogger().info("Java Timer trigger function executed at: " + LocalDateTime.now());
}
Коды ошибок привязки
При интеграции с службами Azure ошибки могут возникать из API базовых служб. Сведения, связанные с ошибками, связанными с привязкой, доступны в разделах "Исключения и коды возврата" в следующих статьях:
- Azure Cosmos DB
- Хранилище BLOB-объектов
- Сетка событий
- Центры событий
- Центр IoT
- Центры уведомлений
- Хранилище очередей
- Служебная шина
- Хранилище таблиц
Связанный контент
- Azure Functions триггеры и привязки
- Лучшие практики для надежных Azure функций