كان لدى ZimaOS بالفعل عارض لسجلات حاويات Docker عند نشر طلب الميزات هذا في عام 2025، لكن طلب توفير عارض كامل لسجلات النظام وjournal ظل منفصلًا. صححت IceWhale ردها الأول وأشارت إلى عنصر التحكم الحالي «الطرفية والسجلات» للتطبيقات.
وهذا يعني أنه لا ينبغي الخلط بين احتياجين مختلفين: فسجلات حاويات التطبيقات جزء من سير عمل التطبيق، بينما تُعدّ سجلات journalctl على مستوى المضيف وسجلات خدمات النظام تشخيصات أعمق.
كانت سجلات تطبيقات Docker متاحة بالفعل
تُظهر لقطة الشاشة من IceWhale واجهة إعدادات التطبيق، وبها زر «الطرفية والسجلات». وبالنسبة إلى حاوية تفشل في البدء أو تتوقف مرارًا أو تعرض واجهة ويب معطلة، ينبغي أن يكون هذا أول مصدر للسجلات.
سجلات النظام طبقة مختلفة
طلب رد لاحق من المجتمع تحديدًا عارضًا لسجلات ZimaOS بالكامل، شبيهًا بـ journalctl. ولا يوضح موضوع النقاش أن مثل هذا المتصفح الكامل لسجلات المضيف قد أُطلق نتيجة لهذا الطلب.
ولا تزال وثائق ZimaOS الحالية تتيح الطرفية لإجراء تشخيصات أعمق. ويوضح م overview ميزات ZimaOS أن السجلات المدمجة والوصول إلى الطرفية متاحان عند استكشاف المشكلات وإصلاحها.
ابدأ بأضيق مصدر للسجلات
إذا كان أحد تطبيقات Docker معطّلًا، فتحقق من سجلات ذلك التطبيق قبل البحث في جميع خدمات النظام. وإذا تعطلت وحدة التخزين أو الشبكة أو الإقلاع أو خدمات ZimaOS الأصلية، فانتقل إلى طرفية المضيف وسجل النظام ذي الصلة.
يساعدك أساسيات تطبيقات Docker على التمييز بين الأعطال على مستوى الحاوية والأعطال على مستوى المضيف.
احفظ السجلات قبل إعادة تشغيل كل شيء
قد تؤدي إعادة التشغيل إلى مسح الحالة التي تسببت في العطل المؤقت. احفظ الخطأ والطابع الزمني واسم الحاوية وإصدار ZimaOS قبل إعادة تشغيل التطبيق أو جهاز NAS بالكامل.
الخلاصة
استند طلب عام 2025 جزئيًا إلى ميزة لم يلاحظها البعض: كانت سجلات Docker موجودة بالفعل في واجهة إعدادات التطبيق. أما الطلب الأوسع، المتعلق بعارض لسجل المضيف بالكامل، فهو مختلف. ابدأ بسجل التطبيق عند حدوث أعطال في التطبيق، واستخدم سجلات الطرفية والنظام فقط عندما يكون الخلل أدنى من طبقة Docker.
