Amazon CloudWatch هو الطبقة الأصلية للمراقبة والرصد لكل خدمة في AWS. إنه ليس مجرد مكان لتخزين السجلات — بل هو حلقة التحكم التي تُبقي الأنظمة الإنتاجية سليمة: تتدفق المقاييس من كل نسخة EC2 وكل كتلة RDS وكل دالة Lambda؛ وتتفاعل التنبيهات فور تجاوز الأرقام حدودها المحددة؛ وتُنقّب استعلامات Logs Insights في تدفقات السجلات الخام في ثوانٍ؛ وتمنح لوحات المعلومات الفريق وعيًا مشتركًا بالحالة. على نطاق الشركات الكبرى، يُعد الإعداد الخاطئ لـ CloudWatch أحد أكثر الأسباب شيوعًا للبقع العمياء في الحوادث. هذا الدرس يجعلك محترفًا في الركائز الأربع: المقاييس، والتنبيهات، والسجلات، ولوحات المعلومات.
المقاييس: الأساس
كل مورد AWS ينشر مقاييسه إلى CloudWatch تلقائيًا. يُعرَّف المقياس بـمساحة الاسم (مثل AWS/EC2)، وواحد أو أكثر من الأبعاد (أزواج مفتاح-قيمة تحدد نطاق المقياس، مثل InstanceId=i-0abc1234)، واسم المقياس (مثل CPUUtilization). تصل نقاط البيانات بدقة إما 60 ثانية (قياسي) أو 1 ثانية (عالي الدقة، متاح للمقاييس المخصصة).
مقاييس EC2 الافتراضية — وحدة المعالجة المركزية، بايتات الشبكة، عمليات القراءة/الكتابة على القرص — مجانية وتُجمع بواسطة المشرف الافتراضي (hypervisor). إلا أنها لا تشمل استخدام الذاكرة أو نسبة امتلاء القرص، لأن المشرف الافتراضي لا يستطيع الاطلاع داخل نظام التشغيل الضيف. للحصول على هذه المقاييس، يجب تثبيت CloudWatch Agent ودفع مقاييس مخصصة.
في كل شركة تُشغّل EC2 بجدية، يكون CloudWatch Agent مدمجًا في صورة AMI الأساسية عبر UserData أو ارتباط SSM State Manager. اعتبر مقاييس الذاكرة والقرص ضرورة لا تقبل النقاش — ستواجه حادثة امتلاء قرص في عطلة نهاية الأسبوع إن تجاهلتها.
# تثبيت وإعداد CloudWatch Agent على Amazon Linux 2 / AL2023
sudo yum install -y amazon-cloudwatch-agent
# كتابة إعداد مبسط للعامل (مقاييس الذاكرة والقرص كل 60 ثانية)
sudo tee /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json <<'AGENTEOF'
{
"metrics": {
"namespace": "CWAgent",
"metrics_collected": {
"mem": {
"measurement": ["mem_used_percent"],
"metrics_collection_interval": 60
},
"disk": {
"measurement": ["disk_used_percent"],
"resources": ["/"],
"metrics_collection_interval": 60
}
}
}
}
AGENTEOF
# تشغيل العامل (يستخدم الإعداد أعلاه)
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config \
-m ec2 \
-c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \
-s
# التحقق من تشغيل العامل
sudo systemctl status amazon-cloudwatch-agent
يمكنك أيضًا نشر مقاييس تطبيقية اعتباطية — زمن استجابة الطلبات، عمق قوائم الانتظار، مؤشرات الأعمال — باستخدام AWS CLI أو SDK. استدعاء put-metric-data هو الأداة الجوهرية وراء كل لوحة مقاييس مخصصة على نطاق واسع.
# دفع مقياس مخصص: عمق قائمة انتظار الطلبات = 42
aws cloudwatch put-metric-data \
--namespace "MyApp/Orders" \
--metric-name QueueDepth \
--value 42 \
--unit Count \
--dimensions Environment=production
# سحب آخر 5 دقائق من ذلك المقياس للتحقق من الاستيعاب
aws cloudwatch get-metric-statistics \
--namespace "MyApp/Orders" \
--metric-name QueueDepth \
--dimensions Name=Environment,Value=production \
--start-time $(date -u -d '5 minutes ago' +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
--period 60 \
--statistics Average Maximum
التنبيهات: ردّ الفعل الآلي
يراقب التنبيه مقياسًا واحدًا (أو تعبيرًا رياضيًا يجمع عدة مقاييس) وينتقل بين ثلاث حالات: OK، وALARM، وINSUFFICIENT_DATA. عندما يدخل التنبيه حالة ALARM، يمكنه تشغيل إشعار SNS، أو سياسة Auto Scaling، أو إجراء EC2 (إعادة تشغيل، إيقاف، إنهاء)، أو بند SSM OpsItem.
يُقيَّم عتبة التنبيه على مدى فترة (نافذة التجميع، لا تقل عن 10 ثوانٍ للمقاييس عالية الدقة، وعادةً 60 ثانية) وزوج datapoints-to-alarm / evaluation-periods. ضبط datapoints-to-alarm=3 من أصل evaluation-periods=3 يعني أن المقياس يجب أن يتجاوز العتبة لثلاث فترات متتالية قبل إطلاق التنبيه — وهذا يُزيل إنذارات الذعر الكاذب الناجمة عن الارتفاعات اللحظية، وهو نمط حيوي في الإنتاج.
آلة حالة تنبيه CloudWatch: الانتقال بين OK وALARM وINSUFFICIENT_DATA، مع تشغيل الإجراءات (SNS، Auto Scaling، EC2) عند الدخول إلى حالة ALARM.
# تنبيه: وحدة المعالجة المركزية فوق 80% لـ3 فترات متتالية مدة كل منها 60 ثانية
aws cloudwatch put-metric-alarm \
--alarm-name "web-cpu-high" \
--alarm-description "EC2 CPU above 80% for 3 minutes" \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=AutoScalingGroupName,Value=web-asg \
--statistic Average \
--period 60 \
--evaluation-periods 3 \
--datapoints-to-alarm 3 \
--threshold 80 \
--comparison-operator GreaterThanOrEqualToThreshold \
--treat-missing-data breaching \
--alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alerts \
--ok-actions arn:aws:sns:us-east-1:123456789012:ops-alerts
# فحص حالة التنبيه
aws cloudwatch describe-alarms \
--alarm-names "web-cpu-high" \
--query "MetricAlarms[*].{Name:AlarmName,State:StateValue,Reason:StateReason}"
treat-missing-data=breaching هو الإعداد الإنتاجي الآمن لمعظم التنبيهات. إذا اختفى مصدر المقياس (تعطل العامل، أو إنهاء النسخة)، فأنت تريد أن يُطلق التنبيه، لا أن يجلس صامتًا في حالة INSUFFICIENT_DATA بينما يفوت المناوب الحادثة. استخدم notBreaching فقط للمقاييس المتفرقة بشكل متعمد كالوظائف المجدولة.
السجلات: CloudWatch Logs وLogs Insights
تُرسل سجلات التطبيقات إلى CloudWatch Logs عبر CloudWatch Agent أو AWS SDK أو التكاملات الأصلية للخدمات (Lambda، ECS، EKS عبر Fluent Bit). التسلسل الهرمي هو: مجموعة السجلات (واحدة لكل تطبيق أو خدمة) ← تدفق السجلات (واحد لكل نسخة أو حاوية) ← أحداث السجلات الفردية.
ضع سياسة احتجاز على كل مجموعة سجلات. الافتراضي هو الاحتجاز إلى الأبد، وهو مكلف على نطاق واسع. 30 يومًا يغطي معظم متطلبات الامتثال وعمليات إعادة النظر في الحوادث؛ أرشف إلى S3 للاحتياجات طويلة الأمد.
# إنشاء مجموعة سجلات بسياسة احتجاز 30 يومًا
aws logs create-log-group \
--log-group-name /app/web/access
aws logs put-retention-policy \
--log-group-name /app/web/access \
--retention-in-days 30
# دفق آخر 5 دقائق من تدفق السجلات (مفيد أثناء الحوادث)
aws logs tail /app/web/access --since 5m --follow
# استعلام Logs Insights: أكثر 10 رسائل خطأ تكرارًا في الساعة الماضية
aws logs start-query \
--log-group-name /app/web/access \
--start-time $(date -d '1 hour ago' +%s) \
--end-time $(date +%s) \
--query-string \
'fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) as errorCount by @message
| sort errorCount desc
| limit 10'
# ثم استرداد النتائج بمعرف الاستعلام:
# aws logs get-query-results --query-id <id>
Logs Insights هو محرك الاستعلام التفاعلي على مجموعات السجلات. بنيته تشبه خط أنابيب SQL مبسط: fields يختار الأعمدة، وfilter هو شرط WHERE، وstats يجمّع، وsort يُرتّب، وlimit يحدد النتائج. تُنفَّذ الاستعلامات بالتوازي عبر الشرائح وتعود في ثوانٍ حتى على تيرابايتات من السجلات — أسرع بكثير من grep عبر SSH.
يمكنك أيضًا إنشاء فلتر مقياس لتحويل نمط في تدفق السجلات إلى مقياس، ثم الإنذار على ذلك المقياس. هذه هي الطريقة التي تبني بها تنبيهات معدل الخطأ من سجلات التطبيقات دون أي تغييرات في SDK.
السجلات المهيكلة مضاعف قوة. إذا كان تطبيقك يُصدر أسطر سجلات JSON (مثل {"level":"error","status":500,"path":"/api/orders","duration_ms":1234})، يمكن لـ Logs Insights تحليل كل حقل تلقائيًا. السجلات المهيكلة هي الفارق بين استعلام Logs Insights لمدة 5 دقائق وجلسة grep لمدة ساعتين أثناء حادث P1.
لوحات المعلومات: وعي مشترك بالحالة
لوحة معلومات CloudWatch هي مجموعة من الأدوات المرئية المثبتة على رابط مشترك. كل أداة تعرض رسمًا بيانيًا لمقياس، أو حالة تنبيه، أو نتيجة استعلام سجلات، أو ملاحظة نصية. تُعرَّف لوحات المعلومات كـJSON — مما يعني إمكانية التحكم بها بنظام الإصدارات ونشرها عبر Infrastructure as Code (CloudFormation أو Terraform).
يجب أن تحتوي كل خدمة إنتاجية كحد أدنى على لوحة "الإشارات الذهبية": زمن الاستجابة، ومعدل الخطأ، وحركة المرور (RPS)، والتشبع (وحدة المعالجة المركزية/الذاكرة). هذه الإشارات الأربع تغطي الغالبية العظمى من حالات الفشل الإنتاجي وقد وثّقها كتاب SRE الخاص بـ Google كنقطة انطلاق مرجعية لمراقبة مستوى الخدمة.
مكدس رصد CloudWatch: المصادر تدفع المقاييس والسجلات؛ التنبيهات ولوحات المعلومات واستعلامات Logs Insights توفر مخرجات تفاعلية واستكشافية.
اضبط treat-missing-data=breaching على تنبيهات زمن الاستجابة ومعدل الخطأ ونبض الحياة.
أصدر سجلات JSON مهيكلة من تطبيقك حتى يتمكن Logs Insights من تحليل الحقول تلقائيًا.
ابنِ لوحة إشارات ذهبية (زمن الاستجابة، الأخطاء، حركة المرور، التشبع) قبل انطلاق خدمتك إلى الإنتاج، لا بعد الحادث الأول.
احفظ JSON لوحة المعلومات في مستودع IaC إلى جانب البنية التحتية التي تراقبها.
تُحتجز مقاييس CloudWatch بدقة ثانية واحدة لمدة 3 ساعات، ودقيقة واحدة لمدة 15 يومًا، و5 دقائق لمدة 63 يومًا، وساعة واحدة لمدة 15 شهرًا. صمم فترات تنبيهاتك وفقًا لذلك — تنبيه بفترة دقيقة واحدة سيكون لديه بيانات لأسبوعين، مما يمنحك نافذة إعادة تشغيل الحادث التي تحتاجها أثناء مراجعات ما بعد الحادث.
نستخدم ملفات تعريف الارتباط لتشغيل هذا الموقع وتحليل الزيارات وعرض إعلانات مخصّصة. يمكنك قبول كل ملفات تعريف الارتباط أو رفض غير الأساسية منها.
سياسة الخصوصية