Поделиться через

Диагностика и устранение неполадок триггера функций Azure для NoSQL в Azure Cosmos DB

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

В этой статье рассматриваются распространенные проблемы, обходные пути и диагностические действия при использовании триггера Azure Functions для Azure Cosmos DB с поддержкой NoSQL.

Зависимости

Триггеры и привязки Azure Functions для Azure Cosmos DB для NoSQL зависят от пакета расширения Microsoft.Azure.WebJobs.Extensions.CosmosDB, работающего поверх базового выполнения Azure Functions. Всегда обновляйте эти пакеты, так как они включают исправления и новые функции, которые помогут решить любые потенциальные проблемы, которые могут возникнуть.

Используйте SDK Azure Cosmos DB автономно

Ключевой функциональностью пакета расширения является предоставление поддержки триггеров и привязок для Функций Azure с Azure Cosmos DB. Пакет также включает пакет SDK для .NET для Azure Cosmos DB, который полезен, если вы хотите программно взаимодействовать с Azure Cosmos DB без использования триггеров и привязок.

Если вы хотите использовать пакет SDK Azure Cosmos DB, убедитесь, что вы не добавите в проект другую ссылку на пакет NuGet. Разрешите ссылку на пакет SDK через пакет расширения Azure Functions вместо этого. Используйте пакет SDK Azure Cosmos DB отдельно от триггера и привязок.

Кроме того, если вы создаете собственный экземпляр клиента ПАКЕТА SDK для Azure Cosmos DB вручную, следует следовать шаблону наличия только одного экземпляра клиента и использования единого подхода к шаблону. Этот процесс позволяет избежать потенциальных проблем с сокетами в ваших операциях.

Распространенные сценарии и решения

Функция Azure завершилась с сообщением об ошибке, связанной с коллекцией "doesn't exist".

Функция Azure завершается сбоем со следующим сообщением об ошибке: "Либо исходная коллекция collection-name (в базе данных database-name), либо коллекция аренды collection2-name (в базе данных database2-name) не существует." Перед запуском средства прослушивания должны существовать обе коллекции. Чтобы автоматически создать коллекцию аренды, задайте для нее значение CreateLeaseCollectionIfNotExiststrue.

Эта ошибка означает, что один или оба контейнера Azure Cosmos DB, необходимые для работы триггера, отсутствуют или не работают должным образом.

  • Не существует
  • Недоступно для функции Azure

Текст ошибки указывает, какую базу данных и контейнер Azure Cosmos DB ищет триггер на основе конфигурации.

Для разрешения этой проблемы:

  1. Убедитесь, Connection что атрибут ссылается на параметр, который существует в приложении-функции Azure.

    • Значение этого атрибута не должно быть самой строка подключения, а именем параметра конфигурации.

  2. Убедитесь, что значения databaseName и containerName существуют в вашей учетной записи Azure Cosmos DB.

    • Если вы используете автоматическую замену значений (с помощью %settingName% шаблонов), убедитесь, что имя параметра существует в приложении-функции Azure.

  3. Если значение не указано LeaseContainerName/leaseContainerName , по умолчанию используется leasesзначение. Убедитесь, что такой контейнер существует.

    • При необходимости атрибут в триггере можно задать CreateLeaseContainerIfNotExists для true автоматического создания атрибута.

  4. Чтобы убедиться, что учетная запись Azure Cosmos DB не блокирует функцию Azure, проверьте конфигурацию брандмауэра учетной записи Azure Cosmos DB.

Не удается запустить функцию Azure с сообщением об ошибке "Shared throughput collection should have a partition key"

Предыдущие версии расширения Azure Cosmos DB не поддерживали использование контейнера аренды, созданного в базе данных общей пропускной способности.

Для разрешения этой проблемы:

Не удается запустить функцию Azure с сообщением об ошибке "PartitionKey must be supplied for this operation"

Эта ошибка означает, что в настоящее время вы используете разделенную коллекцию аренды со старой зависимостью от расширения.

Для разрешения этой проблемы:

  • Обновление до последней доступной версии.

Не удается запустить функцию Azure с сообщением об ошибке "Forbidden (403); Substatus: 5300... The given request [POST ...] can't be authorized by Microsoft Entra token in data plane"

Эта ошибка означает, что функция пытается выполнить операцию без данных с использованием удостоверений Microsoft Entra. Нельзя использовать CreateLeaseContainerIfNotExists = true, когда вы используете идентификацию Microsoft Entra.

Не удается запустить функцию Azure с сообщением об ошибке "The lease collection, if partitioned, must have partition key equal to id"

Эта ошибка означает, что текущий контейнер разделов секционирован, но путь к разделу ключа не соответствует /id.

Для разрешения этой проблемы:

  • Повторно создайте контейнер аренды с /id ключом секции.

При попытке запустить триггер вы получите сообщение об ошибке "Value can't be null. Parameter name: o" in your Azure function logs"

Эта проблема может возникнуть, если вы используете портал Azure, и при проверке функции Azure, которая использует триггер, нажмите кнопку "Выполнить". Триггеру не требуется выбирать Запустить, чтобы его активировать. Он автоматически запускается при развертывании функции.

Для разрешения этой проблемы:

  • Чтобы проверить поток журнала функции в портале Azure, перейдите к отслеживаемому контейнеру и вставьте некоторые новые элементы. Триггер выполняется автоматически.

Получение изменений занимает слишком много времени.

Этот сценарий может иметь несколько причин. Попробуйте использовать любое или все из следующих решений:

  • Развернута ли ваша функция Azure и учетная запись Azure Cosmos DB в отдельных регионах? Для оптимальной задержки сети функция Azure и учетная запись Azure Cosmos DB должны находиться в одном регионе Azure.

  • Являются ли изменения, которые происходят в контейнере Azure Cosmos DB непрерывным или нерегулярным?

    • Если они спорадические, может возникнуть некоторая задержка между сохранением изменений и функцией Azure, обрабатывающей их. Это происходит, когда триггер проверяет внутренние изменения в контейнере Azure Cosmos DB и не находит никаких изменений, ожидающих чтения. Затем триггер спит на настраиваемое время (5 секунд, по умолчанию) перед проверкой новых изменений. Триггер использует это поведение, чтобы избежать потребления единиц запросов (ЕЗ). Вы можете настроить время сна с помощью FeedPollDelay/feedPollDelay параметра в конфигурации триггера. Ожидается, что значение будет в миллисекундах.

  • В контейнере Azure Cosmos DB может быть ограничена скорость.

  • Вы можете использовать атрибут PreferredLocations в триггере, чтобы указать список регионов Azure, разделяемый запятыми, для определения предпочтительного порядка подключения.

  • Скорость обработки новых изменений определяет скорость, с которой триггер получает эти изменения. Проверьте время выполнения функции или длительность. Если функция работает медленно, это увеличивает время, необходимое триггеру для получения новых изменений. Если вы видите недавнее увеличение длительности, то недавнее изменение кода может повлиять на него. Если скорость, с которой вы получаете операции в контейнере Azure Cosmos DB, быстрее, чем скорость триггера, она отстает. Может потребоваться изучить код функции, чтобы определить наиболее трудоемкую операцию и как оптимизировать ее.

  • Журналы отладки можно использовать для проверки диагностики и проверки задержек в сети.

Некоторые изменения повторяются в моем триггере

Концепция изменения — это операция с элементом. Наиболее распространенные сценарии получения событий для одного и того же элемента:

  • Ваша функция не выполняется из-за ошибки во время выполнения. Если политики повторных попыток включены для функции или в случаях, когда выполнение функции превышает допустимое время выполнения, то один и тот же пакет изменений может быть доставлен снова в функцию. Этот сбой ожидается и по проектированию, просмотрите журналы функций для указания сбоев и убедитесь, что вы включили журналы триггеров для получения дополнительных сведений .

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

  • Элемент обновляется. Канал изменений может содержать несколько операций для одного элемента. Если элемент получает обновления, он может получить несколько событий (по одному для каждого обновления). Один из простых способов различать различные операции для одного и того же элемента — отслеживать _lsnсвойство для каждого изменения. Если свойства не соответствуют, изменения отличаются.

  • Если вы идентифицируете элементы только по id, помните, что уникальный идентификатор элемента включает в себя id и его ключ секции. (Два элемента могут иметь один и тот же id ключ секции.

Некоторые изменения отсутствуют в триггере

Вы можете обнаружить, что функция не взяла некоторые изменения, которые произошли в контейнере Azure Cosmos DB для NoSQL. Или некоторые изменения отсутствуют в месте назначения при их копировании. Если это так, попробуйте использовать решения в этом разделе.

  • Убедитесь, что у вас есть журналы . Убедитесь, что ошибки не происходят во время обработки.

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

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

    • В этом сценарии наилучшим действием будет добавление блоков try/catch в ваш код и внутри циклов, обрабатывающих изменения. Добавление помогает обнаружить любой сбой для определенного подмножества элементов и обрабатывать их соответствующим образом (отправлять их в другое хранилище для дальнейшего анализа или повтора). Кроме того, можно настроить политики повторных попыток Функции Azure.

      Примечание.

      Триггер Azure Functions для базы данных Azure Cosmos DB для NOSQL по умолчанию не будет повторять пакет изменений, если во время выполнения кода произошло необработанное исключение. Это означает, что причина того, что изменения не прибыли в место назначения, могут быть потому, что вы не смогли обработать их.

  • Если назначением является другой контейнер Azure Cosmos DB и вы выполняете операции upsert для копирования элементов, проверьте определение ключа партиции в обоих контейнерах. Ключ раздела для контейнера мониторинга и целевого контейнера должен совпадать. Операции Upsert могут сохранять несколько исходных элементов в качестве одного в месте назначения из-за этой разницы конфигурации.

  • Если вы обнаружили, что триггер не получил некоторые изменения, наиболее распространенный сценарий заключается в том, что другая функция Azure запущена. Другая функция может быть развернута в Azure или функция может работать локально на компьютере разработчика с той же конфигурацией. Если это так, эта функция может перенаправлять часть изменений, которые, как ожидалось, должны были быть обработаны вашей функцией Azure.

Кроме того, можно проверить сценарий, если вы знаете, сколько экземпляров приложения-функции Azure запущено. Если вы проверяете контейнер аренд и подсчитываете количество элементов аренд в нем, отдельные значения свойства Owner в них должны быть равны количеству экземпляров вашего функционального приложения. Если владельцев больше, чем известных экземпляров функций приложений Azure, это означает, что именно эти дополнительные владельцы "присваивают" изменения.

Одним из простых способов обойти эту ситуацию является применение LeaseCollectionPrefix/leaseCollectionPrefix к вашей функции с новым или другим значением или, кроме того, тестирование с помощью нового контейнера аренд.

Необходимо перезапустить и повторно обработать все элементы в контейнере с самого начала.

Повторная обработка всех элементов в контейнере с самого начала:

  1. Остановите функцию Azure, если она запущена в настоящее время.

  2. Удалите документы в коллекции аренды (или удалите и повторно создайте коллекцию аренды, чтобы она пуста).

  3. Задайте для атрибута StartFromBeginning CosmosDBTrigger в функции trueзначение .

  4. Перезапустите функцию Azure. Теперь функция считывает и обрабатывает все изменения с самого начала.

Установка StartFromBeginning в true сообщает функции Azure начать читать изменения с начала истории коллекции, а не с текущего времени.

Это решение работает только при отсутствии уже созданных договоров аренды (то есть документов в коллекции договоров аренды).

Установка этого свойства true не действует, если уже созданы договоры аренды. В этом сценарии при остановке и перезапуске функции начинается чтение с последней контрольной точки, как определено в коллекции аренд.

Ошибка: Binding can be done only with IReadOnlyList<Document> or JArray

Эта ошибка возникает, если проект Azure Functions содержит вручную добавленную ссылку на пакет NuGet SDK Azure Cosmos DB, которая имеет конфликт версий. Эта ошибка часто возникает, так как пакет имеет версию, отличную от версии, предоставленной расширением Azure Cosmos DB для Функции Azure.

Чтобы обойти эту ситуацию, удалите вручную добавленную ссылку NuGet и разрешите ссылку на SDK Azure Cosmos DB через расширение Azure Cosmos DB для пакета Azure Functions.

Изменение интервала опроса функции Azure для обнаружения изменений

Как объяснялось ранее в разделе "Получение ваших изменений занимает слишком много времени", функция Azure находится в режиме ожидания в течение настраиваемого времени (5 секунд по умолчанию), прежде чем проверять наличие новых изменений (чтобы избежать высокого потребления единиц запросов). Это время сна можно настроить с помощью FeedPollDelay/feedPollDelay параметра в конфигурации триггера (значение должно находиться в миллисекундах).

Связанный контент

  • Last updated on