تنبيهات قوية تدعم بنية Hugging Face الإنتاجية

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

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

معدل مرور NAT Gateway العالي

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

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

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

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

في مناسبة أخرى، أدت التعديلات على بنية تحتية لدينا إلى تجنب مسار خاص منخفض التكلفة بين بنية تحتية محددة للمنتج. لتوضيح ذلك، كانت أكثر الأحمال تأثيرًا من حيث توفير التكاليف التي وجدناها هي تلك التي تصل إلى تخزين الكائنات. إن جلب الكائنات مباشرة أقل تكلفة من المرور عبر أصول مستضافة على CDN لتخزين مستودع LFS لدينا، بالإضافة إلى أنها لا تتطلب نفس تدابير الأمان التي يوفرها WAF لدينا مقارنةً بالطلبات العامة التي تصل إلى بابنا. لقد أصبح استخدام تجاوزات DNS لتبديل الحركة عبر المسارات الشبكية الخاصة والعامة تقنية قيمة بالنسبة لنا، مدفوعة بمزود CDKTF AWS.

new Route53ResolverFirewallRule( stack, `dns-override-rule-${key}-${j}`, { provider: group?.provider!, name: `dns-override-${dnsOverride.name}-${rule[0]}`, action: 'BLOCK', blockOverrideDnsType: 'CNAME', blockOverrideDomain: `${rule[1]}.`, blockOverrideTtl: dnsOverride.ttl, blockResponse: 'OVERRIDE', firewallDomainListId: list.id, firewallRuleGroupId: group!.id, priority: 100 + j, }, );


كملحوظة أخيرة، بينما لدينا تكوين كود يضمن أن الحالة المرغوبة دائمًا سارية، فإن وجود طبقة إضافية من التنبيه يساعد في حالة حدوث أخطاء عند التعبير عن الحالة المرغوبة من خلال الكود.
  معدل نجاح أرشفة سجلات طلبات Hub 
تعتبر بنية التسجيل في Hugging Face نظامًا معقدًا مصممًا لجمع ومعالجة وتخزين كميات هائلة من بيانات السجلات الناتجة عن تطبيقاتنا وخدماتنا. في قلب هذا النظام توجد خط أنابيب تسجيل تطبيق Hub، وهو حل مصمم بشكل جيد يضمن التقاط بيانات استخدام نموذج Hub بكفاءة، وتغنيتها، وتخزينها لأغراض التقارير والأرشفة. يبدأ خط الأنابيب بـ Filebeat، وهو شاحن سجلات خفيف الوزن يعمل كخدمة بجانب حاويات تطبيقنا في كل مجموعة Kubernetes. دور Filebeat هو جمع السجلات من مصادر متعددة، بما في ذلك حاويات التطبيقات، وإرسالها إلى المرحلة التالية من خط الأنابيب.
بمجرد جمع السجلات بواسطة Filebeat، يتم إرسالها إلى Logstash، وهو أداة قوية لمعالجة السجلات. يعمل Logstash كآلة معالجة البيانات، حيث يطبق سلسلة من التحولات والتعديلات على السجلات الواردة. يشمل ذلك إثراء السجلات ببيانات GeoIP للحصول على رؤى جغرافية، وتوجيه السجلات إلى فهارس Elasticsearch محددة بناءً على معايير محددة مسبقًا، وتعديل حقول السجلات عن طريق الإضافة أو الإزالة أو إعادة التنسيق لضمان الاتساق وسهولة التحليل. بعد معالجة Logstash للسجلات، يتم إرسالها إلى مجموعة Elasticsearch.
تشكل Elasticsearch، وهي محرك بحث وتحليل موزع، جوهر منصة تخزين وتحليل السجلات لدينا. تستقبل السجلات من Logstash وتطبق مجموعتها الخاصة من قواعد المعالجة من خلال خطوط أنابيب Elasticsearch. تقوم هذه الخطوط بأداء مهام معالجة بسيطة، مثل إضافة حقول الطوابع الزمنية للإشارة إلى وقت المعالجة، وهو أمر حاسم لتحليل السجلات والارتباط. توفر Elasticsearch حلاً قابلًا للتوسع ومرنًا للتخزين، مما يسمح لنا بتخزين السجلات للاستخدام التشغيلي والتحليل الفوري.
لإدارة دورة حياة السجلات داخل Elasticsearch، نعتمد استراتيجية قوية لإدارة التخزين والدورة الحياتية. يضمن ذلك الاحتفاظ بالسجلات في Elasticsearch لفترة محددة، مما يوفر وصولًا سريعًا لأغراض التشغيل واستكشاف الأخطاء. بعد هذه الفترة، يتم نقل السجلات إلى تخزين أرشيفي طويل الأجل. تشمل عملية الأرشفة أداة مؤتمتة تقرأ السجلات من فهارس Elasticsearch، وتقوم بتنسيقها كملفات Parquet - وهو تنسيق تخزين عمودي فعال - وتكتبها إلى نظام تخزين الكائنات لدينا.
تستفيد المرحلة النهائية من خط أنابيب التسجيل لدينا من خدمات تخزين البيانات في AWS. هنا، يتم استخدام زاحف AWS Glue لاكتشاف وتصنيف البيانات في نظام تخزين الكائنات لدينا، مما يولد تلقائيًا كتالوج بيانات Glue، الذي يوفر مستودع بيانات موحد. يتم تحديث مخطط جدول Glue بشكل دوري لضمان بقائه محدثًا مع الهيكل المتطور لبيانات السجلات لدينا. يتيح لنا هذا التكامل مع AWS Glue استعلام السجلات المؤرشفة باستخدام Amazon Athena، وهي خدمة استعلام تفاعلية بدون خادم. تسمح لنا Athena بتشغيل استعلامات SQL مباشرة ضد البيانات في نظام تخزين الكائنات، مما يوفر حلاً فعالاً من حيث التكلفة وقابل للتوسع لتحليل السجلات واستكشاف البيانات التاريخية.

بينما تم تصميم خط أنابيب التسجيل بعناية، إلا أنه ليس خاليًا من التحديات ونقاط الفشل المحتملة. واحدة من أكثر الثغرات حرجة تكمن في مرونة النظام، خاصة في مجموعة Elasticsearch. يمكن أن تواجه Elasticsearch، كونها نظامًا موزعًا، ضغطًا عكسيًا في سيناريوهات مختلفة، مثل حركة المرور العالية، أو الاستعلامات المكثفة، أو العمليات الداخلية مثل نقل الشظايا. عندما يحدث ضغط عكسي، يمكن أن يؤدي إلى سلسلة من المشكلات في جميع أنحاء خط الأنابيب. على سبيل المثال، إذا أصبحت مجموعة Elasticsearch مثقلة، فقد تبدأ في رفض أو تأخير إدخال السجلات، مما يتسبب في تراكمات في Logstash أو حتى Filebeat، مما قد يؤدي إلى فقدان السجلات أو تأخير المعالجة.
نقطة ضعف أخرى هي آلية اكتشاف المخطط التلقائي في Elasticsearch. بينما تم تصميمها للتكيف مع الهياكل المتغيرة للسجلات، إلا أنها قد تفشل عندما تخضع سجلات التطبيقات لتغييرات كبيرة في نوع الحقول. إذا فشلت آلية اكتشاف المخطط في التعرف على أنواع الحقول الجديدة، فقد يؤدي ذلك إلى فشل الكتابات من Logstash إلى Elasticsearch، مما يتسبب في اختناقات معالجة السجلات واحتمال وجود عدم اتساق البيانات. تسلط هذه المشكلة الضوء على أهمية إدارة مخطط السجلات بشكل استباقي وضرورة المراقبة القوية لاكتشاف ومعالجة مثل هذه المشكلات على الفور.
تعتبر إدارة الذاكرة أيضًا جانبًا حاسمًا في استقرار خط الأنابيب. تعمل طبقة معالجة السجلات، بما في ذلك Logstash وFilebeat، بموارد ذاكرة محدودة للتحكم في التكاليف. عندما يحدث ضغط عكسي، يمكن أن تواجه هذه المكونات مشاكل في نفاد الذاكرة (OOM)، خاصةً خلال تباطؤ النظام. مع تراكم السجلات وزيادة الضغط العكسي، يزداد البصمة الذاكرية لهذه العمليات، مما يدفعها إلى حدودها. إذا لم يتم معالجة ذلك على الفور، فقد يؤدي ذلك إلى تعطل العمليات أو تفاقم مشكلة الضغط العكسي.
واجهت وظائف الأرشفة، المسؤولة عن نقل السجلات من Elasticsearch إلى نظام تخزين الكائنات، أيضًا تحديات. في بعض الأحيان، يمكن أن تكون هذه الوظائف كثيفة الموارد، حيث تصبح أداؤها حساسة لحجم العقد وتوافر الذاكرة. في الحالات التي تمر فيها بيانات غير مرغوب فيها أو إدخالات سجلات كبيرة بشكل غير عادي عبر خط الأنابيب، يمكن أن تؤدي إلى ضغط على عملية الأرشفة، مما يؤدي إلى الفشل بسبب نفاد الذاكرة أو حدود سعة العقد. يبرز هذا أهمية التحقق من صحة البيانات وتصفيتها في وقت مبكر من خط الأنابيب لمنع مثل هذه المشكلات من الوصول إلى مرحلة الأرشفة.
لتخفيف هذه الفشل المحتملة، قمنا بتنفيذ نظام تنبيه قوي بدافع فريد: التحقق من تدفق السجلات من النهاية إلى النهاية. تم تصميم التنبيه لمقارنة عدد الطلبات المستلمة بواسطة موازن تحميل التطبيق (ALB) مع عدد السجلات المؤرشفة بنجاح، مما يوفر رؤية شاملة لتدفق بيانات السجلات عبر خط الأنابيب بأكمله. تتيح لنا هذه الطريقة التعرف بسرعة على أي تناقضات قد تشير إلى فقدان السجلات أو مشكلات في المعالجة.

    
        
            
        
        مقالات ذات صلة
    
    
        
        

        
        
                            
                                        
                        
                        
                    
                    
                                                    الذكاء الاصطناعي
                                                Anthropic تتهم DeepSeek باستغلال Claude AI: تهديد أمني خطير
                        
                            
                                
                                منذ ساعة
                            
                            
                                
                                0
                            
                        
                    
                
                            
                                        
                        
                        
                    
                    
                                                    الذكاء الاصطناعي
                                                Toy Story 5: هل يعيد إحياء سلسلة [[Pixar]] الشهيرة في 2026؟
                        
                            
                                
                                منذ ساعتين
                            
                            
                                
                                0
                            
                        
                    
                
                            
                                        
                        
                        
                    
                    
                                                    الذكاء الاصطناعي
                                                تحذير: روبوتات الذكاء الاصطناعي تتفوق على البشر بالوظائف 2050
                        
                            
                                
                                منذ ساعتين
                            
                            
                                
                                0
                            
                        
                    
                
                            
                                        
                        
                        
                    
                    
                                                    الذكاء الاصطناعي
                                                سبوتيفاي يختبر ميزة 'الملاحظات' لضبط توصياتك الموسيقية
                        
                            
                                
                                منذ ساعتين
                            
                            
                                
                                0
                            
                        
                    
                
                            
                                        
                        
                        
                    
                    
                                                    الذكاء الاصطناعي
                                                جوجل كروم: دمج الذكاء الاصطناعي Gemini في شريط العنوان (إصدار 145)
                        
                            
                                
                                منذ ساعتين
                            
                            
                                
                                0
                            
                        
                    
                
                            
                                        
                        
                        
                    
                    
                                                    الذكاء الاصطناعي
                                                تراجع أسهم الأمن السيبراني: هل الذكاء الاصطناعي يهدد القطاع؟
                        
                            
                                
                                منذ ساعتين
                            
                            
                                
                                0
                            
                        
                    
                
                    

        
        
    


آلية التنبيه تعتمد على مقارنة بسيطة لكنها فعالة: عدد الطلبات التي تصل إلى ALB لدينا، والتي تمثل إجمالي حجم السجلات التي تدخل النظام، مقابل عدد السجلات التي تم أرشفتها بنجاح في تخزيننا طويل الأجل. من خلال مراقبة هذه النسبة، يمكننا التأكد من أن ما يدخل يجب أن يخرج، مما يوفر تحققًا قويًا من صحة بنية سجلاتنا. عندما يتم تفعيل التنبيه، فإنه يشير إلى وجود عدم تطابق محتمل، مما يستدعي التحقيق الفوري وإصلاح المشكلة.
في الممارسة العملية، أثبت هذا التنبيه أنه أداة قيمة، خاصة خلال فترات إعادة هيكلة البنية التحتية. على سبيل المثال، عندما قمنا بترحيل ALB لدينا إلى أصل VPC، كان التنبيه أساسيًا في تحديد ومعالجة التباينات الناتجة في تدفق السجلات. ومع ذلك، فقد أنقذنا أيضًا في سيناريوهات أقل وضوحًا. على سبيل المثال، عندما فشلت مهام الأرشفة في التشغيل بسبب مشاكل غير متوقعة، أشار التنبيه إلى السجلات المفقودة، مما سمح لنا بالتحقيق في المشكلة وحلها بسرعة قبل أن تؤثر على تحليل سجلاتنا وعمليات الاحتفاظ بها.
بينما يعد هذا التنبيه أداة قوية، إلا أنه جزء واحد فقط من استراتيجيتنا الشاملة للمراقبة. نحن نستمر في تحسين وتكييف بنية سجلاتنا للتعامل مع الحجم المتزايد وتعقيد بيانات السجلات. من خلال الجمع بين المراقبة الاستباقية، وإدارة الموارد بكفاءة، وفهم عميق لسلوك نظامنا، تضمن Hugging Face أن تظل قناتنا الخاصة بالسجلات مرنة وموثوقة وقادرة على دعم نمو منصتنا واحتياجاتها المتطورة. هذا التنبيه هو شهادة على التزامنا بالحفاظ على نظام سجلات قوي وشفاف، مما يوفر لفرقنا الرؤى التي تحتاجها للحفاظ على تشغيل Hugging Face بسلاسة.
  أخطاء طلبات Kubernetes API وتحديد المعدلات 
عند تشغيل التطبيقات السحابية الأصلية والبنى التحتية المعتمدة على Kubernetes، يمكن أن تتصاعد حتى المشاكل الصغيرة إلى فترات توقف كبيرة إذا تُركت دون مراقبة. وهذا ينطبق بشكل خاص على Kubernetes API، الذي يعمل كنظام عصبي مركزي لمجموعة Kubernetes، منظمًا لإنشاء وإدارة وتواصل الحاويات. في Hugging Face، تعلمنا من خلال التجربة أن مراقبة معدل أخطاء Kubernetes API ومقاييس تحديد المعدلات هي ممارسة حاسمة، يمكن أن تمنع الكوارث المحتملة.
تتداخل بنية Hugging Face بعمق مع Kubernetes، وقد كانت مكتبة kube-rs أساسية في بناء وإدارة هذا النظام البيئي بكفاءة. تقدم kube-rs نهجًا مركزيًا حول Rust لتطوير تطبيقات Kubernetes، مما يوفر للمطورين مجموعة أدوات مألوفة وقوية. في جوهرها، تقدم kube-rs ثلاثة مفاهيم رئيسية: العاكسات، ووحدات التحكم، وواجهات الموارد المخصصة. تضمن العاكسات التزامن الفوري لموارد Kubernetes، مما يمكّن التطبيقات من الاستجابة بسرعة للتغييرات. وحدات التحكم، التي تتخذ القرارات، تتواصل باستمرار بين الحالة المرغوبة والحالة الفعلية للموارد، مما يجعل Kubernetes ذاتية الشفاء. تمتد واجهات الموارد المخصصة لـ Kubernetes، مما يسمح للمطورين بتعريف موارد محددة للتطبيق من أجل تحسين التجريد.
بالإضافة إلى ذلك، تقدم kube-rs المراقبين والمُنهين. تراقب المراقبون موارد محددة بحثًا عن التغييرات، مما يحفز الإجراءات استجابةً للأحداث. من ناحية أخرى، تضمن المُنهين التنظيف الصحيح وإنهاء الموارد من خلال تعريف منطق مخصص. من خلال توفير تجريدات قائمة على Rust لهذه المفاهيم في Kubernetes، تتيح kube-rs للمطورين بناء تطبيقات قوية وفعالة، مستفيدين من قوة ومرونة منصة Kubernetes مع الحفاظ على نهج تطوير مركزي حول Rust. تسهل هذه التكامل عملية بناء وإدارة تطبيقات Kubernetes المعقدة، مما يجعلها أداة قيمة في بنية Hugging Face.
تعتبر تكامل Hugging Face مع Kubernetes ركيزة أساسية في بنيتنا التحتية، وتلعب مكتبة kube-rs دورًا محوريًا في إدارة هذا النظام البيئي. يعد kube::api:: module أساسيًا في أتمتة المهام المختلفة، مثل إدارة شهادات HTTPS للنطاقات المخصصة التي تدعم منتج Spaces الخاص بنا. من خلال التعامل برمجيًا مع دورات حياة الشهادات، نضمن أمان خدماتنا وسهولة الوصول إليها، مما يوفر للمستخدمين تجربة سلسة. بالإضافة إلى ذلك، استخدمنا هذا الموديل خارج الميزات التي تواجه المستخدمين خلال الصيانة الروتينية لتسهيل تصريف وإنهاء العقد، مما يوفر استقرارًا للمجموعة أثناء تحديثات البنية التحتية.
لقد كان kube::runtime:: module مهمًا بنفس القدر بالنسبة لنا، مما يمكّن من تطوير ونشر وحدات تحكم مخصصة تعزز من أتمتة ومرونة بنيتنا التحتية. على سبيل المثال، قمنا بتنفيذ وحدات تحكم لإدارة الفواتير في خدماتنا المدارة، حيث تضمن المراقبون والمُنهين على حاويات العملاء تتبع الموارد بدقة والفوترة. يسمح لنا هذا المستوى من التخصيص بتكييف Kubernetes وفقًا لاحتياجاتنا المحددة.
من خلال kube-rs، حققت Hugging Face مستوى عالٍ من الكفاءة والموثوقية والتحكم في تطبيقاتنا السحابية الأصلية. يتماشى تصميم المكتبة المتمركز حول Rust مع فلسفتنا الهندسية، مما يسمح لنا بالاستفادة من نقاط قوة Rust في إدارة موارد Kubernetes. من خلال أتمتة المهام الحيوية وبناء وحدات تحكم مخصصة، أنشأنا بنية تحتية قابلة للتوسع وذاتية الشفاء تلبي احتياجات مستخدمينا وعملائنا المؤسسيين المتنوعة والمتطورة. يوضح هذا التكامل التزامنا باستغلال الإمكانات الكاملة لـ Kubernetes مع الحفاظ على نهج تطوير مصمم وفقًا لمتطلباتنا الفريدة.
بينما نادرًا ما تواجه بنيتنا مشاكل تتعلق بـ Kubernetes API، فإننا نبقى يقظين، خاصة أثناء وبعد عمليات النشر. تعتبر Kubernetes API عنصرًا حاسمًا في استخدامنا لـ kube::runtime:: لإدارة حاويات العملاء وموارد الشبكات السحابية. يمكن أن تؤدي أي انقطاعات أو كفاءات غير فعالة في الاتصال بالـ API إلى تأثيرات متتالية على خدماتنا، مما قد يؤدي إلى فترات توقف أو تدهور في الأداء.
تؤكد تجارب مستخدمي Kubernetes الآخرين على أهمية مراقبة هذه المقاييس API. على سبيل المثال، شاركت OpenAI تحديث حالة يوضح كيف أدت مشاكل توفر DNS إلى فترات توقف كبيرة. على الرغم من عدم ارتباطها مباشرة بـ Kubernetes API، إلا أن تجربتهم تسلط الضوء على الترابط بين مكونات البنية التحتية المختلفة وإمكانية حدوث فشل متسلسل. تمامًا كما أن توفر DNS أمر حيوي لسهولة الوصول إلى التطبيقات، فإن وجود Kubernetes API صحي واستجابة أمر ضروري لإدارة وتنظيم أحمال العمل الحاوية لدينا.
كأفضل ممارسة، قمنا بتكامل هذه المقاييس API في أنظمة المراقبة والتنبيه لدينا، مما يضمن أن أي شذوذ أو اتجاهات يتم إبلاغنا بها على الفور. يسمح لنا ذلك باتخاذ نهج استباقي، والتحقيق في القضايا ومعالجتها قبل أن تؤثر على عملائنا. على سبيل المثال، في إحدى المناسبات، بدأ مجموعة واحدة في تحديد المعدلات للطلبات إلى Kubernetes API. تمكنا من تتبع ذلك إلى أحد أدواتنا الخارجية التي واجهت خطأ وطلبت مرارًا تصريف عقدة حتى وإن كانت قد تمت بالفعل. استجبنا من خلال تصريف الوظيفة المعطلة من النظام قبل أن تؤثر أي تدهورات ملحوظة على مستخدمينا. هذه مثال رائع على أن سيناريوهات التنبيه لا تحدث فقط بعد نشر إصدارات جديدة من وحدات التحكم المخصصة لدينا - يمكن أن تستغرق الأخطاء وقتًا لتظهر كمشاكل إنتاجية.
في الختام، بينما بنيتنا التحتية قوية ومصممة بشكل جيد، ندرك أن اليقظة والمراقبة الاستباقية أمران أساسيان للحفاظ على صحتها واستقرارها. من خلال مراقبة معدل أخطاء Kubernetes API ومقاييس تحديد المعدلات، نحمي خدماتنا المدارة، ونضمن تجارب سلسة للعملاء، ونلتزم بالموثوقية والأداء. هذه شهادة على إيماننا بأنه في عالم التقنيات السحابية الأصلية، يلعب كل مكون، مهما كان صغيرًا، دورًا كبيرًا في المرونة العامة ونجاح منصتنا.
  تنبيه إضافي: مجموعة جديدة لا ترسل أي مقاييس 
وأخيرًا، تنبيه إضافي لمن قرأ حتى هنا في المنشور!
في Hugging Face، تجاربنا في حالة تغير مستمر، وغالبًا ما يتم تشغيل مجموعات مناسبة للغرض وإيقافها بينما نقوم بتكرار الميزات والمنتجات. لإضافة إلى الفوضى، يعد نموّنا أيضًا عاملًا كبيرًا، حيث تتوسع المجموعات إلى حدودها وتtrigger الانقسامات الشبيهة بالانقسام للحفاظ على التوازن. للتنقل في هذا البيئة الديناميكية دون اللجوء إلى التشفير الثابت أو إدخال طبقة اكتشاف مجموعات إضافية، قمنا بتطوير تنبيه ذكي يتكيف مع هذه التغييرات.
( (sum by (cluster) (rate(container_network_transmit_packets_total{pod="prometheus"}[1h] ) ) > 0) or (-1 * (sum by (cluster) (rate(container_network_transmit_packets_total{pod="prometheus"}[1h] offset 48h) ) > 0)) ) < 0 

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

الجزء الأول من الاستعلام يقوم بفحص المعدل الحالي. الجزء الثاني من الاستعلام يقوم بفحص المعدل التاريخي باستخدام نفس الحساب مثل فحص المعدل الحالي بالإضافة إلى عبارةoffset 48h. يتم استخدام الضرب بـ-1 * لعكس النتيجة، بحيث إذا كان المعدل التاريخي أكبر من 0، ستكون النتيجة أقل من 0.

يستخدم المشغل or لدمج الجزئين من الاستعلام. سيعيد الاستعلام true إذا تم استيفاء أي من الشرطين التاليين:


معدل نقل الحزم الحالي لمجموعة أكبر من 0.
معدل نقل الحزم التاريخي لمجموعة (قبل 48 ساعة) أكبر من 0، ولكن المعدل الحالي ليس كذلك.
الشرط الخارجي < 0 يتحقق مما إذا كانت نتيجة عملية or أقل من 0. وهذا يعني أن الاستعلام سيفعل فقط إذا لم يتم استيفاء أي من الشرطين، أي إذا كانت مجموعة لم ترسل أي مقاييس (كلا المعدلين الحالي والتاريخي هما 0).

هناك حالتان حيث سيتم تفعيل الاستعلام:

مجموعة جديدة بدون مقاييس: تمت إضافة مجموعة جديدة، لكنها لم ترسل أي مقاييس بعد. في هذه الحالة، سيكون كلا المعدلين الحالي والتاريخي 0، وسيتفعل الاستعلام.
مجموعة لم ترسل أي مقاييس من قبل: مجموعة موجودة لأكثر من 48 ساعة، لكنها لم ترسل أي مقاييس. في هذه الحالة، سيكون المعدل التاريخي 0، والمعدل الحالي سيكون أيضًا 0، مما يؤدي إلى تفعيل الاستعلام.
في كلتا الحالتين، سيكتشف الاستعلام أن المجموعة لا ترسل أي مقاييس وسيفعل التنبيه.
هذه الحلول البسيطة والفعالة تتفاعل في السيناريوهات حيث تتعطل بنية المقاييس لدينا، خلال إعداد المجموعات، وعند تفكيكها، مما يوفر لنا رؤى في الوقت المناسب حول صحة بنيتنا التحتية. بينما قد لا يكون هذا التنبيه الأكثر أهمية في ترسانتنا، إلا أنه يحتل مكانة خاصة لأنه وُلد من التعاون. إنه شهادة على قوة العمل الجماعي من خلال مراجعة الشيفرة الدقيقة، بفضل خبرة ورغبة زملائنا في فريق بنية Hugging Face في المساعدة 🤗
  الخاتمة 
في هذا المنشور، شاركنا بعضًا من تنبيهاتنا المفضلة التي تدعم البنية التحتية في Hugging Face. نود أن نسمع عن المفضلات في فريقكم أيضًا!
كيف تقومون بمراقبة بنية ML الخاصة بكم؟ ما هي التنبيهات التي تجعل فريقكم يعود لإصلاحات؟ ما الذي يتعطل كثيرًا في بنيتكم، أو على العكس، ما الذي لم تراقبوه أبدًا ويعمل ببساطة؟
شاركونا في التعليقات أدناه!