كيفية مراقبة وحدات الطلب/الثانية التي تمت تسويتها لحاوية Azure Cosmos DB أو حساب

ينطبق على: NoSQL MongoDB كاساندرا العفريت جدول

توفر Azure Monitor لـ Azure Cosmos DB طريقة عرض مقاييس لمراقبة حسابك وإنشاء لوحات المعلومات. يتم تجميع قياسات Azure Cosmos DB افتراضياً، ولا تتطلب هذه الميزة تمكين أو تكوين أي شيء بشكل صريح.

تعريف المقياس

مقياس Normalized RU Consumption هو مقياس بين 0% إلى 100% يُستخدم للمساعدة في قياس استخدام معدل النقل المتوفر في قاعدة بيانات أو حاوية. يتم إصدار المقياس على فترات زمنية مدتها دقيقة واحدة، ويتم تعريفه على أنه الحد الأقصى لاستخدام وحدة طلب/ثانية (RU/s) عبر جميع نطاقات مفاتيح الأقسام في الفاصل الزمني. يتم تعيين كل نطاق مفتاح قسم إلى قسم مادي واحد، ويتم تعيينه للاحتفاظ بالبيانات لمجموعة من قيم التجزئة الممكنة. بشكل عام، كلما زادت نسبة RU المُطابقة، زاد استخدامك لمعدل النقل المقدم. يمكن أيضاً استخدام المقياس لعرض استخدام نطاقات مفاتيح الأقسام الفردية في قاعدة بيانات أو حاوية.

على سبيل المثال، لنفترض أن لديك حاوية حيث قمت بتعيين الحد الأقصى لمعدل النقل للمقياس التلقائي بمقدار 20000 وحدة طلب/ثانية (بقياسات تتراوح بين 2000 - 20000 RU/ثانية) ولديك نطاقان من مفاتيح الأقسام (الأقسام المادية) P1 وP2. نظراً لأن Azure Cosmos DB يوزع معدل النقل المقدم بشكل متساوٍ عبر جميع نطاقات مفاتيح الأقسام، يمكن أن يتراوح نطاق كل من P1 وP2 بين 1000 - 10,000 وحدة طلب/ثانية. افترض أنه في فاصل زمني مدته دقيقة واحدة، في ثانية معينة، استهلك P1 6000 وحدة طلب واستهلك P2 8000 وحدة طلب. معدل استهلاك RU العادي لـ P1 هو 60% و80% لـ P2. إجمالي استهلاك RU القياسي للحاوية بأكملها هو MAX(60%, 80%) = 80%.

إذا كنت مهتماً برؤية استهلاك وحدة الطلب في فاصل زمني لكل ثانية، جنباً إلى جنب مع نوع العملية، فيمكنك استخدام ميزة الاشتراك سجلات التشخيص والاستعلام عن جدول PartitionKeyRUConsumption. للحصول على نظرة عامة عالية المستوى على العمليات ورمز الحالة الذي ينفذه التطبيق الخاص بك على مورد Azure Cosmos DB، يمكنك استخدام مقياس إجمالي طلبات Azure Monitor المضمنة (API for NoSQL) أو طلبات Mongo أو طلبات Gremlin أو مقياس طلبات Cassandra. يمكنك لاحقاً تصفية هذه الطلبات بواسطة رمز الحالة 429 وتقسيمها حسب نوع العملية.

ما يمكن توقعه والقيام به عندما تكون وحدة الطلبات/ثانية التي تمت تسويتها أعلى

عندما يصل استهلاك RU الطبيعي إلى 100% لنطاق مفتاح قسم معين، وإذا استمر العميل في تقديم الطلبات في تلك النافذة الزمنية التي تبلغ ثانية واحدة إلى نطاق مفتاح القسم المحدد - فإنه يتلقى خطأً محدوداً بالمعدل (429).

هذا لا يعني بالضرورة وجود مشكلة في الموارد الخاصة بك. بشكل افتراضي، تعيد مجموعات SDK الخاصة بعميل Azure Cosmos DB وأدوات استيراد البيانات مثل Azure Data Factory ومكتبة المنفذ المجمع الطلبات تلقائيًا على 429 ثانية. يعيدون المحاولة عادةً حتى 9 مرات. نتيجة لذلك، على الرغم من أنك قد ترى 429 ثانية في المقاييس، فقد لا يتم إرجاع هذه الأخطاء إلى تطبيقك.

بشكل عام، بالنسبة لأعباء الإنتاج، إذا رأيت ما بين 1-5٪ من الطلبات بـ 429 ثانية، وكان وقت الاستجابة من البداية إلى النهاية مقبولًا، فهذه علامة جيدة على الاستفادة الكاملة من RU / s . في هذه الحالة، يعني مقياس استهلاك RU المعياري الذي يصل إلى 100% فقط أنه في ثانية معينة، استخدم نطاق مفتاح قسم واحد على الأقل كل سرعة النقل المقدمة. هذا مقبول لأن المعدل الإجمالي لـ 429 ثانية لا يزال منخفضاً. ولا يتطلب الأمر أي إجراء آخر.

لتحديد النسبة المئوية لطلباتك لقاعدة البيانات أو الحاوية التي نتجت عن 429 ثانية، من تعليمة برمجية حساب Azure Cosmos DB، انتقل إلى Insights>الطلبات>إجمالي الطلبات حسب التعليمة البرمجية للحالة. قم بتصفية إلى قاعدة بيانات وحاوية معينة. بالنسبة لواجهة برمجة التطبيقات ل Gremlin، استخدم مقياس طلبات Gremlin.

إذا كان مقياس استهلاك RU الذي تمت تسويته دائماً 100% عبر نطاقات مفاتيح أقسام متعددة وكان المعدل 429 ثانية أكبر من 5%، فمن المستحسن زيادة معدل النقل. يمكنك معرفة العمليات الثقيلة وما هي ذروة استخدامها باستخدام قياسات مراقبة Azure وسجلات تشخيص مراقبة Azure. اتبع أفضل الممارسات لتوسيع نطاق معدل النقل المقدم (RU/ثانية).

ليس الأمر دائماً هو أنك سترى خطأ في تحديد المعدل 429 لمجرد أن RU الطبيعي قد وصل إلى 100%. وذلك لأن RU الطبيعي هو قيمة واحدة تمثل الحد الأقصى للاستخدام على جميع نطاقات مفاتيح الأقسام. قد يكون أحد نطاقات مفاتيح الأقسام مشغولاً، ولكن نطاقات مفاتيح الأقسام الأخرى يمكنها خدمة الطلبات دون مشاكل. على سبيل المثال، ستؤدي عملية واحدة مثل إجراء مخزن يستهلك كل وحدات RU/ثانية الموجودة في نطاق مفتاح القسم إلى ارتفاع قصير في مقياس استهلاك RU العادي. وفي مثل هذه الحالات، لن تكون هناك أي أخطاء فورية في الحد من المعدل إذا كان معدل الطلب الإجمالي منخفضاً أو تم تقديم الطلبات إلى أقسام أخرى في نطاقات مفاتيح الأقسام المختلفة.

تعرف على المزيد حول كيفية تفسير وتصحيح أخطاء تقييد معدل 429.

كيفية مراقبة الأقسام المزدحمة (المشغولة)

يمكن استخدام مقياس استهلاك RU المعياري لمراقبة ما إذا كان حمل العمل لديك يحتوي على قسم مزدحم (مشغول). ينشأ القسم الساخن عندما يستهلك مفتاح واحد أو عدد قليل من مفاتيح الأقسام المنطقية قدرًا غير متناسب من إجمالي RU / s بسبب زيادة حجم الطلب. يمكن أن يحدث هذا بسبب تصميم مفتاح القسم الذي لا يوزع الطلبات بالتساوي. ينتج عنه توجيه العديد من الطلبات إلى مجموعة فرعية صغيرة من الأقسام المنطقية (التي تشير إلى نطاقات مفاتيح الأقسام) التي تصبح "مزدحمة"؛ نظراً لأن جميع البيانات الخاصة بالقسم المنطقي موجودة في نطاق مفتاح قسم واحد، ويتم توزيع إجمالي RU/ثانية بالتساوي بين جميع نطاقات مفاتيح الأقسام، ويمكن أن يؤدي القسم المزدحم (المشغول) إلى 429 ثانية واستخدام غير فعال لمعدل النقل.

كيفية تحديد ما إذا كان هناك قسم مزدحم (مشغول)

للتحقق مما إذا كان هناك قسم فعال، انتقل إلى Insights > معدل النقل > استهلاك RU الطبيعي (٪) بواسطة PartitionKeyRangeID . قم بتصفية إلى قاعدة بيانات وحاوية معينة.

يتم تعيين كل معرف نطاق رئيسي للقسم إلى قسم مادي واحد. إذا كان هناك PartitionKeyRangeId واحد يحتوي على استهلاك RU طبيعي أعلى بكثير من غيره (على سبيل المثال، واحد ثابت بنسبة 100%، بينما الآخر بنسبة 30% أو أقل)، يمكن أن يكون هذا علامة على وجود قسم مزدحم (مشغول).

لتحديد الأقسام المنطقية التي تستهلك معظم وحدات RU/ثانية، بالإضافة إلى الحلول الموصى بها، راجع المقالة تشخيص واستكشاف أخطاء Azure Cosmos DB معدل كبير جداً (429) استثناءات.

تطبيع استهلاك RU ومقياس تلقائي

سيظهر مقياس استهلاك RU المعياري على أنه 100% إذا كان نطاق مفتاح قسم واحد على الأقل يستخدم جميع وحدات RU/ثانية المخصصة في أي ثانية معينة في الفاصل الزمني. أحد الأسئلة المتداولة التي تُطرح هو: لماذا يتم تطبيع استهلاك RU بنسبة 100%، لكن Azure Cosmos DB لم يقم بتوسيع RU/ثانية إلى الحد الأقصى من معدل النقل باستخدام المقياس التلقائي؟

عند استخدام تحجيم تلقائي، يقوم Azure Cosmos DB فقط بتحجيم RU / s إلى الحد الأقصى لمعدل النقل عندما يكون استهلاك RU الطبيعي 100٪ لفترة زمنية متواصلة ومستمرة في فاصل 5 ثوانٍ. يتم ذلك للتأكد من أن منطق القياس سهل التكلفة للمستخدم، لأنه يضمن أن الارتفاعات اللحظية الفردية لا تؤدي إلى توسيع غير ضروري وتكلفة أعلى. عندما تكون هناك ارتفاعات مؤقتة، يتدرج النظام عادةً إلى قيمة أعلى من القيمة التي تم تحجيمها سابقًا إلى RU / s، ولكن أقل من الحد الأقصى لـ RU / s.

على سبيل المثال، لنفترض أن لديك حاوية بسعة نقل قصوى للمقياس التلقائي تبلغ 20000 وحدة طلب/ثانية (قياسات تتراوح بين 2000 - 20000 وحدة طلب/ثانية) ونطاقَين لمفاتيح التقسيم. يمكن أن يتراوح نطاق كل مفتاح قسم بين 1000 - 10000 وحدة طلب/ثانية. ونظراً لأن المقياس التلقائي يوفر جميع الموارد المطلوبة مقدماً، يمكنك استخدام ما يصل إلى 20000 وحدة طلب/ثانية في أي وقت. لنفترض أن لديك ارتفاعاً متقطعاً في نسبة استخدام الشبكة، حيث يكون استخدام أحد نطاقات مفاتيح القسم لمدة ثانية واحدة 10000 وحدة طلب/ثانية. للثواني اللاحقة، يعود الاستخدام إلى 1000 وحدة طلب/ثانية. ونظراً لأن مقياس استهلاك RU المعياري يُظهر أعلى استخدام في الفترة الزمنية عبر جميع الأقسام، فسيظهر 100%. ومع ذلك، ونظراً لأن الاستخدام كان 100% فقط لمدة ثانية واحدة، فلن يصل المقياس التلقائي إلى الحد الأقصى تلقائياً.

ونتيجة لذلك، وعلى الرغم من أن المقياس التلقائي لم يصل إلى الحد الأقصى، فما زلت قادراً على استخدام إجمالي وحدة طلب/ثانية المتاح. للتحقق من استهلاك وحدة طلب/ثانية الخاص بك، يمكنك استخدام سجلات التشخيص لميزة الاشتراك للاستعلام عن استهلاك وحدة طلب/ثانية الإجمالي في المستوى الثاني عبر جميع نطاقات مفاتيح الأقسام.

CDBPartitionKeyRUConsumption
| where TimeGenerated >= (todatetime('2022-01-28T20:35:00Z')) and TimeGenerated <= todatetime('2022-01-28T20:40:00Z')
| where DatabaseName == "MyDatabase" and CollectionName == "MyContainer"
| summarize sum(RequestCharge) by bin(TimeGenerated, 1sec), PartitionKeyRangeId
| render timechart

بشكل عام، بالنسبة إلى حمل عمل الإنتاج باستخدام مقياس تلقائي، إذا رأيت ما بين 1-5% من الطلبات مع 429 ثانية، وكان وقت الاستجابة من طرف إلى طرف مقبولاً، فهذه علامة صحية على استخدام وحدة طلب/ثانية بشكل كامل. حتى إذا كان استهلاك RU الطبيعي يصل أحياناً إلى 100% ولا يصل المقياس التلقائي إلى الحد الأقصى لوحدة طلب/ثانية، فلا بأس في ذلك لأن المعدل الإجمالي البالغ 429 ثانية منخفض. لا توجد أية إجراءات مطلوبة.

عرض مقياس استهلاك وحدة الطلبات التي تم تسويتها

1. قم بتسجيل الدخول إلى بوابة Azure.

2. حدد Monitor من شريط التنقل الأيسر وحدد Metrics.

   

3. من جزء المقاييس حدد >موارد> واختر الاشتراك المطلوب ومجموعة الموارد. بالنسبة إلى Resource type، حدد Azure Cosmos DB accounts، واختر أحد حسابات Azure Cosmos DB الحالية، وحدد Apply.

   

4. بعد ذلك يمكنك تحديد مقياس من قائمة المقاييس المُتوفرة. يمكنك تحديد مقاييس مُحددة لوحدات الطلب والتخزين وزمن الانتقال والتوفر، وCassandra، وغيرها. للتعرف بالتفصيل على جميع المقاييس المتوفرة في هذه القائمة، راجع مقالة المقاييس حسب الفئة. في هذا المثال، لنحدد مقياس Normalized RU Consumption وMax كقيمة التجميع.

   بالإضافة إلى هذه التفاصيل، يمكنك أيضاً تحديد Time range وTime granularity للمقاييس. كحد أقصى، يمكنك عرض قياسات آخر 30 يوماً. بعد تطبيق عامل التصفية، يتم عرض مخطط بناءً على عامل التصفية الخاص بك.

   

عامل تصفية لمقياس استهلاك RU الطبيعي

يمكنك أيضاً تصفية المقاييس والمخطط المعروض بتحديد CollectionNameمحدد، DatabaseName، وPartitionKeyRangeID، وRegion. لتصفية المقاييس، حدد Add filter واختر الخاصية المطلوبة مثل CollectionName والقيمة المقابلة التي تهمك. يعرض الرسم البياني بعد ذلك مقياس استهلاك RU المعياري للحاوية للفترة المحددة.

يمكنك تجميع المقاييس باستخدام خيار تطبيق التقسيم. بالنسبة لقواعد بيانات معدل النقل المشتركة، مقياس وحدة الطلب (RU)الذي تم تسويته يعرض البيانات في نقاوة قاعدة البيانات فقط، ولا يعرض أي بيانات لكل مجموعة. لذلك بالنسبة لقاعدة بيانات معدل النقل المشتركة، لن ترى أي بيانات عند تطبيق التقسيم حسب اسم المجموعة.

يُعرض مقياس استهلاك وحدة الطلب التي تمت تسويتها لكل حاوية كما هو مُوضح في الصورة التالية:

الخطوات التالية

• مراقبة بيانات قاعدة البيانات Azure Cosmos باستخدام إعدادات التشخيص في Azure.
• تدقيق عمليات وحدة التحكم في قاعدة البيانات Azure Cosmos
• تشخيص واستكشاف أخطاء معدل طلب Azure Cosmos DB الكبير جدا (429) استثناءات