أساسيات التنبيهات في CloudWatch

تنبيهان في الليلة نفسها وداخل الحساب نفسه. الأول لم يُطلق قط بينما تكدّس طابور الدفع 40 دقيقة. والثاني أُطلق 14 مرة بين 02:00 و03:00 دون أن يكون هناك خلل حقيقي. بناهما مهندسان يعرفان تماماً ما يعنيه CPUUtilization وما يعنيه ApproximateAgeOfOldestMessage، ولا يعرف أي منهما كيف يقرّر CloudWatch تغيير حالة التنبيه.

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

مما يتكوّن التنبيه

يراقب تنبيه المقياس مقياساً واحداً، أو ناتج تعبير metric math واحد، ويحمل واحدة من ثلاث حالات. وليقرّر أيها، يحتاج إلى إجابات ستة أسئلة:

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

وهذا تنبيه واحد بقيم حقيقية: راقب CPUUtilization للخادم i-0a1b2c3d4e5f67890، خذ Average لكل فترة مدتها 60 ثانية، عُدّ الفترة سيئة حين يتجاوز متوسطها 80، وانتقل إلى ALARM حين تكون 3 من آخر 5 فترات سيئة.

aws cloudwatch put-metric-alarm \
  --alarm-name "checkout-api-cpu-high" \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0a1b2c3d4e5f67890 \
  --statistic Average \
  --period 60 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 5 \
  --datapoints-to-alarm 3 \
  --treat-missing-data missing \
  --alarm-actions arn:aws:sns:eu-west-1:111122223333:ops-critical

ثلاث حالات، وقاعدة يخطئ فيها الجميع تقريباً

التنبيه دائماً في واحدة من هذه الحالات بالضبط:

• OK: المقياس داخل العتبة.
• ALARM: المقياس خارج العتبة.
• INSUFFICIENT_DATA: التنبيه بدأ للتو، أو المقياس غير متاح، أو البيانات لا تكفي للحكم.

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

والآن القاعدة: يستدعي التنبيه إجراءاته عند تغيّر حالته فقط. لا عند كل فترة، ولا كل دقيقة. مرة واحدة، عند الانتقال.

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

وهناك استثناء واحد بالضبط يحبّه الاختبار: في إجراءات Auto Scaling يواصل التنبيه استدعاء الإجراء مرة كل دقيقة ما بقي في حالته الجديدة. وهذا مقصود، لأن سياسة توسيع تُطلق مرة واحدة ثم تصمت لن تكمل أبداً توسيع مجموعة مثقلة بالحمل.

الفترة وعدد فترات التقييم ونقاط التنبيه

من هذه الإعدادات الثلاثة يأتي التنبيه الذي «لم يُطلق أبداً» والتنبيه الذي «أُطلق 14 مرة»، فاشتغل عليها بالأرقام لا بالتعريفات.

الفترة (Period) هي المدة التي تغطيها كل نقطة بيانات. قيمها الصالحة 10 أو 20 أو 30 أو أي مضاعف لـ 60 ثانية.

عدد فترات التقييم (Evaluation Periods, N) هو عدد أحدث نقاط البيانات التي ينظر إليها التنبيه.

نقاط التنبيه (Datapoints to Alarm, M) هو عدد النقاط المخالفة المطلوب من بين تلك الـ N لينتقل التنبيه إلى ALARM. ونقاط المخالفة ليست ملزمة بالتتالي، بل يكفي وقوعها داخل نافذة آخر N نقطة.

حين تساوي M قيمة N يصبح لديك تنبيه «فترات متتالية»: كل نقطة في النافذة يجب أن تكون مخالفة. وحين تقلّ M عن N يصبح لديك تنبيه M من N، وهو يتحمّل ومضة سليمة في منتصف فترة سيئة.

فاصل التقييم هو ببساطة حاصل ضرب N في الفترة. أربع نقاط من خمس بفترة دقيقة واحدة تعني فاصلاً مدته 5 دقائق. وثلاث من ثلاث بفترة 10 دقائق تعني فاصلاً مدته 30 دقيقة.

ولأي فترة تبلغ دقيقة أو تزيد، يُقيَّم التنبيه كل دقيقة، والنافذة تنزلق. بفترة 5 دقائق وفترة تقييم واحدة، تُقيّم نهاية الدقيقة 5 الدقائقَ من 1 إلى 5، وتُقيّم نهاية الدقيقة 6 الدقائقَ من 2 إلى 6. وإن كانت الفترة 10 أو 20 أو 30 ثانية، فالتقييم كل 10 ثوانٍ بدلاً من ذلك.

وهناك حدّان يقيّدان إلى أي مدى يستطيع التنبيه النظر إلى الوراء. حاصل ضرب الفترة في عدد فترات التقييم لا يتجاوز 604,800 ثانية (سبعة أيام) للتنبيهات ذات الفترة البالغة ساعة فأكثر، ولا يتجاوز 86,400 ثانية (يوماً واحداً) لما هو أقصر. والتنبيه الذي تتخطى نافذته يوماً واحداً يصبح تنبيهاً متعدد الأيام، فيُقيَّم مرة واحدة كل ساعة ولا يأخذ في الحسبان إلا المقاييس حتى الدقيقة :00 من الساعة الجارية. المهمة التي تفشل عند 10:02 لن تحرّك تنبيهاً كهذا في 10:03، بل يستجيب عند 11:03.

البيانات المفقودة: ماذا يعني الصمت

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

فتخبره أنت، بواحد من أربعة إعدادات:

الافتراضي هو missing. واستثناءان يستحقان الحفظ. التنبيهات على مقاييس مساحة الاسم AWS/DynamoDB تعتمد افتراضياً ignore. وتوصي AWS تحديداً بـ missing للتنبيهات التي توقف خوادم EC2 أو تنهيها أو تعيد تشغيلها أو تستعيدها، لأن نشر مقاييس EC2 قد ينقطع لحظياً على خادم سليم تماماً، ولا تريد لثغرة في النشر أن تنهي خادم إنتاج.

اختياران محدّدان: مقياس ThrottledRequests في DynamoDB لا ينشر نقطة إلا حين يُخنق طلب، فـ notBreaching هو الصحيح. والتنبيه الذي يشغّل تراجعاً عن نشرة يراقب مقياساً يبلّغ باستمرار، فالثغرة فيه تعني على الأرجح أن التطبيق توقف عن الرد، وbreaching هو الصحيح.

نطاق التقييم، ولماذا يُتجاهل إعدادك غالباً

هنا الجزء الذي يجعل التنبيهات تتصرّف بطرق لا تتوقعها الإعدادات ظاهرياً.

كلما قيّم التنبيه حالته، يسترجع CloudWatch نقاط بيانات أكثر من عدد فترات التقييم. والإطار الزمني لتلك النقاط الإضافية يسمّى نطاق التقييم (evaluation range). فالتنبيه بثلاث فترات تقييم يكون نطاق تقييمه 5 نقاط بيانات.

ثم يطبّق ثلاث قواعد بالترتيب:

1. إن لم تكن أي نقطة داخل نطاق التقييم مفقودة، يقيّم أحدث N نقطة ويتجاهل الزائد.
2. إن فُقدت بعض النقاط لكن مجموع النقاط الحقيقية المسترجعة بلغ N أو تجاوزه، يقيّم أحدث N نقطة حقيقية، ممتداً إلى النقاط الإضافية الأقدم. ولا يُستخدم إعداد البيانات المفقودة إطلاقاً.
3. ولا يملأ CloudWatch الفجوات بإعدادك إلا حين تبقى النقاط الحقيقية أقل من N، وحتى حينها يستخدم أقل عدد ممكن من النقاط المستبدَلة.

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

ولهذا يستطيع مهندسان أن يضبطا breaching وnotBreaching على المقياس المتقطّع نفسه، ثم يشاهدا التنبيهين يتصرفان تصرفاً متطابقاً لأسابيع.

وهناك منطق إضافي اسمه تفادي حالة التنبيه المبكرة. بنقاط تنبيه تساوي 3، لا تنتقل بيانات - - - - X (أربع مفقودة ثم واحدة مخالفة) إلى ALARM فوراً، لأن النقطة التالية قد تكون سليمة. لكن بيانات - - X - - تنتقل إلى ALARM حتى مع معاملة المفقود على أنه مفقود، لأن أقدم نقطة مخالفة متاحة لا تقل قِدماً عن قيمة M وكل ما هو أحدث منها مخالف أو مفقود. لا تتوقّع من جدول البيانات المفقودة وحده أن يتنبأ بهذه الحواف.

التنبيهات عالية الدقة

اضبط الفترة على 10 أو 20 أو 30 ثانية فتكون قد أنشأت تنبيهاً عالي الدقة، يُقيَّم كل 10 ثوانٍ ويُحاسَب بسعر أعلى من التنبيه العادي.

استخدم هذه الفترات فقط للمقاييس المنشورة بدقة تخزين مقدارها ثانية واحدة، أي مقاييسك المخصصة عالية الدقة. وجّه تنبيهاً بفترة 10 ثوانٍ إلى مقياس قياسي الدقة فسيحاول CloudWatch جمع البيانات كل 10 ثوانٍ، ولا يجد شيئاً في خمس محاولات من ست، ويُسقط التنبيه في INSUFFICIENT_DATA بانتظام. تحصل على تنبيه غير موثوق وعلى السعر المرتفع في آن واحد.

أبعد من رقم ثابت

ليس لكل سؤال عتبة ثابتة، ويعطيك CloudWatch طريقتين لتجاوز ذلك.

تنبيهات metric math تراقب ناتج تعبير بدل مقياس خام. والحالة الكلاسيكية هي معدل الأخطاء، لأن «500 خطأ» تعني شيئاً مختلفاً تماماً عند 600 طلب مما تعنيه عند 6 ملايين:

{
  "Metrics": [
    { "Id": "errors",   "MetricStat": { "Metric": { "Namespace": "MyService", "MetricName": "ConnectionsFailed" }, "Period": 60, "Stat": "Sum" }, "ReturnData": false },
    { "Id": "attempts", "MetricStat": { "Metric": { "Namespace": "MyService", "MetricName": "ConnectionAttempts" }, "Period": 60, "Stat": "Sum" }, "ReturnData": false },
    { "Id": "error_rate", "Expression": "(errors/attempts)*100", "ReturnData": true, "Label": "Connection error rate" }
  ],
  "Threshold": 40,
  "ComparisonOperator": "GreaterThanThreshold",
  "EvaluationPeriods": 3
}

عنصر واحد بالضبط داخل مصفوفة Metrics يضبط ReturnData على true، وهو التعبير الذي يراقبه التنبيه.

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

{
  "Metrics": [
    { "Id": "m1", "ReturnData": true, "MetricStat": { "Metric": { "Namespace": "AWS/EC2", "MetricName": "CPUUtilization" }, "Stat": "Average", "Period": 60 } },
    { "Id": "t1", "Expression": "ANOMALY_DETECTION_BAND(m1, 3)" }
  ],
  "ThresholdMetricId": "t1",
  "ComparisonOperator": "LessThanLowerOrGreaterThanUpperThreshold",
  "EvaluationPeriods": 2
}

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

• النموذج خاص بمقياس واحد وإحصاء واحد. نموذج مدرّب على Average لا يقول لك شيئاً عن Maximum.
• تستطيع استبعاد فترات زمنية من التدريب، وهكذا تمنع اختبار حمل أُجري الشهر الماضي من تعليم النموذج أن قفزة بعشرة أضعاف أمر طبيعي.
• التنبيهات المبنية على نموذج شذوذ لا تقبل إجراءات Auto Scaling.
• كل تنبيه اكتشاف شذوذ يُحاسَب كثلاثة مقاييس تنبيه قياسية الدقة (المقياس زائد الحدّين الأعلى والأدنى)، أي نحو 0.30 دولار شهرياً مقابل 0.10 دولار لتنبيه مقياس عادي.

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

تشخيص تنبيه لا يغادر INSUFFICIENT_DATA

هذه أكثر تذاكر التنبيهات شيوعاً، ولها قائمة أسباب قصيرة:

• الفترة أقصر من دقة المقياس. المراقبة الأساسية في EC2 تنشر كل 5 دقائق، فتترك فترة الـ 60 ثانية أربع فترات فارغة من كل خمس.
• مجموعة الأبعاد لم تُنشر قط. يمكن إنشاء التنبيه قبل وجود مقياسه المخصص، وسيبقى راكناً في INSUFFICIENT_DATA إلى الأبد إن لم تطابق الأبعاد بالضبط ما تنشره.
• تحديد Unit لا يستخدمه المقياس أبداً. توصي AWS بحذف Unit كلياً، لأن عدم التطابق ينتج تنبيهاً عالقاً بدل تنبيه يعطي خطأ.
• المورد خامل فعلاً. أحجام EBS غير المرتبطة، ودوال Lambda بلا استدعاءات، ومجموعات Auto Scaling عند صفر خوادم، جميعها تتوقف عن النشر.

يُحتفظ بتاريخ التنبيه 30 يوماً، ويعرض describe-alarm-history كل انتقال حالة مع طابعه الزمني. هذه محطتك الأولى حين يسألك أحدهم إن كان التنبيه قد أُطلق يوماً.

aws cloudwatch describe-alarm-history \
  --alarm-name "checkout-api-cpu-high" \
  --history-item-type StateUpdate \
  --max-records 10

نصائح للاختبار

• عبارة «بقي التنبيه في ALARM لكننا استلمنا رسالة واحدة» ليست عطلاً أبداً. الإجراءات تُطلق عند تغيّر الحالة. والإجراء الوحيد الذي يُعاد استدعاؤه ما دامت الحالة قائمة هو إجراء Auto Scaling، مرة كل دقيقة.
• اقرأ صياغة العتبات بدقة. «3 فترات متتالية» تعني تساوي M وN، و«3 من 5» تعني M=3 وN=5 ونقاط المخالفة قد تكون متناثرة.
• اربط خيارات البيانات المفقودة بطبيعة المقياس: المقياس الذي لا ينشر إلا عند الفشل يشير إلى notBreaching، والمقياس المستمر الذي يكون صمته مريباً يشير إلى breaching، وتنبيهات إيقاف EC2 وإنهائه وإعادة تشغيله واستعادته تشير إلى missing وهو الافتراضي العام أيضاً.
• الفترة 10 أو 20 أو 30 ثانية تعني تنبيهاً عالي الدقة، وهو لا يعمل إلا على المقاييس المخزّنة بدقة الثانية. أي سؤال يذكر فترة دون الدقيقة ومقياساً تنشره AWS يصف تنبيهاً معطوباً.
• إن قال السيناريو «لا تصلح أي عتبة ثابتة، فالمستوى الطبيعي يتغيّر حسب ساعة اليوم»، فالجواب اكتشاف الشذوذ، وتذكّر أنه لا يستطيع تشغيل Auto Scaling.
• نافذة التنبيه التي تتجاوز يوماً تُقيَّم كل ساعة مقابل البيانات حتى رأس الساعة، والنافذة الكلية تتوقف عند سبعة أيام.

القاعدة التي تحملها معك: حالة التنبيه تقرّرها نافذة منزلقة من آخر N نقطة بيانات، وكل ما يبدو غير متوقع في التنبيهات مصدره ما يفعله CloudWatch حين تكون في تلك النافذة ثقوب. بعد ذلك تتبع الإشعار وهو يخرج من التنبيه ويدخل إلى Amazon SNS، حيث تنتظرك مجموعة أخرى من الأعطال الصامتة.