لقد ورثت مرةً ما نسخة من Grafana تحتوي على 47 لوحة بيانات. استخدام وحدة المعالجة المركزية، استهلاك الذاكرة، إدخال/إخراج القرص، بايتات الشبكة، كومة JVM — كل مقياس يمكنك تخيله. كل شيء كان أخضر. طوال الوقت.
بعد يومين، تعطلت واجهة API لمدة 4 ساعات. لم ينطلق أي تنبيه واحد.
لماذا؟ لأن استخدام وحدة المعالجة المركزية كان 22%، والذاكرة 45%، والقرص 30%. كلها "سليمة." المشكلة الفعلية كانت استنزاف تجمع الاتصالات — مقياس لم يكن أحد يراقبه.
الإشارات الذهبية الأربع (ولا شيء غيرها)
كتاب Google's SRE أصاب الهدف. تحتاج بالضبط إلى أربع إشارات:
1. زمن الاستجابة — كم من الوقت تستغرق الطلبات؟ ليس متوسط زمن الاستجابة — فهذا يخفي المشاكل. تتبع P50 و P95 و P99:
- P50 = 200ms يعني أن نصف المستخدمين يحصلون على استجابات في 200ms (جيد)
- P95 = 800ms يعني أن 1 من كل 20 مستخدمًا ينتظر 800ms (مقبول)
- P99 = 5000ms يعني أن 1 من كل 100 مستخدم ينتظر 5 ثوانٍ (مشكلة)
P99 الخاص بك هو أداؤك الحقيقي. المتوسط يكذب.
2. حركة المرور — كم عدد الطلبات التي تتعامل معها؟ هذا هو خط الأساس لديك. إذا انخفضت حركة المرور بنسبة 80% في الساعة 2 ظهرًا من يوم الثلاثاء، فهناك خطأ ما حتى لو كانت جميع المقاييس الأخرى خضراء.
3. الأخطاء — ما النسبة المئوية للطلبات التي تفشل؟ تتبع معدل الخطأ، وليس عدد الأخطاء. 100 خطأ من أصل مليون طلب (0.01%) أمر جيد. 100 خطأ من أصل 200 طلب (50%) هو انقطاع للخدمة.
4. التشبع — ما مدى امتلاء نظامك؟ اتصالات قاعدة البيانات، الذاكرة، عمق قائمة الانتظار، تجمعات الخيوط. عندما يصل أي مورد إلى 80% من الاستخدام، تحتاج إلى التصرف — ليس لأنه معطل، ولكن لأنك فقدت مساحة الأمان لديك.
إعداد المراقبة الفعلي لدي
لمنصة Nexural:
\\
