پایش نقطه پایانی

اندپوینت چیست؟

اندپوینت هر چیزی است که در اینترنت قابل آدرس‌دهی بوده و می‌توان برای بررسی دسترسی‌پذیری آن را استعلام کرد. حالت کلاسیک آن URL یک صفحه وب است — اما در زیرساخت‌های مدرن، مواردی که باید مراقب آن‌ها باشید بسیار متنوع‌تر هستند: REST API، اندپوینت‌های GraphQL، سرورهای ایمیل، لیسنرهای دیتابیس، صف‌های پیام، پورت‌های health-check کانتینرها، پنل‌های مدیریت داخلی، گیرنده‌های وب‌هوک. DiagnoSEO Uptime Monitoring همه این‌ها را به طور یکسان در نظر می‌گیرد: تعریف می‌کنید "سالم بودن" برای آن اندپوینت یعنی چه، زمان‌بندی بررسی‌ها را تنظیم می‌کنید، و در صورت خرابی هشدار دریافت می‌کنید.

این صفحه هر نوع اندپوینتی که ابزار پشتیبانی می‌کند، کاربرد مناسب هر نوع و سیگنال دریافتی از پایش آن را توضیح می‌دهد.

اندپوینت‌های HTTP / HTTPS (صفحات وب)

حالت پیش‌فرض. شما https://example.com را وارد می‌کنید و مانیتور در هر بازه مشخصی (۱ دقیقه، ۵، ۱۰، ۳۰ یا ۶۰ دقیقه بسته به پلن شما) درخواست GET ارسال می‌کند. بررسی موفق یعنی: اتصال TCP برقرار شده، handshake TLS به پایان رسیده (برای HTTPS)، پاسخ HTTP با کد وضعیت مورد انتظار (پیش‌فرض: 2xx یا 3xx) دریافت شده و به صورت اختیاری کلیدواژه‌ای در body پاسخ حضور دارد (یا حضور ندارد). بررسی، زمان Time To First Byte، مجموع زمان پاسخ، اندازه محتوا، زنجیره ریدایرکت‌ها و مجموعه کامل هدرهای پاسخ را ثبت می‌کند.

اندپوینت‌های HTTP انتخاب مناسبی برای: سایت‌های بازاریابی، وبلاگ‌ها، فروشگاه‌های اینترنتی، داشبوردهای SaaS، پورتال‌های مستندسازی — هر جایی که افراد با مرورگر بازدید می‌کنند، هستند.

اندپوینت‌های API (REST / GraphQL / JSON-RPC)

APIها به چیزی فراتر از "آیا پاسخ داده است" نیاز دارند — نیاز دارند به "آیا درست پاسخ داده است". مانیتور را با متد HTTP دلخواه (GET، POST، PUT، DELETE، PATCH)، هدرهای دلخواه (توکن احراز هویت، content-type)، بدنه درخواست (payload JSON برای POST/PUT) و assertionهای JSON روی پاسخ پیکربندی می‌کنید (data.status باید برابر با "ok" باشد، result.count باید بزرگ‌تر از ۰ باشد، errors[] باید خالی باشد). APIای که HTTP 200 با payload خراب برمی‌گرداند بدترین نوع خرابی است — برای مانیتور ساده سالم به نظر می‌رسد اما همه کلاینت‌ها را ناامید می‌کند. assertionهای JSON این را شناسایی می‌کنند.

برای جزئیات و نحوه پیکربندی و نگارش assertionها راهنمای مانیتورینگ API را ببینید.

اندپوینت‌های پورت TCP

برای سرویس‌های غیر HTTP: SMTP (پورت ۲۵ / ۵۸۷ / ۴۶۵)، POP3 (۱۱۰ / ۹۹۵)، IMAP (۱۴۳ / ۹۹۳)، لیسنرهای دیتابیس (PostgreSQL 5432، MySQL 3306، Redis 6379، MongoDB 27017)، SSH (۲۲)، FTP (۲۱)، پورت‌های دلخواه اپلیکیشن. مانیتور یک اتصال TCP به host:port داده‌شده برقرار می‌کند و اگر اتصال در بازه زمانی تایم‌اوت پذیرفته شد آن را موفق گزارش می‌کند. بدون handshake سطح پروتکل — صرفاً "آیا سرویس در حال گوش دادن است؟"

این مانیتور مناسب برای هر سرویس مبتنی بر TCP است که برای شما دسترسی اهمیت دارد و نیازی به بررسی پروتکل تخصصی ندارید. برای بررسی banner SMTP یا تست پرس و جو پایگاه داده از مانیتور heartbeat استفاده کنید (سرویس شما زمانی که سالم است ما را ping می‌کند – مراجعه کنید به cron-job / heartbeat monitoring).

اندپوینت‌های پینگ (ICMP)

بررسی دسترسی در لایه ۳. مانیتور یک درخواست ICMP echo به hostname یا IP مقصد ارسال می‌کند و منتظر پاسخ می‌ماند. مناسب برای روترها، سوییچ‌ها، دستگاه‌های IoT، و هر چیز دیگری که به پینگ جواب می‌دهد اما HTTP ندارد. توجه داشته باشید که بسیاری از ارائه‌دهندگان ابری (AWS، GCP، Azure) به طور پیش‌فرض ICMP را در سطح security-group مسدود می‌کنند حتی اگر هاست سالم باشد – برای بارکاری‌های ابری بررسی‌های HTTP یا پورت TCP را ترجیح دهید.

اندپوینت‌های hostname / DNS

پایش resolve شدن DNS. ابزار به صورت دوره‌ای رکوردهای A، AAAA، MX، NS، TXT و CNAME دامنه شما را resolve می‌کند، اسنپ شاتی از نتایج تهیه می‌کند و هر گونه تغییر را هشدار می‌دهد. می‌تواند موارد زیر را شناسایی کند: تصاحب غیرمجاز DNS، خطاهای تصادفی پیکربندی هنگام تغییر سرویس‌دهنده DNS، سرویس‌های خارجی که اندپوینت‌های خود را بدون اطلاع‌رسانی تغییر می‌دهند (مثلا CDN شما بلاک‌های IP را عوض می‌کند)، رکورد MX پاک شده به خاطر تایپ اشتباه.

پایش DNS برای دسترسی‌پذیری نیست — سرویس‌دهنده DNS شما تقریبا همیشه از origin قابل اطمینان‌تر است. موضوع تشخیص تغییر است. برای توضیح کامل، به مانیتورینگ تغییرات DNS مراجعه کنید.

اندپوینت‌های گواهی SSL

هر اندپوینت HTTPS به طور خودکار پایش SSL را همراه با بررسی uptime خود دریافت می‌کند. ابزار گواهی را خوانده، دوره اعتبار و صادرکننده را پارس می‌کند و در ۳۰، ۱۴، ۷، ۳ و ۱ روز مانده به انقضا هشدار می‌دهد. برای جزئیات بیشتر مانیتورینگ گواهی SSL را ببینید.

اندپوینت‌های انقضای دامنه

برای هر URL مورد پایش، ابزار هر روز یک بار WHOIS را استعلام می‌کند و تاریخ انقضای دامنه را دنبال می‌کند. هشدارها در همان بازه‌های زمانی مانند SSL (۳۰/۱۴/۷/۳/۱ روز) فعال می‌شوند. تمدید نشدن به موقع دامنه فاجعه‌بار است — دامنه بدون مالک شده و هر کسی می‌تواند در پایان دوره grace آن را ثبت کند. به مانیتورینگ انقضای دامنه مراجعه کنید.

انتخاب نوع مناسب اندپوینت

اگر نمی‌دانید کدام نوع مانیتور را انتخاب کنید، برای هر چیزی با رابط کاربری وب از HTTP/HTTPS شروع کنید، برای سرویس‌های دیگر از پورت TCP و برای وظایف batch که هیچ سطح شبکه‌ای ندارند، مانیتور heartbeat اضافه کنید. می‌توانید یک هدف را با چند نوع مانیتور کنید — مثلاً چک پورت TCP روی ۴۴۳ می‌تواند "سرور بالا است، اما TLS handshake مشکل دارد" را تشخیص دهد که بررسی HTTP روی همان URL هم شناسایی می‌کند، در حالی که heartbeat از عامل مانیتورینگ داخلی شما تایید می‌کند منطق اپلیکیشن شما واقعا کار می‌کند.

سوالات متداول

• اندپوینت چیست؟

  هر چیزی که در اینترنت قابل آدرس دادن است: HTTP/HTTPS URL ها، REST API، پورت‌های TCP (SMTP، MySQL، دلخواه)، hostname‌ها برای پینگ، رکوردهای DNS، گواهی‌های SSL و ورودی‌های ثبت دامنه. برای هر نوع اندپوینت یک مانیتور مجزا تنظیم کنید.

• از بررسی HTTP استفاده کنم یا پورت TCP؟

  HTTP یک انتخاب پیش‌فرض خوب برای هر سرویس وب است. پورت TCP برای سرویس‌های غیر HTTP (دیتابیس‌ها، سرور ایمیل، پروتکل‌های دلخواه) بهتر است که فقط به "آیا سرویس به اتصالات پاسخ می‌دهد" اهمیت دارید. برای دسترسی سطح پایین از TCP و برای "آیا اپلیکیشن واقعا به درستی پاسخ می‌دهد" از HTTP استفاده کنید.

• تفاوت مانیتورهای heartbeat (کرون جاب) چیست؟

  heartbeat برعکس است — به جای اینکه ما سرویس شما را استعلام کنیم، سرویس شما به یک URL مشخص به ما ping می‌زند. اگر پینگ را در بازه مورد انتظار نگیریم هشدار می‌دهیم. برای کرون جاب‌ها، فرآیندهای batch و هر چیزی که برنامه‌ریزی‌شده است و سطح شبکه برای بررسی ندارد، استفاده می‌شود.

• آیا یک URL می‌تواند چند مانیتور داشته باشد؟

  بله. می‌توانید یک هدف را با انواع مختلف بررسی مانیتور کنید — مثلا بررسی HTTP برای دسترسی جامع به اضافه بررسی TCP پورت ۴۴۳ که مشکلات TLS handshake را می‌گیرد. هر مانیتور مستقل عمل می‌کند و به صورت مجزا هشدار می‌دهد.

• آیا باید SSL و دامنه را جدا پایش کنم؟

  خیر — هر اندپوینت HTTPS به طور خودکار پایش SSL را همراه با بررسی uptime خود دریافت می‌کند و هر URL مورد پایش، پایش روزانه انقضای دامنه را دریافت می‌کند. هر دو در یک بسته و بدون پیکربندی اضافه انجام می‌شوند. پایش دامنه به ازای هر دامنه است — چند مانیتور روی یک دامنه داده‌های WHOIS را به اشتراک می‌گذارند.