Моніторинг кінцевих точок

Що таке "endpoint"?

Endpoint — це все, що має адресу в інтернеті й може бути опитаним для перевірки доступності. Класичний випадок — це URL вебсторінки, але в сучасній інфраструктурі речі, за які ви відповідаєте, набагато різноманітніші: REST API, endpoint-и GraphQL, поштові сервери, лісенери баз даних, черги повідомлень, порти health-check контейнерів, внутрішні адміністративні панелі, отримувачі webhook-ів. DiagnoSEO Uptime Monitoring поводиться з ними однаково: ви визначаєте, що значить "здоровий" для цього endpoint-а, налаштовуєте розклад перевірок, отримуєте сповіщення при збої.

На цій сторінці описаний кожен тип endpoint-а, який підтримує цей інструмент, для чого підходить кожен і який сигнал дає моніторинг.

HTTP / HTTPS endpoint-и (вебсторінки)

Типовий випадок. Ви вводите https://example.com, і монітор виконує GET-запит з заданим інтервалом (1 хвилина, 5, 10, 30 або 60 хвилин залежно від плану). Успішна перевірка означає: встановлено TCP-з'єднання, handshake TLS завершено (для HTTPS), отримано HTTP-відповідь з очікуваним статус-кодом (типово: 2xx або 3xx), і, додатково, keyword присутній (або відсутній) у тілі відповіді. Перевірка фіксує Time To First Byte, загальний час відповіді, розмір контенту, ланцюжок редіректів і повний набір заголовків відповіді.

HTTP-endpoint-и є правильним вибором для: маркетингових сторінок, блогів, e-commerce магазинів, дашбордів SaaS, порталів документації — всюди, де люди заходять через браузер.

API endpoint-и (REST / GraphQL / JSON-RPC)

API вимагає більше, ніж просто "чи відповів" — потрібно "чи відповів правильно". Ви налаштовуєте монітор з кастомним HTTP-методом (GET, POST, PUT, DELETE, PATCH), кастомними заголовками (авторизаційні токени, content-type), тілом запиту (JSON-пейлоад для POST/PUT) і JSON-асерціями у відповіді (data.status має дорівнювати "ok", result.count має бути більше 0, errors[] має бути пустим). API, що повертає HTTP 200 з поламаним payload, — найгірший тип збою: виглядає здоровим для наївного монітора, але не працює для жодного клієнта. JSON-асерції це виявляють.

Дивіться окремий посібник з моніторингу API для деталей налаштування та синтаксису асерцій.

TCP-порти endpoint-и

Для не-HTTP послуг: SMTP (порт 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), лісенери баз даних (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), кастомні порти додатків. Монітор відкриває TCP-з'єднання до вказаного host:port і повідомляє про успіх, якщо з'єднання прийнято в межах timeout. Без handshake на рівні протоколу — просто "чи демон слухає".

Це правильний монітор для кожної TCP-служби, де вам важлива доступність і не потрібні перевірки, які розуміють протокол. Для перевірки SMTP-banner або запитів до бази даних використовуйте heartbeat-монітор (ваша служба пінгує нас, коли є здоровою; див. моніторинг cron-job / heartbeat).

Ping endpoint-и (ICMP)

Перевірка доступності на 3-му рівні. Монітор надсилає ICMP echo-запит на цільовий hostname або IP і чекає на відповідь. Корисно для роутерів, комутаторів, IoT-пристроїв, усього, що відповідає на ping, але не запускає HTTP. Зверніть увагу, що багато хмарних провайдерів (AWS, GCP, Azure) за замовчуванням блокують ICMP на рівні security-group, навіть коли хост сам по собі здоровий — для хмарних workload-ів віддавайте перевагу HTTP-перевіркам або TCP-портам.

Hostname / DNS endpoint-и

Моніторинг розв'язання DNS. Інструмент періодично розв'язує записи A, AAAA, MX, NS, TXT і CNAME вашого домену, робить знімок результатів і надсилає сповіщення, якщо щось змінюється. Виявляє: несанкціоноване захоплення DNS, випадкові конфігураційні помилки при міграції DNS-провайдера, зовнішні сервіси, що оновлюють свої endpoint-и без сповіщення (наприклад, коли ваш CDN перемикає IP-блоки), MX-записи, видалені через друкарську помилку.

Моніторинг DNS не про доступність — імовірно, ваш DNS-провайдер значно надійніший, ніж origin. Мова йде про виявлення змін. Дивіться моніторинг змін DNS для повного опису.

SSL-сертифікати endpoint-и

Кожен HTTPS-endpoint автоматично отримує моніторинг SSL поверх своєї перевірки uptime. Інструмент читає сертифікат, парсить термін дії й видавця, і попереджає за 30, 14, 7, 3 і 1 день до закінчення терміну дії. Дивіться моніторинг SSL-сертифікатів для деталей.

Endpoint-и закінчення терміну дії домену

Для кожного моніторингованого URL інструмент також опитує WHOIS раз на добу й відстежує дату закінчення реєстрації домену. Попередження спрацьовують на тих же порогах, що і SSL (30/14/7/3/1 днів). Несплата за продовження — катастрофа: домен стає без власника, і хтось може його зареєструвати після закінчення grace-періоду. Дивіться моніторинг закінчення терміну дії домену.

Вибір правильного типу endpoint-а

Якщо ви не знаєте, який тип моніторингу використати, почніть з HTTP/HTTPS для всього, що має веб-інтерфейс, TCP-порту для решти, та додайте heartbeat для batch-задач, які не мають жодної мережевої поверхні. Ви можете моніторити ту ж ціль декількома типами — наприклад, TCP-перевірка порту 443 помітить "сервер піднятий, але TLS-handshake зламаний", що й HTTP-перевірка на тому самому URL також позначить, а heartbeat з вашого власного внутрішнього агента моніторингу підтвердить, що логіка вашого застосунку дійсно працює.

Поширені запитання

• Що таке endpoint?

  Все, що має адресу в інтернеті: HTTP/HTTPS URL-и, REST API, TCP-порти (SMTP, MySQL, кастомні), host-и для ping, DNS-записи, SSL-сертифікати й дані реєстрації домену. Налаштуйте окремий монітор для кожного типу endpoint-а.

• Яку перевірку вибрати: HTTP чи TCP-порт?

  HTTP — це гарний вибір за замовчуванням для кожної веб-служби. TCP-порт краще підходить для не-HTTP сервісів (бази даних, поштові сервери, власні протоколи), де вас цікавить лише "чи демон приймає з'єднання". Використовуйте TCP для базового рівня доступності, HTTP для "чи застосунок реально правильно відповідає".

• Чим відрізняються монітори heartbeat (cron-job)?

  Heartbeat працює навпаки — замість того, щоб ми опитували вашу службу, ваша служба пінгує нас через відомий URL. Якщо ми не отримаємо ping у вказаний проміжок часу, то сповіщаємо. Використовується для cron job-ів, batch-процесів та всього, що працює за розкладом без зовнішньої мережевої поверхні.

• Чи може одна URL мати кілька моніторів?

  Так. Ви можете моніторити ту саму ціль різними типами перевірок — наприклад, HTTP-перевірка для повної доступності плюс TCP-перевірка порту 443, яка ловить проблеми з TLS-handshake. Кожен монітор працює незалежно й сповіщає окремо.

• Чи потрібно окремо моніторити SSL і домен?

  Ні — кожен HTTPS-endpoint автоматично отримує моніторинг SSL разом із перевіркою uptime, а кожен моніторингований URL отримує щоденне відстеження закінчення терміну дії домену. Обидві функції у комплекті, без додаткових налаштувань. Моніторинг домену здійснюється на рівні домену — декілька моніторів на одному домені спільно використовують дані WHOIS.