المقاييس والسجلات في CloudWatch

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

ويرسم كذلك الحد الذي تدور عليه أسئلة كثيرة في الاختبار. يسجّل CloudWatch ما تفعله مواردك، ويسجّل CloudTrail من طلب منها ذلك. والخدمتان هنا معاً، لأن الحوادث تحتاج إليهما معاً عادة.

ما الذي يغطيه هذا الموضوع

• هوية المقياس وتخزينه: مساحات الأسماء والأبعاد والدقة والإحصاءات والنسب المئوية، وسلّم الاحتفاظ الذي يقرّر ما تستطيع استعلامه بعد أشهر
• بنية CloudWatch Logs ومدد الاحتفاظ، والطرق الثلاث التي تصير بها بيانات السجل نافعة: metric filters وsubscription filters واستعلامات Logs Insights
• نشر وكيل CloudWatch الموحّد عبر أسطول كامل باستخدام Systems Manager وParameter Store، والحد الأمني بين سياسة الخادم وسياسة الإدارة
• CloudTrail في العمليات: سجل الأحداث مقابل الـ trails، وأنواع الأحداث الأربعة، وtrails المؤسسة، وCloudTrail Lake، والتنبيه على نشاط الحساب
• قياسات الحاويات عبر Container Insights على ECS وEKS، ومتى تكون Amazon Managed Service for Prometheus مع Amazon Managed Grafana الخيار الأنسب
• مراقبة serverless والذكاء الاصطناعي: مقاييس Lambda وفخ الخنق مقابل الخطأ، وLambda Insights وX-Ray، وتفكيك زمن الاستجابة في API Gateway، وتتبّع استهلاك Amazon Bedrock

لماذا هذا مهم

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

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