STACKDUST
EN
لوحة تحكم نظام المراقبة Beszel تعرض استهلاك المعالج والذاكرة وإحصائيات حاويات دوكر وصحة مصفوفات ZFS

نظام Beszel: منصة خفيفة ومستضافة ذاتيا لمراقبة أداء الخوادم وحاويات دوكر


نظام Beszel: مراقبة دقيقة وموفرة للموارد للخوادم وحاويات دوكر والمختبرات المنزلية

فرضت مراقبة الخوادم ومتابعة استهلاك الموارد في المختبرات المنزلية والخوادم الافتراضية الخاصة معادلة صعبة على المهندسين لسنوات. فالمنظومات المؤسسية المعتمدة على دمج Prometheus وNode Exporter وGrafana تستهلك مئات الميجابايتات من الذاكرة العشوائية وتتطلب إعدادات معقدة ولغات استعلام خاصة مثل PromQL لمجرد رسم بياني لاستهلاك المعالج والقرص الصلب. ومن ناحية أخرى، تستهلك أدوات المراقبة اللحظية مثل Netdata دورات معالجة ملحوظة على الأجهزة متواضعة العتاد مثل أجهزة Raspberry Pi.

يقدم مشروع Beszel، المطور بواسطة Henry Gressmann والمنشور تحت رخصة MIT بأكثر من 25 ألف نجمة على GitHub، بديلا برمجيا متفوقا. وعقب إطلاق الإصدار v0.19.0 في سبتمبر 2026، والذي أضاف دعما عميقا لمصفوفات ZFS وإدارة المستخدمين المتعددين، تحول Beszel إلى المعيار الأبرز لمراقبة الخوادم الخفيفة.

ما هو نظام Beszel

نظام متكامل ومستضاف ذاتيا لمراقبة الخوادم صمم لتقديم أعلى كفاءة مع أدنى استهلاك ممكن للموارد. بني النظام بلغة Go وفق معمارية ثنائية الطبقات تتألف من مركز تحكم رئيسي (Hub) وعميل برمجي مستقل (Agent).

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

لماذا لم تسمع عنه من قبل

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

نشأ مشروع Beszel خارج أروقة التسويق المؤسسي كرد عملي من المطورين على تضخم برمجيات المراقبة. فمن خلال دمج محرك PocketBase المعتمد على SQLite مباشرة داخل الملف التنفيذي للخادم، تخلص Beszel تماما من متطلبات قواعد بيانات PostgreSQL الخارجية أو وسائط التخزين المؤقت Redis. ويمكن نشر مركز المراقبة بالكامل في ثوان معدودة عبر حاوية دوكر واحدة.

كيف يعمل النظام برمجيا

يفصل Beszel جمع المقاييس عن عرضها عبر آلية استطلاع غير متزامنة ومحمية بمفاتيح تشفير متقدمة:

معمارية جمع الإحصائيات في نظام Beszel
1. جمع الإحصائيات محليا عبر العميل المنفذ 45876

يجمع العميل البرمجي إحصائيات المعالج ودرجات الحرارة ونشاط الأقراص وحاويات دوكر عبر واجهات cgroups ونظام /proc كل بضع ثوان.

2. الاستعلام الموثق بمفاتيح ed25519 تشفير ed25519

يتصل الخادم المركزي بالعميل عبر اتصال موثق بتوقيعات ed25519 المشفرة، ليجلب حزم البيانات المنظمة في دورة دورية مدتها 60 ثانية.

3. التجميع الزمني والتخزين المدمج PocketBase SQLite

تخزن المقاييس في جداول SQLite المدمجة مع تلخيص آلي للبيانات القديمة، للحفاظ على السجلات التاريخية بحجم إجمالي يقل عن 50 ميجابايت.

4. العرض التفاعلي وإرسال الإشعارات المنفذ 8090

يستعرض المستخدم الرسوم البيانية عبر الويب، وترسل التنبيهات فورا عبر Discord أو Telegram أو Webhooks عند تجاوز الحدود المعينة.

كفاءة العميل البرمجي والأمان التلقائي

كتب العميل البرمجي بلغة Go ليعمل مباشرة دون الاعتماد على مفسرات أو حزم خارجية. وعند تشغيله داخل حاوية دوكر، لا يتطلب سوى ربط مقبس /var/run/docker.sock بوضع القراءة فقط لقراءة نشاط الحاويات.

خلافا للأدوات التي تفتح منافذ HTTP غير محمية على الشبكة المحلية، يستمع عميل Beszel على المنفذ 45876 ويتحقق بدقة من كل اتصال قادم باستخدام المفتاح العام ed25519 المحدد عند التثبيت. وإذا لم يتطابق التوقيع، يغلق العميل اتصال TCP فورا، مانعا أي محاولة استكشاف أو اختراق محلي.

التكامل مع أنظمة ZFS ومراقبة العتاد

في حين تقتصر أدوات مراقبة الجهوزية مثل Uptime Kuma على فحص استجابة المنافذ الخارجية، يغوص Beszel في فحص العتاد الداخلي. يوفر الإصدار v0.19.0 قراءة تفصيلية لمصفوفات ZFS تشمل استهلاك السعة، ومعدل نقل البيانات، وحالة عمليات الفحص الدوري Scrub، واستهلاك الذاكرة المخبأة ZFS ARC.

وبالتوازي، يقرأ النظام حساسات اللوحة الأم مباشرة من واجهة Linux /sys/class/hwmon لعرض سرعة المراوح ودرجات حرارة الأنوية. ولضمان سلامة وسائط التخزين، يراقب النظام إحصائيات S.M.A.R.T. ومؤشرات تآكل ذواكر eMMC ومصفوفات RAID البرمجية، مما يوفر تنبيها مبكرا قبل تلف الأقراص المفاجئ.

جدول المقارنة التقنية

مقارنة حلول مراقبة الخوادم والأنظمة

وجه المقارنةBeszelPrometheus وGrafanaNetdataUptime Kuma
التركيز الأساسيموارد الخوادم وحاويات دوكرتحليل السلاسل الزمنية المؤسسيةالتشخيص اللحظي فائق السرعةفحص استجابة المنافذ والمواقع
استهلاك ذاكرة الخادم المركزيمن 35 إلى 60 ميجابايتمن 400 إلى 1200 ميجابايتيعمل كعميل محلي (~80 ميجابايت)من 60 إلى 90 ميجابايت
استهلاك ذاكرة العميلأقل من 15 ميجابايتمن 30 إلى 60 ميجابايتمدمج داخل نفس التطبيقلا يوجد عميل محلي
الاحتفاظ بالبيانات التاريخيةتجميع آلي داخل SQLiteقاعدة بيانات TSDB متخصصةذاكرة مؤقتة تنتهي بإعادة التشغيلسجلات أحداث وانقطاعات فقط
إحصائيات حاويات دوكررسوم بيانية تلقائية لكل حاويةيتطلب تثبيت حاوية cAdvisorقراءة مدمجة عبر cgroupsفحص حالة الحاوية فقط
تعقيد التثبيت والإعدادجاهز للعمل بدون إعدادات معقدةمرتفع يتطلب شفرات PromQL وYAMLمنخفض إلى متوسطمنخفض وسهل
مراقبة ZFS وحساسات العتاددعم مدمج وشامليتطلب أدوات تصدير مخصصةدعم مدمجغير مدعوم

التشغيل والتثبيت

يتطلب إعداد منظومة المراقبة تثبيت مركز التحكم (Hub) على خادمك الرئيسي، وتشغيل العميل البرمجي (Agent) على كل عقدة ترغب في مراقبتها.

تثبيت مركز التحكم Beszel Hub

يعمل مركز التحكم عبر ملف Docker Compose خفيف مع وحدة تخزين دائمة:

docker-compose.hub.yml
services:
  beszel:
    image: henrygd/beszel:latest
    container_name: beszel-hub
    restart: unless-stopped
    ports:
      - "8090:8090"
    volumes:
      - ./beszel_data:/beszel_data
    environment:
      - PORT=8090

بعد تشغيل الحاوية، افتح العنوان http://<hub-ip>:8090 في المتصفح لإنشاء الحساب الإداري. انقر فوق زر Add System لنسخ المفتاح العام ed25519.

تثبيت العميل البرمجي Beszel Agent

على أي خادم أو جهاز ترغب في مراقبته (مثل خوادم Proxmox أو VPS أو Raspberry Pi)، شغل خدمة العميل:

docker-compose.agent.yml
services:
  beszel-agent:
    image: henrygd/beszel-agent:latest
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./beszel_agent_data:/var/lib/beszel-agent
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - LISTEN=45876
      - KEY="ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... (المفتاح المنسوخ من لوحة التحكم)"

ما الذي يحل محله النظام

يحل Beszel محل بيئات Prometheus وGrafana الثقيلة في المنظومات التي يحتاج مسؤولوها فقط إلى تتبع استهلاك الموارد وحاويات دوكر وتلقي التنبيهات دون الدخول في دهاليز لغات الاستعلام المعقدة. ويعمل النظام بانسجام تام إلى جانب أدوات فحص الجهوزية مثل Uptime Kuma ومديري الحاويات مثل Dockge، موفرا رؤية داخلية وخارجية شاملة للبنية التحتية.

القيود والمآخذ التقنية

  1. ليس منصة لتتبع مسار التطبيقات (APM): صمم Beszel لمراقبة موارد البنية التحتية والحاويات، ولا يدعم تحليل مسارات استدعاء الدوال البرمجية الدقيقة أو حزم OpenTelemetry.
  2. فترة استطلاع ثابتة للبيانات التاريخية: تجمع البيانات التاريخية في دورات محددة بدقيقة واحدة، وبالتالي فإن المهندسين الذين يحتاجون لمقاييس لحظية بأجزاء من الثانية لفحص النواة سيظلون بحاجة لأداة مثل Netdata.
  3. عدم دعم العمليات الرياضية التجميعية المعقدة: يركز Beszel على الرسوم البيانية القياسية الواضحة، ولا يوفر لغة معادلات رياضية معقدة لحساب متجهات متعددة عبر تصنيفات مخصصة كالمتوفرة في PromQL.

الفئات المستفيدة

صمم Beszel لمسؤولي المختبرات المنزلية، وفرق العمليات التي تدير أساطيل خوادم تتراوح بين خادم واحد وخمسين خادما، والمطورين الذين يديرون تطبيقات متعددة الحاويات ويريدون مراقبة موثوقة دون إهدار موارد الخادم.

التقييم النهائي

يوفر Beszel حلا متوازنا لمراقبة الخوادم وحاويات التطبيقات دون فرض أعباء الذاكرة أو التعقيد الإعدادي المرتبط بحزم Prometheus وGrafana. وبفضل عميله الخفيف المكتوب بلغة Go، ومقاييس ZFS المدمجة، ومحرك PocketBase الموفر للموارد، يقدم النظام طبقة مراقبة عملية وموثوقة لأسطول الخوادم المنزلية والافتراضية.

المصادر


→المقال التاليمشروع Scanopy: التوثيق الآلي ورسم المخططات الهيكلية الحية للشبكات المحليةالمقال السابق←مشروع NextExplorer: مدير ملفات مستضاف ذاتيا وواجهة ويب لمشاركة وتصفح البيانات