تحرير

مشاركة عبر

مراقبة تطبيق الخدمات المصغرة في AKS

Azure Monitor
Azure Kubernetes Service (AKS)

توضح هذه المقالة أفضل الممارسات لمراقبة تطبيق الخدمات المصغرة الذي يتم تشغيله على Azure Kubernetes Service (AKS). تتضمن الموضوعات المحددة جمع بيانات تتبع الاستخدام، ومراقبة حالة نظام المجموعة، والمقاييس، والتسجيل، والتسجيل المنظم، والتتبع الموزع. يتم توضيح هذا الأخير في هذا الرسم التخطيطي:

Diagram that shows the architecture of a drone delivery application.

قم بتنزيل ملف Visio لهذه البنية.

مجموعة بيانات تتبع الاستخدام

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

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

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

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

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

  • على مستوى العقدةقياسات، بما في ذلك استخدام CPU والذاكرة والشبكة والقرص ونظام الملفات. تساعدك مقاييس النظام على فهم تخصيص الموارد لكل عقدة في نظام المجموعة، واستكشاف القيم الخارجية وإصلاحها.

  • قياسات الحاوية. بالنسبة للتطبيقات الحاوية، تحتاج إلى جمع القياسات على مستوى الحاوية، وليس فقط على مستوى VM.

  • قياسات التطبيق. هذه المقاييس ذات صلة لفهم سلوك الخدمة. تتضمن الأمثلة عدد طلبات HTTP الواردة في قائمة الانتظار وزمن انتقال الطلب وطول قائمة انتظار الرسائل. يمكن للتطبيقات أيضا استخدام مقاييس مخصصة خاصة بالمجال، مثل عدد المعاملات التجارية التي تتم معالجتها في الدقيقة.

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

مراقبة حالة نظام المجموعة

استخدم Azure Monitor لمراقبة صحة مجموعاتك. تظهر لقطة الشاشة التالية مجموعة تحتوي على أخطاء فادحة في pods المنشورة من قبل المستخدم:

Screenshot that shows the Monitor dashboard.

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

إذا تعطل حاوية، تصبح الحاوية StateWaiting، مع من ReasonCrashLoopBackOff. بالنسبة للسيناريو النموذجي، حيث يكون الجراب جزءا من مجموعة النسخ المتماثلة ونهج إعادة المحاولة هو Always، لا تظهر هذه المشكلة كخطأ في حالة نظام المجموعة. ومع ذلك، يمكنك تشغيل الاستعلامات أو إعداد التنبيهات لهذا الشرط. لمزيد من المعلومات، راجع فهم أداء نظام مجموعة AKS باستخدام رؤى حاوية Azure Monitor.

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

Screenshot that shows the workbooks for an AKS resource.

المقاييس

نوصي باستخدام Monitor لجمع وعرض المقاييس لمجموعات AKS وأي خدمات Azure تابعة أخرى.

  • بالنسبة لمقاييس نظام المجموعة والحاوية، قم بتمكين Azure Monitor Container insights. عند تمكين هذه الميزة، يجمع Monitor مقاييس الذاكرة والمعالج من وحدات التحكم والعقد والحاويات عبر واجهة برمجة تطبيقات مقاييس Kubernetes. لمزيد من المعلومات حول المقاييس المتوفرة من نتائج تحليلات الحاوية، راجع فهم أداء مجموعة AKS باستخدام رؤى حاوية Azure Monitor.

  • استخدم Application Insights لجمع قياسات التطبيق. Application Insights هي خدمة إدارة أداء التطبيقات القابلة للتوسعة (APM). لاستخدامه، تقوم بتثبيت حزمة أجهزة في تطبيقك. تراقب هذه الحزمة التطبيق وترسل بيانات تتبع الاستخدام إلى Application Insights. يمكنه أيضاً سحب بيانات تتبع الاستخدام من البيئة المضيفة. ثم يتم إرسال البيانات إلى Monitor. يوفر Application Insights أيضا الارتباط المضمن وتتبع التبعية. (راجع التتبع الموزع، لاحقا في هذه المقالة.)

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

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

إذا كان معدل البيانات مرتفعا بما يكفي لتشغيل التقييد، ولم يكن أخذ العينات أو التجميع مقبولا، ففكر في تصدير المقاييس إلى قاعدة بيانات سلسلة زمنية، مثل Azure Data Explorer أو Prometheus أو InfluxDB، التي تعمل في نظام المجموعة.

  • Azure Data Explorer هي خدمة استكشاف بيانات أصلية وقابلة للتطوير بدرجة كبيرة من Azure لبيانات السجل وبيانات تتبع الاستخدام. يتميز بدعم تنسيقات بيانات متعددة ولغة استعلام غنية واتصالات لاستهلاك البيانات في أدوات شائعة مثل Jupyter Notebooks وGrafana. يحتوي Azure Data Explorer على موصلات مضمنة لاستيعاب بيانات السجل والقياسات عبر مراكز الأحداث. لمزيد من المعلومات، راجع استيعاب بيانات المراقبة والاستعلام عنها في Azure Data Explorer.

  • InfluxDB هو نظام قائم على الدفع. يحتاج العامل لدفع القياسات. يمكنك استخدام مكدس TICK لإعداد مراقبة Kubernetes. بعد ذلك، يمكنك دفع المقاييس إلى InfluxDB باستخدام Telegraf، وهو عامل لجمع المقاييس والإبلاغ عنها. يمكنك استخدام InfluxDB للأحداث غير المنتظمة وأنواع بيانات السلسلة.

  • بروميثيوس هو نظام قائم على السحب. يقوم بشكل دوري بإلغاء القياسات من المواقع التي تم تكوينها. يمكن لـ Prometheus استخراج القياسات التي تم إنشاؤها بواسطة Azure Monitor أو kube-state-metrics. kube-state-metrics هي خدمة تجمع المقاييس من خادم Kubernetes API وتجعلها متاحة ل Prometheus (أو قصاصة متوافقة مع نقطة نهاية عميل Prometheus). بالنسبة لمقاييس النظام، استخدم مصدر العقدة، وهو مصدر Prometheus لمقاييس النظام. يدعم Prometheus بيانات النقطة العائمة ولكن ليس بيانات السلسلة، لذلك فهي مناسبة لمقاييس النظام ولكن ليس السجلات. Kubernetes Metrics Server هو مجمع على مستوى المجموعة لبيانات استخدام الموارد.

تسجيل الدخول

فيما يلي بعض التحديات العامة لتسجيل الدخول إلى تطبيق الخدمات المصغرة:

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

هناك بعض التحديات الإضافية للبنى المستندة إلى Kubernetes:

  • يمكن للحاويات التنقل وإعادة جدولتها.
  • لدى Kubernetes تجريد شبكة يستخدم عناوين IP الظاهرية وتعيينات المنفذ.

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

يتكامل Azure Monitor مع AKS لدعم هذا الأسلوب. يجمع Monitor سجلات الحاوية ويرسلها إلى مساحة عمل Log Analytics. من هناك، يمكنك استخدام Kusto Query Language لكتابة الاستعلامات عبر السجلات المجمعة. على سبيل المثال، إليك استعلام Kusto لعرض سجلات الحاوية ل pod محدد:

ContainerLogV2
| where PodName == "podName" //update with target pod
| project TimeGenerated, Computer, ContainerId, LogMessage, LogSource

Azure Monitor هي خدمة مدارة، وتكوين نظام مجموعة AKS لاستخدام Monitor هو تغيير تكوين بسيط في CLI أو قالب Azure Resource Manager. (لمزيد من المعلومات، راجع كيفية تمكين رؤى حاوية Azure Monitor.) ميزة أخرى لاستخدام Azure Monitor هي أنه يدمج سجلات AKS الخاصة بك مع سجلات النظام الأساسي Azure الأخرى لتوفير تجربة مراقبة موحدة.

تتم فوترة Azure Monitor لكل غيغابايت (GB) من البيانات التي تم استيعابها في الخدمة. (راجع أسعار Azure Monitor.) وبأحجام كبيرة، قد تصبح التكلفة أحد الاعتبارات. هناك العديد من البدائل مفتوحة المصدر المتاحة لنظام Kubernetes البنائي. على سبيل المثال، تستخدم العديد من المؤسسات Fluentd مع Elasticsearch. Fluentd هو مجمع بيانات مفتوح المصدر، و Elasticsearch هي قاعدة بيانات مستندات تستخدم للبحث. يتمثل التحدي في هذه الخيارات في أنها تتطلب تكوينا وإدارة إضافيين لنظام المجموعة. بالنسبة إلى حمل عمل الإنتاج، قد تحتاج إلى تجربة إعدادات التكوين. ستحتاج أيضاً إلى مراقبة أداء البنية الأساسية للتسجيل.

التتبع المفتوح

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

  • تسجيل عمليات الطلب الأساسية، مثل وقت البدء ووقت الخروج والمدة
  • تم طرح استثناءات
  • نشر السياق (مثل إرسال معرف ارتباط عبر حدود استدعاء HTTP)

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

تم تجهيز العديد من حزم Azure SDK باستخدام OpenTelemetry أو أنها قيد التنفيذ.

يمكن لمطور التطبيق إضافة أدوات يدوية باستخدام OpenTelemetry SDKs للقيام بالأنشطة التالية:

  • إضافة تقرير عن حالة النظام حيث لا توفرها مكتبة أساسية.
  • إثراء سياق التتبع عن طريق إضافة امتدادات لعرض وحدات العمل الخاصة بالتطبيق (مثل حلقة الطلب التي تنشئ امتدادا لمعالجة كل سطر طلب).
  • إثراء الامتدادات الموجودة بمفاتيح الكيان لتمكين التتبع الأسهل. (على سبيل المثال، أضف مفتاح/قيمة OrderID إلى الطلب الذي يعالج هذا الطلب.) تظهر هذه المفاتيح بواسطة أدوات المراقبة كقيم منظمة للاستعلام والتصفية والتجميع (دون تحليل سلاسل رسائل السجل أو البحث عن مجموعات من تسلسلات رسائل السجل، كما كان شائعا مع نهج التسجيل أولا).
  • نشر سياق التتبع عن طريق الوصول إلى سمات التتبع والامتداد، وحقن traceIds في الاستجابات والحمولات، و/أو قراءة traceIds من الرسائل الواردة، من أجل إنشاء الطلبات والامتدادات.

اقرأ المزيد حول الأجهزة وOpenTelemetry SDKs في وثائق OpenTelemetry.

Application Insights

يجمع Application Insights بيانات غنية من OpenTelemetry ومكتبات الأجهزة الخاصة به ويلتقطها في مخزن بيانات فعال لتوفير مرئيات غنية ودعم الاستعلام. مكتبات الأجهزة المستندة إلى Application Insights OpenTelemetry، للغات مثل .NET وJava وNode.js وPython، تجعل من السهل إرسال بيانات القياس عن بعد إلى Application Insights.

إذا كنت تستخدم .NET Core، نوصي أيضا بمراعاة Application Insights لمكتبة Kubernetes . تثري هذه المكتبة تتبعات Application Insights بمعلومات إضافية، مثل الحاوية والعقدة والجراب والتسميات ومجموعة النسخ المتماثلة.

يقوم Application Insights maps بتعيين سياق OpenTelemetry إلى نموذج البيانات الداخلي الخاص به:

  • التتبع -> العملية
  • معرف التتبع -> معرف العملية
  • سبان -> طلب أو تبعية

ضع الاعتبارات التالية في الاعتبار:

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

تسجيل منظم

لتسهيل تحليل السجلات، استخدم التسجيل المنظم عندما يمكنك ذلك. عند استخدام التسجيل المنظم، يكتب التطبيق السجلات بتنسيق منظم، مثل JSON، بدلا من إخراج سلاسل نصية غير منظمة. هناك العديد من مكتبات التسجيل المهيكلة المتاحة. على سبيل المثال، إليك عبارة تسجيل تستخدم مكتبة Serilog ل .NET Core:

public async Task<IActionResult> Put([FromBody]Delivery delivery, string id)
{
    logger.LogInformation("In Put action with delivery {Id}: {@DeliveryInfo}", id, delivery.ToLogInfo());

    ...
}

هنا، يتضمن استدعاء LogInformation معلمة Id ومعلمة DeliveryInfo. عند استخدام التسجيل المنظم، لا يتم استنتاج هذه القيم في سلسلة الرسالة. بدلا من ذلك، يبدو إخراج السجل كما يلي:

{"@t":"2019-06-13T00:57:09.9932697Z","@mt":"In Put action with delivery {Id}: {@DeliveryInfo}","Id":"36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef","DeliveryInfo":{...

هذه سلسلة JSON، حيث @t يكون الحقل طابعا زمنيا، @mt هي سلسلة الرسالة، وأزواج المفاتيح/القيم المتبقية هي المعلمات. يؤدي إخراج تنسيق JSON إلى تسهيل الاستعلام عن البيانات بطريقة منظمة. على سبيل المثال، يبحث استعلام Log Analytics التالي، المكتوب بلغة طلب البحث Kusto، عن مثيلات هذه الرسالة المعينة من جميع الحاويات المسماة fabrikam-delivery:

traces
| where customDimensions.["Kubernetes.Container.Name"] == "fabrikam-delivery"
| where customDimensions.["{OriginalFormat}"] == "In Put action with delivery {Id}: {@DeliveryInfo}"
| project message, customDimensions["Id"], customDimensions["@DeliveryInfo"]

إذا قمت بعرض النتيجة في مدخل Microsoft Azure، يمكنك أن ترى أن DeliveryInfo هو سجل منظم يحتوي على التمثيل التسلسلي للنموذج DeliveryInfo :

Screenshot that shows the Log Analytics workspace.

إليك JSON من هذا المثال:

{
  "Id": "36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef",
  "Owner": {
    "UserId": "user id for logging",
    "AccountId": "52dadf0c-0067-43e7-af76-86e32b48bc5e"
  },
  "Pickup": {
    "Altitude": 0.29295161612934972,
    "Latitude": 0.26815900219052985,
    "Longitude": 0.79841844309047727
  },
  "Dropoff": {
    "Altitude": 0.31507750848078986,
    "Latitude": 0.753494655598651,
    "Longitude": 0.89352830773849423
  },
  "Deadline": "string",
  "Expedited": true,
  "ConfirmationRequired": 0,
  "DroneId": "AssignedDroneId01ba4d0b-c01a-4369-ba75-51bde0e76cc9"
}

تشير العديد من رسائل السجل إلى بداية أو نهاية وحدة العمل، أو تقوم بتوصيل كيان أعمال بمجموعة من الرسائل والعمليات من أجل التتبع. في كثير من الحالات، يعد إثراء نطاق OpenTelemetry وعناصر الطلب نهجا أفضل من تسجيل بدء العملية ونهاائها فقط. يؤدي القيام بذلك إلى إضافة هذا السياق إلى جميع التتبعات المتصلة والعمليات التابعة، ويضع هذه المعلومات في نطاق العملية الكاملة. تدعم مجموعات OpenTelemetry SDK للغات المختلفة إنشاء امتدادات أو إضافة سمات مخصصة على الامتدادات. على سبيل المثال، تستخدم التعليمات البرمجية التالية Java OpenTelemetry SDK، والتي يدعمها Application Insights. يمكن إثراء نطاق أصل موجود (على سبيل المثال، نطاق طلب مقترن باستدعاء وحدة تحكم REST وتم إنشاؤه بواسطة إطار عمل الويب المستخدم) بمعرف كيان مقترن به، كما هو موضح هنا:

import io.opentelemetry.api.trace.Span;

// ...

Span.current().setAttribute("A1234", deliveryId);

تقوم هذه التعليمة البرمجية بتعيين مفتاح أو قيمة على النطاق الحالي، والذي يرتبط بالعمليات ورسائل السجل التي تحدث ضمن هذا النطاق. تظهر القيمة في كائن طلب Application Insights، كما هو موضح هنا:

requests
| extend deliveryId = tostring(customDimensions.deliveryId)  // promote to column value (optional)
| where deliveryId == "A1234"
| project timestamp, name, url, success, resultCode, duration, operation_Id, deliveryId

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

requests
| extend deliveryId = tostring(customDimensions.deliveryId)  // promote to column value (optional)
| where deliveryId == "A1234"
| project deliveryId, operation_Id, requestTimestamp = timestamp, requestDuration = duration  // keep some request info
| join kind=inner traces on operation_Id   // join logs only for this deliveryId
| project requestTimestamp, requestDuration, logTimestamp = timestamp, deliveryId, message

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

تتبع موزع

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

مثال على التتبع الموزع

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

Diagram that shows the architecture of a drone delivery application.

في هذا السيناريو، تتضمن المعاملة الموزعة الخطوات التالية:

  1. تضع خدمة الاستيعاب رسالة على قائمة انتظار ناقل خدمة Azure.
  2. تسحب خدمة سير العمل الرسالة من قائمة الانتظار.
  3. تستدعي خدمة سير العمل ثلاث خدمات خلفية لمعالجة الطلب (جدولة الطائرات بدون طيار والحزمة والتسليم).

تظهر لقطة الشاشة التالية خريطة التطبيق لتطبيق تسليم الطائرات بدون طيار. تُظهر هذه الخريطة استدعاءات نقطة نهاية API العامة التي تؤدي إلى سير عمل يتضمن خمس خدمات مصغرة.

Screenshot that shows the application map for the drone delivery application.

تُظهر الأسهم من fabrikam-workflow وfabrikam-ingestion إلى قائمة انتظار ناقل خدمة Microsoft Azure مكان إرسال الرسائل واستلامها. لا يمكنك معرفة الخدمة التي ترسل الرسائل وأيها تتلقى من الرسم التخطيطي. تظهر الأسهم فقط أن كلتا الخدمتين تتصلان بناقل خدمة Microsoft Azure. ولكن معلومات حول الخدمة التي يتم إرسالها والتي يتم تلقيها متاحة في التفاصيل:

Screenshot that shows the application map details.

نظرا لأن كل مكالمة تتضمن معرف عملية، يمكنك أيضا عرض الخطوات الشاملة لمعاملة واحدة، بما في ذلك معلومات التوقيت ومكالمات HTTP في كل خطوة. فيما يلي تصور معاملة من هذا القبيل:

Screenshot that shows an end-to-end transaction.

تظهر هذه المرئيات الخطوات من خدمة الاستيعاب إلى قائمة الانتظار، ومن قائمة الانتظار إلى خدمة سير العمل، ومن خدمة سير العمل إلى الخدمات الخلفية الأخرى. الخطوة الأخيرة هي خدمة سير العمل التي تضع علامة على رسالة ناقل خدمة Microsoft Azure على أنها مكتملة.

يوضح هذا المثال المكالمات إلى خدمة خلفية تفشل:

Screenshot that shows an application map with errors.

توضح هذه الخريطة فشل جزء كبير (36٪) من المكالمات إلى خدمة جدولة الطائرات بدون طيار خلال فترة الاستعلام. تكشف طريقة عرض المعاملة الشاملة عن حدوث استثناء عند إرسال طلب HTTP PUT إلى الخدمة:

Screenshot of the end-to-end transaction. It shows that an exception occurs when an HTTP PUT request is sent to the service.

إذا قمت بالتعمق أكثر، يمكنك أن ترى أن الاستثناء هو استثناء مأخذ التوصيل: "لا يوجد مثل هذا الجهاز أو العنوان."

Fabrikam.Workflow.Service.Services.BackendServiceCallFailedException: 
No such device or address 
---u003e System.Net.Http.HttpRequestException: No such device or address 
---u003e System.Net.Sockets.SocketException: No such device or address

يشير هذا الاستثناء إلى أن الخدمة الخلفية غير قابلة للوصول. في هذه المرحلة، يمكنك استخدام kubectl لعرض تكوين التوزيع. في هذا المثال، لا يتم حل اسم مضيف الخدمة بسبب خطأ في ملفات تكوين Kubernetes. تحتوي المقالة Debug Services في وثائق Kubernetes على تلميحات لتشخيص هذا النوع من الأخطاء.

فيما يلي بعض الأسباب الشائعة للأخطاء:

  • أخطاء التعليمة البرمجية. قد تظهر هذه الأخطاء على النحو التالي:
    • الاستثناءات. ابحث في سجلات Application Insights لعرض تفاصيل الاستثناءات.
    • فشلت عملية. انظر إلى حالة الحاوية والقاعدة، واعرض سجلات الحاوية أو تتبعات Application Insights.
    • أخطاء HTTP 5xx .
  • استنفاد الموارد:
    • ابحث عن التقييد (HTTP 429) أو طلب المهلات.
    • فحص مقاييس الحاوية لوحدة المعالجة المركزية والذاكرة والقرص.
    • انظر إلى التكوينات لحدود موارد الحاوية والـpod.
  • اكتشاف الخدمة. افحص تكوين خدمة Kubernetes وتعيينات المنافذ.
  • عدم تطابق API. ابحث عن أخطاء HTTP 400. إذا تم إصدار واجهات برمجة التطبيقات، فانظر إلى الإصدار الذي يتم استدعاؤه.
  • خطأ في سحب صورة حاوية. انظر إلى مواصفات البود. تأكد أيضا من أن نظام المجموعة مصرح له بالسحب من سجل الحاوية.
  • مشاكل التحكم في الوصول استنادا إلى الدور.

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

تعرَّف على المزيد حول الميزات الموجودة في Azure Monitor التي تدعم مراقبة التطبيقات على AKS: