Uptime Kuma یک ابزار متنباز و خودمیزبان برای پایش در دسترس بودن سایتها و سرورهاست. آن را با یک دستور docker run یا فایل Compose اجرا کنید، پورت را روی 127.0.0.1 نگه دارید و با Nginx و HTTPS منتشرش کنید. برای هر سایت مانیتور HTTP با بررسی کلیدواژه و هشدار انقضای گواهی بسازید، اعلان تلگرام یا ایمیل را وصل کنید و در صورت نیاز یک صفحهٔ وضعیت عمومی بسازید. بهتر است Uptime Kuma روی سروری جدا از سرورهای تحت پایش اجرا شود.
چرا مانیتورینگ لازم است؟
بدترین راه برای فهمیدن قطع شدن سایت، پیام یک مشتری ناراضی است. سایت ممکن است به دلایل زیادی از دسترس خارج شود: پر شدن دیسک، توقف سرویس پس از بهروزرسانی، تمام شدن گواهی SSL، مشکل DNS یا قطعی شبکهٔ دیتاسنتر. هرچه زودتر باخبر شوید، زمان قطعی کوتاهتر است.
Uptime Kuma یک ابزار متنباز و رایگان است که روی سرور خودتان اجرا میشود و در فاصلههای منظم سایتها و سرویسها را بررسی میکند. اگر چیزی از کار افتاد، از طریق تلگرام، ایمیل، دیسکورد، Slack یا دهها روش دیگر خبرتان میکند. رابط کاربری ساده و زیبایی دارد و برای راهاندازی به دانش خاصی نیاز ندارد.
کجا نصبش کنیم؟
نکتهٔ کلیدی: مانیتور را روی همان سروری که پایش میکند نصب نکنید. اگر سرور خاموش شود یا شبکهاش قطع شود، Uptime Kuma هم همراهش از کار میافتد و هیچ اعلانی نمیفرستد. بهترین گزینه یک سرور مجازی کوچک و جداگانه است، ترجیحاً در دیتاسنتر یا حتی کشوری دیگر. Uptime Kuma منابع کمی مصرف میکند و روی کوچکترین سرورها هم بهراحتی اجرا میشود.
اگر سرورهای شما هم در ایران و هم خارج هستند، دید از دو نقطه ارزشمند است: گاهی سایت از داخل در دسترس است و از خارج نه، یا برعکس، و یک مانیتور تنها این تفاوت را نشان نمیدهد.
نصب با داکر
پیشنیاز، داکر نصبشده طبق آموزش نصب داکر است. سریعترین روش یک فایل Compose کوچک است:
services:
uptime-kuma:
image: louislam/uptime-kuma:1
restart: unless-stopped
ports:
- "127.0.0.1:3001:3001"
volumes:
- kuma-data:/app/data
volumes:
kuma-data:
mkdir -p ~/kuma && cd ~/kuma
nano docker-compose.yml
docker compose up -d
پورت فقط روی 127.0.0.1 منتشر شده تا از اینترنت مستقیم در دسترس نباشد. همهٔ تنظیمات و تاریخچه در volume با نام kuma-data ذخیره میشود و با حذف و ساخت دوبارهٔ کانتینر از بین نمیرود.
انتشار با دامنه و HTTPS
Uptime Kuma از WebSocket استفاده میکند، پس در Nginx هدرهای Upgrade لازم است:
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;
}
}
سپس با sudo certbot --nginx -d status.example.com گواهی بگیرید. این الگو در آموزش Nginx برای اپلیکیشنهای داکر با جزئیات آمده است. اولین بار که آدرس را باز میکنید، از شما میخواهد حساب مدیر بسازید؛ این کار را فوراً انجام دهید و رمز قوی انتخاب کنید.
انواع مانیتور
پس از ورود، با دکمهٔ «Add New Monitor» مانیتور بسازید. مهمترین انواع:
- HTTP(s): آدرس را درخواست میکند و کد وضعیت را بررسی میکند. پایهایترین مانیتور برای هر سایت.
- HTTP(s) - Keyword: علاوه بر کد وضعیت، بررسی میکند متن مشخصی در صفحه وجود دارد. این مهم است، چون گاهی سایت کد 200 برمیگرداند اما صفحه خالی یا صفحهٔ خطای برنامه است.
- TCP Port: بررسی میکند پورتی باز است و اتصال میپذیرد؛ برای SSH، دیتابیس یا سرویسهای غیروبی. مفهوم پورت در مقالهٔ پورت شبکه آمده است.
- Ping: در دسترس بودن سرور در سطح شبکه. اگر فایروال سرور ICMP را مسدود کرده باشد، این مانیتور همیشه قطع نشان میدهد.
- DNS: بررسی میکند رکورد DNS به مقدار مورد انتظار اشاره میکند.
- Docker Container: وضعیت یک کانتینر روی همان سرور.
- Push: برعکس بقیه؛ سرویس شما باید بهطور منظم به یک آدرس خبر بدهد. اگر خبر نرسید، هشدار میدهد. برای کرونجابها و پشتیبانگیریها عالی است.
- HTTP و Keyword برای سایتها
- TCP Port برای SSH و دیتابیس
- DNS برای رکوردهای مهم
- Uptime Kuma خودش بررسی میکند
- کرونجاب و پشتیبانگیری
- اسکریپتهای دورهای
- سرویسهای پشت فایروال
- سرویس شما باید خبر بدهد
تنظیمات مهم هر مانیتور
- Heartbeat Interval: فاصلهٔ بررسی. فاصلهٔ خیلی کوتاه بار بیدلیل ایجاد میکند؛ برای بیشتر سایتها یک دقیقه مناسب است.
- Retries: چند بار پیاپی باید شکست بخورد تا وضعیت «قطع» اعلام شود. مقدار یک یا دو جلوی هشدارهای کاذب ناشی از یک خطای گذرای شبکه را میگیرد.
- Certificate Expiry Notification: در مانیتورهای HTTPS این گزینه را فعال کنید تا چند روز پیش از انقضای گواهی هشدار بگیرید. این بهترین بیمه در برابر مشکلات تمدید Let's Encrypt است.
- Accepted Status Codes: اگر صفحهای عمداً ریدایرکت میکند، کدهای مربوط را مجاز کنید یا مانیتور را روی آدرس نهایی بگذارید.
برای یک سایت معمولی چه مانیتورهایی بسازیم؟
یک مجموعهٔ پیشنهادی برای یک سایت فروشگاهی یا شرکتی روی یک سرور:
- صفحهٔ اصلی با Keyword: یک عبارت ثابت از فوتر یا عنوان سایت را بررسی کنید تا صفحهٔ خطای برنامه با کد 200 هم شناسایی شود.
- یک صفحهٔ پویا: مثلاً صفحهٔ جستوجو یا یک محصول که به دیتابیس وابسته است. اگر دیتابیس از کار بیفتد، صفحهٔ اصلی کششده ممکن است هنوز باز شود اما این صفحه نه.
- پورت SSH: برای اطمینان از اینکه سرور در سطح شبکه زنده است و میتوانید به آن وصل شوید.
- انقضای گواهی: روی مانیتور HTTPS اصلی فعال باشد.
- Push برای پشتیبانگیری: تا اگر پشتیبان شبانه اجرا نشد، صبح باخبر شوید.
اگر سایت پشت CDN است، یک مانیتور جداگانه هم مستقیم روی سرور اصلی بگذارید؛ مثلاً یک زیردامنهٔ بدون پروکسی یا آدرس سلامت مخصوص. اینطور وقتی خطایی رخ میدهد، فوراً میفهمید مشکل از CDN است یا از سرور. توضیح این تفکیک در مقالهٔ خطاهای 5xx در CDN آمده است.
اعلانها
از بخش Settings و سپس Notifications، روش اعلان را تعریف کنید. برای تلگرام:
- با BotFather یک ربات بسازید و توکن آن را بگیرید.
- به ربات پیام بدهید و شناسهٔ چت خود را پیدا کنید؛ Uptime Kuma در فرم تنظیم دکمهای برای پیدا کردن خودکار آن دارد.
- توکن و شناسه را وارد و دکمهٔ Test را بزنید.
گزینهٔ «Default enabled» را فعال کنید تا این اعلان روی همهٔ مانیتورهای جدید فعال باشد. بهتر است حداقل دو کانال اعلان داشته باشید؛ مثلاً تلگرام و ایمیل، تا اگر یکی در دسترس نبود، دیگری خبر برساند.
صفحهٔ وضعیت عمومی
Uptime Kuma میتواند یک صفحهٔ وضعیت عمومی بسازد که مشتریان ببینند کدام سرویسها سالماند. از بخش Status Pages یک صفحه بسازید، مانیتورهای عمومی را به آن اضافه کنید و در صورت قطعی، یک اطلاعیه منتشر کنید. این صفحه تعداد تیکتها و سؤالهای تکراری را هنگام قطعی کاهش میدهد. فقط مراقب باشید مانیتورهای داخلی، مثل دیتابیس یا آدرسهای مدیریتی، را در صفحهٔ عمومی قرار ندهید.
- سرور جداگانه
یک سرور کوچک مستقل از سرورهای تحت پایش.
- اجرای کانتینر
Compose با پورت روی 127.0.0.1 و volume داده.
- دامنه و HTTPS
Nginx با هدرهای WebSocket و گواهی Certbot.
- ساخت مانیتورها
HTTP با Keyword، هشدار گواهی و Retries مناسب.
- اعلان و تست
تلگرام و ایمیل؛ با دکمهٔ Test مطمئن شوید پیام میرسد.
پشتیبانگیری و بهروزرسانی
همهٔ دادهها در پوشهٔ /app/data داخل کانتینر و در volume ذخیره میشوند. از بخش Settings و سپس Backup میتوانید تنظیمات را به فایل JSON صادر کنید، اما مطمئنترین روش، پشتیبانگیری از خود volume است. برای بهروزرسانی:
cd ~/kuma
docker compose pull
docker compose up -d
پیش از بهروزرسانیهای بزرگ، یادداشتهای انتشار را بخوانید و از volume پشتیبان بگیرید.
سؤالات متداول
Uptime Kuma چقدر منابع مصرف میکند؟
بسیار کم. برای پایش دهها سایت، کوچکترین سرورها هم کافیاند. مصرف با تعداد مانیتورها و کوتاه بودن فاصلهٔ بررسیها بیشتر میشود؛ با docker stats میتوانید آن را ببینید.
چرا مانیتور Ping همیشه قطع نشان میدهد؟
احتمالاً فایروال سرور مقصد یا شبکهٔ بین راه، بستههای ICMP را مسدود میکند. بهجای Ping از مانیتور TCP Port روی پورت ۲۲ یا ۴۴۳ استفاده کنید که وضعیت واقعی سرویس را بهتر نشان میدهد.
چطور کرونجاب پشتیبانگیری را پایش کنم؟
یک مانیتور از نوع Push بسازید و در انتهای اسکریپت پشتیبانگیری، با curl آدرس Push را فراخوانی کنید. اگر پشتیبانگیری اجرا نشود یا وسط کار شکست بخورد، پس از مدت تعیینشده هشدار میگیرید.
آیا میتوانم Uptime Kuma را روی همان سرور سایت نصب کنم؟
از نظر فنی بله، اما اگر سرور خاموش شود یا شبکهاش قطع شود، مانیتور هم از کار میافتد و هشداری نمیفرستد. برای پایش واقعی، آن را روی سروری جداگانه اجرا کنید.
از ۱٬۲۰۰ تومان در ساعت · پرداخت ریالی



