مانیتورینگ سرور با Uptime Kuma؛ هشدار داون شدن از داخل ایران

ابزار Uptime Kuma یک سامانه مانیتورینگ متن‌باز است که خودتان نصب می‌کنید و دسترس‌پذیری سرویس را فقط از همان نقطه نصب می‌سنجد. همین نکته چهار تصمیم این آموزش را می‌سازد: ناظر کجا نصب شود، چه نوع مانیتوری بسازید، بازه و تلاش مجدد چقدر باشد و هشدار از چه مسیری برسد. «ناظر» یعنی نمونه نصب‌شده و «مانیتور» یعنی هر بررسی تعریف‌شده در آن.

تصمیم	گزینه‌ها	انتخاب پیشنهادی	دلیل
محل نصب ناظر	همان سرور، سرور دوم داخلی، سرور بیرون از ایران	سرور دوم داخلی و یک نقطه دید بیرونی	ناظر روی سرور قطع‌شده هم خاموش می‌شود
روش نصب	داکر، نصب دستی با Node.js	داکر با یک volume نام‌دار	روش رسمی مخزن، با به‌روزرسانی ساده
نوع مانیتور	HTTP(s)، Keyword، TCP، Ping، DNS، Push	کلیدواژه برای سایت، Ping برای شبکه	کد 200 صفحه سفید را هم می‌پوشاند
بازه و تلاش مجدد	20 ثانیه تا چند دقیقه	60 ثانیه با 3 تلاش مجدد	بازه کوتاه بدون تلاش مجدد هشدار اشتباه می‌دهد
مسیر هشدار	ایمیل SMTP، پیام‌رسان یا پیامک	کانالی با نقطه پایانی در دسترس	هشداری که نرسد، فایده‌ای ندارد

نصب این ابزار کمتر از نیم ساعت وقت می‌گیرد؛ چیزی که وقت می‌برد، تصمیم‌های بعد از نصب است. پس ترتیب کار را همان‌طور نگه می‌داریم که در عمل پیش می‌آید. اول جای ناظر، بعد نصب و اولین مانیتور. سپس تنظیم‌هایی که هشدار اشتباه را کم می‌کنند و آخر، مسیر رسیدن هشدار و صفحه وضعیت عمومی. 👇

جای نصب Uptime Kuma؛ ناظر را کجا بگذاریم؟

میزبان ناظر باید از سرویس تحت نظر مستقل باشد. مانیتوری که روی همان سرور سایت اجرا می‌شود، در لحظه ریبوت یا قطعی برق سرور با خودش خاموش می‌شود و هیچ هشداری نمی‌فرستد. نکته دوم مهم‌تر است: هر مانیتور فقط می‌گوید سرویس «از دید همان نقطه شبکه» در دسترس بوده، نه از دید همه کاربران.

چرا نصب روی سرور تحت نظر جواب نمی‌دهد

ناظر محلی دو چیز مهم را نمی‌بیند: قطعی خود سرور و خرابی مسیر شبکه تا دیتاسنتر. اگر تنها به آن تکیه کنید، وقتی سایت از بیرون باز نمی‌شود داشبورد همه‌چیز را سبز نشان می‌دهد. برای منابع داخلی مانند CPU و رم ابزارهای دیگری مناسب‌ترند؛ آموزش مانیتورینگ منابع سرور با Netdata و Glances همان بخش از ماجرا را پوشش می‌دهد.

سه گزینه برای میزبانی ناظر و تفاوتشان

• روی همان سرور تحت نظر: فقط برای تست. در قطعی واقعی ساکت است.
• روی سرور دومی داخل ایران: نزدیک‌ترین دید به کاربر ایرانی و مستقل از اختلال مسیر بین‌الملل، چون مسیر ناظر داخل شبکه کشور می‌ماند.
• روی سروری بیرون از ایران: دید کاربر خارجی را نشان می‌دهد، اما در اختلال مسیر بین‌الملل سرویس سالم را «داون» گزارش می‌کند.
• روی رایانه شخصی: خاموشی شبانه، تاریخچه آپتایم را بی‌معنا می‌کند.

ترکیب دوم و سوم بهترین نتیجه را می‌دهد: ناظر اصلی روی سروری کم‌منبع داخل ایران و یک نمونه دوم بیرون. برای ناظر داخلی یک سرور مجازی ایران با IP مستقیم کافی است؛ بار این ابزار سبک است.

دو نقطه دید و خواندن درست نتیجه

دو ناظر تنها وقتی ارزش دارند که نتیجه‌شان را کنار هم بخوانید. جدول زیر کار دقیقه اول حادثه را نشان می‌دهد.

ناظر داخل ایران	ناظر بیرون از ایران	تفسیر	اقدام اول
سالم	داون	مسیر بین‌الملل مشکل دارد و سرویس روی سرور بالاست	مسیر و اعلان دیتاسنتر را ببینید؛ سرویس را ریستارت نکنید
داون	داون	خود سرور، سرویس یا دیتاسنتر مشکل دارد	کنسول و وضعیت سرویس را ببینید و تیکت بزنید
داون	سالم	مسیر داخلی یا فایروال مشکل دارد	از چند شبکه داخلی تست کنید و فایروال را ببینید
سالم	سالم	سرویس بالاست؛ مشکل از DNS، مرورگر یا شبکه کاربر است	رکوردهای DNS و گزارش کاربر را بررسی کنید

نصب Uptime Kuma با داکر و امن‌کردن دسترسی از قدم اول

مخزن رسمی اجرای یک کانتینر داکر با پوشه داده جداگانه را پیشنهاد می‌کند و پنل روی پورت 3001 بالا می‌آید. یک نکته امنیتی را جا نیندازید: صفحه راه‌اندازی بدون احراز هویت است و اولین کسی که به پورت 3001 برسد مدیر می‌شود.

پیش‌نیازها و محدودیت‌های رسمی پروژه

• نصب بدون داکر به Node.js نسخه 20.4 یا بالاتر، Git و معمولاً pm2 نیاز دارد.
• سیستم‌عامل: توزیع‌های اصلی لینوکس و همچنین ویندوز 10 و ویندوز سرور 2012 R2 به بالا.
• فایل‌سیستم NFS برای پوشه داده پشتیبانی نمی‌شود؛ آن را روی دیسک محلی نگه دارید.
• خانواده BSD شامل FreeBSD، OpenBSD و NetBSD پشتیبانی نمی‌شود.

دستور نصب؛ ابتدا فقط روی localhost

خود README دو شکل از این دستور را می‌دهد. شکل رایج با -p 3001:3001 پنل را روی همه اینترفیس‌های شبکه منتشر می‌کند. شکل دوم، که README آن را برای محدودکردن دسترسی به لوکال‌هاست پیشنهاد می‌کند، -p 127.0.0.1:3001:3001 است. با وجود صفحه راه‌اندازی بی‌رمز، از همین شکل دوم شروع کنید:

docker run -d --restart=always -p 127.0.0.1:3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2

نام volume را عوض نکنید؛ تاریخچه و تنظیم‌ها همان‌جا می‌ماند. تگ 2 شاخه اصلی فعلی پروژه است و آخرین نسخه پایدار علامت‌خورده در صفحه انتشارهای مخزن، نسخه 2.5.0 است (بررسی مهر 1405).

وب‌سرور و گواهی TLS، پیش از اولین ورود

حالا پنل فقط از خود سرور در دسترس است و فرصت دارید مسیر امن را بسازید. یک وب‌سرور مثل nginx را با گواهی TLS روی دامنه خودتان بالا بیاورید و درخواست را به 127.0.0.1:3001 بفرستید. این پنل روی WebSocket کار می‌کند، پس اگر هدرهای Upgrade و Connection را پاس ندهید، بعد از ورود داشبورد خالی می‌ماند.

ورود اول و ورود دو مرحله‌ای

نشانی https دامنه خود را باز کنید و حساب مدیر را بسازید، بعد ورود دو مرحله‌ای را از تنظیم‌های حساب فعال کنید. این پنل به توکن همه کانال‌های اطلاع‌رسانی دسترسی دارد، پس دسترسی به آن هم‌ارز زیرساخت است.

اجرا با داکر کمپوز

mkdir uptime-kuma
cd uptime-kuma
curl -o compose.yaml https://raw.githubusercontent.com/louislam/uptime-kuma/master/compose.yaml
docker compose up -d

فایل کمپوز رسمی چهار کلید دارد: image: louislam/uptime-kuma:2، restart: unless-stopped، نگاشت پورت 3001:3001 و یک bind mount به ./data:/app/data. نام کانتینر و volume نام‌دار ندارد، پس داده در پوشه data کنار همان فایل می‌نشیند. برای محدودکردن دسترسی، خط پورت را 127.0.0.1:3001:3001 بگذارید. اگر دریافت تصویر خطا داد، میرور داخلی رجیستری را در /etc/docker/daemon.json با کلید registry-mirrors معرفی کنید و داکر را ری‌استارت کنید.

به‌روزرسانی نسخه داکری

برای مسیر docker run، به‌روزرسانی سه دستور است: دریافت تصویر، حذف کانتینر و اجرای دوباره همان دستور با همان volume. در کمپوز، docker compose pull و سپس docker compose up -d --force-recreate کافی است. سوئیچ -v را به docker rm اضافه نکنید و مسیر داده را عوض نکنید. پیش از ارتقای نسخه اصلی اسنپ‌شات بگیرید؛ بازگشت به نسخه پایین‌تر بعد از مهاجرت پایگاه داده مسیر رسمی ندارد.

docker pull louislam/uptime-kuma:2
docker stop uptime-kuma && docker rm uptime-kuma
# سپس همان دستور docker run با همان volume را اجرا کنید

انتخاب نوع مانیتور و تنظیم بازه، تلاش مجدد و تایم‌اوت

نوع مانیتور تعیین می‌کند چه چیزی را «سالم» می‌نامید و پنج تنظیم تعیین می‌کند چه زمانی هشدار می‌دهید. نوع‌های فهرست‌شده در مخزن رسمی: HTTP(s)، TCP، HTTP(s) Keyword، HTTP(s) JSON Query، WebSocket، Ping، DNS Record، Push، Steam Game Server و کانتینر داکر.

کلیدواژه و JSON Query در برابر کد 200

یک صفحه می‌تواند کد 200 برگرداند و در عمل خطای دیتابیس یا صفحه سفید نشان دهد. مانیتور کلیدواژه داخل پاسخ دنبال رشته‌ای مشخص می‌گردد، مثل نام دکمه «افزودن به سبد خرید»؛ برای APIها نوع JSON Query همین کار را روی یک کلید از پاسخ JSON می‌کند. کلیدواژه را از بخشی بردارید که با تغییر قالب عوض نشود.

پنج تنظیمی که هشدار اشتباه را کم می‌کنند

در Uptime Kuma این فیلدها با همین نام‌ها در پنل می‌آیند. شرح رسمی Retries در فایل زبان پروژه: «بیشترین تعداد تلاش مجدد پیش از آنکه سرویس داون علامت بخورد و هشدار فرستاده شود».

فیلد	کار آن	پیشنهاد عملی
Heartbeat Interval	فاصله بررسی‌ها	60 ثانیه برای سایت و API؛ بازه‌های چندثانیه‌ای را فقط برای سرویس بحرانی نگه دارید
Retries	تلاش مجدد پیش از علامت داون و ارسال هشدار	2 یا 3؛ صفر یعنی هر لرزش شبکه یک هشدار است
Retry every	فاصله تلاش‌های مجدد	20 تا 60 ثانیه
Request Timeout	چند ثانیه منتظر پاسخ می‌ماند	دو تا سه برابر زمان پاسخ عادی، با سقف 80٪ بازه
Resend every	تکرار هشدار داون پس از چند بررسی	عددی که یادآور باشد، نه پیام تکراری؛ قابل غیرفعال‌کردن

حساب ساده تأخیر هشدار

تأخیر هشدار دو تکه است: تأخیر کشف تا یک بازه کامل، و تأخیر تأیید که حاصل‌ضرب تعداد تلاش مجدد در فاصله آن‌هاست. با بازه 60 ثانیه، سه تلاش مجدد و فاصله 60 ثانیه، تأیید 180 ثانیه می‌برد. کشف قطعی هم تا 60 ثانیه تأخیر دارد، پس هشدار سه تا چهار دقیقه بعد از قطعی می‌رسد. اگر این تأخیر زیاد است، فاصله تلاش مجدد را کم کنید نه تعدادش را. یک محدودیت سخت را هم بدانید: تایم‌اوت هرگز بیش از 80٪ بازه اعمال نمی‌شود و مقدار صفر یعنی همان 80٪؛ با بازه 20 ثانیه و تایم‌اوت 30، بی‌اعلام 16 ثانیه می‌گیرید.

مانیتور Push برای کارهای زمان‌بندی‌شده

نوع Push منطق را برعکس می‌کند: ناظر منتظر می‌ماند تا سرویس خودش درخواستی به نشانی اختصاصی بفرستد و اگر در بازه مقرر نیامد، هشدار می‌دهد. همین را برای بکاپ شبانه و کرون‌جاب لازم دارید؛ بدون آن، شکست خاموش کرون‌جاب هفته‌ها دیده نمی‌شود.

حالت Upside Down و هشدار گواهی

گزینه Upside Down Mode وضعیت را برعکس می‌کند؛ شرح رسمی‌اش می‌گوید اگر سرویس در دسترس باشد، نتیجه داون است. کاربردش جایی است که انتظار دارید چیزی بسته باشد، مثل پورتی که نباید باز باشد. برای سایت HTTPS هم هشدار انقضای گواهی را روشن کنید و نادیده‌گرفتن خطای TLS را فقط برای گواهی داخلی به کار ببرید.

مسیر هشدار و صفحه وضعیت عمومی

هشدار وقتی ارزش دارد که به دست آدم بیدار برسد. مخزن رسمی از پشتیبانی بیش از نود کانال می‌گوید و در فهرست کد منبع نسخه فعلی صد و نه سرویس ثبت شده است. معیار انتخاب یک چیز است: نقطه پایانی کانال از محل ناظر در دسترس باشد.

کانال هشدار را از روی نقطه پایانی‌اش انتخاب کنید

هر کانال پیام را به یک نشانی API می‌فرستد و اگر آن نشانی از سرور ناظر در دسترس نباشد، هشدار به مقصد نمی‌رسد. برای ناظر داخل ایران، کانال‌های با نقطه پایانی داخلی منطقی‌ترند. در کد منبع Uptime Kuma سه نمونه ثبت شده است:

• کانال بله: پیام را به https://tapi.bale.ai/bot{token}/sendMessage می‌فرستد و توکن بات و شناسه چت می‌خواهد.
• کانال sms.ir: درخواست را به https://api.sms.ir/v1/send/verify می‌فرستد و کلید API، شناسه قالب و شماره موبایل می‌خواهد. چون با قالب تاییدشده کار می‌کند متن آزاد نیست، و سقف پیام در کد این کانال 20 کاراکتر است؛ پیام بلندتر اول بی‌فاصله و بعد بریده می‌شود، پس نام مانیتورها را کوتاه بگذارید.
• کانال آموت اس ام اس هم در همین فهرست هست.

ایمیل SMTP؛ ساده‌ترین مسیر قابل اتکا

کانال SMTP را به سرویس ایمیل خودتان وصل کنید. ایمیل هشدار باید از دامنه‌ای برود که SPF و DKIM دارد، وگرنه در اسپم می‌نشیند؛ سرور ناظر هم باید به پورت خروجی SMTP آن سرویس برسد. یک تست دستی بفرستید و رسیدنش را در اینباکس ببینید، نه در لاگ.

صفحه وضعیت عمومی و بازه تعمیر

صفحه وضعیت، فهرست منتخبی از مانیتورها را به شکل عمومی نشان می‌دهد و پروژه چند صفحه وضعیت و اتصال هر صفحه به دامنه اختصاصی را پشتیبانی می‌کند. فایده واقعی‌اش کم شدن تماس‌ها در زمان حادثه است. دو قاعده این صفحه را کاربردی می‌کند. فقط سرویس‌هایی را نشان دهید که کاربر با آن‌ها کار می‌کند و نامشان را به زبان کاربر بنویسید، نه به زبان زیرساخت. پیش از هر تغییر برنامه‌ریزی‌شده هم یک بازه تعمیر ثبت کنید تا تاریخچه آپتایم با قطعی عمدی خراب نشود. برای فهم همین عددها آپتایم چیست نقطه شروع خوبی است.

سوال‌های پرتکرار درباره پایش آپتایم و هشدار قطعی

جمع‌بندی؛ مانیتورینگ درست با Uptime Kuma
نصب کانتینر و ساختن اولین مانیتور کمتر از نیم ساعت است، اما ارزش کار به چهار تصمیم بعدی بسته است. اول اینکه ناظر را روی سروری مستقل از سرویس تحت نظر بگذارید و دو نقطه دید داشته باشید، یکی داخل شبکه کشور و یکی بیرون؛ هر مانیتور تنها دسترس‌پذیری از جای خودش را گزارش می‌کند. دوم اینکه نوع مانیتور را با معنای واقعی «سالم» هم‌تراز کنید؛ کلیدواژه برای صفحه‌های مهم و Push برای کارهای زمان‌بندی‌شده. سوم اینکه بازه، تلاش مجدد و تایم‌اوت را با آگاهی از تأخیری که می‌سازند تنظیم کنید، چون هشدار اشتباه در هفته دوم باعث می‌شود اعلان‌ها را بی‌صدا کنید. چهارم اینکه کانال هشدار را از روی در دسترس بودن نقطه پایانی‌اش انتخاب کنید و رسیدن پیام را دستی تست کنید. اگر این چهار تصمیم را یک بار درست بگیرید، آن وقت می‌توانید به داشبورد خود تکیه کنید.

اگر سوالی داشتید، در بخش نظرات با ما در ارتباط باشید.

• مخزن رسمی پروژه در گیت‌هاب (نصب، پیش‌نیازها، فهرست امکانات و محدودیت‌ها)
• فایل زبان رسمی پروژه (شرح فیلدهای Retries، Heartbeat Interval، Request Timeout و Upside Down Mode)
• کد کانال اطلاع‌رسانی بله در مخزن پروژه
• کد کانال پیامکی sms.ir در مخزن پروژه
• صفحه انتشارهای رسمی پروژه (نسخه پایدار علامت‌خورده)