Uptime Kuma: مراقبة حالة مستضافة ذاتيًا

ما الذي تبنيه

حاوية واحدة صغيرة تراقب خوادمك ومواقعك الأخرى من الخارج، وتخبرك في اللحظة التي يتوقف فيها أحدها عن الاستجابة، عبر البريد الإلكتروني أو Telegram أو Discord أو webhook. Uptime Kuma عملية Node واحدة مدعومة بملف SQLite، فتعمل بسلاسة في 256-512 MB من ذاكرة RAM، وتمنحك لوحة معلومات حية، ورسومًا بيانية تاريخية، وصفحة حالة عامة. التثبيت ملف Compose من عشرة أسطر؛ أما الجزء الذي يهم فعلًا فهو أين تُشغّله وهل أطلقت تنبيهاتك فعلًا في اختبار، لأن مراقبًا لم تُثبت قط أنه يستطيع الوصول إليك أسوأ من لا مراقب على الإطلاق: فهو يمنحك شعورًا بالتغطية بينما لا يراقب شيئًا.

شغّل المراقب حيث لا يصله العطل

هذا القرار وحده يصنع كل شيء أو يهدمه، لذلك يأتي أولًا. لا تُشغّل Uptime Kuma على الجهاز نفسه الذي يراقبه. فإذا عاش المراقب على الخادم الذي يراقبه، فإن الحدث بعينه الذي يهمك — موت ذلك الجهاز أو نفاد ذاكرته — يقتل المراقب أيضًا فلا تحصل على أي تنبيه على الإطلاق: صمت مراقب ميت يبدو تمامًا مثل «كل شيء على ما يرام». وهناك فخ أدق حتى مع بقاء الجهاز حيًا: مراقب موجَّه إلى localhost يتشارك المعالج مع حِمل العمل، فيجعل ارتفاع الحمل فحصه هو نفسه ينتهي بتجاوز المهلة ويقلب الهدف إلى down، إنذارًا كاذبًا، بينما يُخدَم المستخدمون الحقيقيون دون مشكلة.

لذا شغّل Uptime Kuma على خادم VPS مختلف عن الذي يراقبه، ويُفضَّل عند مزوّد أو في منطقة مختلفة، ليصل إلى خدماتك بالطريقة نفسها التي يصل بها مستخدموك: عبر الإنترنت العام، باسم المضيف. تكفي نسخة رخيصة، ويستطيع خادم VPS صغير واحد للمراقبة أن يراقب كل خوادمك. ولرصد تعطّل Kuma نفسه، أضف نبضة (heartbeat) تدفعها مهمة cron من موضع آخر.

المتطلبات المسبقة وتحديد الحجم

• خادم VPS جديد بنظام Ubuntu 24.04 مزوّد بـ Docker Engine وإضافة Compose v2، مثبَّتين من مستودع apt الخاص بـ Docker نفسه، لا من حزمة التوزيعة docker.io التي تتأخر عن الإصدارات الحديثة.
• 256 MB من ذاكرة RAM تكفي لتشغيل حفنة من المراقبات؛ ومن 512 MB إلى 1 GB مريحة لعشرات منها مع الوكيل العكسي، والمعالج شبه خامل بين الفحوصات.
• نطاق وسجل DNS من نوع A (لنقل status.example.com يشير إلى خادم VPS)، فقط إن أردت TLS وصفحة حالة عامة. أما النسخة الخاصة فيمكنها تجاوز DNS واستخدام VPN أو نفق SSH.
• اتصال شبكي صادر إلى أي وجهة تذهب إليها التنبيهات: SMTP إلى مزوّد بريدك، أو HTTPS إلى Telegram وDiscord.

ملف Compose

ضع هذا في /srv/uptime-kuma/compose.yaml.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - kuma-data:/app/data

volumes:
  kuma-data:

شغّله وراقب الإقلاع الأول:

sudo mkdir -p /srv/uptime-kuma
# save the file above as /srv/uptime-kuma/compose.yaml, then:
cd /srv/uptime-kuma && sudo docker compose up -d
sudo docker compose logs -f uptime-kuma

بدء التشغيل الصحيح يسجّل Listening on 3001 ثم يصمت. ثلاثة أشياء في هذا الملف مقصودة.

127.0.0.1:3001:3001، لا 3001:3001. ينشر Docker المنافذ بقواعد DNAT تُقيَّم قبل أن يرى ufw الحزمة أصلًا، فكتابة 3001:3001 مجردة تضع لوحة معلوماتك على الإنترنت العام بصرف النظر عن جدار حمايتك. الربط بعنوان الاسترجاع المحلي (loopback) يبقيها خاصة، مع كشف الوكيل العكسي وحده؛ ويمكن للنسخة الخاصة تجاوز الوكيل والوصول إلى 3001 عبر شبكة WireGuard VPN مستضافة ذاتيًا بدلًا من ذلك.

وحدة تخزين مسمّاة (named volume) عند /app/data. كل ما يتذكره Uptime Kuma — قاعدة بيانات SQLite، ومراقباتك، وإعدادات الإشعار، وشعارات صفحة الحالة — يعيش هناك. اخسرها وستبدأ من شاشة إدارة فارغة؛ وهي الشيء الوحيد الذي يجب أن تنسخه احتياطيًا.

الصورة مثبَّتة على وسم إصدار رئيسي، :2. هذا هو الخط المستقر الحالي؛ تحقق من Docker Hub لمعرفة أحدث رقم رئيسي قبل أن تنسخ هذا، ولا تتبع أبدًا وسمًا متحركًا مثل latest، الذي أوقف المشروع دعمه. القفز بين إصدار رئيسي وآخر على هذه الصورة هجرة قاعدة بيانات باتجاه واحد تريد إطلاقها عمدًا، لا أن تقع فيها مصادفةً أثناء pull روتيني.

تنبيه واحد: يجب أن يكون /app/data على نظام ملفات يدعم أقفال ملفات POSIX. وحدة تخزين Docker المحلية تفي بالغرض؛ أما على NFS فتتلف قاعدة بيانات SQLite وتحصل على SQLITE_BUSY وdatabase disk image is malformed، لذا لا تستخدم أبدًا مشاركة شبكية.

التشغيل الأول: أنشئ حساب المسؤول

تصفّح النسخة عبر وكيلك على https://status.example.com، أو عبر نفق SSH: نفّذ ssh -L 3001:127.0.0.1:3001 user@your-vps وافتح http://localhost:3001. الصفحة الأولى نموذج إعداد لاسم مستخدم وكلمة مرور المسؤول؛ لا يوجد تسجيل دخول افتراضي. اختر كلمة مرور حقيقية: فهذه اللوحة ترى العناوين الداخلية والرموز (tokens) الخاصة بكل ما تراقبه. نسيتها لاحقًا؟ أعد ضبطها من المضيف، لا من المتصفح:

sudo docker compose exec uptime-kuma npm run reset-password

أضف قنوات الإشعار أولًا، واختبرها

جهّز التنبيهات قبل إضافة المراقبات، حتى تستطيع إرفاق قناة عند إنشاء كل واحد منها. اذهب إلى Settings ثم Notifications ثم Setup Notification، واستخدم زر Test الخاص بكل قناة للتأكد من وصول الرسالة، لأن الإشعار غير المختبَر هو ثاني أشيع طريقة يفشل بها الإعداد بصمت.

البريد الإلكتروني (SMTP). املأ المضيف، والمنفذ، والتشفير، واسم المستخدم، وكلمة المرور، وحقلي From وTo. التوليفتان العاملتان هما 465 مع ضبط «Secure» على TLS/SSL، أو 587 مع STARTTLS. بالنسبة إلى Gmail ومعظم المزوّدين الذين يفعّلون المصادقة الثنائية، عليك توليد كلمة مرور تطبيق؛ فكلمة مرور الحساب العادية تُعيد Error: Invalid login: 535-5.7.8 Username and Password not accepted.

Telegram. راسل @BotFather، وأرسل /newbot، وانسخ رمز البوت (bot token). للحصول على معرّف الدردشة (chat ID)، راسل البوت الجديد مرة واحدة، ثم افتح https://api.telegram.org/bot<token>/getUpdates واقرأ chat.id من الـJSON. البوت الذي لم تراسله أولًا يعطي getUpdates فارغًا ولا وجهة يرسل إليها.

Discord. في القناة، افتح Edit Channel ثم Integrations ثم Webhooks ثم New Webhook، وانسخ الرابط، والصقه كإشعار من نوع Discord.

Webhook عام. لأي شيء آخر — webhook وارد في Slack، أو نقطة نهاية مخصصة، أو خطاف أتمتة منزلية — يرسل نوع Webhook حمولة JSON بطلب POST إلى رابط تحدده أنت، ويغطي تكامل Apprise المدمج معظم الخدمات التسعين الأخرى الموجودة في القائمة.

أضف مراقبات، نوعًا واحدًا في كل مرة

انقر Add New Monitor، واختر نوعًا، واضبط Friendly Name، وCheck Interval (60 ثانية قيمة معقولة)، وRetries (عدد الإخفاقات المتتالية قبل «down»؛ 2 أو 3 حتى لا تتحول حزمة واحدة ضائعة إلى استدعاء طارئ)، والتنبيهات التي تريد إطلاقها. الأنواع التي ستستخدمها:

• HTTP(s). رابط كامل. up تعني رمز حالة مقبولًا (200-299 افتراضيًا؛ وسّعه تحت Accepted Status Codes إن كان 301 أو 401 طبيعيًا عندك). الأداة الأساسية للمواقع وواجهات API.
• HTTP(s) - Keyword. الطلب نفسه، لكن up يشترط أيضًا وجود سلسلة نصية في المتن، أو غيابها مع Invert. يكشف هذا موقعًا يعيد 200 OK بينما يعرض «Error establishing a database connection»، وهو ما يعتبره فحص HTTP العادي سليمًا.
• TCP Port. اتصال TCP مجرد بمضيف ومنفذ، لما ليس HTTP: SSH على المنفذ 22، وPostgres على 5432، وخادم SMTP على 25، وخادم ألعاب.
• Ping. صدى ICMP: قابلية وصول وزمن استجابة رخيصان. لكن كثيرٌ من الشبكات وجدران الحماية السحابية يُسقط ICMP، فقد يعني مراقب ping أحمر «المضيف معطل» أو «المزوّد يحظر ping»؛ تأكد بمراقب TCP.
• DNS. يحلّ سجلًا (A، AAAA، MX، TXT وغيرها) عبر مُحلِّل (resolver) تسمّيه، ويمكنه التحقق من الإجابة، فيكشف مبكرًا عطل مسجِّل النطاق أو DNS.
• Push. المراقب المقلوب من الداخل إلى الخارج، ونتناوله بعد قليل.

مراقبة مهمة cron بمراقب Push (نبضة)

كل مراقب مما سبق يصل إلى داخل خدمتك من الخارج. أما مراقب Push فيعمل بالاتجاه المعاكس: ينتظر Uptime Kuma، ومهمتك هي التي تستدعيه لتقول «لقد عملت». إنها الطريقة الصادقة الوحيدة لمراقبة نسخة احتياطية أو مهمة cron: فحص HTTP يعرف أن رابطًا يستجيب، لكن المهمة وحدها تعرف أنها اكتملت.

أنشئ مراقبًا من نوع Push. يولّد Uptime Kuma رابطًا فريدًا يشبه:

https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=

اضبط Heartbeat Interval على وتيرة تشغيل المهمة، مع هامش بسيط إضافي. ثم أضف سطرًا واحدًا في نهاية السكربت، حتى يُطلَق فقط عند النجاح:

#!/usr/bin/env bash
set -euo pipefail
# ... your backup or job runs here; set -e aborts on any failure ...
curl -fsS --retry 3 "https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=backup+ok&ping="

إذا فشلت المهمة، يُوقف set -e التنفيذ قبل الوصول إلى curl؛ وإذا كان الجهاز معطلًا، فهو لن يعمل أصلًا أيضًا. في الحالتين تتوقف النبضة، وبمجرد أن تمر نافذة الفاصل الزمني مضافًا إليها إعادة المحاولات، يقلب Uptime Kuma المراقب إلى down وينبهك. عامل رمز الـ push هذا بوصفه سرًا: فأي شخص يملكه يستطيع تزوير نبضة سليمة.

أنشئ صفحة حالة عامة

صفحة الحالة هي الواجهة التي يراها العملاء: أي الخدمات تعمل (up) وتاريخها الحديث، من دون كشف لوحة معلوماتك. اذهب إلى Status Pages ثم New Status Page، وأعطها اسمًا وslug (المسار العام، مثل /status/main)، واسحب المراقبات التي تريدها إلى مجموعات مثل «Websites» و«APIs»، وأضف شعارًا ووصفًا قصيرًا، ثم احفظ. يمكنك أيضًا ربط الصفحة بنطاقها الخاص بحيث يخدمها status.example.com مباشرة.

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

ضعه خلف وكيل عكسي بشهادة TLS، وانتبه إلى WebSocket

من أجل نسخة عامة، ضع وكيلًا عكسيًا أمام الحاوية المربوطة بعنوان الاسترجاع المحلي لأجل TLS واسم مضيف. التفصيل الذي يُوقع الجميع: واجهة Uptime Kuma تطبيق Socket.IO حي، فيجب على الوكيل ترقية اتصال WebSocket. أغفِل ذلك وستُحمَّل الصفحة لكنها لن تتصل أبدًا؛ تبقى لوحة المعلومات على «Connecting...»، ولا تتحدّث النبضات الحية أبدًا، ويُظهر console المتصفح WebSocket connection to 'wss://.../socket.io/...' failed.

ثبّت nginx وcertbot، ثم اكتب vhost يمرّر الحركة إلى منفذ الاسترجاع المحلي. ضعه على المنفذ 80 الآن ودع certbot يضيف TLS لاحقًا؛ التحدي (challenge) ومؤقّت التجديد وأنماط فشله مشروحة في إصدار شهادات Let's Encrypt باستخدام certbot وnginx.

sudo apt install -y nginx certbot python3-certbot-nginx

احفظ هذا في /etc/nginx/sites-available/status.example.com؛ سطرا WebSocket هما ما يهم:

server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

فعّل الموقع، واختبر الإعداد، ثم دع certbot يعيد كتابة الكتلة لتستمع على 443، ويُدرج الشهادة، ويضيف إعادة توجيه من HTTP إلى HTTPS:

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

زوج Upgrade وConnection "upgrade" هو كل ما يهم هنا، وproxy_read_timeout 3600s يمنع nginx من هدم socket طويل العمر؛ وينسخ certbot الاثنين معًا إلى كتلة 443 التي يولّدها. إن كنت تُشغّل بالفعل عدة حاويات خلف وكيل واحد، فإن توجيهها عبر Traefik بشهادات TLS تلقائية يفعل الشيء نفسه بتصنيفات (labels) الحاوية، ويمرّر ترقيات WebSocket افتراضيًا.

لا تضع مصادقة Basic على vhost بأكمله، لأن ذلك يقفل أيضًا صفحة الحالة العامة ونقطة النهاية /api/push. أبقِ تسجيل الدخول المدمج في Uptime Kuma، وأضف fail2ban يراقب محاولات الدخول الفاشلة المتكررة إن كانت مواجهة للإنترنت العام، وإن لم تكن لوحة المعلومات بحاجة إلى أن تكون عامة إطلاقًا، فتخلَّ عن الوكيل واصل إليها عبر VPN.

مراقبة انتهاء صلاحية الشهادات، بالطريقة الصحيحة

يستطيع مراقب HTTP(s) أيضًا أن يحذّرك قبل انتهاء صلاحية شهادة TLS: فعّل Certificate Expiry Notification وسينبهك Uptime Kuma قبل عدد أيام محدد. خطآن يجعلانه يقرأ الأمر خطأً. راقب عبر اسم المضيف، لا IP، وإلا فإن طلبًا بلا SNI يحصل على شهادة الخادم الافتراضية وسترى Hostname/IP does not match certificate's altnames. ولا تفعّل Ignore TLS/SSL Error على مراقب تريد منه تحذيرات انتهاء الصلاحية: هذا الخيار مخصص للمضيفين الداخليين ذوي الشهادات الموقّعة ذاتيًا (unable to verify the first certificate، DEPTH_ZERO_SELF_SIGNED_CERT)، لكنه يوقف Uptime Kuma عن التحقق من الشهادة كليًا، بما في ذلك انتهاء صلاحيتها.

النسخ الاحتياطي: كل شيء في دليل واحد

لأن كل شيء يعيش في /app/data، فالنسخة الاحتياطية هي نسخة من تلك الوحدة تُؤخذ أثناء إيقاف الحاوية، حتى يبقى ملف SQLite متسقًا:

cd /srv/uptime-kuma
sudo docker compose stop
sudo docker run --rm \
  -v uptime-kuma_kuma-data:/data \
  -v /var/backups/kuma:/backup \
  alpine tar czf /backup/kuma-$(date -u +%Y%m%dT%H%M%SZ).tgz -C /data .
sudo docker compose start

تأكد أولًا من الاسم الحقيقي للوحدة بالأمر docker volume ls | grep kuma، لأن Compose يسبقه باسم دليل المشروع. ثم انسخ الأرشيف خارج الجهاز، لأن نسخة احتياطية على الخادم نفسه مجرد نسخة، لا نسخة احتياطية. الاستعادة هي العملية المعاكسة: أوقف الحزمة، وفكّ الأرشيف في وحدة /app/data فارغة، ثم شغّلها.

الترقيات

الترقية هي عملية pull لصورة جديدة:

cd /srv/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

تنفّذ الحاوية الجديدة أي هجرة لقاعدة البيانات عند أول تشغيل؛ راقب docker compose logs -f. خذ النسخة الاحتياطية أعلاه قبل تنفيذ pull، والتزم بوسم إصدار رئيسي واحد: الانتقال من :1 إلى :2 هجرة باتجاه واحد، لذا خذ نسخة احتياطية أولًا وراجع ملاحظات الإصدار.

أنماط الفشل، مع النصوص التي ستراها

«down» زائف على مراقب موجَّه إلى localhost. يتحول المراقب إلى الأحمر مع timeout of 48000ms exceeded أو connect ETIMEDOUT، مع أن الخدمة تستجيب من حاسوبك المحمول. إذا كان يستهدف المضيف نفسه الذي يعمل عليه Uptime Kuma، فإن ارتفاعًا في المعالج أو الذاكرة أنهك الفحص نفسه، لا الهدف. انقل المراقب إلى خادم VPS منفصل واستهدف اسم المضيف العام.

connect ECONNREFUSED 127.0.0.1:443 (أو أي منفذ آخر). لم يكن شيء يستمع على ذلك المنفذ: إما أن الخدمة معطلة، أو أنك راقبت localhost من داخل الحاوية، حيث 127.0.0.1 هو الحاوية نفسها، لا خادمك. راقب اسم المضيف العام، لا عنوان الاسترجاع المحلي.

Invalid login: 535-5.7.8 Username and Password not accepted عند اختبار بريد. بيانات اعتماد SMTP خاطئة، أو أن المزوّد يريد كلمة مرور خاصة بالتطبيق وحصل بدلًا منها على كلمة مرور حسابك. ولّد كلمة مرور تطبيق والصقها.

connect ETIMEDOUT أو queryA ETIMEDOUT <host> عند اختبار بريد. منفذ خاطئ، أو أن المزوّد يحظر SMTP الصادر. تأكد أن 465 أو 587 يطابق إعداد Secure/STARTTLS، واختبر من المضيف بالأمر nc -vz smtp.example.com 587. كثير من المزوّدين يحظرون المنفذ 25 الصادر، وبعضهم يحظر منافذ الإرسال (submission) حتى تطلب فتحها.

self signed certificate أو unable to verify the first certificate عند اختبار بريد. خادم SMTP لديك يقدّم شهادة لن تثق بها Node؛ أصلح شهادة خادم البريد بدلًا من التحايل عليها.

لوحة المعلومات عالقة على «Connecting...»، وconsole تُظهر WebSocket connection ... failed. الوكيل العكسي لا يرقّي WebSocket. أضف ترويستي Upgrade وConnection "upgrade" على nginx، أو استخدم وكيلًا يمرّرهما افتراضيًا مثل Traefik أو Caddy. يُحمَّل HTML لأن ذلك مجرد HTTP GET عادي؛ socket الحي وحده يحتاج إلى الترقية.

مراقب انتهاء صلاحية الشهادة لا يحذّر أبدًا، أو يحذّر خطأً. إما أن Ignore TLS/SSL Error مفعّل، وهو ما يعطّل التحقق من الشهادة، أو أن المراقب يستهدف IP فيقرأ الشهادة الخطأ بسبب غياب SNI، فيُظهر Hostname/IP does not match certificate's altnames. عطّل خيار التجاهل، وراقب باسم المضيف.

SQLITE_BUSY أو database disk image is malformed في السجلات. وحدة /app/data على نظام ملفات بلا أقفال ملفات سليمة، غالبًا NFS؛ انقلها إلى وحدة Docker محلية واستعد من النسخة الاحتياطية.

FAQ

أين ينبغي أن أُشغّل مراقب التوفر الخاص بي؟

على خادم مختلف عن الخوادم التي يراقبها، ويُفضَّل عند مزوّد أو في منطقة أخرى، ليصل إليها باسم المضيف عبر الإنترنت العام تمامًا كما يفعل مستخدموك. إذا شارك المراقب جهازًا مع أهدافه، فإن العطل الذي يقتل الخادم يقتل المراقب أيضًا، والمضيف المُثقَل يجعله يطلق تنبيه «down» كاذبًا عن خدمات سليمة. خادم VPS صغير منفصل يتجنب الأمرين.

كيف أحصل على تنبيهات عبر Telegram أو البريد الإلكتروني؟

أضف القناة تحت Settings ثم Notifications، ثم أرفقها بكل مراقب. بالنسبة إلى Telegram، أنشئ بوتًا بواسطة @BotFather واقرأ chat.id من https://api.telegram.org/bot<token>/getUpdates؛ وبالنسبة إلى البريد، استخدم 465 لـSSL أو 587 لـSTARTTLS مع كلمة مرور تطبيق إن كان مزوّدك يستخدم مصادقة ثنائية. اضغط Test وتأكد من وصول الرسالة قبل أن تعتمد عليها.

هل يستطيع Uptime Kuma مراقبة مهمة cron أو سكربت نسخ احتياطي؟

نعم، وذلك عبر مراقب Push: يمنحك Uptime Kuma رابطًا وتستدعيه بـcurl في نهاية السكربت حتى يُطلَق فقط عند النجاح. إذا فشلت المهمة أو كان الجهاز معطلًا، لا تصل النبضة أبدًا، وتُنبَّه بعد مرور الفاصل الزمني. إنها الطريقة الموثوقة الوحيدة لمعرفة أن مهمة مجدولة نُفِّذت فعلًا، لأن فحصًا خارجيًا لا يستطيع رؤية ما يجري بداخلها.

Uptime Kuma أم Zabbix، أيهما أشغّل؟

يجيب Uptime Kuma عن سؤال «هل هو يعمل، من الخارج، وهل نبّهني؟» خلال عشر دقائق بموارد شبه معدومة، مع صفحة حالة. لكنه لا يجمع مقاييس عميقة كاتجاهات المعالج والذاكرة والقرص أو عتبات على مستوى الأسطول؛ ولهذا فإن خادم مراقبة Zabbix الكامل هو الأداة الأثقل القائمة على عميل (agent)، وكثيرون يشغّلون الاثنين معًا. ما زلت تحدد ما ستشغّله أصلًا؟ جولتنا فيما يستحق الاستضافة الذاتية في 2026 تضع المراقبة في سياقها.