[{"data":1,"prerenderedAt":188},["ShallowReactive",2],{"seo-verification":3,"blog-مراقبة-استباقية-vps-beszel-uptime-kuma-ar":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-مراقبة-استباقية-vps-beszel-uptime-kuma-ar",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":130,"ctaBody":131,"ctaButton":132,"ctaUrl":133,"relatedPosts":134},440,"مراقبة-استباقية-vps-beszel-uptime-kuma",{"fr":12,"en":13,"ar":10,"es":14},"monitoring-alerte-proactif-self-hosted-vps","proactive-vps-monitoring-beszel-uptime-kuma-v2","monitorizacion-proactiva-vps-beszel-uptime-kuma-v2","مراقبة استباقية على VPS: Beszel و‎Uptime Kuma v2","انشر Beszel و‏Uptime Kuma v2 على خادم VPS لمراقبة كامل أسطولك من الخوادم وتلقّي تنبيهات Telegram أو SMTP قبل أن يلاحظ عملاؤك أي عطل.",11,0,false,"2026-10-14T00:00:00+00:00","2026-10-14T23:33:30+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"الأمان والمراقبة","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fmonitoring-alerte-proactif-self-hosted-vps-poster.svg","يتوقف خدمة PostgreSQL دون أن تُطلق أي تنبيه يتعلق بالقرص. يتصل العميل. تعلم بالعطل في نفس الوقت الذي يعلم فيه هو. هذا السيناريو الموثّق والمُشارَك في المجتمع في أكتوبر 2026، يكشف مشكلة أدوات المراقبة أحادية الطبقة: كل أداة تُراقب ما صُمِّمت له فحسب، ولا شيء غير ذلك. يُغطي الجمع بين Beszel و‏Uptime Kuma v2 الجانبين معاً — مقاييس النظام على كل مضيف، والتحقق من التوافر من طرف لطرف — بتكلفة موارد أقل من موقع WordPress خامل.",[35,39,51,54,79,82,120,124,127],{"type":36,"title":37,"body":38},"h2","لماذا المراقبة الاستباقية، ولماذا لا تكفي الأدوات الكلاسيكية","التنبيه التفاعلي — الذي يصل بعد أن يكون العميل قد اتصل بالفعل — لا يحمي العلاقة، بل يُصلحها. الفرق بين الحالتين ليس حظاً، بل هو مسألة تغطية.\n\nأداة مراقبة التوافر مثل ‏Uptime Kuma تتحقق من استجابة خدمة على منفذ أو رابط URL. لكنها لا تعلم إذا كانت PostgreSQL تعمل خارج هذا المنفذ، أو إذا كانت ذاكرة الحاوية على وشك الامتلاء، أو إذا كان قرص السجلات يمتلئ بمعدل 200 ميغابايت في الساعة. في المقابل، أداة مقاييس النظام مثل ‏Beszel تُراقب استهلاك كل مضيف باستمرار، لكنها لا تختبر الخدمات التطبيقية من طرف لطرف.\n\nالحادثة الموثّقة على \u003Ca href=\"https:\u002F\u002Flemmy‎.world\u002Fpost\u002F52895878\">‏Lemmy\u003C\u002Fa> في 11 أكتوبر 2026 (112 تصويتاً) تُجسّد هذا تماماً: توقفت PostgreSQL على خادم ‏VPS دون أن تُطلق أي تنبيه قرص. لم يُتجاوز أي حد مساحة. كان التحقق على المستوى التطبيقي هو الوحيد القادر على الكشف عن التوقف — وهو ما لم يكن المشغّل يملكه.\n\nتُعالج مجموعة Beszel و‏Uptime Kuma v2 كلا الجانبين. يُراقب Beszel مقاييس كل مضيف (المعالج، والذاكرة، والقرص، والشبكة، والحاويات) من مركز تجميع واحد. يتحقق Uptime Kuma v2 من توافر الخدمات المكشوفة مع قنوات تنبيه قابلة للتهيئة. كلاهما مفتوح المصدر، مستضاف ذاتياً، ويُنصب على ‏VPS مخصص لمراقبة أسطولك.",{"type":40,"title":41,"items":42},"ul","ما تُقدّمه هذه المجموعة للوكالة عملياً",[43,44,45,46,47,48,49,50],"عرض موحّد لجميع خوادم عملائك في واجهة Beszel واحدة، دون تكثير وصلات SSH.","تنبيهات المقاييس (المعالج، الذاكرة، القرص، الشبكة) بعتبات قابلة للتهيئة لكل مضيف.","فحوصات توافر HTTP(s) و‏TCP و‏DNS وشهادات SSL عبر Uptime Kuma v2 — كل 60 ثانية افتراضياً.","إشعارات Telegram أو SMTP جاهزة في الساعة الأولى، دون اشتراك في خدمات خارجية.","الكشف عن اكتمال القرص أو تسريب الذاكرة قبل أن يحجب خدمة تطبيقية.","صفحات حالة Uptime Kuma العامة القابلة للمشاركة مع العملاء النهائيين.","إجمالي استهلاك المجموعة أقل من 150 ميغابايت من ذاكرة الوصول العشوائي على خادم VPS المراقبة.","نشر قابل للتكرار عبر Docker Compose، قابل للإصدار وإعادة النشر في دقائق.",{"type":36,"title":52,"body":53},"متطلبات الموارد المُحدَّدة","لاستضافة مركز Beszel و‏Uptime Kuma v2 على خادم VPS مخصص للمراقبة:\n\n**الموارد الدنيا.** خادم VPS بنواة معالج واحدة و1 غيغابايت من الذاكرة كافٍ لمراقبة نحو عشرة مضيفين مع Beszel ونحو خمسين مراقِباً مع Uptime Kuma. عملياً، يستهلك مركز Beszel نحو 50 ميغابايت من الذاكرة و‏Uptime Kuma v2 نحو 100 ميغابايت — أقل من 200 ميغابايت إجمالاً في وضع الخمول، وفق قياسات المجتمع. لأسطول من 20 إلى 50 خادم VPS، خصّص 2 غيغابايت من الذاكرة. يخزّن Beszel بياناته في SQLite؛ خصّص 5 إلى 10 غيغابايتات من القرص للاحتفاظ بتاريخ يمتد لأشهر عديدة.\n\n**البرامج المطلوبة.** Docker و‏Docker Compose مثبّتان على خادم VPS المراقبة. نطاق أو نطاق فرعي يشير إلى هذا الخادم (`‏monitoring.your-domain.com`) للوكيل العكسي و‏SSL. المنافذ 80 و443 مفتوحة للوكيل العكسي، والمنفذ `8090` أو أي منفذ تختاره لمركز Beszel.\n\n**على خوادم VPS المُراقَبة.** كل مضيف يُراقَب يستقبل فقط وكيل Beszel — ثنائي خفيف أو حاوية Docker تستهلك نحو 10 ميغابايتات من الذاكرة. لا حاجة لأي تغيير في جدار الحماية العام: الوكيل هو من يُنشئ الاتصال نحو المركز، وليس العكس.",{"type":55,"title":56,"steps":57},"steps","النشر الكامل: مركز Beszel والوكلاء و‏Uptime Kuma v2 والتنبيهات",[58,61,64,67,70,73,76],{"title":59,"body":60},"إنشاء هيكل Docker Compose على خادم VPS المراقبة","اتصل بخادم VPS المخصص للمراقبة. أنشئ دليل عمل وملف Compose:\n\n```bash\nmkdir -p \u002Fopt\u002Fmonitoring && cd \u002Fopt\u002Fmonitoring\n```\n\nأنشئ ملف `docker-compose‎.yml` بالخدمتين:\n\n```yaml\nservices:\n  beszel:\n    image: henrygd\u002Fbeszel:latest\n    restart: unless-stopped\n    volumes:\n      - .\u002Fbeszel_data:\u002Fbeszel_data\n    ports:\n      - \"8090:8090\"\n    environment:\n      - DATA_DIR=\u002Fbeszel_data\n\n  uptime-kuma:\n    image: louislam\u002Fuptime-kuma:2\n    restart: unless-stopped\n    volumes:\n      - .\u002Fuptime-kuma-data:\u002Fapp\u002Fdata\n    ports:\n      - \"3001:3001\"\n    healthcheck:\n      test: [\"CMD\", \"node\", \"extra\u002Fhealthcheck\"]\n      interval: 30s\n      timeout: 10s\n      retries: 3\n```\n\nلاحظ كتلة `healthcheck` على Uptime Kuma: إنها ضرورية لتجنب فخ حلقة التعطل (انظر قسم المخاطر).",{"title":62,"body":63},"تشغيل المجموعة وإنشاء حسابات المدير","شغّل الحاويتين:\n\n```bash\ndocker compose up -d\n```\n\nتحقق من أن الحاويتين في حالة `healthy` أو `running`:\n\n```bash\ndocker compose ps\n```\n\nادخل إلى Beszel على `http:\u002F\u002F\u003Cip-vps>:8090` وأنشئ حساب المدير عند أول وصول. افعل الشيء ذاته مع Uptime Kuma على `http:\u002F\u002F\u003Cip-vps>:3001`. يجب بعد ذلك وضع كلتا الواجهتين خلف وكيل عكسي مع SSL لتجنب كشفهما عبر HTTP العادي.",{"title":65,"body":66},"نشر وكيل Beszel على كل خادم VPS للمراقبة","على كل خادم VPS عميل يُراد مراقبته، انسخ المفتاح العام المُنشأ في واجهة Beszel (الإعدادات ← مفتاح SSH)، ثم نفّذ:\n\n```bash\ncurl -sL https:\u002F\u002Fraw.githubusercontent.com\u002Fhenrygd\u002Fbeszel\u002Fmain\u002Fsupplemental\u002Fscripts\u002Finstall-agent.sh | bash -s -- -p 45876 -k \"\u003Cyour-public-key>\"\n```\n\nبدلاً من ذلك، استخدم Docker على المضيف المُراقَب:\n\n```yaml\nservices:\n  beszel-agent:\n    image: henrygd\u002Fbeszel-agent:latest\n    restart: unless-stopped\n    network_mode: host\n    volumes:\n      - \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock:ro\n    environment:\n      - KEY=\u003Cyour-public-key>\n      - PORT=45876\n```\n\nفي Beszel، أضف كل مضيف من الواجهة (الأنظمة ← إضافة نظام) بتحديد عنوان IP ومنفذ الوكيل. يُنشئ المركز الاتصال نحو الوكيل: لا يحتاج المضيف المُراقَب إلى كشف هذا المنفذ للعموم.",{"title":68,"body":69},"تهيئة تنبيهات المقاييس في Beszel","في Beszel، افتح تفاصيل أي نظام وانتقل إلى تبويب التنبيهات. هيّئ عتبات للمقاييس الحرجة:\n\n- **القرص**: تنبيه عند 80% وتنبيه حرج عند 90% — يغطي سيناريو PostgreSQL من مقدمة المقال.\n- **الذاكرة**: تنبيه إذا تجاوز الاستخدام 85% لمدة 5 دقائق متواصلة.\n- **المعالج**: تنبيه إذا تجاوزت النسبة 90% لأكثر من 3 دقائق.\n\nيدعم Beszel كلاً من Telegram و‏Discord و‏Slack و‏Gotify و‏Ntfy والـ Webhooks العامة. للتنبيهات عبر Telegram، تحتاج إلى رمز Bot (من `@BotFather`) ومعرّف محادثتك أو مجموعتك.",{"title":71,"body":72},"تهيئة مراقبي Uptime Kuma v2 وتنبيهات SMTP أو Telegram","في Uptime Kuma، ابدأ بتهيئة قناة إشعار (الإعدادات ← الإشعارات). خياران شائعان:\n\n**Telegram.** أدخل رمز Bot ومعرّف المحادثة. Bot ذاتُه المستخدم مع Beszel يعمل — استخدم Bot واحداً للأداتين وميّزهما بقنوات مختلفة.\n\n**SMTP.** أدخل خادم SMTP والمنفذ (587 مع STARTTLS) وبيانات الاعتماد وعنوان الوجهة. استخدم حساباً مخصصاً لإرسال التنبيهات.\n\nأنشئ بعد ذلك مراقبين لكل خدمة حرجة: رابط URL بـ HTTP(s) للمواقع، و‏TCP لقواعد البيانات والمنافذ التطبيقية. لحالة PostgreSQL، أضف مراقباً TCP على المنفذ `5432` لكل خادم VPS يستضيف نسخة — إذا توقفت PostgreSQL، سيتوقف المنفذ عن الاستجابة وسيُطلق التنبيه في ثوانٍ.",{"title":74,"body":75},"وضع كل شيء خلف وكيل عكسي مع SSL","أضف خدمة nginx أو Caddy إلى Compose لعرض Beszel و‏Uptime Kuma عبر HTTPS:\n\n```yaml\n  caddy:\n    image: caddy:alpine\n    restart: unless-stopped\n    ports:\n      - \"80:80\"\n      - \"443:443\"\n    volumes:\n      - .\u002FCaddyfile:\u002Fetc\u002Fcaddy\u002FCaddyfile\n      - caddy_data:\u002Fdata\n```\n\nمع `Caddyfile` بسيط:\n\n```\nmonitoring.your-domain.com {\n    reverse_proxy beszel:8090\n}\n\nstatus.your-domain.com {\n    reverse_proxy uptime-kuma:3001\n}\n```\n\nيُصدر Caddy شهادات ‏Let's Encrypt تلقائياً ويجدّدها. احذف أقسام `ports` من beszel و‏uptime-kuma في Compose بمجرد وضعهما خلف وكيل — يجب ألا يكونا قابلَين للوصول مباشرةً.",{"title":77,"body":78},"التحقق من الإعداد وتهيئة الاحتفاظ بالبيانات","اختبر كل شيء بإيقاف خدمة يدوياً على خادم VPS تجريبي (`docker compose stop \u003Cservice>`) والتحقق من وصول تنبيه Telegram أو SMTP خلال أقل من دقيقتين.\n\nبالنسبة لـ Beszel، هيّئ الاحتفاظ بالبيانات في الإعدادات ← الاحتفاظ: القيمة الافتراضية هي 7 أيام للبيانات عالية الدقة و30 يوماً للتجميعات الساعية. اضبطها وفق سعة قرصك.\n\nبالنسبة لـ Uptime Kuma، يُهيَّأ الاحتفاظ في الإعدادات ← متقدم ← التنظيف التلقائي. احتفظ بـ 90 يوماً على الأقل لامتلاك اتجاهات uptime شهرية لتقديمها للعملاء.",{"type":36,"title":80,"body":81},"مخاطر يجب معرفتها قبل الإطلاق في الإنتاج","**حلقة تعطل Docker المُبلَّغ عنها على أنها تعمل — مشكلة Uptime Kuma رقم #7956.** بدون `healthcheck` في Compose، قد يُبلّغ Docker عن حاوية Uptime Kuma بوصفها `running` بينما هي في حلقة إعادة تشغيل. سيُظهر مراقب Uptime Kuma الذي يراقب نفسه (TCP على المنفذ 3001) إيجابية زائفة: المنفذ يستجيب خلال الفترة القصيرة بين عمليتي إعادة تشغيل. الحل هو بالضبط كتلة `healthcheck` المُوضَّحة في الخطوة الأولى — إنها تستخدم السكريبت المضمّن في الصورة لاختبار الحالة الداخلية للتطبيق، لا مجرد وجود العملية. يضع Docker حينئذٍ الحاوية في حالة `unhealthy` إذا فشل الفحص ثلاث مرات متتالية، ويرى مراقب Uptime Kuma ذلك.\n\n**وكيل Beszel مع `network_mode: host`.** إذا كانت المضيفات المُراقَبة تشغّل حاويات، يحتاج وكيل Beszel إلى الوصول إلى مقبس Docker (`\u002Fvar\u002Frun\u002Fdocker.sock`) لرفع مقاييس كل حاوية. في وضع الشبكة الجسرية، يكون المقبس قابلاً للوصول لكن عنوان IP المُرفوع من الوكيل قد يكون عنوان شبكة Docker الداخلية. يُفضَّل استخدام `network_mode: host` على الوكيل لضمان رؤية مركز Beszel لعنوان IP العلني للخادم.\n\n**تنبيهات Beszel لا تحل محل الفحوصات التطبيقية.** يُراقب Beszel موارد النظام وتوافر حاويات Docker. لا يختبر أن تطبيقاً يستجيب بشكل صحيح لطلب HTTP أو أن PostgreSQL تقبل اتصالات. هذان المستويان متكاملان: يكشف Beszel التشبع الذي يسبق العطل، بينما يؤكد Uptime Kuma العطل حين يحدث.",{"type":83,"title":84,"headers":85,"rows":90},"comparison","تغطية التنبيهات حسب تهيئة المجموعة",[86,87,88,89],"سيناريو العطل","Beszel وحده","Uptime Kuma وحده","Beszel + Uptime Kuma v2",[91,96,101,106,110,115],[92,93,94,95],"امتلاء القرص بنسبة 95%","تنبيه عند العتبة المهيّأة","لا يُكشف","تنبيه Beszel قبل العطل",[97,98,99,100],"توقف PostgreSQL (منفذ TCP معطّل)","لا يُكشف (خدمة خارج Docker)","تنبيه TCP في أقل من دقيقتين","تنبيه Uptime Kuma TCP",[102,103,104,105],"حاوية في حلقة تعطل","تنبيه إذا أثّر على المعالج\u002Fالذاكرة","إيجابية زائفة بدون healthcheck","يُكشف إذا كان healthcheck موضوعاً",[107,108,94,109],"تسريب ذاكرة تدريجي","تنبيه على عتبة الذاكرة","تنبيه Beszel استباقي",[111,112,113,114],"شهادة SSL تنتهي في 7 أيام","غير مُراقَبة","تنبيه انتهاء SSL","تنبيه Uptime Kuma SSL",[116,117,118,119],"خادم VPS غير قابل للوصول (شبكة أو مضيف معطّل)","المركز يفقد الوكيل","تنبيه TCP\u002FHTTP","إشارة مزدوجة، متقاربة",{"type":121,"title":122,"body":123},"tip","التصليب: عزل خادم VPS المراقبة","خادم VPS المراقبة أصل حرج: إذا توقف، تفقد الرؤية على كل شيء آخر. ثلاث قواعد لتصليبه.\n\nأولاً، لا تستضف تطبيقات العملاء على هذا الخادم. يجب أن يكون حمله متوقعاً ودوره الوحيد هو المراقبة.\n\nثانياً، أغلق جميع المنافذ غير الضرورية بجدار حماية خادم VPS. فقط 80 و443 ومنفذ SSH (منقول إلى منفذ غير قياسي) يجب أن تكون قابلة للوصول من الإنترنت. منفذ وكيل Beszel (45876 افتراضياً) يجب فتحه فقط من عناوين IP خوادم VPS الأخرى، وليس من الإنترنت بأكمله.\n\nثالثاً، أضف مراقباً Uptime Kuma خارجياً — مثلاً من خدمة فحص HTTP مجانية — يتحقق من استجابة نسختك من Uptime Kuma. بدون هذه الطبقة الخارجية، يمر عطل خادم VPS المراقبة نفسه دون أن يُلاحَظ.",{"type":36,"title":125,"body":126},"استكشاف أخطاء المشكلات الشائعة","**يظهر وكيل Beszel غير متصل فوراً بعد الإضافة.** تحقق من أن منفذ الوكيل (45876 افتراضياً) قابل للوصول من المركز. على المضيف المُراقَب، اختبر بـ `nc -zv \u003Chub-ip> 8090` — إذا فشل الاتصال، المشكلة في جدار حماية المركز. الوكيل نفسه لا يحتاج إلى فتح أي منفذ وارد.\n\n**Uptime Kuma لا يستقبل تنبيهات Telegram.** السبب الأكثر شيوعاً هو انحراف ساعة الحاوية. تحقق بـ `docker exec uptime-kuma date` أن الوقت يتطابق مع UTC الحقيقي. إذا لم يكن كذلك، أضف `\u002Fetc\u002Flocaltime:\u002Fetc\u002Flocaltime:ro` في أحجام خدمة Uptime Kuma.\n\n**مركز Beszel لا يبدأ أو يفقد بياناته بعد إعادة التشغيل.** تحقق من أن الحجم `.\u002Fbeszel_data` يملكه ‏UID المستخدم من قِبل حاوية Beszel. خطأ في صلاحيات مجلد البيانات يمنع SQLite من الكتابة: `chown -R 1000:1000 .\u002Fbeszel_data` يُصلح المشكلة في معظم الحالات.\n\n**Uptime Kuma في حالة `unhealthy` عند البدء.** قد تستغرق صورة v2 من 30 إلى 60 ثانية لتبدأ بالكامل قبل أن يَنجح الـ healthcheck. هذا طبيعي. إذا بقيت الحاوية `unhealthy` بعد دقيقتين، راجع السجلات: `docker compose logs uptime-kuma`.",{"type":36,"title":128,"body":129},"للمزيد","تُغطي هذه المجموعة المستويين الأساسيين: مقاييس النظام والتحقق من التوافر. للمستوى الثالث — قابلية التتبع وتحليل اتجاهات الحمل الدقيقة — تُعدّ مجموعة Grafana و‏Prometheus الخطوة التالية الطبيعية. إنها أكثر استهلاكاً للموارد (خصّص 2 غيغابايت من الذاكرة)، لكنها تفتح PromQL ولوحات التحكم المخصصة. يغطي مقال \u003Ca href=\"\u002Fblog\u002Fmonitoring-vps-grafana-prometheus\">مراقبة VPS مع Grafana و‏Prometheus\u003C\u002Fa> هذا النشر خطوة بخطوة.\n\nللنسخ الاحتياطية لخادم VPS المراقبة نفسه — لتجنب إعادة بناء كل الإعداد عند الفقدان — \u003Ca href=\"\u002Fblog\u002Fbackup-vps-restic-s3-3-2-1\">استراتيجية 3-2-1 مع Restic وتخزين S3\u003C\u002Fa> تنطبق مباشرةً على أحجام Docker لهذه المجموعة.\n\nإذا كنت تُدير عدة خوادم عملاء من منصة واحدة، تُفصّل صفحة \u003Ca href=\"\u002Fsolutions\u002Fagences\">‏\u002Fsolutions\u002Fagences\u003C\u002Fa> كيف تُمركز ServOrbit مراقبة أسطولك على VPS Start.","راقب أسطولك من خادم VPS واحد","أنت تُدير عدة خوادم لعملائك. مركز مراقبة أسطولك على خادم VPS من ServOrbit مع وصول root وعنوان IPv4 مخصص و‏Docker — مجموعة Beszel و‏Uptime Kuma v2 تعمل على الخطة الأساسية.","راقب أسطولي","\u002Fsolutions\u002Fagences",[135,154,171],{"id":136,"slug":137,"slugs":138,"title":142,"excerpt":143,"readTime":144,"views":18,"isPinned":19,"publishedAt":145,"updatedAt":146,"category":147,"categories":148,"featuredImage":30,"bgImage":31,"posterImage":150,"relatedSolution":151},105,"مراقبة-خادمك-الافتراضي-vps-باستخدام-uptime-kuma",{"fr":139,"en":140,"ar":137,"es":141},"superviser-vps-uptime-kuma","monitoring-your-vps-with-uptime-kuma","supervisar-vps-con-uptime-kuma","مراقبة خادمك الافتراضي VPS باستخدام Uptime Kuma","انشر Uptime Kuma على خادمك الافتراضي VPS لمراقبة مواقعك وخدماتك ذاتيًا، مع تنبيهات وصفحة حالة عامة.",4,"2026-03-07T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[149],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsuperviser-vps-uptime-kuma-poster.svg",{"categorySlug":152,"appSlug":153},"المراقبة-وقابلية-الرصد","uptime-kuma",{"id":155,"slug":156,"slugs":157,"title":161,"excerpt":162,"readTime":23,"views":163,"isPinned":19,"publishedAt":164,"updatedAt":146,"category":165,"categories":166,"featuredImage":30,"bgImage":31,"posterImage":168,"relatedSolution":169},133,"استضف-beszel-على-vps-مركز-مراقبة-متعدد-الخوادم",{"fr":158,"en":159,"ar":156,"es":160},"self-host-beszel-vps","self-host-beszel-multi-server-monitoring-hub-on-your-vps","alojar-beszel-hub-monitorizacion-vps","استضف Beszel على VPS: المراقبة والتنبيهات والأمان","انشر Beszel على VPS، راقب كامل أسطولك من مركز واحد، هيّئ تنبيهات Telegram والبريد الإلكتروني، فعّل المصادقة الثنائية وحلّ مشاكل الوكلاء الصامتين وأخطاء TLS والمنافذ المحجوبة.",1,"2026-02-14T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[167],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fself-host-beszel-vps-poster.svg",{"categorySlug":152,"appSlug":170},"beszel",{"id":172,"slug":173,"slugs":174,"title":178,"excerpt":179,"readTime":17,"views":18,"isPinned":19,"publishedAt":180,"updatedAt":181,"category":182,"categories":183,"featuredImage":30,"bgImage":31,"posterImage":185,"relatedSolution":186},106,"مراقبة-الخادم-الافتراضي-vps-باستخدام-grafana-و-prometheus",{"fr":175,"en":176,"ar":173,"es":177},"monitoring-vps-grafana-prometheus","vps-monitoring-with-grafana-and-prometheus","monitorizacion-vps-grafana-prometheus","مراقبة VPS باستخدام Grafana وPrometheus","انشر Prometheus 3.x وGrafana 13.x وNode Exporter وAlertmanager على خادمك VPS بـ Docker Compose. لوحات معلومات وتنبيهات وتصليب.","2026-03-06T00:00:00+00:00","2026-10-05T14:05:27+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[184],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitoring-vps-grafana-prometheus-poster.svg",{"categorySlug":152,"appSlug":187},"grafana",1792031847685]