مراقبة RDS وPerformance Insights

واجهة دفع تنقطع مهلتها نحو 4 دقائق كل صباح عند الساعة 09:05. تفتح كونسول RDS. CPUUtilization يبلغ ذروته عند 41%. وFreeableMemory مستوٍ. وReadLatency عند 2 مللي ثانية. وFreeStorageSpace فيه متّسع. كل مقياس تملكه يقول إن قاعدة البيانات سليمة، وهي بوضوح ليست كذلك.

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

تعطيك RDS ثلاث طبقات مراقبة، كل واحدة تنظر إلى قاعدة البيانات من موضع مختلف. ومعرفة أيها تجيب عن أي سؤال هي معظم المهارة هنا.

ثلاث طبقات وثلاثة أسئلة مختلفة

اقرأ العمود الأوسط مرة أخرى، فهو الدرس كله في سطر. الطبقة 1 تقف خارج الخادم وترى مجاميع الموارد. والطبقة 2 تقف داخل نظام التشغيل وترى العمليات. والطبقة 3 تقف داخل محرك قاعدة البيانات وترى الجلسات. وحادثة الساعة 09:05 غير مرئية في الطبقة 1 وبيّنة في الطبقة 3.

مقاييس CloudWatch التي تستحق المراقبة

ترسل RDS مقاييسها إلى CloudWatch بفترة دقيقة واحدة افتراضياً، في فضاء الأسماء AWS/RDS وببعد DBInstanceIdentifier. ونقاط الـ 60 ثانية تلك تبقى متاحة 15 يوماً.

اثنان من هذه يخفيان فخاً.

DatabaseConnections ليس عدد الجلسات. إنه يعدّ اتصالات العملاء الشبكية، فيستبعد الجلسات التي ينشئها المحرك لنفسه، وجلسات مجدول المهام، وجلسات التنفيذ المتوازي، والجلسات التي مات اتصالها الشبكي قبل التنظيف، واتصالات RDS الإدارية. والعدد الحقيقي أعلى، وأحياناً أعلى بكثير، والجلسات هي ما يستهلك ذاكرة الاتصالات.

BurstBalance وEBSIOBalance% دلوان مختلفان. فـ BurstBalance هو دلو أرصدة الإدخال/الإخراج الخاص بحجم gp2 نفسه. أما EBSIOBalance% وEBSByteBalance% فيصفان سعة اندفاع خادم قاعدة البيانات نحو EBS، وهي موجودة على مقاسات كثيرة مهما كان نوع التخزين، ويحسبانها من إنتاجية كل الأحجام بما فيها الحجم الجذري. فحين يتّجه EBSByteBalance% إلى الصفر، الخادم هو الذي ينفد لا الحجم، والجواب فئة خادم أكبر لا مزيد من IOPS المزوّدة. وعكس هذين يقودك إلى شراء الشيء الخطأ.

Enhanced Monitoring: الرؤية التي لا يستطيع CloudWatch إعطاءك إياها

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

ويشتري لك الوكيل شيئاً لا تستطيع طبقة الافتراضية تسليمه بأي دقة: تفصيل لكل عملية ولكل خيط. فحين يكون المعالج عند 90% وتحتاج إلى معرفة هل السبب محرك قاعدة البيانات أم نسخة احتياطية أم خيط صيانة شارد، فهذه الطبقة وحدها هي التي تجيب.

والتفاصيل التي تُختبر:

• الدقة هي 1 أو 5 أو 10 أو 15 أو 30 أو 60 ثانية. وضبط --monitoring-interval 0 يوقفه.
• المقاييس تذهب إلى CloudWatch Logs، في مجموعة السجلات RDSOSMetrics، باحتفاظ افتراضي قدره 30 يوماً. وتغيّر ذلك على مجموعة السجلات لا على خادم قاعدة البيانات.
• يحتاج إلى دور IAM. والكونسول يستطيع إنشاء rds-monitoring-role نيابةً عنك؛ ومن CLI أو API تنشئه بنفسك بسياسة AmazonRDSEnhancedMonitoringRole وعلاقة ثقة مع مبدأ الخدمة monitoring.rds.amazonaws.com. ويحتاج المستدعي إلى صلاحية iam:PassRole.
• تفعيله لا يتطلب إعادة تشغيل.
• كونسول RDS يحدّث العرض كل 5 ثوانٍ في أفضل الأحوال. فإن ضبطت الدقة على ثانية واحدة، تحصل على بيانات الثانية من CloudWatch Logs لا من الكونسول.

aws rds modify-db-instance \
  --db-instance-identifier payments-prod \
  --monitoring-interval 5 \
  --monitoring-role-arn arn:aws:iam::123456789012:role/rds-monitoring-role

وهنا الالتباس الذي تخلقه هذه الطبقة. لأن كونسول RDS يرسم قيم Enhanced Monitoring رسوماً بيانية، يفترض الناس أنهم يستطيعون التنبيه عليها كما ينبّهون على CPUUtilization. وهم لا يستطيعون، لا مباشرةً. فمخرجات Enhanced Monitoring أحداث سجل، والتنبيه عليها يعني إنشاء مرشّح مقياس في CloudWatch Logs فوق RDSOSMetrics أولاً، ثم التنبيه على المقياس الذي ينتجه ذلك المرشّح.

حمل قاعدة البيانات: المقياس الذي يجيب عن «لماذا»

تقيس الطبقة 3 شيئاً مختلفاً عن كل مقياس أعلاه. ليس مورداً، بل عملاً قيد التنفيذ.

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

وحمل قاعدة البيانات هو عدد الجلسات النشطة، ووحدته متوسط الجلسات النشطة. ويأخذ Performance Insights عيّنة من هذا العدد مرة كل ثانية، والمتوسط هو مجموع الجلسات المرصودة مقسوماً على عدد العيّنات.

خذ خمس عيّنات متتالية بفاصل ثانية:

فحمل تلك الفترة 2 جلسة نشطة: في المتوسط كانت جلستان نشطتين في أي لحظة. والمتوسط هنا مقصود. فقفزة ثانية واحدة إلى 40 جلسة تحرّك الرقم بالكاد، بينما 5 جلسات عالقة دقيقة كاملة تدفعه بقوة. وهذا هو الانحياز الصحيح، لأن ما يؤذي قاعدة البيانات هو الاصطفاف المستمر لا الاندفاعات اللحظية.

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

قراءة المخطط: Max vCPU وأحداث الانتظار وأثقل الاستعلامات

يرسم مخطط الحمل خطاً أفقياً عند عدد vCPU لخادم قاعدة البيانات، اسمه Max vCPU. وهذا هو المرجع الذي يحوّل رقماً مجرّداً إلى حكم.

اعمل عليه على خادم db.r6g.2xlarge بثمانية vCPU:

• حمل ثابت عند 3: ثلاث جلسات نشطة مقابل سعة 8 vCPU. مريح.
• حمل عند 8 وكله تقريباً على المعالج: الخادم مشبع على المعالج. ومزيد من vCPU سيفيد.
• حمل عند 21 منها 18 منتظرة: 21 جلسة نشطة لكن قليلاً منها يعمل فعلاً. والثماني عشرة الأخرى تصطف خلف شيء ما. وزيادة vCPU لن تغيّر شيئاً، لأن المعالج لم يكن القيد أصلاً.

والحالة الأخيرة هي التي يخطئ الناس في قراءتها، ولهذا بالضبط يُقسَّم الحمل إلى مقاييس CloudWatch منفصلة:

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

ثم قسّمه حسب أثقل عبارات SQL لتعرف أي العبارات تنتج ذلك الانتظار. ومن الشائع أن يستأثر استعلام واحد من بين المئات بأغلب الحمل. ويلتقط Performance Insights كذلك خطط التنفيذ لأكثر الاستعلامات استهلاكاً للموارد كل 5 دقائق، فترى كيف اختار المحرك تنفيذ الاستعلام الذي يؤذيك. وتستطيع أيضاً التقسيم حسب المضيف وحسب المستخدم، وهكذا تحدّد خادم تطبيق واحداً يسيء التصرف أو حساب تقارير بعينه.

وسير العمل بهذا الترتيب: الحمل يقول كم الوضع سيئ، وأحداث الانتظار تقول أي نوع من السوء، وأثقل الاستعلامات تقول من المتسبّب، والخطة تقول لماذا ذلك الاستعلام بطيء.

وعودةً إلى حادثة 09:05. يقفز الحمل إلى 25 جلسة نشطة على خادم بثمانية vCPU، كله تقريباً على حدث انتظار قفل صف، وتُظهر أثقل العبارات عبارة UPDATE واحدة على جدول الحسابات. مهمة دفعات ليلية تحتفظ بمعاملة طويلة، وكتابات الواجهة تصطف خلفها. ولم يكن أي مقياس موارد ليُظهر لك ذلك أبداً، لأن لا مورد كان تحت ضغط.

Performance Insights صار CloudWatch Database Insights

تقاعد كونسول Performance Insights في 31 يوليو 2026، وصار الكونسول يعيد التوجيه إلى CloudWatch Database Insights. ولم يتغيّر شيء في القياس نفسه: الحمل نفسه، ومتوسط الجلسات النشطة نفسه، وأحداث الانتظار وأثقل الاستعلامات نفسها. المتغيّر هو أين تنظر إليها وكيف تُحزَم.

وما يستحق التذكّر:

• وضع Standard هو الافتراضي، وهو ما انتقلت إليه تلقائياً الخوادم التي كانت تستخدم Performance Insights، محتفظةً بمدة احتفاظها القائمة.
• واجهة برمجة التطبيقات لم تتغيّر. فقوالب CloudFormation وإعدادات Terraform والسكربتات التي تضبط PerformanceInsightsEnabled وPerformanceInsightsRetentionPeriod تعمل كما كُتبت تماماً.
• الاحتفاظ ما زال 7 أيام افتراضياً بلا تكلفة إضافية، أو من شهر إلى 24 شهراً على مستوى مدفوع.
• خطط التنفيذ والتحليل عند الطلب تتطلب الآن وضع Advanced.

وفي الاختبار، عامل «Performance Insights» و«عرض الحمل في Database Insights» جواباً واحداً. فالسؤال الذي يصف إيجاد أثقل عبارة SQL خلف قفزة حمل يشير إلى هذه الطبقة في الحالتين.

التوصيات الاستباقية

يراقب Performance Insights مقاييس مختارة، ويتعلّم عتبة من خط الأساس الخاص بذلك المورد بعينه، ويرفع توصية استباقية حين تتجاوز القيم تلك العتبة مدة كافية. والغاية التقاط المشكلة وهي تتكوّن لا بعد أن توقظك.

وتظهر التوصيات في كونسول RDS، إما في صفحة Recommendations على مستوى الحساب مرتّبةً بالخطورة، وإما في تبويب Recommendations لقاعدة بيانات واحدة. وكل توصية تعطيك المشكلة المكتشفة، ورسوماً للمقياس مقابل عتبته المتعلَّمة، وتحليلاً يشرح الإجراء المقترح. فإما أن تنفّذها وإما أن تتجاهلها.

وشرط واحد يُختبر: التوصيات الاستباقية تحتاج إلى مستوى احتفاظ مدفوع. فالاحتفاظ المجاني بسبعة أيام لا يكفي الميزة لبناء خط أساس، وخادم على الاحتفاظ الافتراضي لا ينتج أي توصية.

التنبيه على الطبقة الصحيحة

تختلف التنبيهات باختلاف الطبقة، وهنا تكفّ الطبقات عن كونها تمييزاً نظرياً.

الطبقة 1 مباشرة. فمقاييس AWS/RDS مقاييس CloudWatch عادية، والتنبيه عليها تنبيه عادي:

aws cloudwatch put-metric-alarm \
  --alarm-name payments-prod-low-storage \
  --namespace AWS/RDS \
  --metric-name FreeStorageSpace \
  --dimensions Name=DBInstanceIdentifier,Value=payments-prod \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 10737418240 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:dba-oncall

الطبقة 2 تحتاج إلى مرشّح مقياس في CloudWatch Logs أولاً، لأن Enhanced Monitoring ينتج أحداث سجل.

الطبقة 3 منقسمة. فمقاييس DBLoad وDBLoadCPU وDBLoadNonCPU وDBLoadRelativeToNumVCPUs تُنشر إلى CloudWatch في فضاء الأسماء AWS/RDS، فتنبّه عليها عادياً. أما بقية مقاييس عدّادات Performance Insights فلا تُنشر مباشرةً، وتصل إليها بدالة حساب المقاييس DB_PERF_INSIGHTS، التي تحوّلها إلى سلسلة زمنية تستطيع رسمها والتنبيه عليها، بما في ذلك تنبيهات عالية الدقة دون الدقيقة.

وسلوك واحد توقّعه: مقاييس DBLoad تُنشر فقط حين يكون هناك حمل على الخادم. ففجوات المخطط على قاعدة بيانات هادئة أمر طبيعي، فاضبط كيف يعامل تنبيهك البيانات المفقودة بدل قراءة الفجوة عطلاً.

أي طبقة تجيب عن أي عرَض

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

• «كل مقاييس CloudWatch طبيعية لكن قاعدة البيانات بطيئة» سؤال Performance Insights في كل مرة. فمقاييس الموارد لا ترى الانتظار.
• «على مستوى العملية» أو «معالج وذاكرة لكل عملية على خادم قاعدة البيانات» تشير إلى Enhanced Monitoring وحده. ولا تستطيع تثبيت وكيل CloudWatch على خادم RDS، فأي خيار يعرض ذلك خاطئ من وجهه.
• Enhanced Monitoring يذهب إلى CloudWatch Logs. فإن قال خيار إن مقاييسه تظهر مباشرةً في مقاييس CloudWatch، فاستبعده.
• انتبه لأرقام الدقة: مقاييس CloudWatch عند 60 ثانية، وEnhanced Monitoring من 1 إلى 60 ثانية، وعيّنة Performance Insights كل ثانية.
• Max vCPU خط مرجعي لا حدّ صارم. وتجاوز الحمل له يعني اصطفافاً، والتقسيم بين المعالج وغيره وحده يقول هل الخادم الأكبر هو الجواب.
• BurstBalance للحجم. وEBSIOBalance% وEBSByteBalance% للخادم. دلوان مختلفان وإصلاحان مختلفان.
• التوصيات الاستباقية تتطلب احتفاظاً مدفوعاً. فالاحتفاظ المجاني بسبعة أيام يعطيك اللوحة لا التوصيات.
• CPUCreditBalance موجود على فئات db.t فقط ويُنشر بتردد 5 دقائق، فتنبيه بفترة دقيقة عليه لن يتصرّف كما تتوقّع.

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