DataPlaneRequests partitionID в журналах диагностики CosmosDB всегда кажется пустым

Я включил диагностическое ведение журнала учетной записи Cosmos (интерфейс SQL). Данные журнала диагностики отправляются в учетную запись хранения, и я вижу, что каждые 5 минут создается новый большой двоичный объект DataPlaneRequests. Все идет нормально.

Я выполняю запросы CRUD к коллекции в учетной записи Cosmos. Я вижу записи в журналах DataPlaneRequest, которые выглядят так ('*' используется для защиты невиновных) ...

{"time": "2020-01-28T03: 04: 59.2606375Z", "resourceId": "/SUBSCRIPTIONS/****/RESOURCEGROUPS/****/PROVIDERS/MICROSOFT.DOCUMENTDB/DATABASEACCOUNTS/**** ****** "," category ":" DataPlaneRequests "," operationName ":" Query "," properties ": {" activityId ":" 38f497ee-7e37-435f-8b4a-a2f0d8d65d12 "," requestResourceType ":" DocumentFeed "," requestResourceId ":" / dbs / **** / colls / **** / docs "," collectionRid ":" "," databaseRid ":" "," statusCode ":" 200 "," duration ":" 4.588500 "," userAgent ":" Windows / 10.0.14393 documentdb-netcore-sdk / 2.8.1 "," clientIpAddress ":" 52. .. *** "," requestCharge ":" 4.160000 "," requestLength ":" 278 "," responseLength ":" 5727 "," resourceTokenUserRid ":" "," region ":" Запад США 2 "," partitionId ": ""}}

Каждая запись в журнале DataPlaneRequests имеет пустое значение свойства partitionId. (Значение свойства operationName в журнале - «Создать» или «Запрос»).

Итак, мой вопрос - почему это свойство пусто?

Вот документация для DataPlaneRequests

На самом деле я пытаюсь получить информацию о нагрузке на физические разделы коллекции. например Я хотел бы знать, что за последние 10 минут в физическом разделе «1» было выполнено 10 тыс. Операций Create, а в физическом разделе «3» - 55 тыс. Операций. Это позволит мне лучше понять, почему в коллекции происходит дросселирование и т. Д.


azure-cosmosdb azure-log-analytics
person user1793093    schedule 28.01.2020    source источник
comment
Почему вы хотите знать, из какого физического раздела были записаны или запрошены данные? Вы смотрели на вкладку метрик в колонке Cosmos на портале? Вверху есть вкладка пропускной способности, на которой можно получить подробную информацию о горячих разделах.   -  person Mark Brown    schedule 02.02.2020
comment
... потому что, когда происходит регулирование, я хотел бы знать, кто несет ответственность за нагрузку на каждый физический раздел. Потому что я хотел бы знать, кто виноват (как с точки зрения значения PartitionKey, так и с точки зрения UserAgent), а также, какие значения PartitionKey (клиенты) могут быть затронуты регулированием.   -  person user1793093    schedule 04.02.2020
comment
Гипотетический пример: микросервис «A» делает много запросов, которые все сопоставляются с одним и тем же физическим разделом «1», поэтому за регулирование в разделе «1» можно возложить ответственность за «A». Микросервис «B» выполняет запросы, которые сопоставляются со всеми физическими разделами, поэтому регулирование в разделе «1» (вызванное «A» будет влиять на подмножество запросов, выполняемых «B»). Поэтому я хотел бы обвинить «А» в регулировании в «1», и я хотел бы иметь возможность сообщить «В», какое подмножество его запросов может испытывать снижение производительности.   -  person user1793093    schedule 04.02.2020
comment
Я думаю, что способ подойти к этому - выяснить, какие операции занимают больше всего RU / s. Взгляните на эту статью здесь. Я думаю, что первые два запроса предоставят вам данные, которые вы ищете. docs.microsoft.com/ ru-us / azure / cosmos-db / Надеюсь, это поможет.   -  person Mark Brown    schedule 04.02.2020
comment
Спасибо за вклад @MarkBrown - я обратился в службу поддержки Microsoft. Я опубликую любое решение, которое из этого выйдет.   -  person user1793093    schedule 10.02.2020

Ответы (1)


arrow_upward
0
arrow_downward

При подключении к Cosmos доступны два режима подключения: шлюз и прямой. Оказывается, только режим Direct заставляет partitionId быть включенным в журналы. (Если вы прочитаете о том, как эти два режима работают (по-разному), тогда это имеет смысл).

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

В журналах доступен идентификатор физического раздела, но он также имеет ограниченное использование, поскольку он отслеживается только для 3 самых больших (логических) значений PartitionKey каждого физического раздела, только если ключ-значение содержит> = 1 ГБ документов.

person user1793093    schedule 17.02.2020