Необъяснимые транзакции хранилища из функций Azure

У меня есть проект с парой функций Azure на основе .NET Core, работающих по расписанию. Один из них запускается каждые 10 минут и служит для обновления количества просмотров, аналогично тому, как SO отслеживает просмотры вопросов, а другой отправляет электронные письма раз в неделю. Эти функции работали нормально около года. Недавно я обновил их для использования Azure Functions SDK v3 и среды выполнения Azure Functions v3, а также .NET Core 3.1 (в основном перешел с .NET Core 2.1 на .NET Core 3.1, поэтому мне нужно было обновить среду выполнения функций).

В какой-то момент я получил счет намного выше, чем обычно. Оказывается, функции, которые используют одну и ту же базовую учетную запись хранилища, начали делать МНОГО транзакций API в хранилище. Как и многие тысячи каждые 5 минут. Обычно каждый запуск генерирует около 100 транзакций хранения (возможно, получение файлов функций?), Но в какой-то момент транзакции резко подскочили. После перезапуска функций транзакция возвращается в нормальное состояние, и в течение нескольких дней все работает нормально, затем они снова скачут и остаются на высоком уровне до перезапуска.

Код функций не был изменен с обновлением только SDK и среды выполнения. Код функции имеет постоянное количество записей в журнал (например, 7) через регистратор, предоставляемый SDK, и никаким другим образом не взаимодействует с хранилищем.

У меня есть две идентичные среды: одна для тестирования, а другая - для производства, и обе имеют одну и ту же проблему. Интервал, который требуется для того, чтобы функция сработала, составляет пару дней, но каждый раз кажется, что она разная. Однако, если я перезапускаю и тестирование, и производство одновременно, следующий всплеск произойдет одновременно в обеих средах, так что там есть что-то детерминированное.

Согласно моему исследованию с помощью инструмента Metrics, типами транзакций-нарушителей являются Create, Close и ChangeNotify с некоторыми отменами (но реже, чем другие). Хранилище не используется ни для чего другого (на самом деле оно существует только потому, что Функциям Azure требуется резервное хранилище для хранения файлов или чего-то еще).

Вот код триггера, если он актуален

[FunctionName("ViewCountUpdater")]
public static async Task RunAsync([TimerTrigger("0 */10 * * * *"/*, RunOnStartup = true*/)]TimerInfo timer, ILogger log, ExecutionContext context)

Я считаю, что обнаружил ошибку в среде выполнения функций Azure или в пакете SDK .NET Core для функций Azure. Кто-нибудь испытал это или знает, как это обойти?


person Stilgar    schedule 07.02.2020    source источник
comment
вы открыли кейс для обращений в службу поддержки Azure? Они должны быть в состоянии расследовать, и, если это была ошибка, вернуть вам деньги   -  person Thiago Custodio    schedule 07.02.2020
comment
да. Я был в цепочке писем с поддержкой Azure уже несколько недель, но безрезультатно. По крайней мере, два человека изучили проблему и отправили ее другим людям после подтверждения того, что проблема возникает. Судя по электронным письмам, моя проблема теперь передана в группу продуктов, но в цепочке писем нет нового человека. Я подумываю открыть проблему в пакете SDK для функций Azure на GitHub, но сначала решил попробовать SO.   -  person Stilgar    schedule 07.02.2020
comment
Окончательно похоже на ошибку. Отправьте твит со ссылкой на этот вопрос @ AzureSupport и @ jeffhollan, главному руководителю PM по функциям Microsoft Azure   -  person CSharpRocks    schedule 07.02.2020
comment
@CSharpRocks Я дам ему еще несколько дней, я не хочу пропустить людей из службы поддержки Azure, они были очень милы и, кажется, стараются изо всех сил. Также я считаю, что есть примерно 10% вероятность того, что я что-то сделал не так. Основная причина, по которой я опубликовал это, заключается в том, что если кто-то другой обнаружит ошибку, он может найти результат в Google и подтвердить, что это действительно ошибка.   -  person Stilgar    schedule 07.02.2020


Ответы (2)


У вас включен AzureWebJobsDashboard? Если да, вам следует отключить его (удалить строку подключения из настроек приложения) и переключиться на аналитику приложений. Известно, что этот параметр вызывает непредвиденные записи в хранилище, которые невозможно объяснить должным образом.

https://github.com/Azure/Azure-Functions/issues/832

person Alex AIT    schedule 07.02.2020
comment
У меня нет строки подключения к хранилищу под строками подключения. У меня есть ключ AzureWebJobsStorage в настройках, но я думаю, что он используется по умолчанию для функций (я не использую его в своем коде). - person Stilgar; 07.02.2020
comment
Я прочитал комментарии GitHub. Выглядит подозрительно похоже. Интересно, возможно ли, чтобы у функций Azure каким-то образом была неявная панель мониторинга. - person Stilgar; 07.02.2020
comment
Да, вам необходимо удалить этот параметр, даже если вы явно не используете его в своем коде. - person Alex AIT; 07.02.2020
comment
Да, но у меня нет настройки AzureWebJobsDashboard, у меня есть только AzureWebJobsStorage - person Stilgar; 07.02.2020
comment
Ах, прости. Я считаю, что с хранилищем все в порядке - person Alex AIT; 07.02.2020

После нескольких недель расследования группа поддержки Azure, и я думаю, мы нашли строку, которая вызывает проблему, и вот она:

.AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)

Файл конфигурации не был опубликован в процессе публикации и отсутствует в Azure. Эксперименты на данный момент, похоже, подтверждают, что когда это присутствует, количество транзакций увеличивается, а когда нет, они нормальны. Это не ответ

  • Почему ошибка вообще возникает
  • Это регресс в .NET Core или во время выполнения функций?
  • Почему ошибка возникает случайно, а не при каждом запуске?

Обратите внимание, что это тестирование требует времени, так как мне приходится несколько дней ждать случайного всплеска, и я никогда не могу быть уверен, исчезнет ли он навсегда, поэтому я не уверен на 100%, что в какой-то момент в будущем всплеск не повторится и Оказалось, что проблема была в другом.

person Stilgar    schedule 16.04.2020