دليل عمليات 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. مراجعة مقاييس بروميثيوس

الوصول إلى لوحة معلومات بروميثيوس والتحقق من:

• معدل مرور الرسائل (آخر 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 أو تحقق من ملفات السجل

ابحث عن:

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

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

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

استخدم استعلام بروميثيوس:

# الرسائل المستلمة في الساعة
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

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

استعلام بروميثيوس:

# الرسائل الموجهة بواسطة كل مسار (الساعة الأخيرة)
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: "Add +1 to 10-digit US numbers",
  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: "Convert 00 prefix to +",
  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: "Strip carrier code from carrier 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)

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

صيانة قاعدة بيانات ميسنيا

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

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

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

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

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

استعادة ميسنيا:

# عبر استيراد واجهة الويب
# أو استعادة النسخ الاحتياطي:
: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

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

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

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

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

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

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

2. جداول التوجيه (ميسنيا):

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

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. تأكيد الاستيراد

تخطيط السعة

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

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

استعلام بروميثيوس (متوسط 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 msg/sec
• الحاجة إلى توزيع جغرافي
• الحاجة إلى توفر عالٍ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. التحقيق:

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

5. الحل:

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

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

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

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

تراكم قائمة الانتظار العالي:

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

فشل التوجيه:

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

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

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

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

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

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