رؤية نحو الملاحظة في الممارسة

واحدة من الاتجاهات الرئيسية في البنية التحتية للبرمجيات في عام 2019 هو الملاحظة .

وقد اكتسب الكثير من الاهتمام في الآونة الأخيرة.

ما هي الملاحظة؟

هناك الكثير من المناقشات والنكات حول هذا المصطلح. على سبيل المثال:

• لماذا نسميها مراقبة؟ هذا ليس مثير بما فيه الكفاية بعد الآن.
• ملاحظة: نظرًا لأن إعادة تسمية Ops كـ DevOps لم تكن سيئة بما فيه الكفاية ، فهي الآن تكرس المراقبة أيضًا.
• تشاك نوريس الجديد من DevOps.
• أنا مهندس يمكنه المساعدة في توفير المراقبة للمهندسين الآخرين في المنظمة.
• > عظيم ، وهنا 80k دولار.
• أنا مهندس يمكن أن يساعد في توفير إمكانية المراقبة للتطبيقات المستندة إلى الحوسبة السحابية.
• > رائع! إليك 300 ألف دولار!

سيندي سريدهاران

ما هو الفرق بين الرصد والملاحظة إذا كان هناك واحد؟

إذا نظرنا إلى الوراء ...

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

تحول نموذجي

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



نتيجة لاعتماد هذه الأفكار الجديدة ، أصبحت الأنظمة التي بنيناها موزعة أكثر فأكثر وزناً.

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

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

ما هو الرصد؟

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



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

الصندوق الاسود مقابل رصد مربع أبيض

هناك طريقتان للرصد.

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



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



لذلك ، الملاحظة هي مجرد اسم آخر لمراقبة الصندوق الأبيض؟ ليس تماما.

لماذا نحتاج إلى نوع جديد من المراقبة

غالبًا ما يتم التمييز بين المراقبة ومفهوم قابلية الملاحظة ، حيث يتم تعريف الأخير على أنه يجمع البيانات حول حالة البنية التحتية / التطبيقات وتتبعات الأداء بطريقة أو بأخرى (https://thenewstack.io/monitoring-and القابلية للإفصاح-ما-الفرق-ولماذا-لا-المسألة-).

أو وفقًا لـ honeycomb.io :

• "أنت تتحقق من حالة وسلوكيات أنظمتك مقابل خط أساس معروف ، لتحديد ما إذا كان أي شيء لا يتصرف كما هو متوقع."
• "يمكنك كتابة الشيكات Nagios للتحقق من أن مجموعة من الأشياء داخل عتبات جيدة معروفة."
• "يمكنك إنشاء لوحات معلومات باستخدام Graphite أو Ganglia لتجميع مجموعات من الرسوم البيانية المفيدة."
• "كل هذه أدوات رائعة لفهم المجهولين المعروفين حول نظامك."

تطور نظام بيئي كبير من المنتجات مثل New Relic و HP و AppDynamics. جميع هذه الأدوات مناسبة تمامًا للمراقبة منخفضة المستوى ومتوسطة المستوى أو لفصل مشكلات الأداء.

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

لماذا لوحات المعلومات عديمة الفائدة

في الواقع ، فهي ليست كذلك. ولكن فقط إذا كنت تعرف متى وأين لمشاهدة. خلاف ذلك ، من الأفضل مشاهدة YouTube.

لوحات المعلومات لا مقياس.

تخيل موقفًا لديك فيه مجموعة من المقاييس المتعلقة بالبنية الأساسية الخاصة بك (على سبيل المثال ، حصص cpu_usage / disk) والتطبيقات (على سبيل المثال ، JVMخصيص_speed / GC Runs) ، إلخ. يمكن أن يزداد إجمالي عدد هذه المقاييس بسهولة إلى آلاف أو عشرات الآلاف. جميع لوحات المعلومات الخاصة بك باللون الأخضر ، ولكن بعد ذلك تحدث مشكلة في خدمة تكامل لجهة خارجية. لا تزال لوحات المعلومات باللون الأخضر ، لكن المستخدمين النهائيين قد تأثروا بالفعل.

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

عندما يُسأل لماذا لا يمكن للعملاء فتح موقع ما ، تبدو الاستجابة في الغالب كما يلي:



spaghettification من لوحات المعلومات

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

هذه هي مقاييس GitLab التشغيلية المفتوحة للجمهور.

وهذا مجرد جزء صغير من جيش كامل من لوحات المعلومات



يبدو وكأنه نسيج حيث يكون من السهل فقدان الخيط.

سجل التجميع

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

ومع ذلك ، فإنه يأتي مع التكلفة. تولد الأنظمة الحديثة كميات هائلة من السجلات ويمكن أن تؤدي زيادة حركة المرور إلى استنفاد موارد ELK الخاصة بك أو رفع معدل فوترة Splunk إلى القمر.

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

من السجلات إلى نموذج الأحداث

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

كما أنه مكمل جدًا لمبادئ التصميم المعتمدة على المجال. العزل وتقاسم المسؤوليات بين الخدمات أو المجالات تجعل الأحداث خاصة بكل جزء من العمل في كل جزء من أجزاء النظام.

على سبيل المثال ، يمكن فصل أحداث خدمة تسجيل الدخول بالنجاح_تسجيلات الدخول ، المدونات الفاشلة ذات السياق الديناميكي الخاص.

يجب أن تبني المقاييس والأحداث قصة حول العمليات في النظام.

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

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

مكتوبة مع أصل عال في الاعتبار هذه البيانات يكشف المجهول المجهول في النظام.

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

"تعريف الحدث على أنه جزء من العمل يمكن اعتباره مرتبطًا بأهداف خدمة معينة."

لماذا لسنا مستعدين لحلول الذكاء الاصطناعى الكاملة

الذكاء الاصطناعى هو كلمة طنانة جيدة لجذب الاستثمارات الناشئة. ومع ذلك ، فإن الشيطان هو دائما في التفاصيل.

1. استنساخ

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

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

2. استهلاك الموارد

لأي نوع من التعلم الآلي المستمر ، تحتاج إلى قدر كبير من الموارد الحاسوبية. عادةً ما يأخذ هذا شكل مجموعات معالجة الدُفعات من البيانات. في حالة بعض المنتجات ، الحد الأدنى لمتطلبات معالجة 200000 مقاييس هو v32CPU و 64 جيجابايت من ذاكرة الوصول العشوائي. إذا كنت تريد مضاعفة مقدار المقاييس ، فأنت بحاجة إلى جهاز آخر يلبي نفس المتطلبات.

3. لا يمكنك توسيع نطاق التعلم الآلي الكامل بعد

وفقًا لأطروحة الماجستير التي كتبها Samreen Hassan Massak (لم تكتمل بعد) ، تستغرق العملية التدريبية لآلاف المقاييس وقتًا في وحدة المعالجة المركزية تبلغ أيامًا أو ساعات من وقت GPU. لا يمكنك توسيع نطاقه دون نفخ ميزانيتك.

4. السرعة

حلول مثل Amazon Forecast التي تعمل كخدمات معالجة دفعية تستوعب البيانات وتنتظر انتهاء الحساب ، ليست مناسبة لذلك.

5. الوضوح

بناءً على تجربة Google:

"يجب أن تكون القواعد التي تصادف حوادث حقيقية في أغلب الأحيان بسيطة ويمكن التنبؤ بها وموثوق بها قدر الإمكان."

landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems

عندما تتغير النماذج أو القواعد باستمرار ، تفقد فهم النظام ويعمل كمربع أسود.

الشذوذ = تنبيهات؟

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

https://berlinbuzzwords.de/15/session/signatures-patterns-and-trends-timeseries-data-mining-etsy

أهم الدروس التي يمكن استخلاصها من مشروع Etsy's Kale:



يؤدي التنبيه حول الحالات الشاذة في المقاييس في النهاية إلى ظهور كميات هائلة من التنبيهات والعمل اليدوي باللعب مع عتبات وعوامل تصفية يدوية الصنع.

لماذا نحتاج إلى نهج الجري

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

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

الأشياء التي يجب اعتبارها

أي عملية يتم تنفيذها على دفق لانهائي من البيانات هي مهمة هندسية. تحتاج التعامل مع الآثار المترتبة على النظم الموزعة.



أثناء مراقبة الأحداث أو أهداف مستوى الخدمة أو KPI على مستوى عالٍ ، يجب أن تكون متفاعلًا ولا تستفسر باستمرار عن بياناتك ، ولكن بدلاً من ذلك تعمل على دفق يمكنه القياس أفقياً وتحقيق سرعة نقل كبيرة وسرعة دون استهلاك كمية هائلة من الموارد.

يتم توجيه بعض أطر التدفق ، مثل Apache Storm و Apache Flink و Apache Spark ، نحو معالجة tuple وليس نحو معالجة السلاسل الزمنية خارج الصندوق.

هناك أيضا مشاكل مع دلالات النظم الموزعة.

دعنا نقول أن لديك الكثير من عمليات النشر في مراكز بيانات مختلفة. يمكن أن يكون لديك مشكلة في الشبكة ولا يستطيع العامل الذي يقوم بتخزين مقاييس KPI إعادة توجيهها. بعد فترة - دعنا نقول 3 دقائق - يرسل الوكيل هذه البيانات إلى النظام. وهذه المعلومات الجديدة يجب أن تؤدي إلى إجراء بناءً على هذا الشرط. هل ينبغي لنا تخزين نافذة البيانات هذه في الذاكرة والتحقق من الظروف ليس فقط للخلف ولكن للأمام في الوقت المناسب أيضًا؟ كم يجب أن تكون نافذة عدم التزامن هذه؟ تعمل على الآلاف من المقاييس في الوقت الحقيقي يجعل هذه الأسئلة مهمة للغاية. لا يمكنك تخزين كل شيء في قاعدة البيانات في حالة أنظمة معالجة الدفق دون فقد السرعة.

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

الميزات المرغوب فيها لاستراتيجية المراقبة وفقًا لمصنف Google SRE

• "عادة ما ينطوي التصميم الحديث على الفصل بين تقييم المجموعة والقواعد (مع حل مثل خادم بروميثيوس) وتخزين السلاسل الزمنية طويلة الأمد (InfluxDB) وتجميع التنبيهات (Alertmanager) ولوحة القيادة (Grafana)."
• "تعالج الأنظمة المستندة إلى سجلات Google كميات كبيرة من البيانات شديدة الدقة. هناك بعض التأخير المتأصل بين وقت حدوث الحدث وعندما يكون مرئيًا في السجلات. للتحليل الذي لا يراعي الوقت ، يمكن معالجة هذه السجلات باستخدام نظام دفعي ، واستجوابها باستخدام استعلامات مخصصة ، وتصورها باستخدام لوحات المعلومات. مثال على سير العمل هذا هو استخدام Cloud Dataflow لمعالجة السجلات ، و BigQuery للاستعلامات المخصصة ، و Data Studio للوحات المعلومات. "
• "على النقيض من ذلك ، يوفر نظام المراقبة المستند إلى المقاييس لدينا ، والذي يجمع عددًا كبيرًا من المقاييس من كل خدمة في Google ، معلومات أقل دقة ، ولكن في الوقت الفعلي القريب. هذه الخصائص نموذجية إلى حد ما لأنظمة المراقبة القائمة على السجلات والقياسات ، على الرغم من وجود استثناءات ، مثل أنظمة السجلات في الوقت الفعلي أو المقاييس عالية الأهمية. "
• "في عالم مثالي ، يجب أن تخضع شفرة المراقبة والتنبيه لنفس معايير الاختبار مثل تطوير الشفرة. بينما يناقش مطورو بروميثيوس تطوير اختبارات الوحدات للمراقبة ، لا يوجد حاليًا نظام معتمد على نطاق واسع يسمح لك بذلك. "
• "في Google ، نقوم باختبار المراقبة والتنبيه باستخدام لغة خاصة بالمجال تتيح لنا إنشاء سلاسل زمنية اصطناعية. نكتب بعد ذلك التأكيدات استنادًا إلى القيم في سلسلة زمنية مشتقة ، أو حالة إطلاق العلامة ووجود تنبيهات محددة. "

THANX كبيرة لشركات الكبرى الخيرية وسيندي سريدهاران
THANX إلى سيغريد maasen لمساعدتها