المراقبة
يوفر Rediacc أوامر مراقبة مدمجة لفحص صحة الأجهزة والحاويات قيد التشغيل والخدمات وحالة المستودعات وتشخيصات النظام.
صحة الجهاز
الحصول على تقرير صحي شامل لجهاز:
rdc machine health --name server-1
يُبلغ هذا عن:
- النظام: وقت التشغيل، استخدام القرص، استخدام مخزن البيانات
- الحاويات: عدد الحاويات قيد التشغيل والسليمة وغير السليمة
- التخزين: حالة SMART
- المشكلات: المشكلات المكتشفة
استخدم --output json للحصول على مخرجات قابلة للقراءة آليًا.
عرض الحاويات
عرض جميع الحاويات قيد التشغيل عبر جميع المستودعات على جهاز:
rdc machine containers --name server-1
| العمود | الوصف |
|---|---|
| Name | اسم الحاوية |
| Status | وقت التشغيل أو سبب الإيقاف |
| State | قيد التشغيل، متوقف، إلخ. |
| Health | سليم، غير سليم، بدون |
| CPU | نسبة استخدام المعالج |
| Memory | استخدام الذاكرة / الحد الأقصى |
| Repository | المستودع الذي يمتلك الحاوية |
الخيارات:
--health-check, إجراء فحوصات صحية نشطة على الحاويات--output json, مخرجات JSON قابلة للقراءة آليًا
تتضمن مخرجات JSON تفاصيل الحاويات الكاملة (labels وport_mappings وimage وid) بالإضافة إلى repository (الاسم المحلول) وrepository_guid (المعرّف GUID الأصلي) وdomain وautoRoute.
عرض الخدمات
عرض خدمات systemd المتعلقة بـ Rediacc على جهاز:
rdc machine services --name server-1
| العمود | الوصف |
|---|---|
| Name | اسم الخدمة |
| State | نشط، غير نشط، فاشل |
| Sub-state | قيد التشغيل، متوقف، إلخ. |
| Restarts | عدد مرات إعادة التشغيل |
| Memory | استخدام ذاكرة الخدمة |
| Repository | المستودع المرتبط |
الخيارات:
--stability-check, تمييز الخدمات غير المستقرة (فاشلة، أكثر من 3 إعادات تشغيل، إعادة تشغيل تلقائية)--output json, مخرجات JSON قابلة للقراءة آليًا
تتضمن مخرجات JSON تفاصيل الخدمات الكاملة مع repository (الاسم المحلول) وrepository_guid (المعرّف GUID الأصلي).
عرض المستودعات
عرض المستودعات على جهاز مع إحصائيات مفصلة:
rdc machine repos --name server-1
| العمود | الوصف |
|---|---|
| Name | اسم المستودع |
| Size | حجم صورة القرص |
| Mount | مثبّت أو غير مثبّت |
| Docker | Docker daemon قيد التشغيل أو متوقف |
| Containers | عدد الحاويات |
| Disk Usage | الاستخدام الفعلي للقرص داخل المستودع |
| Modified | وقت آخر تعديل |
الخيارات:
--search <text>, التصفية حسب الاسم أو مسار التثبيت--output json, مخرجات JSON قابلة للقراءة آليًا
تتضمن مخرجات JSON الحقلين name (الاسم المحلول) وguid (المعرّف GUID الأصلي)، كما تدرج لكل مستودع مصفوفتَي containers (بما فيها domain وautoRoute وrepository/repository_guid) وservices.
صحة التخزين
فحص تجزئة BTRFS ومشاركة reflink عبر جميع المستودعات على جهاز:
rdc machine query --name server-1 --storage-health
| العمود | الوصف |
|---|---|
| Size | حجم ملف صورة LUKS (المظهر الكلي للمستودع) |
| Unique | البيانات الفعلية الفريدة التي يمتلكها هذا المستودع فقط |
| Shared | كتل البيانات المُعاد استخدامها عبر المستودعات بواسطة روابط BTRFS المرجعية (نسخ مجانية) |
| Extents | عدد امتدادات الملفات (القيمة الأعلى تعني تجزئة أكبر) |
| Frag | مستوى التجزئة: منخفض، معتدل، أو مرتفع |
يعرض الملخص إجمالي المدخرات من روابط BTRFS المرجعية:
14 repos, 224.3 GB virtual size
Unique data: 323.7 MB | Shared: 224.0 GB | Efficiency: 99.9%
- الحجم الافتراضي هو مجموع أحجام صور المستودعات. هذا ما تبدو عليه المستودعات، غير أنه يحسب مزدوجًا الكتل المشتركة عبر الروابط المرجعية.
- البيانات الفريدة هي التخزين الفعلي الذي تستهلكه بيانات المستودع الموجودة في مستودع واحد فقط. وهذا ما ستحرره عند حذف مستودع.
- المشترك هو البيانات المُعاد استخدامها عبر المستودعات بواسطة روابط BTRFS المرجعية. يؤدي تفريع مستودع إلى إنشاء نسخ مرجعية تشترك في الكتل حتى يكتب أحد الطرفين بيانات جديدة، عندها تتباعد الكتل.
- الكفاءة هي نسبة البيانات المُعاد استخدامها عبر الروابط المرجعية. القيمة الأعلى أفضل. الجهاز الذي يحتوي على كثير من تفريعات الأصل ذاته سيُظهر كفاءة قريبة من 100%.
يمكن إلغاء تجزئة المستودعات ذات التجزئة المرتفعة والكتل المشتركة الصفرية بأمان باستخدام btrfs filesystem defragment. لا يجب إلغاء تجزئة المستودعات ذات الكتل المشتركة لأن إلغاء التجزئة يستبدل الكتل المشتركة بنسخ فريدة مما يزيد استخدام القرص.
يعمل الفحص بشكل متوازٍ ويستغرق 5-15 ثانية حسب عدد المستودعات وحجمها. عند عدم تحديد --storage-health، يظهر تلميح من سطر واحد بعد مخرجات الاستعلام كتذكير.
فحص BTRFS
يجدول Rediacc تلقائيًا فحص BTRFS أسبوعيًا على كل جهاز. يقرأ الفحص كل كتلة بيانات في مخزن البيانات، ويتحقق من المجاميع الاختبارية، ويُبلغ عن أي تلف. يكتشف هذا تلف البيانات الصامت (تعفن البت) قبل انتشاره في النسخ الاحتياطية والتفريعات.
يعمل الفحص كل يوم أحد الساعة 02:00 بالتوقيت المحلي للجهاز مع تأخير عشوائي يصل إلى ساعة واحدة. يعمل بأدنى أولوية I/O (ionice idle وnice 19) حتى لا يتعارض مع الخدمات قيد التشغيل. على الأجهزة المدعومة بـ SSD، توقع نحو 8 دقائق لكل 100 غيغابايت من مخزن البيانات.
يُثبَّت مؤقت الفحص تلقائيًا عند أول بدء تشغيل للخدمة بعد ترقية renet. عند تغيير سياسة الفحص في إصدار renet مستقبلي، تُحدِّث نفسها عند بدء التشغيل التالي دون الحاجة إلى أي إجراء من المستخدم.
حالة الفحص
يُحفظ نتيجة آخر فحص خارج حجم BTRFS (في /var/lib/rediacc/scrub-last-result.json) حتى يظل قابلًا للقراءة حتى في حالة وجود مشكلات في الحجم. تتضمن مخرجات rdc machine query --system حقل scrub_status:
"scrub_status": {
"last_run_human": "3 days ago",
"status": "ok",
"total_errors": 0,
"uncorrectable": 0,
"duration_seconds": 312
}
| الحالة | المعنى |
|---|---|
ok | اكتمل الفحص الأخير دون أخطاء |
never_run | لم يعمل الفحص بعد (تم تثبيت المؤقت للتو) |
overdue | مضى على آخر فحص أكثر من 14 يومًا |
errors_found | عثر الفحص على عدم تطابق في المجاميع الاختبارية (تحقق من عددَي total_errors وuncorrectable) |
failed | خرجت عملية الفحص برمز غير صفري |
إذا كانت قيمة uncorrectable أكبر من صفر، فلا يمكن إصلاح الكتل المتأثرة تلقائيًا (BTRFS ذو قرص واحد لا يحتوي على نسخة احتياطية زائدة). استعد المستودع المتأثر من أحدث نسخة احتياطية.
الفحص اليدوي
لتشغيل فحص فوري (مثلًا بعد انقطاع التيار الكهربائي أو ترحيل القرص):
rdc term connect -m server-1 -c "sudo renet maintenance scrub --datastore /mnt/rediacc"
تُحفظ النتيجة في ملف JSON ذاته وتظهر فورًا في rdc machine query --system التالي.
حالة Vault
الحصول على نظرة عامة كاملة على جهاز بما في ذلك معلومات النشر:
rdc machine vault-status --name server-1
يوفر هذا:
- اسم المضيف ووقت التشغيل
- استخدام الذاكرة والقرص وDatastore
- إجمالي المستودعات وعدد المثبّتة وعدد Docker قيد التشغيل
- معلومات تفصيلية لكل مستودع
استخدم --output json للحصول على مخرجات قابلة للقراءة آليًا.
اختبار الاتصال
محوّل السحابة فقط. في المحوّل المحلي، استخدم
rdc term connect -m server-1 -c "hostname"للتحقق من الاتصال.
التحقق من اتصال SSH بجهاز:
rdc machine test-connection --ip 203.0.113.50 --user deploy
يُبلغ عن:
- حالة الاتصال (ناجح/فاشل)
- طريقة المصادقة المستخدمة
- تكوين مفتاح SSH
- حالة نشر المفتاح العام
- إدخال Known hosts
الخيارات:
--port <number>, منفذ SSH (الافتراضي: 22)--save -m server-1, حفظ مفتاح المضيف المتحقق منه في تكوين الجهاز
التشخيصات (doctor)
تشغيل فحص تشخيصي شامل لبيئة Rediacc الخاصة بك:
rdc doctor
| الفئة | الفحوصات |
|---|---|
| البيئة | إصدار Node.js، إصدار CLI، وضع SEA، تثبيت Go، توفر Docker |
| Renet | موقع الملف الثنائي، الإصدار، CRIU، rsync، أصول SEA المضمنة |
| التكوين | الإعداد النشط، المحوّل، الأجهزة، مفتاح SSH |
| المحاكاة الافتراضية | التحقق من إمكانية تشغيل أجهزة افتراضية محلية (rdc ops) |
يُبلغ كل فحص عن OK أو تحذير أو خطأ. استخدم هذا كخطوة أولى عند استكشاف أي مشكلة وإصلاحها.
رموز الخروج: 0 = نجاح الكل، 1 = تحذيرات، 2 = أخطاء.