ملاحظة SRE: مساحات الأسماء والبنية المترية


تعتبر Spyglass by Shorai-san

مساحات أسماء المقاييس الهيكلية مهمة للوصول السريع إلى المعلومات أثناء الحوادث. تخطيط الأسماء وأبعاد المقاييس بعناية لدعم مجموعة واسعة من طلبات البحث والإضافات. إحدى الطرق الفعالة في إنشاء نموذج متري مرن هي التفكير فيها كشجرة.

يوفر هذا العديد من المزايا: عرض مجموعات فرعية معينة من البيانات ، وتحديد مقياس من حيث توابعه ، وإقامة علاقات بين المقاييس. Mail.ru حلول سحابة

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

مساحات الأسماء المترية وبنيتها


مساحات أسماء المقاييس هي المساحات المفاهيمية التي تعيش فيها المقاييس. غالبًا ما تقتصر على قاعدة بيانات أو حساب:


مساحة الاسم المترية هي أيضًا بنية المقاييس داخل مساحة الاسم. يفتح الاسم والهيكل المناسبان عددًا من المزايا الضخمة.

لا تحتوي مساحة الاسم في الرسم البياني أعلاه على بنية صريحة. كل مقياس منفصل ومستقل. لا يوجد شيء مشترك بين المقاييس باستثناء حقيقة وجودها في نفس مساحة الاسم. في هذا الهيكل غير ذي الصلة ، سيتم استخدام كل مقياس على حدة. لمعرفة تكرار طلبات http لخدمة ما ، يجب الوصول إلى مقياس الخدمة مباشرة - service_N_http_requests_total.

افترض أننا نريد أن نرى العدد الإجمالي للطلبات لجميع الخدمات. ماذا يحدث في المثال أعلاه إذا أنشأنا خدمة جديدة؟


إذا تم حساب العدد الإجمالي للطلبات من خلال جمع الطلبات إلى service_1 و service_2 ، فإن إضافة service_3 لا يغير إجمالي عدد الطلبات. لحساب العدد الإجمالي الصحيح للطلبات ، تحتاج إلى تغيير قاعدة الحساب عن طريق إضافة service_3_http_requests_total. ألق نظرة على الرسم البياني لعدد الطلبات أدناه:


شجرة المقاييس


من البدائل لمساحة الاسم غير الهيكلية قبول بنية صريحة باستخدام اسم المقياس كمساحة الاسم. في الرسم البياني أدناه ، ترى هذا الهيكل كشجرة:


في بروميثيوس وDatadog، يتم إنشاء بنية المتري باستخدام علامات و علامات . تسمح لك العلامات ببناء شجرة ديناميكيًا: كلما تمت إضافة خدمة جديدة ، فإنها تشير إلى مقياس الجذر.

في بروميثيوس ، يمكن عرض عدد الطلبات في الثانية لجميع الخدمات من خلال بناء طلب ، كما في الصورة أدناه:


باستخدام مساحة الاسم المنظمة ، يمكنك حساب مجموع الاستعلامات بشكل ديناميكي عبر العقدة بأكملها. في هذه الحالة ، يحسب Prometheus عدد الطلبات في الثانية لكل خدمة كمقياس منفصل.

تحديد مقاييس الميراث


عند استخدام شجرة المقاييس ، يحتوي كل بُعد قياس (يسمى "الخدمة") على تكرار فردي لطلبات خدمة معينة. باستخدام مساحة اسم المقاييس ، لا يمكنك الحصول على إجمالي تكرار الطلب فحسب ، بل يمكنك أيضًا الحصول على تكرار الطلب لكل خدمة:


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

تضييق العينة - مجموعات فرعية من البيانات


تدعم مساحات الأسماء أيضًا تضييق الاستعلام لاسترداد مجموعات فرعية محددة من البيانات. على سبيل المثال ، دعنا نطرح السؤال التالي: "ما هو تأخير p99 (99٪ من الطلبات أسرع من التأخير المحدد) في جميع طلبات HTTP الناجحة للخوادم التي تم نشرها كناري؟".


تضع الشجرة أعلاه نموذجًا لمساحة الاسم وتختار بشكل اختياري كيفية تخزين المقاييس على القرص. يسمح لك استخدام مساحة اسم مقياس محددة جيدًا بتوسيع المقاييس لأي معلمة.

توضح الصورة أدناه رسمًا بيانيًا لـ p99 و p50 من شجرة المقاييس أعلاه:


إذا قدمت طلبًا أكثر تحديدًا ، فيمكنك ، على سبيل المثال ، الإجابة عن السؤال التالي: "ما هو تأخير p99 في جميع طلبات HTTP الناجحة للخوادم التي تم نشرها في سياق كل خادم؟"


في ما يلي تصور لمقياس مع تحديد بحسب معرّف الجهاز:


نظرًا لأن المقياس بهيكل محدد جيدًا ، يمكننا تحديد البيانات الضرورية من مقياس المستوى الأعلى عن طريق تحديد معايير الاختيار اللازمة - في حالتنا ، machine_id.

قاعدة الاحتمالات


المعاملات هي طريقة أخرى لهيكلة البيانات (الارتباطات). هذه آلية قوية للغاية وأساس لحساب مدى توفر ومعدل الخطأ في SLO (تم نشر هذه المؤشرات من قبل خبراء Google SRE).

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

دعنا نوضح هذا ونفترض أن هناك تطبيقًا نفذ الطلب ، ويمكن أن يؤدي الطلب إلى إحدى الحالتين: البيانات المأخوذة من ذاكرة التخزين المؤقت (cache_hit: true) أو البيانات المأخوذة من المصدر الرئيسي (cache_hit: false). لمعرفة نسبة نتائج ذاكرة التخزين المؤقت ، يجب تنظيم البيانات على النحو التالي:


يوضح الرسم البياني أدناه تكرار ذاكرة التخزين المؤقت الضائعة والخطيرة. كل طلب يحصل أو لا يدخل في ذاكرة التخزين المؤقت. في المجموع ، يحدث حوالي 160 طلبًا في الثانية:


يوضح الرسم البياني التالي نسبة نتائج ذاكرة التخزين المؤقت نسبة إلى العدد الإجمالي للطلبات. معامل الضرب 0.5 (50٪):


لذا يمكنك ربط أي مقياسين. في Datadog و Prometheus ، يتم التعبير عن هذه العلاقة من خلال عملية حسابية بسيطة.

الإجابة على الأسئلة بالبيانات


من المهم التفكير من خلال الأسئلة التي يجب أن تجيب عليها البيانات. في المثال الأول ، لا يمكن لأخذ عينات البيانات الإجابة بالضبط على السؤال: "كم عدد الطلبات في الثانية التي تعالجها جميع الحالات؟" ، لكن شجرة مساحة الاسم ستساعد في الحصول على الإجابة.

حالة أخرى شائعة هي مساحة الاسم لمقاييس العميل مع اسم الخدمة ، وليس باسم مكتبة العميل. ستؤدي إضافة اسم مكتبة عميل إلى مساحة الاسم إلى الإجابة عن السؤال التالي: "إجمالي عدد الطلبات من جميع العملاء؟".

الأسئلة المفيدة العامة تجيب على الإشارات الذهبية الأربعة لـ Google . يتم طرح كل سؤال بطريقة عامة ، ثم يتم تحديده:

  1. كم عدد الطلبات التي يقدمها جميع العملاء في المجموع؟
  2. كم عدد الطلبات التي يقدمها كل عميل؟
  3. كم عدد الطلبات التي يقدمها كل عميل لكل عقدة؟
  4. ما هي النسبة المئوية لطلبات الخادم الناجحة لكل RPC؟

تنطبق نفس الإستراتيجية على التأخيرات ومعدلات الخطأ وتشبع الموارد.

مقاييس عامة موسومة


إليك ما قرأت في أفضل الممارسات لتحسين الاستعلام وتخزين البيانات لـ Datadog و Prometheus.

للحصول على نظرة عامة تدعم التفاصيل لشرائح محددة ، ابدأ بمساحة اسم علوية شائعة وأضف علامات وتصنيفات (ابدأ بعلامات شائعة ، ثم أضف علامات أكثر تحديدًا). عند القيام بذلك ، خذ بعين الاعتبار التوصية أدناه.

احذر الأصالة


يوصي كل من Datadog و Prometheus بتحديد عدد العلامات. لاقتباس دليل بروميثيوس :



, , , . , .

, 10. , , . .

, 100 , , .

, node_exporter. . , , node_filesystem_avail. 10 000 , 100 000 node_filesystem_avail, Prometheus.

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

ابدأ بدون علامات وأضف المزيد من العلامات بمرور الوقت حسب الحاجة.

غالبًا ما يتم تحقيق المراقبة المريحة على مستوى المستخدم بشكل أفضل من خلال التتبع الموزع . التتبع الموزع له مساحة المقاييس وأفضل الممارسات.

استنتاج


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

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

حظا طيبا وفقك الله!

ماذا تقرأ :

  1. طرق التخزين المؤقت البسيطة في GitLab CI: دليل صور .
  2. أفضل 10 حيل ونصائح Kubernetes .
  3. قناة برقية لدينا حول التحول الرقمي .

All Articles