القائمة الرئيسية

الصفحات

استكشاف الاختلافات بين المراقبة والملاحظة

 استكشاف الاختلافات بين المراقبة والملاحظة


المراقبة مقابل إمكانية الملاحظة - هل هناك فرق حتى وهل نظام المراقبة الخاص بك يمكن ملاحظته؟      

اكتسبت إمكانية المراقبة شعبية كبيرة في السنوات الأخيرة. تشجع نماذج DevOps الحديثة على بناء تطبيقات قوية من خلال دمج الأتمتة والبنية التحتية ككود والتطوير السريع. لتقييم صحة و "متانة" أنظمة تكنولوجيا المعلومات ، تستخدم الفرق الهندسية عادةً السجلات ، والمقاييس ،  والتتبعات ، التي تستخدمها أدوات المطورين المختلفة لتسهيل إمكانية الملاحظة. ولكن ما هي إمكانية المراقبة بالضبط ، وكيف تختلف عن المراقبة؟      
ما هي القدرة على الملاحظة؟ "إمكانية المراقبة  هي مقياس لمدى جودة استنتاج الحالات الداخلية لنظام ما من معرفة مخرجاته الخارجية." -   ويكيبيديا يسمح لنا النظام الذي يمكن ملاحظته بتقييم كيفية عمل النظام دون التدخل أو حتى التفاعل معه. ببساطة من خلال النظر إلى مخرجات النظام ( مثل السجلات والمقاييس والتتبعات ) ، يمكننا تقييم كيفية أداء هذا النظام.       
المراقبة مقابل المراقبة تم تقديم أحد أفضل التفسيرات حول المراقبة وإمكانية الملاحظة التي رأيتها في دورة عبر الإنترنت ،  "إنشاء تطبيقات Python الحديثة على AWS" ، من  قبل Morgan Willis ، كبير تقني السحابة في AWS.      

" المراقبة هي عملية جمع البيانات . 

ما هي أنواع البيانات التي نجمعها ، وماذا نفعل بالبيانات ، وما إذا كانت هذه البيانات جاهزة للتحليل أو المتاحة ، فهي قصة مختلفة. هذا هو المكان الذي تلعب فيه إمكانية الملاحظة. الملاحظة ليست فعلًا ، وليست شيئًا تفعله. بدلاً من ذلك ،   تعد إمكانية الملاحظة أكثر من خاصية للنظام ". -   مورغان ويليس وفقًا لهذا الشرح ، يمكن اعتبار أدوات مثل  CloudWatch  أو X-Ray كأدوات مراقبة أو تتبع. إنها تسمح لنا بجمع السجلات والمقاييس حول نظامنا وإرسال تنبيهات حول الأخطاء والحوادث. لذلك ، تعد المراقبة  جزءًا نشطًا من جمع  البيانات  التي ستساعدنا في تقييم صحة نظامنا وكيف تعمل مكوناته المختلفة معًا. بمجرد إنشاء المراقبة التي تجمع السجلات ومخرجات النظام والمقاييس والتتبعات باستمرار ،  يصبح نظامنا قابلاً للملاحظة .       
بصفتي مهندس بيانات ، أود أن أفكر في المراقبة باعتبارها جزء استيعاب البيانات من ETL (الاستخراج والتحويل والتحميل). بمعنى ، تقوم بجمع البيانات من مصادر متعددة ( السجلات والتتبعات والمقاييس ) وتضعها في بحيرة بيانات. بمجرد توفر كل هذه البيانات ، يمكن للمحلل الماهر اكتساب رؤى من تلك البيانات وإنشاء لوحات معلومات جميلة تحكي قصة تنقلها هذه البيانات.      
هذا هو جزء الملاحظة - اكتساب رؤى من البيانات المجمعة. و منصات قابلية الملاحظة  مثل  Dashbird تلعب دور المحلل المهرة . أنها توفر لك تصورات ورؤى حول صحة نظامك.       
ستزودك المراقبة بمعلومات حول نظامك  وتتيح لك معرفة ما إذا كان هناك فشل ، بينما  تمنحك خاصية المراقبة  طريقة سهلة لفهم  مكان ولماذا حدث هذا الفشل ، وما سبب ذلك. المراقبة هي شرط أساسي للملاحظة. النظام الذي لا نراقبه لا يمكن ملاحظته.      أمثلة الرصد مقابل المراقبة      
الغرض النهائي من المراقبة هو التحكم في صحة النظام من خلال الجمع الفعال  لسجلات الأخطاء ومقاييس النظام ثم الاستفادة منها للتنبيه بشأن الحوادث. هذا يعنى:      
تتبع  الأخطاء  و  تنبيه  عنهم في أقرب وقت حدوثها، وتتبع مقاييس  حول  استخدام وحدة المعالجة المركزية  أو  حركة مرور الشبكة  إلى وقت لاحق مراقبة ما إذا كانت الموارد حساب محددة هي صحية أم لا، ردا على  انقطاع التيار و  الحوادث الأمنية  من خلال تنبيه، وأجهزة الإنذار، والإخطارات.      
على الرغم من أن المراقبة عملية نشطة ، فإن AWS تعتني بذلك تلقائيًا عندما نستخدم CloudWatch أو X-Ray.      
الملاحظة      ا
لغرض من إمكانية الملاحظة هو  استخدام مخرجات النظام  لجمع الأفكار والتصرف بناءً عليها . أمثلة:      
تحديد  النسبة المئوية للأخطاء  عبر جميع استدعاءات الوظائف أو الحاويات ، تحديد  الاختناقات  في الخدمات المصغرة من خلال مراقبة الآثار التي تظهر زمن الانتقال بين استدعاءات الوظائف الفردية والانتقال بين المكونات ، تحديد  أنماط  وقت حدوث الأخطاء والاختناقات واستخدام الأفكار لاتخاذ إجراءات من أجل منع مثل هذه السيناريوهات في المستقبل ، قياس وتقييم  أداء  التطبيق بأكمله ، التعرف على  البدايات الباردة ، تحديد مقدار  الذاكرة التي  يستهلكها تطبيقك ، تحديد متى و  متى  تشغيل التعليمات البرمجية الخاصة بك، تحديد مقدار  التكاليف  التي يتم تكبدها لكل مورد معين ، تحديد  القيم المتطرفة  - على سبيل المثال. استدعاء وظيفة محددة استغرق وقتًا أطول بكثير من المعتاد ، تحديد كيفية تأثير  التغييرات  على أحد المكونات على أجزاء أخرى من النظام ، تحديد واستكشاف أخطاء  تدفق حركة المرور  المتدفقة عبر خدماتنا المصغرة وإصلاحها ، تحديد  كيفية أداء النظام بمرور الوقت  - كم عدد استدعاءات كل وظيفة نراها يوميًا أو أسبوعيًا أو شهريًا ، وعدد الاستدعاءات  الناجحة منها. إمكانية مراقبة الخدمات المصغرة بدون خادم على الرغم من أن الخدمات المصغرة بدون خادم تقدم عددًا  لا يحصى من الفوائد من  حيث الفصل ، وتقليل التبعيات بين المكونات الفردية ، ودورات التطوير الشاملة الأسرع ، فإن التحدي الأكبر هو  التأكد من أن جميع هذه "الأجزاء المتحركة" الصغيرة تعمل بشكل جيد معًا . من غير العملي للغاية ، إن لم يكن من المستحيل ، تتبع جميع الخدمات المصغرة من خلال البحث يدويًا عن السجلات والمقاييس والتتبعات المنتشرة عبر خدمات السحابة المختلفة.       
عند النظر إلى AWS ، سيتعين عليك الانتقال إلى AWS للاطلاع على السجلات ، والعثور على مجموعة سجلات وظيفة Lambda الخاصة بك ، ثم العثور على السجلات التي تهتم بها حقًا. وبعد ذلك ، لمشاهدة آثار واجهة برمجة التطبيقات المقابلة ، يمكنك الانتقال إلى X- Ray أو CloudTrail ثم ابحث مرة أخرى عبر مئات المكونات المحتملة للعثور على المكون الذي تريد التحقيق فيه. كما ترى ، فإن العثور على سجلات وآثار كل مكون والوصول إليها يستغرق وقتًا طويلاً. بالإضافة إلى ذلك ، لا يمنحك تصحيح أخطاء الأجزاء المفردة طريقة عرض "الصورة الكبيرة" لكيفية عمل هذه المكونات معًا.      
بكل بساطة، وتحصل على  قابلية الملاحظة  في التطبيق الخاص بك عن طريق  الحياكة مراقبة معا  مع  تنبيه  في حين وجود واضح  الحل التصحيح التي توفر وضوح للبيانات الخاصة بك. سيؤدي فقدان جانب واحد فقط من هذه الجوانب إلى وضعك في وضع غير مؤات ، حيث تطارد ذيلك في محاولة لمعرفة الخطأ الذي حدث في تطبيقك. انها  لا يكفي  أن يتم إعلامك في كل مرة فواصل شيء إلى أسفل.      
لا يمتلك أي منهما البصيرة لمعرفة متى يكون هناك شيء على وشك الحدوث. يجب أن تكون قادرًا على  تحديد المشكلة داخل النظام الأساسي الخاص بك بكفاءة.      
مع البنية المتزايدة للخدمات المصغرة ، نحتاج إلى طريقة أسهل ( آلية ) لإضافة إمكانية المراقبة إلى النظام البيئي الذي لا يحتوي على خادم.      
كيف يفعل تويتر ذلك؟     
 إليك مثال على خدمة مألوفة لدينا جميعًا - Twitter. كما قد تتخيل أن منتجًا مثل  Twitter به الكثير من الأجزاء المتحركة  وعندما يتعطل شيء ما   ، قد يكون من  الصعب فهم سبب المشكلة  أو  سببها . تخيل وجود 350 مليون مستخدم نشط يتفاعلون مع بعضهم البعض من خلال نظامك ، ويقومون بالتغريد ، والإعجاب ، و dm-ing ، وإعادة التغريد ، وما إلى ذلك.      
هناك  الكثير من المعلومات التي يجب متابعتها  ، وإذا سبق لك العمل على نظام أساسي بهذا الحجم ، فيمكنك تخيل نوع الجهد الذي قد يتطلبه الأمر لمعرفة سبب عدم نشر تغريدة أو أن الرسالة تستغرق وقتًا طويلاً ليتم تسليمها.      
قبل قيامهم بالتبديل من تطبيق أحادي إلى نظام موزع ، كان اكتشاف سبب عدم عمل شيء ما ، في بعض الأحيان ، أمرًا بسيطًا مثل فتح ملف سجل الأخطاء ورؤية الخطأ الذي حدث .      
عندما يكون لديك مئات وربما الآلاف من الخدمات الصغيرة التي تتواصل بشكل غير متزامن مع بعضها البعض ، والقول إن تصحيح أخطاء شيء بسيط مثل تغريدة لا تنطلق سيكون أمرًا بسيطًا تمامًا. لقد نشروا منشورًا رائعًا حقًا حول ترحيلهم إلى الخدمات المصغرة في عام 2013. اقرأ المنشور  هنا .      
من خلال الأنظمة الموزعة (قراءة الخدمات المصغرة) ، خاصة  على نطاق واسع ، يعد الحصول على إمكانية الملاحظة في النظام الأساسي الخاص بك أكثر من ضرورة ، إنه مطلب لا يمكن التحايل عليه باستخدام التنبيه فقط أو من خلال النظر فقط في السجلات. أنت بحاجة إلى بيئة توفر الرؤية على المستوى المجهري من أجل الحصول على المعلومات الصحيحة التي يمكنك التصرف بناءً عليها.     
 يعد نظام المراقبة في Twitter عملاً واستغرق سنوات لتطويره إلى آلة جيدة التزييت كما هو الحال اليوم.      
"يوفر فريق هندسة المراقبة في Twitter مكتبات متكاملة وخدمات متعددة لفرق الهندسة الداخلية لدينا لمراقبة صحة الخدمة ، والتنبيه بشأن المشكلات ، ودعم التحقيق في السبب الجذري من خلال توفير تتبع استدعاء الأنظمة الموزعة ، ودعم التشخيص من خلال إنشاء فهرس يمكن البحث فيه عن التطبيق 
هل اعجبك الموضوع :

تعليقات