مشاركة عبر

مراقبة Azure Service Fabric

  • مقالة

توضح هذه المقالة ما يلي:

  • أنواع بيانات المراقبة التي يمكنك جمعها لهذه الخدمة.
  • طرق لتحليل تلك البيانات.

إشعار

إذا كنت على دراية بهذه الخدمة و/أو Azure Monitor وتريد فقط معرفة كيفية تحليل بيانات المراقبة، فشاهد قسم Analyze بالقرب من نهاية هذه المقالة.

عندما يكون لديك تطبيقات وعمليات أعمال مهمة تعتمد على موارد Azure، تحتاج إلى مراقبة النظام والحصول على تنبيهات له. تجمع خدمة Azure Monitor المقاييس والسجلات وتجمعها من كل مكون من مكونات النظام. يوفر لك Azure Monitor طريقة عرض التوفر والأداء والمرونة، ويعلمك بالمشكلات. يمكنك استخدام مدخل Microsoft Azure أو PowerShell أو Azure CLI أو REST API أو مكتبات العميل لإعداد بيانات المراقبة وعرضها.

مراقبة Azure Service Fabric

يحتوي Azure Service Fabric على الطبقات التالية التي يمكنك مراقبتها:

  • مراقبة التطبيق: التطبيقات التي تعمل على العقد. يمكنك مراقبة التطبيقات باستخدام مفتاح Application Insights أو SDK أو EventStore أو تسجيل ASP.NET Core.
  • مراقبة النظام الأساسي (نظام المجموعة): مقاييس العميل والسجلات والأحداث للنظام الأساسي أو عقد نظام المجموعة ، بما في ذلك مقاييس الحاوية. تختلف المقاييس والسجلات لعقد Linux أو Windows.
  • مراقبة البنية الأساسية (الأداء): عدادات صحة الخدمة والأداء للبنية الأساسية للخدمة.

يمكنك مراقبة كيفية استخدام التطبيقات الخاصة بك، والإجراءات التي اتخذتها منصة Service Fabric، واستخدام الموارد الخاصة بك مع عدادات الأداء، والصحة العامة للمجموعة الخاصة بك. توفر سجلات Azure Monitor وApplication Insights تكاملا مضمنا مع Service Fabric.

مستكشف Service Fabric

Service Fabric Explorer، وهو تطبيق سطح مكتب ل Windows وmacOS وLinux، هو أداة مفتوحة المصدر لفحص أنظمة مجموعات Azure Service Fabric وإدارتها. لتمكين الأتمتة، يمكن أيضا تنفيذ كل إجراء يمكن اتخاذه من خلال Service Fabric Explorer من خلال PowerShell أو واجهة برمجة تطبيقات REST.

مراقبة التطبيق

تتعقب مراقبة التطبيق كيفية استخدام ميزات التطبيق ومكوناته. تريد مراقبة تطبيقاتك للتأكد من اكتشاف المشكلات التي تؤثر في المستخدمين. تقع مسؤولية مراقبة التطبيق على عاتق المستخدمين الذين يقومون بتطوير تطبيق وخدماته نظراً لتفرده من ناحية منطق تسلسل العمل لتطبيقك. يمكن أن تكون مراقبة تطبيقاتك مفيدة في السيناريوهات التالية:

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

الشيء العظيم الذي تقدمه مراقبة التطبيق هو تمكين المطورين من استخدام أي أدوات وإطار عمل يرغبون فيه لأنها متواجدة دائماً في سياق تطبيقك! يمكنك معرفة المزيد حول حل Azure لمراقبة التطبيق باستخدام Azure Monitor Application Insights في تحليل الأحداث باستخدام Application Insights.

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

تسجيل التطبيق

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

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

  • Application Insights SDK: يتمتع Application Insights بتكامل غني مع Service Fabric خارج الصندوق. يمكن للمستخدمين إضافة حزم AI Service Fabric nuget وتلقي البيانات والسجلات التي تم إنشاؤها وجمعها القابلة للعرض في مدخل Azure. بالإضافة إلى ذلك، يتم تشجيع المستخدمين على إضافة بيانات تتبع الاستخدام الخاصة بهم من أجل تشخيص وتصحيح تطبيقاتهم وتتبع الخدمات وأجزاء تطبيقاتهم الأكثر استخداماً. توفر فئة TelemetryClient في عدة تطوير البرامج العديد من الطرق لتتبع بيانات تتبع الاستخدام في تطبيقاتك. لمزيد من المعلومات، راجع تحليل الأحداث والتصور باستخدام Application Insights.

    تحقق من مثال على كيفية وضع علامة وإضافة رؤى التطبيق إلى التطبيق الخاص بك في البرنامج التعليمي لدينا لمراقبة وتشخيص تطبيق .NET.

  • EventSource: عند إنشاء حل Service Fabric من قالب في Visual Studio، يتم إنشاء فئة مشتقة من EventSource (ServiceEventSource أو ActorEventSource). يتم إنشاء قالب، حيث يمكنك إضافة أحداث للتطبيق أو الخدمة. يجب أن يكون اسم EventSource فريداً ويجب إعادة تسميته من سلسلة القالب الافتراضي MyCompany-<solution>-<project>. يؤدي وجود تعريفات EventSource متعددة تستخدم نفس الاسم إلى حدوث مشكلة في وقت التشغيل. يجب أن يكون لكل حدث محدد معرف فريد. إذا لم يكن المعرف فريداً، يحدث فشل في وقت التشغيل. تقوم بعض المؤسسات بتعيين نطاقات القيم مسبقاً للمعرفات لتجنب التعارضات بين فرق التطوير المنفصلة. لمزيد من المعلومات، راجع مدونة Vance أو وثائق MSDN.

  • ASP.NET تسجيل Core: من المهم التخطيط بعناية لكيفية وضع علامة على التعليمات البرمجية الخاصة بك. يمكن أن يساعدك تقرير عن حالة النظام الصحيح على تجنب زعزعة استقرار قاعدة التعليمات البرمجية الخاصة بك، ثم الحاجة إلى إعادة وضع علامة على التعليمات البرمجية. لتقليل المخاطر، يمكنك اختيار مكتبة تقرير عن حالة النظام مثل Microsoft.Extensions.Loggging، وهي جزء من Microsoft ASP.NET Core. يحتوي ASP.NET Core على واجهة ILogger يمكنك استخدامها مع الموفر الذي تختاره، مع تقليل التأثير على التعليمات البرمجية الموجودة. يمكنك استخدام التعليمة البرمجية في ASP.NET Core على Windows وLinux، وفي .NET Framework الكامل، بحيث يتم توحيد تعليمة تقرير عن حالة النظام البرمجية الخاصة بك.

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

مراقبة النظام الأساسي (نظام المجموعة)

يتحكم المستخدم في بيانات تتبع الاستخدام التي تأتي من تطبيقه نظراً لأن المستخدم يكتب التعليمة البرمجية نفسها، ولكن ماذا عن التشخيصات من النظام الأساسي لـ Service Fabric؟ يتمثل أحد أهداف Service Fabric في الحفاظ على مرونة التطبيقات في مواجهة فشل الأجهزة. يتم تحقيق هذا الهدف من خلال قدرة خدمات النظام الأساسي على اكتشاف مشكلات البنية الأساسية وأحمال العمل سريعة تجاوز الفشل إلى العُقد الأخرى في المجموعة. ولكن في هذه الحالة بالذات، ماذا لو كانت خدمات النظام نفسها تواجه مشكلات؟ أو تم انتهاك قواعد وضع الخدمات أثناء محاولتها نشر حمل عمل أو نقله؟ يوفر Service Fabric تشخيصات لهذه الأمور وأكثر للتأكد من اطلاعك على النشاط الذي يحدث في مجموعتك. تتضمن بعض عينات سيناريوهات مراقبة نظام مجموعة ما يلي:

لمزيد من المعلومات حول مراقبة النظام الأساسي (نظام المجموعة)، راجع مراقبة نظام المجموعة.

أحداث Service Fabric

يوفر Service Fabric مجموعة شاملة من أحداث التشخيص خارج الصندوق، والتي يمكنك الوصول إليها من خلال EventStore أو قناة الحدث التشغيلي التي يعرضها النظام الأساسي. توضح أحداث Service Fabric هذه الإجراءات التي يقوم بها النظام الأساسي على كيانات مختلفة مثل العقد والتطبيقات والخدمات والأقسام. تتوفر نفس الأحداث على مجموعات كل من Windows وLinux.

  • قنوات أحداث Service Fabric: في Windows، تتوفر أحداث Service Fabric من موفر ETW واحد مع مجموعة من القنوات ذات الصلة logLevelKeywordFilters المستخدمة للانتقاء بين قنوات التشغيل والبيانات والمراسلة. هذه هي الطريقة التي نفصل بها أحداث Service Fabric الصادرة ليتم تصفيتها حسب الحاجة. على نظام التشغيل Linux، تأتي أحداث Service Fabric من خلال LTTng، ويتم وضعها في جدول تخزين واحد، حيث يمكن تصفيتها حسب الحاجة. تحتوي هذه القنوات على أحداث مجمعة ومنظمة يمكن استخدامها لفهم حالة مجموعتك بشكل أفضل. يتم تمكين التشخيصات بشكل افتراضي في وقت إنشاء نظام المجموعة، والتي تنشئ جدول تخزين Azure حيث يتم إرسال الأحداث من هذه القنوات إليك للاستعلام عنها في المستقبل.

  • EventStore هي ميزة تعرض أحداث النظام الأساسي ل Service Fabric في Service Fabric Explorer وبشكل برمجي من خلال واجهة برمجة تطبيقات REST لمكتبة عميل Service Fabric. يمكنك مشاهدة عرض لقطة لما يحدث في نظام المجموعة الخاص بك لكل عقدة وخدمة وتطبيق واستعلام استنادا إلى وقت الحدث. تتوفر واجهات برمجة تطبيقات EventStore فقط لمجموعات Windows التي تعمل على Azure. على أجهزة Windows، يتم إدخال هذه الأحداث في سجل الأحداث، حتى تتمكن من رؤية أحداث Service Fabric في عارض الأحداث.

تظهر لقطة الشاشة علامة التبويب EVENTS في جزء Nodes عدة أحداث، بما في ذلك حدث NodeDown.

تُقدم التشخيصات في شكل مجموعة شاملة من الأحداث غير التقليدية. توضح أحداث Service Fabric هذه الإجراءات التي تقوم بها المنصة على كيانات مختلفة، مثل العقد، والتطبيقات، والخدمات، والأقسام، وما إلى ذلك. في السيناريو الأخير أعلاه، إذا كانت العقدة متوقفة عن التشغيل، فسيصدر النظام الأساسي حدثاً NodeDown، ويمكن إعلامك على الفور بواسطة أداة المراقبة التي تختارها. تتضمن الأمثلة الشائعة الأخرى ApplicationUpgradeRollbackStarted أو PartitionReconfigured أثناء تجاوز الفشل. تتوفر نفس الأحداث على مجموعات كل من Windows وLinux.

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

مراقبة السلامة

يتضمن النظام الأساسي لـ Service Fabric نموذجاً صحياً يوفر تقارير صحية قابلة للتوسيع لحالة الكيانات في نظام المجموعة. لكل عقدة، أو تطبيق، أو خدمة، أو قسم، أو نسخة متماثلة، أو مثيل حالة صحية قابلة للتحديث باستمرار. يمكن أن تكون الحالة الصحية إما "OK"، أو "Warning"، أو "Error". فكر في أحداث Service Fabric كأفعال تقوم بها المجموعة لكيانات مختلفة، وفكر في الصحة كصفة لكل كيان. في كل مرة تنتقل فيها صحة كيان معين، سيتم أيضاً إصدار حدث. وبهذه الطريقة، يمكنك إعداد الاستعلامات والتنبيهات للأحداث الصحية في أداة المراقبة التي تختارها، تماماً مثل أي حدث آخر.

وبالإضافة إلى ذلك، نسمح للمستخدمين بتجاوز صحة الكيانات. إذا كان تطبيقك يمر بترقية وفشلت اختبارات التحقق من الصحة، يمكنك الكتابة إلى Service Fabric Health باستخدام Health API للإشارة إلى أن تطبيقك لم يعد سليما، وسيقوم Service Fabric تلقائيا باستعادة الترقية! لمعرفة المزيد عن النموذج الصحي، راجع مقدمة مراقبة صحة Service Fabric

لقطة شاشة للوحة معلومات صحة SFX.

هيئات المراقبة

بشكل عام، هيئة الرقابة هي خدمة منفصلة تراقب الصحة والحمل عبر الخدمات، ونقاط نهاية أدوات اختبار الاتصال، وتبلغ عن الأحداث الصحية غير المتوقعة في المجموعة. يمكن أن يساعد ذلك في منع أخطاء قد لا تُكتشف استناداً إلى أداء خدمة واحدة فقط. تعد هيئات المراقبة أيضاً مكاناً جيداً لاستضافة التعليمة البرمجية التي تنفذ إجراءات علاجية لا تتطلب تفاعل المستخدم، مثل تنظيف ملفات السجل في التخزين على فترات زمنية معينة. إذا كنت تريد خدمة هيئة مراقبة SF مفتوحة المصدر مُنفذة بالكامل وتتضمن نموذجاً سهل الاستخدام لقابلية توسيع هيئة المراقبة ويمكن تشغيلها في كل من أنظمة مجموعات Windows وLinux، فراجع مشروع FabricObserver. FabricObserver هو برنامج جاهز للإنتاج. نحن نشجعك على توزيع FabricObserver في أنظمة مجموعات الاختبار والإنتاج الخاصة بك وتوسيعه لتلبية احتياجاتك إما من خلال نموذج المكون الإضافي الخاص بالبرنامج أو عن طريق تفريعه وكتابة مراقبيك المضمنين. النهج الأول (المكونات الإضافية) هو النهج الموصى به.

مراقبة البنية الأساسية (الأداء)

الآن بعد أن قمنا بتغطية التشخيصات في تطبيقك والنظام الأساسي، كيف نعرف أن الأجهزة تعمل كما هو متوقع؟ تُعد مراقبة البنية التحتية الأساسية جزءاً أساسياً من فهم حالة مجموعتك واستخدام الموارد. يعتمد قياس أداء النظام على العديد من العوامل التي يمكن أن تكون ذاتية اعتماداً على أحمال العمل الخاصة بك. عادة ما تُقاس هذه العوامل من خلال عدادات الأداء. يمكن أن تأتي عدادات الأداء هذه من مجموعة متنوعة من المصادر، بما في ذلك نظام التشغيل، أو إطار عمل .NET، أو النظام الأساسي لـ Service Fabric نفسه. بعض السيناريوهات التي ستكون مفيدة فيها هي:

  • هل أستخدم جهازي بكفاءة؟ هل تريد استخدام الأجهزة الخاصة بك بنسبة 90٪ CPU أو 10% CPU. يكون هذا مفيداً عند تحجيم مجموعتك، أو تحسين عمليات التطبيق الخاص بك.
  • هل يمكنني التنبؤ بمشكلات البنية الأساسية بشكل استباقي؟ - تسبق العديد من المشكلات تغييرات مفاجئة (انخفاضات) في الأداء؛ ولذلك يمكنك استخدام عدادات الأداء مثل إدخال/إخراج الشبكة واستخدام وحدة المعالجة المركزية للتنبؤ بالمشكلات وتشخيصها بشكل استباقي.

يمكن العثور على قائمة بعدادات الأداء التي يجب جمعها على مستوى البنية الأساسية في مقاييس الأداء.

يوصى بسجلات Azure Monitor لمراقبة الأحداث على مستوى نظام المجموعة. بعد تكوين عامل Log Analytics مع مساحة العمل الخاصة بك، يمكنك جمع:

  • مقاييس الأداء مثل استخدام وحدة المعالجة المركزية.
  • عدادات أداء .NET مثل استخدام وحدة المعالجة المركزية على مستوى العملية.
  • عدادات أداء Service Fabric مثل عدد الاستثناءات من خدمة موثوق بها.
  • مقاييس الحاوية مثل استخدام وحدة المعالجة المركزية.

أنواع الموارد

يستخدم Azure مفهوم أنواع الموارد والمعرفات لتحديد كل شيء في الاشتراك. أنواع الموارد هي أيضا جزء من معرفات الموارد لكل مورد يعمل في Azure. على سبيل المثال، نوع مورد واحد لجهاز ظاهري هو Microsoft.Compute/virtualMachines. للحصول على قائمة بالخدمات وأنواع الموارد المقترنة بها، راجع موفري الموارد.

ينظم Azure Monitor بالمثل بيانات المراقبة الأساسية في مقاييس وسجلات استنادا إلى أنواع الموارد، وتسمى أيضا مساحات الأسماء. تتوفر مقاييس وسجلات مختلفة أنواع موارد مختلفة. قد تكون خدمتك مقترنة بأكثر من نوع مورد واحد.

لمزيد من المعلومات حول أنواع الموارد ل Azure Service Fabric، راجع مرجع بيانات مراقبة Service Fabric.

تخزين البيانات.

بالنسبة إلى Azure Monitor:

  • يتم تخزين بيانات المقاييس في قاعدة بيانات مقاييس Azure Monitor.
  • يتم تخزين بيانات السجل في مخزن سجلات Azure Monitor. Log Analytics هي أداة في مدخل Microsoft Azure يمكنها الاستعلام عن هذا المتجر.
  • سجل نشاط Azure هو مخزن منفصل بواجهة خاصة به في مدخل Microsoft Azure.

يمكنك اختياريا توجيه بيانات سجل المقاييس والنشاط إلى مخزن سجلات Azure Monitor. يمكنك بعد ذلك استخدام Log Analytics للاستعلام عن البيانات وربطها ببيانات السجل الأخرى.

يمكن للعديد من الخدمات استخدام إعدادات التشخيص لإرسال بيانات القياس والسجل إلى مواقع التخزين الأخرى خارج Azure Monitor. تتضمن الأمثلة تخزين Azure وأنظمة الشركاء المستضافة وأنظمة الشركاء غير Azure باستخدام مراكز الأحداث.

للحصول على معلومات مفصلة حول كيفية تخزين Azure Monitor للبيانات، راجع النظام الأساسي لبيانات Azure Monitor.

مقاييس النظام الأساسي ل Azure Monitor

يوفر Azure Monitor مقاييس النظام الأساسي للعديد من الخدمات. للحصول على قائمة بجميع المقاييس، من الممكن جمعها لجميع الموارد في Azure Monitor، راجع المقاييس المدعومة في Azure Monitor.

لا تجمع هذه الخدمة مقاييس النظام الأساسي.

المقاييس غير المستندة إلى Azure Monitor

توفر هذه الخدمة مقاييس أخرى غير مضمنة في قاعدة بيانات مقاييس Azure Monitor.

مقاييس نظام التشغيل الضيف

يجب جمع مقاييس نظام التشغيل الضيف (OS) الذي يعمل على عقد مجموعة Service Fabric من خلال عامل واحد أو أكثر يعمل على نظام التشغيل الضيف. تتضمن قياسات نظام التشغيل الضيف عدادات الأداء التي تتعقب نسبة المعالج الضيف أو استخدام الذاكرة، وكلاهما يُستخدم بشكل متكرر في التحجيم التلقائي أو التنبيه.

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

إشعار

يحل عامل Azure Monitor محل ملحق تشخيص Azure وعامل Log Analytics لتوجيه نظام التشغيل الضيف. لمزيد من المعلومات، راجع نظرة عامة على وكلاء Azure Monitor.

سجلات موارد Azure Monitor

توفر سجلات الموارد نظرة ثاقبة على العمليات التي تم إجراؤها بواسطة مورد Azure. يتم إنشاء السجلات تلقائيا، ولكن يجب توجيهها إلى سجلات Azure Monitor لحفظها أو الاستعلام عنها. يتم تنظيم السجلات في فئات. يمكن أن تحتوي مساحة الاسم المحددة على فئات سجل موارد متعددة يمكنك جمعها.

لا تجمع هذه الخدمة سجلات الموارد، ولكن يمكنك العثور على معلومات عنها في مراقبة البيانات من موارد Azure.

سجلات وأحداث Service Fabric

يمكن ل Service Fabric جمع السجلات التالية:

  • بالنسبة لمجموعات Windows، يمكنك إعداد مراقبة نظام المجموعة باستخدام Diagnostics Agent وسجلات Azure Monitor.
  • بالنسبة لمجموعات Linux، تعد سجلات Azure Monitor أيضا الأداة الموصى بها لمراقبة النظام الأساسي والبنية التحتية في Azure. تتطلب تشخيصات نظام Linux الأساسي تكوينا مختلفا. لمزيد من المعلومات، راجع أحداث مجموعة Service Fabric Linux في Syslog.
  • يمكنك تكوين عامل Azure Monitor لإرسال سجلات نظام التشغيل الضيف إلى سجلات Azure Monitor، حيث يمكنك الاستعلام عنها باستخدام Log Analytics.
  • يمكنك كتابة سجلات حاوية Service Fabric إلى stdout أو stderr حتى تكون متوفرة في سجلات Azure Monitor.
  • يمكنك إعداد حل مراقبة الحاوية لسجلات Azure Monitor لعرض أحداث الحاوية.

حلول التسجيل الأخرى

على الرغم من أن الحلين الموصى بهما، سجلات Azure Monitor وApplication Insights، قد تم تضمينهما في التكامل مع Service Fabric، إلا أن العديد من الأحداث تتم كتابتها من خلال موفري ETW وهي قابلة للتوسعة مع حلول التسجيل الأخرى. يجب عليك أيضاً النظر في Elastic Stack (خاصة إذا كنت تفكر في تشغيل مجموعة في بيئة غير متصلة بالإنترنت) أو Dynatrace أو أي نظام أساسي آخر تفضله. للحصول على قائمة بالشركاء المتكاملين، راجع شركاء مراقبة Azure Service Fabric.

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

سجل الأنشطة Azure

يحتوي سجل النشاط على أحداث على مستوى الاشتراك تتعقب العمليات لكل مورد Azure كما هو ظاهر من خارج هذا المورد؛ على سبيل المثال، إنشاء مورد جديد أو بدء تشغيل جهاز ظاهري.

المجموعة: يتم إنشاء أحداث سجل النشاط تلقائيا وتجميعها في مخزن منفصل للعرض في مدخل Microsoft Azure.

التوجيه: يمكنك إرسال بيانات سجل النشاط إلى سجلات Azure Monitor حتى تتمكن من تحليلها جنبا إلى جنب مع بيانات السجل الأخرى. تتوفر أيضا مواقع أخرى مثل Azure Storage وAzure Event Hubs وبعض شركاء مراقبة Microsoft. لمزيد من المعلومات حول كيفية توجيه سجل النشاط، راجع نظرة عامة على سجل نشاط Azure.

تحليل بيانات المراقبة

هناك العديد من الأدوات لتحليل بيانات المراقبة.

أدوات Azure Monitor

يدعم Azure Monitor الأدوات الأساسية التالية:

  • مستكشف المقاييس، أداة في مدخل Microsoft Azure تسمح لك بعرض وتحليل المقاييس لموارد Azure. لمزيد من المعلومات، راجع تحليل المقاييس باستخدام مستكشف مقاييس Azure Monitor.

  • Log Analytics، أداة في مدخل Microsoft Azure تسمح لك بالاستعلام عن بيانات السجل وتحليلها باستخدام لغة استعلام Kusto (KQL). لمزيد من المعلومات، راجع البدء في استعلامات السجل في Azure Monitor.

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

تتضمن الأدوات التي تسمح بتصور أكثر تعقيدا ما يلي:

  • لوحات المعلومات التي تتيح لك دمج أنواع مختلفة من البيانات في جزء واحد في مدخل Microsoft Azure.
  • المصنفات والتقارير القابلة للتخصيص التي يمكنك إنشاؤها في مدخل Microsoft Azure. يمكن أن تتضمن المصنفات النص والمقاييس واستعلامات السجل.
  • Grafana، أداة منصة مفتوحة تتفوق في لوحات المعلومات التشغيلية. يمكنك استخدام Grafana لإنشاء لوحات معلومات تتضمن بيانات من مصادر متعددة غير Azure Monitor.
  • Power BI، خدمة تحليلات الأعمال التي توفر مرئيات تفاعلية عبر مصادر بيانات مختلفة. يمكنك تكوين Power BI لاستيراد بيانات السجل تلقائيًا من Azure Monitor للاستفادة من هذه المرئيات.

للحصول على نظرة عامة على سيناريوهات تحليلات مراقبة Service Fabric الشائعة، راجع تشخيص السيناريوهات الشائعة باستخدام Service Fabric.

أدوات تصدير Azure Monitor

يمكنك الحصول على البيانات من Azure Monitor في أدوات أخرى باستخدام الطرق التالية:

  • المقاييس: استخدم واجهة برمجة تطبيقات REST للمقاييس لاستخراج بيانات القياس من قاعدة بيانات مقاييس Azure Monitor. تدعم واجهة برمجة التطبيقات تعبيرات التصفية لتحسين البيانات التي تم استردادها. لمزيد من المعلومات، راجع مرجع Azure Monitor REST API.

  • السجلات: استخدم واجهة برمجة تطبيقات REST أو مكتبات العميل المقترنة.

  • خيار آخر هو تصدير بيانات مساحة العمل.

لبدء استخدام واجهة برمجة تطبيقات REST ل Azure Monitor، راجع معاينة واجهة برمجة تطبيقات REST لمراقبة Azure.

استعلامات Kusto

يمكنك تحليل بيانات المراقبة في مخزن Azure Monitor Logs / Log Analytics باستخدام لغة استعلام Kusto (KQL).

هام

عند تحديد Logs من قائمة الخدمة في المدخل، يفتح Log Analytics مع تعيين نطاق الاستعلام إلى الخدمة الحالية. يعني هذا النطاق أن استعلامات السجل ستتضمن بيانات من هذا النوع من الموارد فقط. إذا كنت ترغب في تشغيل استعلام يتضمن بيانات من خدمات Azure الأخرى، فحدد Logs من قائمة Azure Monitor . راجع نطاق الاستعلام عن السجل والزمن في Azure Monitor Log Analytics للحصول على التفاصيل.

للحصول على قائمة بالاستعلامات الشائعة لأي خدمة، راجع واجهة استعلامات Log Analytics.

نماذج الاستعلامات

ترجع الاستعلامات التالية أحداث Service Fabric، بما في ذلك الإجراءات على العقد. للحصول على استعلامات مفيدة أخرى، راجع أحداث Service Fabric.

إرجاع الأحداث التشغيلية المسجلة في الساعة الماضية:

ServiceFabricOperationalEvent
| where TimeGenerated > ago(1h)
| join kind=leftouter ServiceFabricEvent on EventId
| project EventId, EventName, TaskName, Computer, ApplicationName, EventMessage, TimeGenerated
| sort by TimeGenerated

إرجاع تقارير السلامة باستخدام HealthState == 3 (خطأ)، واستخراج المزيد من الخصائص EventMessage من الحقل:

ServiceFabricOperationalEvent
| join kind=leftouter ServiceFabricEvent on EventId
| extend HealthStateId = extract(@"HealthState=(\S+) ", 1, EventMessage, typeof(int))
| where TaskName == 'HM' and HealthStateId == 3
| extend SourceId = extract(@"SourceId=(\S+) ", 1, EventMessage, typeof(string)),
         Property = extract(@"Property=(\S+) ", 1, EventMessage, typeof(string)),
         HealthState = case(HealthStateId == 0, 'Invalid', HealthStateId == 1, 'Ok', HealthStateId == 2, 'Warning', HealthStateId == 3, 'Error', 'Unknown'),
         TTL = extract(@"TTL=(\S+) ", 1, EventMessage, typeof(string)),
         SequenceNumber = extract(@"SequenceNumber=(\S+) ", 1, EventMessage, typeof(string)),
         Description = extract(@"Description='([\S\s, ^']+)' ", 1, EventMessage, typeof(string)),
         RemoveWhenExpired = extract(@"RemoveWhenExpired=(\S+) ", 1, EventMessage, typeof(bool)),
         SourceUTCTimestamp = extract(@"SourceUTCTimestamp=(\S+)", 1, EventMessage, typeof(datetime)),
         ApplicationName = extract(@"ApplicationName=(\S+) ", 1, EventMessage, typeof(string)),
         ServiceManifest = extract(@"ServiceManifest=(\S+) ", 1, EventMessage, typeof(string)),
         InstanceId = extract(@"InstanceId=(\S+) ", 1, EventMessage, typeof(string)),
         ServicePackageActivationId = extract(@"ServicePackageActivationId=(\S+) ", 1, EventMessage, typeof(string)),
         NodeName = extract(@"NodeName=(\S+) ", 1, EventMessage, typeof(string)),
         Partition = extract(@"Partition=(\S+) ", 1, EventMessage, typeof(string)),
         StatelessInstance = extract(@"StatelessInstance=(\S+) ", 1, EventMessage, typeof(string)),
         StatefulReplica = extract(@"StatefulReplica=(\S+) ", 1, EventMessage, typeof(string))

احصل على الأحداث التشغيلية لـ Service Fabric مجمعة مع الخدمة والعقدة المحددة:

ServiceFabricOperationalEvent
| where ApplicationName  != "" and ServiceName != ""
| summarize AggregatedValue = count() by ApplicationName, ServiceName, Computer

التنبيهات

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

هناك العديد من مصادر التنبيهات الشائعة لموارد Azure. للحصول على أمثلة للتنبيهات الشائعة لموارد Azure، راجع نموذج استعلامات تنبيه السجل. يوفر موقع Azure Monitor Baseline Alerts (AMBA) طريقة شبه آلية لتنفيذ تنبيهات قياس النظام الأساسي الهامة ولوحات المعلومات والإرشادات. ينطبق الموقع على مجموعة فرعية موسعة باستمرار من خدمات Azure، بما في ذلك جميع الخدمات التي تعد جزءا من منطقة هبوط Azure (ALZ).

يوحد مخطط التنبيه الشائع استهلاك إعلامات تنبيه Azure Monitor. لمزيد من المعلومات، راجع مخطط التنبيه الشائع.

أنواع التنبيهات

يمكنك التنبيه على أي مقياس أو مصدر بيانات سجل في النظام الأساسي للبيانات Azure Monitor. هناك العديد من أنواع التنبيهات المختلفة اعتمادا على الخدمات التي تراقبها وبيانات المراقبة التي تجمعها. أنواع مختلفة من التنبيهات لها فوائد وعيوب مختلفة. لمزيد من المعلومات، راجع اختيار نوع تنبيه المراقبة الصحيح.

تصف القائمة التالية أنواع تنبيهات Azure Monitor التي يمكنك إنشاؤها:

  • تقيم التنبيهات القياسية مقاييس الموارد على فترات منتظمة. يمكن أن تكون المقاييس مقاييس النظام الأساسي أو المقاييس المخصصة أو السجلات من Azure Monitor المحولة إلى مقاييس أو مقاييس Application Insights. يمكن أن تطبق التنبيهات القياسية أيضا شروطا متعددة وحدا ديناميكيا.
  • تسمح تنبيهات السجل للمستخدمين باستخدام استعلام Log Analytics لتقييم سجلات الموارد بتردد محدد مسبقا.
  • يتم تشغيل تنبيهات سجل النشاط عند حدوث حدث سجل نشاط جديد يطابق الشروط المحددة. تنبيهات صحة الموارد وتنبيهات حالة الخدمة هي تنبيهات سجل النشاط التي تبلغ عن الخدمة وصحة الموارد.

تدعم بعض خدمات Azure أيضا تنبيهات الكشف الذكية أو تنبيهات Prometheus أو قواعد التنبيه الموصى بها.

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

قواعد تنبيه Service Fabric

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

نوع التنبيه شرط ‏‏الوصف
حدث العقدة العقدة تتعطل ServiceFabricOperationalEvent حيث EventID >= 25622 و EventID <= 25626. يتم العثور على معرفات الأحداث هذه في مرجع أحداث العقدة.
حدث التطبيق التراجع عن ترقية التطبيق ServiceFabricOperationalEvent حيث EventID == 29623 أو EventID == 29624. يتم العثور على معرفات الأحداث هذه في مرجع أحداث التطبيق.
صحة الموارد خدمة الترقية غير قابلة للوصول/غير متوفرة ينتقل نظام المجموعة إلى حالة UpgradeServiceUnreachable.

توصيات Advisor

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

لمزيد من المعلومات حول Azure Advisor، راجع نظرة عامة على Azure Advisor.

الآن بعد أن تجاوزنا كل مجال من مجالات المراقبة وسيناريوهات الأمثلة، إليك ملخصاً لأدوات مراقبة Azure والإعداد اللازم لمراقبة جميع المجالات أعلاه.

يمكنك أيضا استخدام نموذج قالب ARM وتعديله لأتمتة توزيع جميع الموارد والوكلاء الضروريين.

المحتوى ذو الصلة