دليل عمليات SMS-C

← العودة إلى فهرس الوثائق | الملف README الرئيسي

إجراءات التشغيل اليومية، والمراقبة، ومهام الصيانة لفرق عمليات SMS-C.

جدول المحتويات

• العمليات اليومية
• المراقبة
• تتبع الرسائل
• إدارة المسارات
• إدارة الواجهة الأمامية
• إدارة ترجمة الأرقام
• صيانة النظام
• النسخ الاحتياطي والاسترداد
• تخطيط السعة
• استجابة الحوادث

العمليات اليومية

فحص الصحة الصباحية

قم بإجراء هذه الفحوصات في بداية كل يوم:

1. تحقق من حالة النظام

# فحص صحة API
curl https://api.example.com:8443/api/status

# الاستجابة المتوقعة:
# {"status":"ok","application":"OmniMessage","timestamp":"2025-10-30T08:00:00Z"}

2. مراجعة مقاييس Prometheus

الوصول إلى لوحة معلومات Prometheus والتحقق من:

• معدل مرور الرسائل (آخر 24 ساعة)
• معدل فشل التوجيه (يجب أن يكون < 1%)
• تراكم الطوابير (يجب أن يكون < 1000 معلق)
• معدل نجاح التسليم (يجب أن يكون > 95%)
• حالة اتصال الواجهة الأمامية (جميع الواجهات الأمامية المتوقعة نشطة)

3. تحقق من قائمة الرسائل

الوصول إلى واجهة الويب: https://sms-admin.example.com/message_queue

مراجعة:

• إجمالي الرسائل المعلقة (يجب أن يكون منخفضًا)
• عمر أقدم رسالة (يجب أن يكون < 5 دقائق)
• الرسائل ذات محاولات التسليم العالية (تحقق إذا كانت > 3)
• الرسائل الميتة (تحقق من أي موجودة)

4. مراجعة حالة الواجهة الأمامية

الوصول إلى واجهة الويب: https://sms-admin.example.com/frontend_status

التحقق من:

• جميع الواجهات الأمامية المتوقعة نشطة
• لا توجد انقطاعات غير منتهية
• لا توجد أخطاء في الواجهة الأمامية خلال آخر 24 ساعة

5. تحقق من سجلات التطبيق

الوصول إلى واجهة الويب: https://sms-admin.example.com/logs أو تحقق من ملفات السجل

ابحث عن:

• رسائل بمستوى خطأ
• فشل التوجيه
• فشل الشحن
• مشاكل في اتصال قاعدة البيانات
• مشاكل في عقدة الكتلة

مراقبة حجم الرسائل

تحقق من عدد الرسائل بالساعة:

استخدم استعلام Prometheus:

# الرسائل المستلمة في الساعة
increase(sms_c_message_received_count[1h])

# الرسائل المرسلة في الساعة
increase(sms_c_delivery_succeeded_count[1h])

# حساب معدل التسليم
rate(sms_c_delivery_succeeded_count[1h]) / rate(sms_c_message_received_count[1h])

الأنماط المتوقعة:

• ساعات العمل: حجم أعلى
• ليالي/عطلات نهاية الأسبوع: حجم أقل
• معدل التسليم: يجب أن يكون > 95%

شروط التنبيه:

• انخفاض مفاجئ في الرسائل ( > 50% انخفاض)
• ارتفا�� مفاجئ في الرسائل ( > 200% زيادة)
• انخفاض معدل التسليم تحت 90%

المراقبة

المقاييس الرئيسية للمراقبة

مقاييس معالجة الرسائل

عدد الرسائل المستلمة (sms_c_message_received_count):

• ما هو: إجمالي الرسائل التي تدخل النظام
• تنبيه: انخفاض أو ارتفاع مفاجئ
• استعلام: rate(sms_c_message_received_count[5m])

مدة معالجة الرسائل (sms_c_message_processing_stop_duration):

• ما هو: الوقت المستغرق في المعالجة من البداية إلى النهاية
• تنبيه: p95 > 1000ms
• استعلام: histogram_quantile(0.95, sms_c_message_processing_stop_duration)

مقاييس التوجيه

فشل التوجيه (sms_c_routing_failed_count):

• ما هو: الرسائل التي لم يمكن توجيهها
• تنبيه: أي فشل ( > 0)
• استعلام: increase(sms_c_routing_failed_count[5m])

المسار المتطابق (sms_c_routing_route_matched_count):

• ما هو: أي المسارات يتم استخدامها
• تنبيه: المسارات ذات الأولوية العالية لا تتطابق
• استعلام: sms_c_routing_route_matched_count

مقاييس التسليم

معدل نجاح التسليم:

• ما هو: نسبة التسليم الناجح
• تنبيه: معدل < 95%
• استعلام: rate(sms_c_delivery_succeeded_count[5m]) / rate(sms_c_delivery_queued_count[5m])

محاولات التسليم (sms_c_delivery_succeeded_attempt_count):

• ما هو: إعادة المحاولات اللازمة للتسليم
• تنبيه: p95 > 2 (الكثير من إعادة المحاولات)
• استعلام: histogram_quantile(0.95, sms_c_delivery_succeeded_attempt_count)

مقاييس الطوابير

حجم الطابور (sms_c_queue_size_size):

• ما هو: إجمالي الرسائل في الطابور
• تنبيه: الحجم > 10,000
• استعلام: sms_c_queue_size_size

عمر أقدم رسالة (sms_c_queue_oldest_message_age_seconds):

• ما هو: عمر أقدم رسالة معلقة
• تنبيه: العمر > 300 ثانية
• استعلام: sms_c_queue_oldest_message_age_seconds

إعداد لوحة المعلومات

لوحات معلومات العمليات:

1. معدل مرور الرسائل (رسم بياني)

   • الرسائل المستلمة (معدل 5 دقائق)
   • الرسائل ال��رسلة (معدل 5 دقائق)
   • نطاق الوقت: آخر 24 ساعة

2. حالة الطابور (إحصائيات فردية)

   • الرسائل المعلقة الحالية
   • عمر أقدم رسالة
   • عدد الرسائل الفاشلة

3. أداء التسليم (رسم بياني)

   • معدل النجاح على مر الزمن
   • معدل الفشل على مر الزمن
   • نطاق الوقت: آخر 24 ساعة

4. حالة التوجيه (جدول)

   • معرف المسار
   • عدد المطابقات (الساعة الأخيرة)
   • وجهة SMSC
   • الأولوية

5. حالة الواجهة الأمامية (جدول)

   • اسم الواجهة الأمامية
   • الحالة (نشطة/منتهية)
   • آخر ظهور
   • عدد الرسائل (الساعة الأخيرة)

6. صحة النظام (إحصائيات فردية)

   • زمن استجابة API (p95)
   • زمن استعلام قاعدة البيانات (p95)
   • زمن بحث ENUM (p95)

إعداد التنبيهات

التنبيهات الحرجة (استجابة فورية مطلوبة):

# لم يتم العثور على مسار - لا يمكن تسليم الرسائل
- alert: RoutingFailures
  expr: increase(sms_c_routing_failed_count[5m]) > 0
  severity: critical
  description: "{{ $value }} messages failed routing in last 5 minutes"

# تراكم الطابور - المعالجة تتأخر
- alert: QueueBacklog
  expr: sms_c_queue_size_pending > 10000
  severity: critical
  description: "Queue has {{ $value }} pending messages"

# الرسائل تتقدم في العمر - التسليم عالق
- alert: OldMessagesInQueue
  expr: sms_c_queue_oldest_message_age_seconds > 300
  severity: critical
  description: "Oldest message is {{ $value }} seconds old"

# الواجهة الأمامية مفصولة - لا يوجد مسار تسليم
- alert: FrontendDisconnected
  expr: sms_c_frontend_status_count{status="disconnected"} > 0
  severity: critical
  description: "{{ $value }} frontends disconnected"

تنبيهات التحذير (تحتاج إلى تحقيق):

# معدل نجاح التسليم يتناقص
- alert: LowDeliveryRate
  expr: rate(sms_c_delivery_succeeded_count[10m]) / rate(sms_c_delivery_queued_count[10m]) < 0.90
  severity: warning
  description: "Delivery success rate is {{ $value }}"

# الكثير من إعادة المحاولات للتسليم
- alert: HighRetryRate
  expr: histogram_quantile(0.95, sms_c_delivery_succeeded_attempt_count) > 2
  severity: warning
  description: "95th percentile delivery attempts: {{ $value }}"

# بحث ENUM بطيء أو فاشل
- alert: SlowEnumLookups
  expr: histogram_quantile(0.95, sms_c_enum_lookup_stop_duration) > 5000
  severity: warning
  description: "ENUM lookups taking > 5 seconds"

# معدل نجاح ذاكرة التخزين المؤقت ENUM منخفض
- alert: LowEnumCacheHitRate
  expr: rate(sms_c_enum_cache_hit_count[10m]) / (rate(sms_c_enum_cache_hit_count[10m]) + rate(sms_c_enum_cache_miss_count[10m])) < 0.70
  severity: warning
  description: "ENUM cache hit rate: {{ $value }}"

تتبع الرسائل

العثور على رسالة معينة

حسب معرف الرسالة:

1. واجهة الويب: انتقل إلى /message_queue
2. أدخل معرف الرسالة في مربع البحث
3. عرض التفاصيل الكاملة وسجل الأحداث

عبر API:

curl https://api.example.com:8443/api/messages/12345

حسب رقم الهاتف:

1. واجهة الويب: انتقل إلى /message_queue
2. أدخل رقم الهاتف في مربع البحث
3. عرض جميع الرسائل لذلك الرقم

تتبع دورة حياة الرسالة

عرض سجل الأحداث:

1. واجهة الويب: انقر على الرسالة في الطابور، عرض ق��م "الأحداث"
2. API: GET /api/events/12345

تسلسل الأحداث الشائع:

1. message_inserted - تم إنشاء الرسالة
   ↓
2. number_translated - تم تطبيع الأرقام (إذا تم تكوينه)
   ↓
3. message_routed - تم اتخاذ قرار التوجيه
   ↓
4. charging_attempted - فحص الشحن (إذا تم تمكينه)
   ↓
5. message_delivered - تم التسليم بنجاح

تسلسل التسليم الفاشل:

1. message_inserted
   ↓
2. message_routed
   ↓
3. delivery_attempt_1 - المحاولة الأولى فشلت
   ↓
4. delivery_attempt_2 - المحاولة الثانية فشلت (تأخير 2 دقيقة)
   ↓
5. delivery_attempt_3 - المحاولة الثالثة فشلت (تأخير 4 دقائق)
   ↓
6. message_dead_letter - تجاوز حد إعادة المحاولة

تحقق من حالة التسليم

الرسائل المعلقة:

• الحالة: "معلقة"
• deliver_after: طابع زمني مستقبلي
• delivery_attempts: 0 أو عدد منخفض

الرسائل المرسلة:

• الحالة: "تم التسليم"
• deliver_time: طابع زمني للتسليم
• dest_smsc: الواجهة الأمامية التي قامت بالتسليم

الرسا��ل الفاشلة:

• الحالة: "معلقة" مع عدد محاولات تسليم مرتفع
• deadletter: true (إذا انتهت)
• تحقق من سجل الأحداث لأسباب الفشل

توجيه الرسائل بناءً على الموقع

يدعم SMS-C استرجاع الرسائل بناءً على الموقع، مما يسمح للواجهات الأمامية باستلام الرسائل الموجهة تلقائيًا للمشتركين المسجلين في موقعهم.

كيف يعمل:

عند استعلام واجهة أمامية عن الرسائل المعلقة باستخدام get_messages_for_smsc(smsc_name)، يعيد النظام الرسائل بطريقتين:

1. التوجيه الصريح - الرسائل التي يتطابق فيها dest_smsc صراحة مع اسم الواجهة الأمامية
2. التوجيه بناءً على الموقع - الرسائل حيث:
   • dest_smsc هو null (غير موجه صراحة)
   • destination_msisdn لديه سجل موقع نشط
   • يتطابق حقل location للموقع مع اسم الواجهة الأمامية
   • لم تنته صلاحية الموقع

سيناريو المثال:

مشترك برقم MSISDN +447700900123 يسجل في الواجهة الأمامية uk_gateway:

# يسجل المشترك (ينشئ سجل موقع)
POST /api/locations
{
  "msisdn": "+447700900123",
  "imsi": "234150123456789",
  "location": "uk_gateway",
  "expires": "2025-11-01T12:00:00Z"
}

عندما تصل رسالة لهذا المشترك بدون توجيه صريح:

# تم تقديم الرسالة بدون dest_smsc
POST /api/messages
{
  "source_msisdn": "+15551234567",
  "destination_msisdn": "+447700900123",
  "message_body": "Hello",
  "source_smsc": "api"
  # ملاحظة: dest_smsc هو null
}

ستستقبل الواجهة الأمامية uk_gateway هذه الرسالة تلقائيًا عندما تستعلم:

# الواجهة الأمامية تستعلم عن الرسائل
GET /api/messages/queue?smsc=uk_gateway

# تعيد الرسالة على الرغم من أن dest_smsc هو null
# لأن المشترك الوجهة مسجل في uk_gateway

متطلبات الموقع:

لكي يعمل التوجيه بناءً على الموقع:

• يجب أن تحتوي جدول locations على إدخال لـ destination_msisdn
• يجب أن يتطابق حقل location مع اسم SMSC الذي يستعلم
• يجب أن يكون طابع expires في المستقبل

مراقبة التوجي�� بناءً على الموقع:

تحقق من سجلات المواقع:

# عبر API
GET /api/locations/{msisdn}

# تحقق مما إذا كانت الموقع قد انتهت
# يجب أن يكون حقل expires > الوقت الحالي

المشاكل الشائعة:

• لم يتم تسليم الرسالة: تحقق مما إذا كانت الموقع قد انتهت
• واجهة أمامية خاطئة: تحقق من أن حقل location يتطابق مع اسم الواجهة الأمامية المتوقع
• لم يتم العثور على الموقع: قد يحتاج المشترك إلى إعادة التسجيل

التدخلات اليدوية

إعادة محاولة الرسالة الفاشلة:

# إعادة تعيين delivery_attempts و deliver_after
curl -X PATCH https://api.example.com:8443/api/messages/12345 \
  -H "Content-Type: application/json" \
  -d '{
    "delivery_attempts": 0,
    "deliver_after": "2025-10-30T12:00:00Z"
  }'

تغيير الوجهة:

# توجيه إلى SMSC مختلف
curl -X PATCH https://api.example.com:8443/api/messages/12345 \
  -H "Content-Type: application/json" \
  -d '{
    "dest_smsc": "backup_gateway"
  }'

حذف الرسالة العالقة:

curl -X DELETE https://api.example.com:8443/api/messages/12345

إدارة المسارات

عرض المسارات الحالية

واجهة الويب: انتقل إلى /sms_routing

عبر API:

# قائمة بجميع المسارات
curl https://api.example.com:8443/api/routes

تحقق من استخدام المسار:

استعلام Prometheus:

# الرسائل الموجهة بواسطة كل مسار (الساعة الأخيرة)
increase(sms_c_routing_route_matched_count[1h])

إضافة مسار جديد

واجهة الويب:

1. انتقل إلى /sms_routing
2. انقر على "إضافة مسار جديد"
3. املأ الحقول:
   • بادئة الاتصال: بادئة رقم المصدر (اختياري)
   • بادئة الاتصال: بادئة رقم الوجهة (مطلوبة للتوجيه الجغرافي)
   • مصدر SMSC: فلتر النظام المصدر (اختياري)
   • وجهة SMSC: بوابة الوجهة (مطلوبة ما لم يكن رد تلقائي/إسقاط)
   • الأولوية: أولوية المسار (1-255، أقل = أولوية أعلى)
   • الوزن: وزن التوازن (1-100)
   • الوصف: وصف قابل للقراءة البشرية
   • مفعل: تحقق للتفعيل الفوري
4. انقر على "حفظ المسار"

مثال: مسار جغرافي:

• بادئة الاتصال: +44
• وجهة SMSC: uk_gateway
• الأولوية: 50
• الوزن: 100
• الوصف: "توجيه المملكة المتحدة"

مثال: مسار موزع:

إنشاء مسارين بنفس المعايير ولكن بأوزان مختلفة:

المسار 1:

• بادئة الاتصال: +44
• وجهة SMSC: uk_primary
• الأولوية: 50
• الوزن: 70
• الوصف: "المملكة المتحدة الرئيسية (70%)"

المسار 2:

• بادئة الاتصال: +44
• وجهة SMSC: uk_backup
• الأولوية: 50
• الوزن: 30
• الوصف: "المملكة المتحدة الاحتياطية (30%)"

اختبار المسارات

محاكي التوجيه:

1. انتقل إلى /simulator
2. أدخل معلمات الاختبار:
   • رقم الاتصال: +15551234567
   • رقم الاتصال: +447700900000
   • مصدر SMSC: (اختياري)
   • نوع المصدر: (اختياري)
3. انقر على "محاكاة التوجيه"
4. مراجعة النتائج:
   • المسار المحدد: أي مسار تم اختياره
   • جميع المطابقات: أي المسارات تطابقت مع المعايير
   • التقييم: لماذا تطابق كل مسار أو لم يتطابق

اختبار قبل الإنتاج:

• اختبار جميع المسارات الجديدة في المحاكي
• التحقق من اختيار المسار الصحيح
• التحقق من ترتيب الأولويات
• التحقق من توزيع الوزن

تعديل المسار الحالي

واجهة الويب:

1. انتقل إلى /sms_routing
2. ابحث عن المسار في القائمة
3. انقر على "تعديل"
4. تعديل الحقول
5. انقر على "حفظ المسار"

التعديلات الشائعة:

• تعطيل المسار: إلغاء تحديد "مفعل" (إزالة مؤقتة)
• تعديل الوزن: تغيير توزيع التوازن
• تغيير الأولوية: إعادة ترتيب تقييم المسار
• تحديث الوجهة: التبديل إلى SMSC مختلف

حذف المسار

واجهة الويب:

1. انتقل إلى /sms_routing
2. ابحث عن المسار في القائمة
3. انقر على "حذف"
4. تأكيد الحذف

تحذير: حذف المسارات دائم. اعتبر تعطيلها بدلاً من ذلك.

تصدير/استيراد المسارات

تصدير المسارات (نسخة احتياطية):

1. انتقل إلى /sms_routing
2. انقر على "تصدير المسارات"
3. حفظ ملف JSON

استيراد المسارات:

1. انتقل إلى /sms_routing
2. انقر على "استيراد المسارات"
3. اختر ملف JSON
4. اختر وضع الاستيراد:
   • دمج: إضافة إلى المسارات الحالية
   • استبدال: حذف جميع المسارات واستيراد

حالات الاستخدام:

• النسخ الاحتياطي قبل التغييرات الكبيرة
• نسخ المسارات بين البيئات
• استرداد الكوارث
• إصدار التكوين

إدارة الواجهة الأمامية

مراقبة اتصالات الواجهة الأمامية

واجهة الويب: انتقل إلى /frontend_status

تحقق من:

• جميع الواجهات الأمامية المتوقعة "نشطة"
• أوقات آخر ظهور حديثة ( < 90 ثانية)
• لا توجد واجهات أمامية منتهية غير متوقعة

عبر API:

# الحصول على الواجهات الأمامية النشطة
curl https://api.example.com:8443/api/frontends/active

# الحصول على الإحصائيات
curl https://api.example.com:8443/api/frontends/stats

التحقيق في الانقطاعات

الواجهة الأمامية منتهية:

1. تحقق من سجلات الواجهة الأمامية للأخطاء
2. تحقق من الاتصال الشبكي بـ SMS-C
3. تأكد من أن الواجهة الأمامية تعمل
4. تحقق من منطق تسجيل الواجهة الأمامية (يجب أن تعيد التسجيل كل 60 ثانية)

التسجيل غير ظاهر:

1. تحقق من أن الواجهة الأمامية تستدعي POST /api/frontends/register
2. تحقق من سجلات API لأخطاء التسجيل
3. تحقق من تنسيق حمولة JSON
4. اختبر التسجيل يدويًا باستخدام curl

مثال على التسجيل اليدوي:

curl -X POST https://api.example.com:8443/api/frontends/register \
  -H "Content-Type: application/json" \
  -d '{
    "frontend_name": "test_gateway",
    "frontend_type": "smpp",
    "ip_address": "10.0.1.50",
    "hostname": "gateway.example.com"
  }'

عرض تاريخ الواجهة الأمامية

واجهة الويب:

1. انتقل إلى /frontend_status
2. ابحث عن الواجهة الأمامية في القائمة
3. انقر على "التاريخ"
4. مراجعة التسجيلات السابقة

عبر API:

curl https://api.example.com:8443/api/frontends/history/uk_gateway

حالات الاستخدام:

• التحقيق في موثوقية الاتصال
• تتبع أنماط وقت تشغيل الواجهة الأمامية
• تحديد التغييرات في التكوين

إدارة ترجمة الأرقام

تتم إدارة قواعد ترجمة الأرقام عبر config/runtime.exs. تتطلب التغييرات إعادة تشغيل التطبيق.

عرض قواعد الترجمة النشطة

تحقق من ملف التكوين:

cat config/runtime.exs | grep -A 20 "translation_rules:"

المهام الشائعة لترجمة الأرقام

إضافة رمز الدولة إلى الأرقام المحلية:

تحرير config/runtime.exs:

%{
  calling_prefix: nil,
  called_prefix: nil,
  source_smsc: nil,
  calling_match: "^(\d{10})$",
  calling_replace: "+1\1",
  called_match: "^(\d{10})$",
  called_replace: "+1\1",
  priority: 100,
  description: "إضافة +1 إلى الأرقام الأمريكية المكونة من 10 أرقام",
  enabled: true
}

تطبيع التنسيق الدولي:

%{
  calling_prefix: nil,
  called_prefix: nil,
  source_smsc: nil,
  calling_match: "^00(\d+)$",
  calling_replace: "+\1",
  called_match: "^00(\d+)$",
  called_replace: "+\1",
  priority: 10,
  description: "تحويل بادئة 00 إلى +",
  enabled: true
}

إزالة رمز محدد من الناقل:

%{
  calling_prefix: nil,
  called_prefix: "101",
  source_smsc: "carrier_a",
  calling_match: nil,
  calling_replace: nil,
  called_match: "^101(\d+)$",
  called_replace: "\1",
  priority: 5,
  description: "إزالة رمز الناقل من الناقل A",
  enabled: true
}

اختبار قواعد الترجمة

بعد تغييرات التكوين:

1. أعد تشغيل التطبيق لتحميل القواعد الجديدة
2. قدم رسالة اختبار مع المصدر/الوجهة التي يجب أن تتطابق
3. تحقق من سجل الأحداث لحدث number_translated
4. تحقق من أن الأرقام تم تحويلها بشكل صحيح

تعطيل قاعدة الترجمة

قم بتعيين enabled: false في القاعدة:

%{
  ...
  enabled: false
}

أعد تشغيل التطبيق.

صيانة النظام

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

تحقق من حجم قاعدة ��لبيانات:

استخدم أدوات إدارة قاعدة البيانات الخاصة بك لمراقبة حجم تخزين CDR:

• MySQL/MariaDB: استعلام information_schema.tables للحصول على حجم قاعدة البيانات
• PostgreSQL: استخدم دالة pg_database_size() أو الأمر \l+ في psql

تنظيف سجلات CDR القديمة:

يجب أرشفة سجلات CDR وحذفها دوريًا بناءً على سياسة الاحتفاظ الخاصة بك:

• تكوين الأرشفة التلقائية بناءً على متطلبات العمل (عادةً 30-90 يومًا في قاعدة البيانات التشغيلية)
• أرشفة السجلات القديمة إلى مستودع البيانات أو التخزين البارد
• حذف السجلات المؤرشفة من قاعدة البيانات التشغيلية في دفعات لتجنب التنافس على القفل

تحسين الجداول:

قم بتحسين جداول قاعدة البيانات دوريًا للحفاظ على الأداء:

• MySQL/MariaDB: نفذ الأمر OPTIMIZE TABLE خلال فترات انخفاض الحركة
• PostgreSQL: نفذ VACUUM ANALYZE بانتظام (أو قم بتمكين autovacuum)

قم بتشغيله أسبوعيًا خلال فترة انخفاض الحركة للحفاظ على الأداء الأمثل.

صيانة قاعدة بيانات Mnesia

تحقق من حجم جدول Mnesia:

# في وحدة التحكم IEx
:mnesia.table_info(:sms_route, :size)
:mnesia.table_info(:translation_rule, :size)

نسخ احتياطي لجداول Mnesia:

# تصدير المسارات (واجهة الويب)
# انتقل إلى /sms_routing
# انقر على "تصدير المسارات"

# أو عبر نسخ احتياطي Mnesia
:mnesia.backup("/var/backups/sms_c/mnesia_backup.bup")

استعادة Mnesia:

# عبر استيراد واجهة الويب
# أو استعادة النسخة الاحتياطية:
:mnesia.restore("/var/backups/sms_c/mnesia_backup.bup", [])

تدوير السجلات

قم بتكوين logrotate لسجلات التطبيق:

# /etc/logrotate.d/sms_c
/var/log/sms_c/*.log {
    daily
    rotate 30
    compress
    delaycompress
    notifempty
    create 0644 sms_user sms_group
    sharedscripts
    postrotate
        systemctl reload sms_c || true
    endscript
}

إعادة تشغيل التطبيق

إعادة التشغيل بشكل سلس (عدم وجود توقف في الكتلة):

# أعد تشغيل عقدة واحدة في كل مرة
systemctl restart sms_c

# انتظر حتى تنضم العقدة إلى الكتلة
# كرر لكل عقدة

إعادة التشغيل الطارئة (جميع العقد):

systemctl restart sms_c

بعد إعادة التشغيل:

• تحقق من إعادة اتصال جميع الواجهات الأمامية
• تحقق من Prometheus لاستمرارية المقاييس
• راقب السجلات بحثًا عن الأخطاء
• تحقق من استئناف معالجة الرسائل

النسخ الاحتياطي والاسترداد

ما يجب نسخه احتياطيًا

1. ملفات التكوين:

   • config/runtime.exs
   • config/config.exs
   • config/prod.exs (إذا كان موجودًا)

2. جداول التوجيه (Mnesia):

   • تصدير عبر واجهة الويب
   • أو أمر نسخ احتياطي Mnesia

3. قاعدة بيانات SQL CDR:

   • نسخة احتياطية كاملة يوميًا
   • نسخ احتياطية لسجل المعاملات (مستمرة)

4. شهادات TLS:

   • priv/cert/*.crt
   • priv/cert/*.key

إجراءات النسخ الاحتياطي

نسخة احتياطية يومية للتكوين:

#!/bin/bash
# /opt/sms_c/scripts/backup_config.sh

BACKUP_DIR="/var/backups/sms_c/$(date +%Y%m%d)"
mkdir -p $BACKUP_DIR

# النسخ الاحتياطي للتكوين
cp -r /opt/sms_c/config $BACKUP_DIR/

# النسخ الاحتياطي للشهادات
cp -r /opt/sms_c/priv/cert $BACKUP_DIR/

# تعيين الأذونات
chmod 600 $BACKUP_DIR/cert/*

echo "اكتمل النسخ الاحتياطي للتكوين: $BACKUP_DIR"

نسخة احتياطية لقاعدة البيانات:

#!/bin/bash
# /opt/sms_c/scripts/backup_database.sh

BACKUP_DIR="/var/backups/sms_c/database"
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p $BACKUP_DIR

# النسخ الاحتياطي لقاعدة بيانات SQL CDR
# MySQL/MariaDB: استخدم mysqldump مع --single-transaction لضمان التناسق
# PostgreSQL: استخدم pg_dump -F c للتنسيق المخصص

# هيكل المثال (تكييفه مع قاعدة البيانات الخاصة بك):
# - استخدم أداة النسخ الاحتياطي المناسبة (mysqldump، pg_dump)
# - تمكين النسخ الاحتياطي الآمن للتعامل مع التناسق
# - ضغط المخرجات لتوفير المساحة
# - تكوين فترة الاحتفاظ (مثل 30 يومًا)

# إزالة النسخ الاحتياطية القديمة
find $BACKUP_DIR -name "sms_c_*.gz" -mtime +30 -delete

echo "اكتمل النسخ الاحتياطي لقاعدة البيانات: sms_c_${DATE}"

نسخة احتياطية لجدول التوجيه:

#!/bin/bash
# /opt/sms_c/scripts/backup_routes.sh

BACKUP_DIR="/var/backups/sms_c/routes"
DATE=$(date +%Y%m%d)

mkdir -p $BACKUP_DIR

# تصدير عبر API
curl https://api.example.com:8443/api/routes/export \
  > $BACKUP_DIR/routes_${DATE}.json

echo "اكتمل النسخ الاحتياطي للمسارات: routes_${DATE}.json"

جدولة النسخ الاحتياطية (crontab):

# يوميًا في الساعة 2 صباحًا
0 2 * * * /opt/sms_c/scripts/backup_config.sh
0 2 * * * /opt/sms_c/scripts/backup_database.sh
0 2 * * * /opt/sms_c/scripts/backup_routes.sh

إجراءات الاسترداد

استعادة التكوين:

# إيقاف التطبيق
systemctl stop sms_c

# استعادة ملفات التكوين
cp -r /var/backups/sms_c/20251030/config/* /opt/sms_c/config/

# استعادة الشهادات
cp -r /var/backups/sms_c/20251030/cert/* /opt/sms_c/priv/cert/

# بدء التطبيق
systemctl start sms_c

استعادة قاعدة بيانات SQL CDR:

استخدم أدوات الاستعادة المناسبة لقاع��ة البيانات الخاصة بك:

• MySQL/MariaDB: فك الضغط وتوجيه إلى عميل mysql
• PostgreSQL: استخدم pg_restore مع النسخ الاحتياطية بالتنسيق المخصص

مهم: أوقف تطبيق SMS-C قبل استعادة قاعدة البيانات لتجنب تعارض البيانات.

استعادة جداول التوجيه:

1. انتقل إلى واجهة الويب /sms_routing
2. انقر على "استيراد المسارات"
3. اختر ملف JSON الاحتياطي
4. اختر وضع "استبدال"
5. أكد الاستيراد

تخطيط السعة

مراقبة اتجاهات النمو

اتجاه حجم الرسائل:

استعلام Prometheus (متوسط 30 يومًا):

avg_over_time(sms_c_message_received_count[30d])

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

-- نمو البيانات الشهري
SELECT
  DATE_FORMAT(inserted_at, '%Y-%m') AS month,
  COUNT(*) AS message_count,
  ROUND(SUM(LENGTH(message_body)) / 1024 / 1024, 2) AS data_mb
FROM message_queues
GROUP BY month
ORDER BY month DESC
LIMIT 12;

مؤشرات السعة

استخدام وحدة المعالجة المركزية:

• طبيعي: < 50% متوسط
• مرتفع: > 70% مستمر
• حرج: > 90%

استخدام الذاكرة:

• طبيعي: < 70% من المتاح
• مرتفع: > 80%
• حرج: > 90%

استخدام القرص:

• طبيعي: < 60% ممتلئ
• مرتفع: > 75%
• حرج: > 85%

عمق الطابور:

• طبيعي: < 1000 معلق
• مرتفع: > 5000 معلق
• حرج: > 10,000 معلق

توصيات التوسع

متى يجب التوسع عموديًا (ترقية الموارد):

• وحدة المعالجة المركزية باستمرار > 70%
• الذاكرة باستمرار > 80%
• اختناق في عقدة واحدة

متى يجب التوسع أفقيًا (إضافة عقد):

• وحدة المعالجة المركزية > 50% في جميع العقد
• حجم الرسائل > 5,000 رسالة/ثانية
• الحاجة إلى توزيع جغرافي
• الحاجة إلى توفر عالي

توسيع قاعدة البيانات:

• نسخ قراءة للاستعلامات التقارير
• تحسين تجميع الاتصالات
• تحسين الفهارس
• تقسيم الجداول الكبيرة حسب التاريخ

استجابة الحوادث

مستويات الخطورة

حرج (استجابة فورية):

• لا يتم تسليم الرسائل
• جميع الوا��هات الأمامية مفصولة
• قاعدة البيانات غير متاحة
• API معطلة تمامًا

مرتفع (استجابة خلال ساعة واحدة):

• معدل نجاح التسليم < 80%
• عدة واجهات أمامية مفصولة
• فشل التوجيه > 10%
• تراكم الطوابير في تزايد

متوسط (استجابة خلال 4 ساعات):

• واجهة أمامية واحدة مفصولة
• معدل نجاح التسليم 80-95%
• معالجة الرسائل بطيئة
• بحث ENUM فاشل

منخفض (استجابة خلال 24 ساعة):

• تدهور طفيف في الأداء
• مشكلة في مسار واحد
• تنبيهات تحذيرية غير حرجة

قائمة التحقق من الحوادث

1. تقييم الخطورة:

• تحقق من تنبيهات Prometheus
• مراجعة مقاييس لوحة المعلومات
• تحقق من حالة قائمة الرسائل
• تحقق من اتصالات الواجهة الأمامية

2. جمع المعلومات:

• هل كانت هناك تغييرات تكوين حديثة؟
• هل كانت هناك نشرات حديثة؟
• حالة الاعتماديات الخارجية (OCS، DNS)؟
• رسائل الخطأ في السجلات؟

3. الإجراءات الفورية:

• إيقاف التغييرات الجارية
• التراجع عن النشرات الأخيرة إذا كانت السبب المشتبه به
• تمكين السجلات التفصيلية إذا لزم الأمر
• إبلاغ المعنيين

4. التحقيق:

• مراجعة سجلات التطبيق
• تحقق من استخدام موارد النظام
• فحص أداء قاعدة البيانات
• اختبار الاعتماديات الخارجية

5. الحل:

• تطبيق الإصلاح
• اختبار في المحاكي
• نشر في الإنتاج
• مراقبة التحسين

6. بعد الحادث:

• توثيق السبب الجذري
• تحديث المراقبة/التنبيهات
• تنفيذ تدابير وقائية
• تحديث كتيبات التشغيل

الحوادث الشائعة

تراكم الطوابير العالي:

1. تحقق من معدل نجاح التسليم
2. تحقق من أن الواجهات الأمامية متصلة وتستعلم
3. تحقق من أداء قاعدة البيانات
4. مراجعة Prometheus للزجاجات
5. النظر في زيادة حجم الدفعة/الفترة

فشل التوجيه:

1. مراجعة تكوين التوجيه
2. اختبار في محاكي التوجيه
3. تحقق من وجود مسارات مفقودة
4. تحقق من وجود مسار catch-all
5. تحقق من سجلات الأحداث لأسباب الفشل

انقطاعات الواجهة الأمامية:

1. تحقق من حالة نظام الواجهة الأمامية
2. تحقق من الاتصال الشبكي
3. مراجعة سجلات الواجهة الأمامية
4. اختبار التسجيل اليدوي لـ API
5. تحقق من قواعد جدار الحماية

معالجة الرسائل البطيئة:

1. تحقق من أداء استعلام قاعدة البيانات
2. مراجعة تكوين عامل الدفعات
3. تحقق من الموارد الكافية (CPU/الذاكرة)
4. تحقق من تأخيرات بحث ENUM
5. مراجعة أداء نظام الشحن

لإجراءات استكشاف الأخطاء التفصيلية، راجع دليل استكشاف الأخطاء.