قياسات في Prometheus، لوحات تحكم في Grafana، سجلات في Loki، تعقب موزع في Tempo، تنبيهات من خلال Alertmanager - كلها مستضافة ذاتيا إلى جانب المنصة التي يراقبونها. الرصد هو الجزء من المشروع الذي يتم تقليصه عندما تتضاعف الميزانية، وهو الجزء الذي يكلف غيابه أكثر من غيره.
| الإجراء | القيمة | المصدر | المقيسة |
|---|---|---|---|
| عناصر قابلية المراقبة العاملة | 5 (Prometheus, Grafana, Loki, Tempo, Alertmanager) | kubectl get deployments,statefulsets -n monitoring | |
| الخدمات في إطار جمع القياسات | 65 deployments in the platform namespace | kubectl get deployments -n kamo |
ما المبنى الذي علمنا
إن كل نظام تقريباً يُطلَب منا أن نتولى تشغيله يحتوي على نفس الفجوة. فليس هناك أي وسيلة لمعرفة ما إذا كان يعمل إلا باستخدامه. ولا أحد يعرف كيف يبدو النظام في حالته الطبيعية، لذا فلا أحد يستطيع أن يعرف متى يتوقف. وأول علامة على المشكلة هي شكوى العميل، وهذا يعني أن الساعة بدأت قبل أن ينظر إليها أي شخص.
التتبع الموزع هو الجزء الأكثر نقصاً وأكثر أهمية في كثير من الأحيان. في نظام من أربعين خدمة، "الصفحة بطيئة" ليست تشخيصاً - إنها بداية جدل بين الفرق. ينهي التتبع الجدل في حوالي دقيقة واحدة عن طريق إظهار أي استدعاء استغرق الوقت بالضبط. نحن نستخدم أنظمة العملاء لهذا قبل الإطلاق، لأن إعادة تجهيز التتبع في نظام عامل هو عدة مرات من العمل الذي يحتاجه لبناءه.
إن التغيير في التصميم يغير أيضاً ما يبدو عليه محادثة الدعم. فعندما يبلغ مستأجر أن أحد الأدوات قد توقف العمل بعد فترة وجيزة من تغيير المخطط، نستطيع أن نعرف من المقاييس أن مجمعات الاتصال هي السبب وأنها سوف تقوم بتطهير نفسها، بدلاً من إعادة تشغيل الخدمات وتفاقم الأمور. إن معرفة متى لا نفعل شيئاً هي مهارة تشغيلية وتعتمد كلياً على القدرة على الرؤية.
بنيت بـ
- Prometheus
- Grafana
- Loki
- Tempo
- Alertmanager
- kube-state-metrics
أخبرنا ماذا تحاول أن تفعل
إن محادثة قصيرة تكفي عادة لمعرفة ما إذا كنا الشخص المناسب. وإذا لم نكن، فسوف نقول ذلك ونشير إليك إلى مكان أفضل.