🧚🏾 👿 🆎 التسجيل وتتبع الاستعلام هي أفضل الممارسات. تقرير ياندكس 🦎 🥑 🧠

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

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

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

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

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

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

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

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

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

نظام تحديد الطلب الموحد

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

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

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

لفة

لإعادة إظهار المشكلة ، نستخدم أداة cURL. هذه أداة مساعدة لوحدة التحكم تجعل طلبات الشبكة - http و https. يدعم cURL العديد من البروتوكولات المختلفة ، ولكن عند إجراء تطوير الويب ، من الأسهل افتراض أن هذه أداة للعمل مع طلبات http (s).

للتعرف على فريق cURL ، يمكنك الانتقال إلى أي موقع ، ثم الانتقال إلى الشبكة ونسخ أي طلب في شكل cURL. والنتيجة هي خط كبير:

إذا حاولت اكتشافه ، فلا داعي للقلق. دعونا نحاول تفكيكها.

هنا هو طلب market.yandex.ru.

تمت إضافة وكيل مستخدم هنا ، والذي يشغل بالفعل مساحة كبيرة.

في الواقع ، الباقي هو ملفات تعريف الارتباط. يوجد الكثير منها في كود Yandex. في شكل متسلسل ، لديهم مظهر هائل للغاية. في الواقع ، لا يوجد شيء آخر غيرهم.

إذن ما فائدة CURL؟ إذا نسختها إلى نفسك وقمت بتشغيلها ، فقد شاهدت نفس صفحة market.yandex.ru كما فعلت - فستختلف فقط الكمبيوتر التي كانت تعمل عليها. بالطبع ، بعض الآثار الجانبية يمكن أن تعطي اختلافات في عناوين IP ، ولكن بشكل عام ستكون نفس الطلبات. سوف نعيد إنتاج نفس السيناريو.

من أجل عدم اختراع استعلامات cURL هذه في كل مرة ، يمكنك استخدام npm-package format-curl.

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

لذلك ، تحتوي جميع سجلاتنا في بيئة مطور البرامج أيضًا على طلبات cURL.

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

يرجى ملاحظة أن طلبات cURL تتضمن نقل ملفات تعريف ارتباط الجلسة - وهذا أمر سيئ. إذا قمت بالتخلي عن طلب cURL الخاص بك على market.yandex.ru ، فيمكنني دخول السوق وأي خدمة Yandex أخرى تحت تسجيل الدخول الخاص بك. لذلك ، لا نقوم بتخزين هذه الطلبات في أي مكان ، ولا نقوم بتسجيلها إلا في مقاعد الاختبار لأنفسنا - لا يمكن تسريب هذه البيانات.

كليك هاوس

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

في هذه الحالة ، مثال تحديد ClickHouse هو SQL عادي. نعرض هنا عدد الطلبات لرموز الحالة لهذا اليوم.

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

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

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

على سبيل المثال ، أخطاء الدفع بالغة الأهمية بالنسبة إلينا ، ولكن في هذه الحالة ستُرجع صفرًا - إنها محظوظة :)

كيف تتأكد من أن سجلاتك في هذا النموذج الملائم ويمكن أخذها عبر SQL؟

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

هذا يعمل بالنسبة لنا إلى حد ما متعدد الطبقات - نرسل السجلات من مثيل محدد إلى خادم تخزين بعيد لمثل هذه السجلات.

طلب تتبع

لا يوجد مفهوم "تتبع الاستعلام". تم صياغة هذا المصطلح من قبل جوجل.

إذا بحثت في الإنترنت عن "استعلام تتبع" ، فسترى الأمر traceroute. ربما هذا مشابه لتتبع الاستعلام.

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

هنا هو موازننا. من خلال تتبع الاستعلام ، لا نقصد هذا ، ولكن كل ما يحدث داخل موازننا - كيف يعيش الطلب بشكل أكبر داخل تطبيق node.js.

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

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

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

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

كيف تجعل نفسك نفس الأداة؟

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

الرسوم البيانية

هذا موضوع مثير للاهتمام للغاية ، لن أتطرق إليه بالتفصيل اليوم ، بالطبع ، :)

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

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

المراقبة

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

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

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

ملخص

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

أوصي بقراءة كتاب هندسة موثوقية الموقع من Google إذا كنت مهتمًا بأشياء البنية التحتية.

التسجيل وتتبع الاستعلام هي أفضل الممارسات. تقرير ياندكس