sultanops
EN
الجزء 25 من سلسلة تعلّم AWS من الصفر

المراقبة والتدقيق: CloudWatch وCloudTrail وConfig

كيف تعرف إن تطبيقك بخير، ومين غيّر وش، وهل إعداداتك لسا زي ما لازم؟ المقاييس والسجلات والإنذارات في CloudWatch، وEventBridge وCloudTrail وConfig، مع تجربة عملية لإنذار يرسل لك إيميل.

  • سلطان عايض
  • 7 دقائق قراءة
في هذا المقال
  1. مقاييس CloudWatch
  2. سجلات CloudWatch
  3. إنذارات CloudWatch
  4. EventBridge: الرد على الأحداث
  5. CloudTrail: مين سوى وش
  6. AWS Config: إعداداتك مع الوقت
  7. X-Ray: تتبع طلب واحد
  8. أدوات ثانية للمتابعة
  9. أيها ومتى؟
  10. عملي: إنذار يرسل لك إيميل
  11. الخلاصة
  12. اختبر نفسك

خلال الأجزاء السابقة بنينا تطبيق بقطع كثيرة. بناؤه هو النص السهل. النص الصعب يجي الساعة ثلاث الفجر: هو واقف؟ من متى؟ ومين غيّر هذاك الإعداد أمس؟

هذا القسم الأخير عن تشغيل اللي بنيته، ويبدأ بثلاث أسئلة، لكل واحد خدمته:

السؤال الخدمة
هو بخير الحين؟ CloudWatch
مين سوى هذا، ومتى؟ CloudTrail
الإعدادات زي ما لازم، وكيف تغيرت؟ Config

وخدمة رابعة ترد على كل هذا: EventBridge.

مقاييس CloudWatch

المقياس (Metric) رقم ينقاس مع الوقت، مثل استخدام المعالج أو عدد الأخطاء. وأغلب خدمات AWS ترسل مقاييسها لحالها، مجمعة في Namespaces ومميزة بـ Dimensions، مثل رقم السيرفر.

النقطة التفاصيل
الافتراضي في EC2 كل 5 دقايق، أو كل دقيقة لو شغلت المراقبة التفصيلية
المقاييس الخاصة ترسل اللي تبي، مثل عدد الطلبات الفاشلة، وبدقة توصل لثانية
السجل التاريخي بيانات الدقيقة تبقى 15 يوم، وبيانات 5 دقايق 63 يوم، والساعة 455 يوم
Metric Streams ترسل المقاييس باستمرار عبر Firehose إلى S3 أو أداة مراقبة ثانية

وDashboards تجمع الرسوم اللي تهمك في صفحة وحدة، وتقدر تجمع مقاييس من مناطق وحسابات مختلفة.

سجلات CloudWatch

كل اللي يطبعه تطبيقك ممكن ينزل هنا، مرتب في Log Groups تمثل عادةً تطبيق واحد، وداخلها Log Streams. وLambda وECS وAPI Gateway وVPC Flow Logs وغيرها ترسل سجلاتها مباشرة، وعلى EC2 أو سيرفرات مكتبك تستخدم نفس الـ Agent.

والسجلات تبقى للأبد افتراضياً، وأنت تدفع عليها. حدد مدة حفظ لكل مجموعة، من يوم إلى عشر سنوات.

وLogs Insights يبحث فيها بلغة استعلام بسيطة. هذا يجيب آخر الأخطاء:

Output
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

وعشان ترسل السجلات لمكان ثاني عندك طريقين:

الطريق التوقيت يناسب
التصدير إلى S3 شغل دفعات، ومو فوري أرشفة طويلة ورخيصة
Subscription Filter شبه فوري الإرسال إلى Lambda أو Kinesis أو Firehose، مثل OpenSearch

إنذارات CloudWatch

رسم ما يطالعه أحد ما له فايدة. الإنذار (Alarm) يراقب مقياس ويسوي شي لما يتجاوز حد.

مقياس المعالج والأخطاء إنذار فوق 80%؟ SNS Auto Scaling إجراء EC2
الإنذار يراقب مقياس، ولما يتجاوز الحد، ينبه أحد أو يزيد السعة أو يتصرف مع السيرفر.

والإنذار يكون في وحدة من ثلاث حالات: OK أو ALARM أو INSUFFICIENT_DATA. وهذي إضافات مفيدة:

  • إجراءات EC2: إيقاف أو إعادة تشغيل أو حذف أو استعادة. والاستعادة تنقل السيرفر لعتاد جديد لو تعطل المضيف، مع الحفاظ على عناوين IP والإعدادات.
  • الإنذارات المركبة: إنذار واحد لـ "معالج مرتفع وأخطاء كثيرة"، وهذا يقلل التنبيهات الكاذبة.
  • الاختبار: set-alarm-state يحط الإنذار في أي حالة، فتتأكد من مسار التنبيه بدون ما تكسر شي. وبنجربه في التجربة العملية.

رؤى جاهزة

الأداة وش تبين
Container Insights مقاييس وسجلات ECS وEKS
Lambda Insights أداء الدوال، ومعها الذاكرة والبداية الباردة
Contributor Insights أكبر المساهمين، مثل عناوين IP اللي ترسل أكثر طلبات
Application Insights تجهز المراقبة لتطبيق كامل وتشير للمشاكل المحتملة

EventBridge: الرد على الأحداث

تقريباً كل شي يصير في AWS هو حدث: سيرفر تغيرت حالته، أو حاوية انشأت، أو إنذار انطلق. EventBridge يستقبل هذي الأحداث على Bus، والقواعد ترسل المطابق منها لهدف.

خدمات AWS تطبيقاتك جدول زمني Event Bus القواعد تفلتر الأحداث Lambda SQS Step Functions
الأحداث توصل على Bus من أي مكان، والقواعد ترسل كل حدث مطابق للخدمة اللي تعالجه.
الاستخدام مثال
الرد على تغيير سيرفر وقف، فنبّه الفريق
جدول زمني شغّل دالة كل ليلة، وEventBridge Scheduler هو الخدمة لهذا الحين
ربط خدماتك خدمة الطلبات تنشر حدث، واللي يهمه ياخذه
أحداث الشركاء أحداث من تطبيقات SaaS على Bus خاص بالشريك

وميزات تستاهل تعرفها: الأرشفة وإعادة الإرسال للأحداث القديمة، وSchema Registry يوصف شكل الأحداث، وسياسات الموارد عشان حساب ثاني يرسل لـ Bus حقك.

ولأغلب الأهداف، مثل Lambda وSQS وSNS، الصلاحية تكون بسياسة مورد على الهدف. ولغيرها، مثل تشغيل مهمة ECS، يستخدم EventBridge دور IAM.

CloudTrail: مين سوى وش

كل استدعاء لـ AWS، من الكونسول أو CLI أو خدمة، يسجله CloudTrail: مين، ووش، ومتى، ومن وين. وهو شغال افتراضياً، وأول مكان تطالعه لما شي يتغير بغموض أو يختفي.

نوع الحدث وش يغطي الافتراضي
Management Events تغييرات الموارد، مثل إنشاء سيرفر أو تعديل سياسة شغال، و90 يوم مجانية في Event History
Data Events عمليات داخل الموارد، مثل القراءة من S3 أو استدعاء Lambda مقفل بسبب كثرتها
Insights Events نشاط غير معتاد، مثل موجة حذف مفاجئة مقفل وبتكلفة إضافية

وعشان تحفظها أكثر من 90 يوم، أنشئ Trail يكتب إلى S3، لكل المناطق وحتى المنظمة كلها، وحللها بـ Athena. ولاحظ إن CloudTrail Lake أقفل على العملاء الجدد في 2026، فالـ Trail هو الطريق.

ونمط قوي يجمعه مع EventBridge: أي أحد يحذف جدول، أو دخول بحساب Root، يطلق تنبيه فوري. CloudTrail يسجله، وEventBridge يطابقه، وSNS يبلغك.

AWS Config: إعداداتك مع الوقت

CloudTrail يقول لك مين استدعى وش. Config يقول لك شكل المورد: يسجل إعدادات مواردك وكل تغيير عليها، فتقدر تسأل كيف كان شكل Security Group الثلاثاء الماضي.

وقواعد Config تحكم على هذي الإعدادات:

  • القواعد: جاهزة، مثل "ما فيه حاويات S3 عامة"، أو خاصة فيك.
  • المنع: ما يمنع شي. يعلّم المورد إنه غير ملتزم، وبس.
  • المعالجة: القاعدة تقدر تشغل مستند Systems Manager Automation يصلح المشكلة تلقائياً.
  • التنبيهات: عبر EventBridge أو SNS.
  • النطاق والتكلفة: يشتغل لكل منطقة، وتدفع لكل عنصر مسجل ولكل تقييم قاعدة.

X-Ray: تتبع طلب واحد

الطلب في التطبيقات الحديثة ممكن يمر على API وثلاث دوال وقاعدة بيانات. المقاييس تقول إن فيه شي بطيء، وAWS X-Ray يقول وين. يجمع Traces لكل طلب وهو يمر على خدماتك، بما فيها اتصالاته بقواعد البيانات وواجهات API الثانية، ويوريك أي خطوة بطيئة أو تفشل.

أدوات ثانية للمتابعة

الأداة وش تعرض
AWS Health Dashboard هل عند AWS نفسها مشكلة تأثر على خدماتك ومواردك، بدون تجهيز وبدون تكلفة
Managed Grafana لوحات للمقاييس والسجلات والتتبع من عدة مصادر، بأداة Grafana المعروفة
Managed Service for Prometheus مقاييس الحاويات بأدوات Prometheus مفتوحة المصدر، بدون سيرفرات تشغلها

أيها ومتى؟

خلنا ناخذ موزع حمل واحد:

مثال
CloudWatch عدد الطلبات وأخطاء 5xx، ولوحة أو إنذار عليها
CloudTrail مين غيّر قواعد المستمع، ومتى
Config Security Group والشهادة الحالية وكيف تغيرت، وهل يلتزم بقواعدك؟

عملي: إنذار يرسل لك إيميل

بنراقب مقياس وهمي للطلبات الفاشلة. من CloudShell، بدّل الإيميل بإيميلك:

Bash
EMAIL=[email protected]

TOPIC_ARN=$(aws sns create-topic --name series-alerts \
  --query TopicArn --output text)

aws sns subscribe --topic-arn $TOPIC_ARN \
  --protocol email --notification-endpoint $EMAIL

افتح إيميلك واضغط Confirm subscription. ثم أنشئ إنذار ينطلق لو فشل أكثر من خمس طلبات في دقيقة:

Bash
aws cloudwatch put-metric-alarm --alarm-name series-failed-orders \
  --namespace Series/Shop --metric-name FailedOrders \
  --statistic Sum --period 60 --evaluation-periods 1 \
  --threshold 5 --comparison-operator GreaterThanThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions $TOPIC_ARN

الحين أرسل قراءة التطبيق، كأن 12 طلب فشلت للتو:

Bash
aws cloudwatch put-metric-data --namespace Series/Shop \
  --metric-name FailedOrders --value 12

انتظر دقيقتين أو ثلاث وشيك على حالة الإنذار. والمفروض يوصلك إيميل بنفس الوقت:

Bash
aws cloudwatch describe-alarms --alarm-names series-failed-orders \
  --query "MetricAlarms[0].[StateValue,StateReason]" --output text

وما تحتاج تكسر شي عشان تختبر مسار التنبيه. جربه لما يرجع الإنذار إلى OK، ويوصلك إيميل ثاني:

Bash
aws cloudwatch set-alarm-state --alarm-name series-failed-orders \
  --state-value ALARM --state-reason "Testing the alert"

وأخيراً، سوّ نفسك محقق. مين أنشأ هذا الإنذار؟ CloudTrail يعرف، بس الأحداث ممكن تاخذ كم دقيقة عشان تظهر:

Bash
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=PutMetricAlarm \
  --max-results 1 \
  --query "Events[0].[EventName,Username,EventTime]" --output text
Bash
aws cloudwatch delete-alarms --alarm-names series-failed-orders
aws sns delete-topic --topic-arn $TOPIC_ARN

الخلاصة

  • CloudWatch للمقاييس والسجلات والإنذارات، والذاكرة تحتاج الـ Agent.
  • حدد مدة حفظ لسجلاتك، لأنها تبقى للأبد افتراضياً.
  • EventBridge يوجه الأحداث للي يعالجها، ويشغّل الأشياء بجدول زمني.
  • CloudTrail يسجل مين سوى وش، وConfig يسجل الإعدادات ويحكم عليها.
  • اختبر مسار التنبيه قبل ما تحتاجه.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 7

فريق يبي إنذار لما تتجاوز ذاكرة سيرفرات EC2 حقته 90%، بس ما يلقى مقياس للذاكرة في CloudWatch. وش يسوي؟

اعرض الجواب

الجواب الصحيح: B

المقاييس الافتراضية تجي من خارج السيرفر، فما فيها الذاكرة. والـ Agent يرسلها من داخله، وبعدها تقدر تحط عليها إنذار.

  • A: هذا يرسل نفس المقاييس بشكل أكثر، والذاكرة لسا مو منها.
  • C: هذا يسجل مين نادى وش، مو كيف أداء السيرفر.
  • D: هذا يسجل إعدادات الموارد، مو اللي يصير داخل السيرفر.

للمراجعة: مقاييس CloudWatch في هذا الجزء، وMetrics collected by the CloudWatch agent في وثائق AWS.

السؤال 2 من 7

بدأ عطل بعد ما غيّر أحد مجموعة أمان البارحة بالليل. والفريق يبي يعرف مين سوى التغيير، ومن وين. وين يدور أول؟

اعرض الجواب

الجواب الصحيح: D

CloudTrail يسجل مين نادى وش، ومتى، ومن وين. والأحداث الإدارية مثل هذا تبقى هناك 90 يوم، بدون أي تجهيز.

  • A: هذي تعرض أرقام مع الوقت، مو مين سوى شي.
  • B: هذي تعرض الزيارات المقبولة والمرفوضة، مو مين غيّر قاعدة.
  • C: هذا يبحث في السجلات اللي ترسلها تطبيقاتك، مو الاستدعاءات إلى AWS.

للمراجعة: CloudTrail: مين سوى وش في هذا الجزء، وWorking with CloudTrail event history في وثائق AWS.

السؤال 3 من 7

شركة تبي تنتبه لما تصير أي حاوية S3 عامة، وتصلحها تلقائياً. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

قاعدة Config تحكم على إعدادات كل حاوية وتعلّمها غير ملتزمة، والـ Remediation يقدر يشغّل مستند Systems Manager Automation يصلحها. والقاعدة لحالها ما تمنع شي.

  • B: الحجم ما يقول شي عن مين يقدر يوصل للحاوية.
  • C: هذا يكشف النشاط غير العادي، وما يحكم على الإعدادات ولا يصلحها.
  • D: هذا يبحث في السجلات لما تطلب، وما يصلح شي.

للمراجعة: AWS Config: إعداداتك مع الوقت في هذا الجزء، وRemediating Noncompliant Resources with AWS Config في وثائق AWS.

السؤال 4 من 7

فريق الأمان يبي تنبيه فوري كل ما حذف أحد جدول DynamoDB أو دخل بالمستخدم الجذر. وش يناسب؟

اعرض الجواب

الجواب الصحيح: C

CloudTrail يسجل الاستدعاء، وEventBridge يطابقه، وSNS يخبرك على طول.

  • A: هذا يلقاها في النهاية، بس ممكن متأخر بأيام.
  • B: اللوحة اللي ما يطالعها أحد ما تنبه أحد.
  • D: هذا يحكم على الإعدادات، وما يتفاعل مع حذف جدول أو تسجيل دخول.

للمراجعة: CloudTrail: مين سوى وش في هذا الجزء، وAWS service events delivered via AWS CloudTrail في وثائق AWS.

السؤال 5 من 7

فاتورة CloudWatch Logs عند فريق تكبر لأن السجلات القديمة ما تنحذف أبداً، ونظام ثاني لازم يستلم سطور الأخطاء خلال ثواني. أي تغييرين يناسبون؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: A + D

السجلات تبقى للأبد افتراضياً، فمدة الاحتفاظ تشيل القديمة. والـ Subscription Filter يوصّل السطور المطابقة شبه فوري.

  • B: هذا شغل دفعي مو فوري، والأصول تبقى وتستمر تكلف.
  • C: هذا يرسل مقاييس EC2 بشكل أكثر، وما له علاقة بالسجلات.
  • E: هذا يسجل العمليات داخل الموارد، وما له علاقة بفاتورة سجلاتك ولا سطور الأخطاء.

للمراجعة: سجلات CloudWatch في هذا الجزء، وWorking with log groups and log streams وReal-time processing of log data with subscriptions في وثائق AWS.

السؤال 6 من 7

طلب الدفع يمر على API Gateway وثلاث دوال Lambda وجدول DynamoDB، وأحياناً ياخذ خمس ثواني. ومقاييس كل خدمة لحالها تبدو طبيعية. وش يبين أي خطوة بطيئة؟

اعرض الجواب

الجواب الصحيح: C

X-Ray يتتبع كل طلب عبر خدماتك واتصالاتها، ويوريك أي خطوة بطيئة أو تفشل.

  • A: هذا يسجل مين نادى أي API، مو كم أخذت كل خطوة من الطلب.
  • B: هذا يسجل إعدادات الموارد.
  • D: هذا يعرض أكبر المساهمين، مثل العناوين اللي ترسل أكثر طلبات، مو مسار الطلب.

للمراجعة: X-Ray: تتبع طلب واحد في هذا الجزء، وWhat is AWS X-Ray? في وثائق AWS.

السؤال 7 من 7

الأخطاء زادت فجأة في تطبيق في منطقة وحدة، وما تغير شي من جهة الفريق. ويبون يعرفون بسرعة هل عند AWS نفسها مشكلة تأثر على مواردهم. وين يشوفون؟

اعرض الجواب

الجواب الصحيح: B

يعرض الأحداث اللي تأثر على خدمات AWS ومواردك، بدون تجهيز وبدون تكلفة.

  • A: هذا يعرض الاستدعاءات في حسابك، وهذي ما تغيرت هنا.
  • C: هذا يعرض كيف تغيرت إعداداتك، وهذي ما تغيرت هنا.
  • D: هذا يفحص حسابك مقابل أفضل الممارسات، وما يبلغ عن الأعطال.

للمراجعة: أدوات ثانية للمتابعة في هذا الجزء، وWhat is AWS Health? في وثائق AWS.

الحين تعرف وش يصير في حساب واحد. بس الشركات عندها عشرات الحسابات ومئات الموظفين. في الجزء السادس والعشرين نديرهم بـ Organizations وIdentity Center.