لا يمكن تصور الويب الحديث تقريبًا بدون محتوى الوسائط: فكل جداتنا تقريبًا لديهن هواتف ذكية ، والجميع يجلس على الشبكات الاجتماعية ، وتعطل الخدمة باهظ الثمن بالنسبة للشركات. يُلفت انتباهك إلى نسخة من قصة Badoo حول كيفية تنظيمها لتسليم الصور باستخدام حل الأجهزة ، ومشاكل الأداء التي واجهتها في العملية ، وما سببها ، وكيف تم حل هذه المشكلات باستخدام حل برنامج يستند إلى Nginx ، مع ضمان خطأ التسامح على جميع المستويات ( فيديو ). نشكر مؤلفي القصة Oleg Sannis Efimov و Alexander Dymov ، الذين شاركوا تجربتهم في مؤتمر Uptime لليوم الرابع .- لنبدأ بمقدمة قصيرة حول كيفية تخزين الصور وتخزينها مؤقتًا. لدينا طبقة نقوم بتخزينها عليها ، وطبقة نقوم فيها بتخزين الصور. في الوقت نفسه ، إذا أردنا تحقيق نجاح كبير وتقليل التحميل على مئات ، فمن المهم بالنسبة لنا أن كل صورة لمستخدم فردي تقع على خادم تخزين مؤقت واحد. وإلا ، يتعين علينا وضع عدد أكبر من المرات من الأقراص ، وعدد الخوادم الموجودة لدينا. لدينا نسبة نجاح تصل إلى حوالي 99٪ ، أي أننا نخفض الحمل على التخزين لدينا بنسبة 100 مرة ، ومن أجل القيام بذلك ، حتى قبل 10 سنوات ، عندما تم بناء كل هذا ، كان لدينا 50 خادمًا. وفقًا لذلك ، من أجل إعطاء هذه الصور ، نحتاج أساسًا إلى 50 نطاقًا خارجيًا تخدمها هذه الخوادم.
بطبيعة الحال ، السؤال الذي يطرح نفسه على الفور: إذا سقط أحد الخوادم ، فلن يكون متاحًا ، ما هو جزء حركة المرور الذي نخسره؟ نظرنا إلى ما هو موجود في السوق وقررنا شراء قطعة من الحديد بحيث تحل جميع مشاكلنا. وقع الاختيار بناءً على قرار شركة F5-network (التي ، بالمناسبة ، اشترت مؤخرًا NGINX، Inc): BIG-IP Local Traffic Manager.
ما تقوم به هذه القطعة من الأجهزة (LTM): هو موجه حديدي يقوم بتكرار الحديد لمنافذه الخارجية ويسمح لك بتوجيه حركة المرور بناءً على هيكل الشبكة ، وفي بعض الإعدادات ، ويقوم بإجراء فحوصات صحية. كان من المهم بالنسبة لنا أن هذه القطعة من الحديد يمكن برمجتها. وفقًا لذلك ، يمكن أن نصف منطق كيفية إعطاء صور لمستخدم معين من ذاكرة تخزين مؤقت معينة. كيف تبدو؟ هناك قطعة من الحديد التي تبحث على الإنترنت عبر مجال واحد ، IP واحد ، يقوم بإلغاء تحميل SSL ، ويوزع طلبات http ، ومن IRule يختار رقم ذاكرة التخزين المؤقت إلى أين تذهب ، ويسمح لحركة المرور بالذهاب إلى هناك. في الوقت نفسه ، فإنه يجعل الفحوصات الصحية ، وإذا كان بعض الجهاز غير متوفر ، قمنا بها في تلك اللحظة بحيث ذهب حركة المرور إلى خادم النسخ الاحتياطي واحد. من وجهة نظر التكوين ، هناك ، بالطبع ، بعض الفروق الدقيقة ، ولكن بشكل عام كل شيء بسيط للغاية: نحن نصف بطاقة ، ونطابق بعض الأرقام مع عنوان IP الخاص بنا على الشبكة ، نقول أننا سنستمع على المنفذين 80 و 443 ، كما نقول ، إذا كان الخادم غير متاح ، فأنت بحاجة إلى بدء حركة المرور على النسخة الاحتياطية ، في هذه الحالة الخامسة والثلاثين ، ونصف مجموعة من المنطق حول كيفية تفكيك هذه البنية. المشكلة الوحيدة هي أن اللغة التي برمجت قطعة الأجهزة كانت Tcl. إذا كان أي شخص يتذكر هذا ... فهذه اللغة هي فقط للكتابة أكثر من لغة ملائمة للبرمجة:
ماذا حصلنا عليه؟ لقد حصلنا على قطعة من الأجهزة توفر إمكانية توفر عالية للبنية التحتية الخاصة بنا ، وتقوم بتوجيه جميع زياراتنا ، وتوفر الرعاية الصحية وتعمل فقط. علاوة على ذلك ، ظلت تعمل لبعض الوقت: خلال السنوات العشر الماضية ، لم تكن هناك أي شكاوى حول هذا الموضوع. بحلول بداية عام 2018 ، كنا نعطي حوالي 80 ألف صورة في الثانية. هذا في مكان ما حوالي 80 غيغا بايت من حركة المرور من كل من مراكز البيانات لدينا.
ومع ذلك ...
في بداية عام 2018 ، رأينا صورة قبيحة على الرسوم البيانية: زادت مدة استجابة الصور بوضوح. وقد توقف لتناسبنا. المشكلة هي أن هذا السلوك كان مرئيًا فقط في ذروة حركة المرور - بالنسبة لشركتنا ، هذه هي الليلة من الأحد إلى الاثنين. لكن بقية الوقت ، تصرف النظام كالمعتاد ، لا توجد علامات على الضرر.
ومع ذلك ، كان يجب حل المشكلة. حددنا الاختناقات المحتملة وبدأنا في القضاء عليها. أولاً وقبل كل شيء ، بالطبع ، قمنا بتوسيع الروابط الخارجية ، وأجرينا مراجعة كاملة للوصلات الصاعدة الداخلية ، ووجدنا جميع الاختناقات المحتملة. ولكن كل هذا لم يعطي نتيجة واضحة ، فإن المشكلة لم تختف.
عنق الزجاجة المحتمل الآخر هو أداء ذاكرة التخزين المؤقت للصور نفسها. وقررنا أن المشكلة ربما تقع عليهم. حسنًا ، قمنا بتوسيع الأداء - بشكل أساسي منافذ الشبكة على ذاكرة التخزين المؤقت للصور. ولكن مرة أخرى ، لم يلاحظ أي تحسن واضح. في النهاية ، أولينا اهتمامًا كبيرًا بأداء LTM نفسه ، وهنا رأينا صورة حزينة على الرسوم البيانية: يبدأ تحميل جميع وحدات المعالجة المركزية (CPUs) بسلاسة ، ولكن بعد ذلك يقع بشكل مفاجئ على الرف. في الوقت نفسه ، يتوقف LTM عن الاستجابة بشكل كاف للفحوصات الطبية والوصلة الصاعدة ويبدأ في إيقاف تشغيلها بشكل عشوائي ، مما يؤدي إلى تدهور خطير في الأداء.
وهذا هو ، حددنا مصدر المشكلة ، حددنا عنق الزجاجة. يبقى أن نقرر ما سنفعله.
أول ما يوحي بأنفسنا أننا يمكن أن نتخذها هو ترقية LTM بطريقة ما. ولكن هناك بعض الفروق الدقيقة ، لأن هذا الحديد فريد من نوعه ، فلن تذهب إلى أقرب سوبر ماركت ولن تشتريه. هذا عقد منفصل ، عقد ترخيص منفصل ، وسوف يستغرق الكثير من الوقت. الخيار الثاني هو أن تبدأ في التفكير بنفسك ، والتوصل إلى الحل الخاص بك على المكونات الخاصة بك ، ويفضل استخدام برنامج الوصول المفتوح. يبقى فقط أن نقرر بالضبط ما الذي سنختاره لهذا الغرض وكم من الوقت سنقضي على حل هذه المشكلة ، لأن المستخدمين لم يتلقوا صورًا. لذلك ، كل هذا يجب أن يتم بسرعة كبيرة ، يمكن القول - بالأمس.
نظرًا لأن المهمة بدت وكأنها "القيام بشيء في أسرع وقت ممكن واستخدام الأجهزة التي لدينا" ، فإن أول شيء كنا نظن أنه ببساطة إزالة بعض الأجهزة غير الأقوى من المقدمة ، وضع Nginx الذي نتعامل معه نحن نعرف كيفية العمل ، ونحاول تنفيذ كل المنطق الذي كانت تفعله قطعة الحديد. هذا هو ، في الواقع ، تركنا أجهزتنا ، وقمنا بإعداد 4 خوادم أخرى كان من المفترض أن يتم تكوينها ، وصنعنا نطاقات خارجية لهم ، على غرار ما كان عليه قبل 10 سنوات ... فقدنا القليل من التوفر إذا تعطلت هذه الأجهزة ، لكن مع ذلك ، أقل حل مشكلة مستخدمينا محليا.
وفقًا لذلك ، يظل المنطق كما هو: نضع Nginx ، ويمكنه القيام بإلغاء تحميل طبقة المقابس الآمنة ، ويمكننا بطريقة أو بأخرى برمجة منطق التوجيه ، والتحقق من الصحة على التكوينات وتكرار المنطق الذي كان لدينا من قبل.
نجلس لكتابة التكوينات. في البداية ، بدا أن كل شيء كان بسيطًا جدًا ، ولكن لسوء الحظ ، من الصعب جدًا العثور على أدلة لكل مهمة. لذلك ، لا نوصي باستخدام google "كيفية تكوين Nginx للصور": من الأفضل الرجوع إلى الوثائق الرسمية ، والتي ستظهر الإعدادات التي تستحق اللمس. لكن من الأفضل اختيار معامل معين بنفسك. حسنًا ، كل شيء بسيط: نحن نصف الخوادم التي لدينا ، ونصف الشهادات ... ولكن الأكثر إثارة للاهتمام هو ، في الواقع ، منطق التوجيه نفسه.
في البداية ، بدا لنا أننا ببساطة نصف موقعنا ، ونطابق عدد ذاكرة التخزين المؤقت للصور الموجودة فيه ، ونصف بأيدينا أو مولد كم عدد عمليات التنقيب التي نحتاجها ، في كل مرحلة من مراحل الإنتاج نشير إلى الخادم الذي يجب أن تذهب إليه الحركة ، وخادم النسخ الاحتياطي في حالة الخادم الرئيسي المتاحة:
لكن ، على الأرجح ، إذا كان كل شيء بسيطًا للغاية ، فسنذهب إلى المنزل فقط ولا نقول أي شيء. لسوء الحظ ، من خلال الإعدادات الافتراضية لـ Nginx ، والتي تم إجراؤها بشكل عام على مدى سنوات عديدة من التطوير وليس تمامًا لهذه الحالة ... يبدو التكوين كما يلي: إذا كان لدى بعض خادم upstream خطأ في الطلب أو مهلة ، فيظل Nginx دائمًا تبديل حركة المرور إلى التالي. في الوقت نفسه ، بعد الملف الأول ، سيتم إيقاف تشغيل الخادم أيضًا لمدة 10 ثوانٍ ، سواء عن طريق الخطأ أو عن طريق المهلة - لا يمكن حتى تكوين هذا. أي إذا قمنا بإزالة أو إعادة تعيين خيار المهلة في التوجيه الأولي ، فعلى الرغم من أن Nginx لن يعالج هذا الطلب وسوف يستجيب مع بعض الأخطاء غير الجيدة ، سيتم إيقاف تشغيل الخادم.
لتجنب هذا ، فعلنا شيئين:
أ) منعوا Nginx من القيام بذلك يدويًا - ولسوء الحظ ، فإن الطريقة الوحيدة للقيام بذلك هي ببساطة تعيين إعدادات فشل ماكس.
ب) تذكر أننا في مشاريع أخرى نستخدم وحدة تسمح لك بإجراء فحوصات صحية في الخلفية - وبناءً على ذلك ، قمنا بإجراء فحوصات صحية متكررة إلى حد ما حتى يكون لدينا حد أدنى في حالة وقوع حادث.
لسوء الحظ ، هذا ليس كل شيء ، لأنه في الأسبوعين الأولين من هذا المخطط أوضح حرفيًا أن التحقق من صحة TCP أمر لا يمكن الوثوق به أيضًا: لا يمكن رفع Nginx أو Nginx في الحالة D على الخادم الرئيسي ، في هذه الحالة ستقبل النواة الاتصال ، وسوف يمر الفحص الصحي ، لكنه لن يعمل. لذلك ، استبدلناها فورًا بـ http: hh-hint-الصحة ، ونجعلها محددة ، وإذا أعادت 200 ، فسيعمل كل شيء في هذا البرنامج النصي. يمكنك القيام بمنطق إضافي - على سبيل المثال ، في حالة خوادم التخزين المؤقت ، تحقق من تثبيت نظام الملفات بشكل صحيح:
وسيكون ذلك مناسبًا لنا ، إلا أنه في هذه اللحظة كرر الدائرة تمامًا ما فعلته قطعة الحديد. لكننا أردنا أن نفعل ما هو أفضل. في السابق ، كان لدينا خادم نسخ احتياطي واحد ، وربما لا يكون هذا جيدًا جدًا ، لأنه إذا كان لديك مائة خوادم ، فعندما يتعطل العديد من الخوادم دفعة واحدة ، فمن غير المرجح أن يتعامل خادم النسخ الاحتياطي مع هذا العبء. لذلك ، قررنا توزيع الحجز عبر جميع الخوادم: لقد قمنا للتو بإجراء عملية تنقيب منفصلة أخرى ، وقمنا بتدوين جميع الخوادم باستخدام معلمات معينة هناك وفقًا لنوع الحمل الذي يمكنهم التعامل معه ، وأضافت نفس الفحوصات الصحية التي أجريناها من قبل :
نظرًا لأنه من المستحيل الانتقال إلى مصدر آخر داخل أحد المنبع ، فقد كان من الضروري التأكد من أنه في حالة عدم توفر المنبع الرئيسي ، حيث تم كتابة ذاكرة التخزين المؤقت للصور الصحيحة ببساطة ، فقد ذهبنا ببساطة إلى الخلف عبر error_page ، ومن أين ذهبنا إلى النسخة الاحتياطية في أبريل:
وبإضافة أربعة خوادم حرفيًا ، حصلنا على هذا: لقد استبدلنا جزءًا من التحميل - تمت إزالته من LTM إلى هذه الخوادم ، ونفذنا نفس المنطق هناك باستخدام أجهزة وبرامج قياسية ، وحصلنا على الفور على إمكانية زيادة حجم هذه الخوادم لأنه يمكن ببساطة ضع ما تحتاج إليه. حسنًا ، الشيء السلبي الوحيد هو أننا فقدنا توفرًا كبيرًا للمستخدمين الخارجيين. لكن في تلك اللحظة اضطررت للتضحية بهذا ، لأن عليّ حل المشكلة على الفور. لذلك ، أزلنا جزءًا من التحميل ، أي حوالي 40٪ في ذلك الوقت ، شعرت LTM بحالة جيدة ، وبعد أسبوعين فقط من بداية المشكلة ، بدأنا في إرسال طلبات لا تصل إلى 45 ألف في الثانية ، ولكن 55 كيلو. في الواقع ، لقد نمت بنسبة 20 ٪ - وهذا هو بوضوح حركة المرور التي لم نمنحها للمستخدم. وبعد ذلك بدأوا في التفكير في كيفية حل المشكلة المتبقية - لتوفير الوصول الخارجي عالية.
كان لدينا وقفة ناقشنا خلالها الحل الذي سنستخدمه لهذا الغرض. كانت هناك اقتراحات لضمان الموثوقية باستخدام DNS ، باستخدام بعض البرامج النصية المكتوبة ذاتيًا ، وبروتوكولات التوجيه الديناميكية ... كان هناك العديد من الخيارات ، لكن أصبح من الواضح أنه بالنسبة لإخراج صور موثوق به حقًا ، يلزمك تقديم طبقة أخرى تراقب ذلك. أطلقنا على هذه الصورة مديري الصور. نظرًا لأن البرنامج الذي اعتمدنا عليه ، فقد اخترت Keepalived:
بادئ ذي بدء - ما يتكون من Keepalived. الأول هو بروتوكول VRRP ، المعروف على نطاق واسع لدى المسوقين الشبكيين ، والموجود على معدات الشبكة التي توفر التسامح مع الخطأ لعنوان IP الخارجي الذي يتصل به العملاء. الجزء الثاني هو IPVS ، خادم IP الظاهري ، لتحقيق التوازن بين أجهزة توجيه الصور وضمان التسامح مع الخطأ في هذا المستوى. والثالث هو الفحوصات الصحية.
لنبدأ بالجزء الأول: VRRP - كيف تبدو؟ يوجد عنوان IP ظاهري معين يوجد عليه إدخال في dns badoocdn.com حيث يتصل العملاء. في وقت ما ، لدينا عنوان IP على خادم واحد. يتم تشغيل حزم Keepalived بين الخوادم التي تستخدم بروتوكول VRRP ، وإذا اختفى المعالج من الرادار - تم إعادة تشغيل الخادم أو أي شيء آخر ، يقوم خادم النسخ الاحتياطي تلقائيًا برفع عنوان IP هذا من نفسه - لا توجد خطوات يدوية ضرورية. يختلف الرئيسي والنسخ الاحتياطي ، والأولوية بشكل رئيسي: كلما ارتفع ، زاد احتمال أن يصبح الجهاز سيدًا. هناك ميزة كبيرة جدًا تتمثل في أنه ليس من الضروري تكوين عناوين IP على الخادم نفسه ، وهو يكفي لوصفها في التكوين ، وإذا كانت عناوين IP تحتاج في الوقت نفسه إلى بعض قواعد التوجيه المخصصة ، يتم وصف ذلك مباشرةً في التكوين ، بناء الجملة نفسه كما هو موضح في حزمة VRRP. لن تقابل أي أشياء غير مألوفة.
كيف تبدو في الممارسة العملية؟ ماذا يحدث إذا سقط أحد الخوادم؟ بمجرد اختفاء السيد ، يتوقف النسخ الاحتياطي لدينا عن تلقي الإعلانات ويصبح تلقائيًا سيدًا. بعد مرور بعض الوقت ، قمنا بإصلاح برنامج Keepalived الرئيسي ، الذي تم إعادة تشغيله ، ورفعه - تأتي الإضافات ذات أولوية أعلى من النسخة الاحتياطية ، بينما تعود النسخ الاحتياطي تلقائيًا إلى الوراء ، وتزيل عناوين IP ، ولا يلزم اتخاذ إجراءات يدوية.
وبالتالي ، تأكدنا من التسامح مع الخطأ لعنوان IP الخارجي. الجزء التالي هو موازنة حركة المرور بطريقة ما مع أجهزة توجيه الصور التي تنهيها بالفعل من عنوان IP خارجي. مع بروتوكولات التوازن ، كل شيء واضح جدا. هذا إما أن يكون بسيطًا أو دائريًا أو أكثر تعقيدًا قليلاً ، wrr ، اتصال القائمة ، وما إلى ذلك. يوصف هذا من حيث المبدأ في الوثائق ، لا يوجد شيء خاص. لكن طريقة التسليم ... هنا نتحدث بمزيد من التفصيل - لماذا اختاروا واحدًا منهم. هذه هي NAT ، التوجيه المباشر و TUN. الحقيقة هي أننا وضعنا على الفور عودة 100 غيغا بايت من حركة المرور من المواقع. إذا تم تقدير ذلك ، فأنت بحاجة إلى 10 بطاقات جيجابت ، أليس كذلك؟ 10 بطاقات جيجابت في خادم واحد - هذا بالفعل خارج نطاق مفهومنا على الأقل "للمعدات القياسية". ثم تذكرنا أننا لا نتخلى فقط عن بعض حركة المرور ، ولكننا نقدم الصور.
ما هي الميزة؟ - الفرق الكبير بين حركة المرور الواردة والصادرة. حركة المرور الواردة صغيرة جدًا ، الصادرة كبيرة جدًا:
إذا نظرت إلى هذه الرسوم البيانية ، يمكنك أن ترى أنه في الوقت الحالي سيأتي حوالي 200 ميجابايت في الثانية إلى المخرج ، وهذا هو أكثر الأيام العادية. نحن نعيد 4500 ميغابايت في الثانية ، النسبة حوالي 1/22. من الواضح بالفعل أنه بالنسبة لنا لضمان حركة المرور الصادرة بالكامل إلى 22 خادمًا عاملاً ، فإن الخادم الذي يقبل هذا الاتصال يكفي. هنا خوارزمية التوجيه المباشر ، خوارزمية التوجيه ، تأتي لمساعدتنا.
كيف تبدو؟ وفقًا لطاولتنا ، يقوم مدير الصور بنقل الاتصالات إلى أجهزة توجيه الصور. لكن أجهزة توجيه الصور ترسل حركة العودة مباشرة إلى الإنترنت ، وإرسالها إلى العميل ، لا تعود من خلال مدير الصور ، وبالتالي ، مع الحد الأدنى لعدد الأجهزة ، نحن نقدم التسامح الكامل مع الخطأ وضخ جميع حركة المرور. في التكوينات تبدو كما يلي: نقوم بتحديد الخوارزمية ، وفي حالتنا هي rr بسيطة ، فنحن نقدم طريقة توجيه مباشرة ثم نبدأ في سرد جميع الخوادم الحقيقية ، وعددنا. والتي سوف تحدد هذه الحركة. في حال حصلنا على خادم أو خادمين إضافيين هناك ، فهناك حاجة ماسة - نحن فقط نضيف هذا القسم في التهيئة ولا نقلق حقًا. من جانب الخوادم الحقيقية ، من جانب جهاز توجيه الصور ، تتطلب هذه الطريقة الحد الأدنى من التكوين ، وهي موصوفة تمامًا في الوثائق ، ولا توجد مطبات هناك.
ما هو لطيف بشكل خاص - مثل هذا الحل لا يعني تغييراً جذرياً في الشبكة المحلية ، لقد كان من المهم بالنسبة لنا ، كان علينا حلها بأقل تكلفة ممكنة. إذا نظرت إلى
إخراج أمر مشرف IPVS ،
فسنرى كيف يبدو. هنا لدينا خادم افتراضي ، على المنفذ 443 ، يستمع ، يقبل الاتصال ، جميع الخوادم العاملة مدرجة ، ومن الواضح أن الاتصال هو نفسه ، زائد أو ناقص. إذا نظرنا إلى الإحصائيات الموجودة على نفس الخادم الظاهري ، فلدينا حزم واردة واتصالات واردة ، ولكن لا توجد حزم صادرة. الاتصالات الصادرة تذهب مباشرة إلى العميل. حسنًا ، لقد تمكنا من عدم التوازن. الآن ، ماذا يحدث إذا تعطل أحد أجهزة توجيه الصور؟ بعد كل شيء ، الحديد هو الحديد. قد تذهب إلى نواة الفزع ، قد تنكسر ، قد تنفد وحدة الإمداد بالطاقة. أي شيء. لهذا ، هناك حاجة إلى الفحوصات الصحية. يمكن أن تكون إما أبسطها - التحقق من كيفية فتح المنفذ معنا - أو بعضها الأكثر تعقيدًا ، حتى بعض النصوص المكتوبة ذاتيًا والتي سوف تحقق من منطق العمل.
لقد توقفنا في مكان ما في الوسط: لدينا طلب https لموقع معين ، يتم استدعاء البرنامج النصي إذا كان يستجيب للإجابة 200 ، ونعتقد أن كل شيء طبيعي مع هذا الخادم ، وأنه مباشر ويمكن تشغيله بهدوء تام.
كيف ، مرة أخرى ، يبدو في الممارسة العملية. قم بإيقاف تشغيل الخادم ، دعنا نقول للخدمة - وميض BIOS ، على سبيل المثال. في السجلات ، لدينا مهلة على الفور ، نرى السطر الأول ، ثم بعد ثلاث محاولات يتم وضع علامة "انقلبت" ، ويتم حذفها ببساطة من القائمة.
هناك سلوك ثانٍ محتمل عندما يتم ضبط VS ببساطة على صفر ، ولكن إذا تم إرجاع الصورة ، فلن تعمل بشكل جيد. يرتفع الخادم ، ويبدأ Nginx من هناك ، وفهمت الفحوصات الصحية أن الاتصال يمر ، وأن كل شيء على ما يرام ، وأن الخادم يظهر في قائمتنا ، ويبدأ التحميل تلقائيًا على الفور. في الوقت نفسه ، لا توجد إجراءات يدوية مطلوبة من المسؤول أثناء الخدمة. في الليل ، أعيد تشغيل الخادم - قسم الرصد لا يتصل بنا حول هذا في الليل. يعلمون أن هذا كان ، كل شيء طبيعي.
, , .
, , , . , Keepalivede, , , DBus, SMTP, SNMP, Zabbix'. , , , - , , , IP- . , , . nginx -, . , , : -, health-check' , , , , - - . - , amazon -, , , anomaly detection, , machine learning, , , , , , . .
: , , , - , , , HTTPS health-check'. , , , , , .
? 2018-. , , LTM, - 40 60 , 2018- .
