Мониторинг на крайни точки

Какво е "endpoint"?

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

Тази страница описва всеки тип endpoint, който инструментът поддържа, за какво е подходящ и какъв сигнал дава мониторингът.

HTTP / HTTPS endpoint-и (уебстраници)

Стандартният случай. Въвеждаш https://example.com и мониторът прави GET заявка на определен интервал (1 минута, 5, 10, 30 или 60 минути — според плана). Успешната проверка означава: установена TCP връзка, приключен TLS handshake (за HTTPS), получен HTTP отговор с очаквания статус код (по подразбиране: 2xx или 3xx), и по желание — ключова дума налична (или липсваща) в body на отговора. Проверката записва Time To First Byte, общо време за отговор, размер на съдържанието, верига от пренасочвания и пълен набор response headers.

HTTP endpoint-ите са правилният избор за: маркетингови сайтове, блогове, онлайн магазини, SaaS dashboard-и, портали с документация — навсякъде, където хората посещават с браузър.

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

API-тата изискват нещо повече от "дали отговарят" — искат "дали отговарят коректно". Конфигурираш монитор с избран HTTP метод (GET, POST, PUT, DELETE, PATCH), потребителски headers (auth tokens, content-type), request body (JSON payload за 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), database listener-и (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), потребителски портове на приложения. Мониторът отваря TCP връзка към зададения host:port и отчита успех, ако връзката е приета в рамките на timeout прозореца. Без handshake на ниво протокол — просто "дали демонът слуша".

Това е подходящият монитор за всяка TCP-базирана услуга, където има значение наличността, но не ти трябва преглед на протоколно ниво. За верификация на SMTP banner или проверки чрез заявка към база данни ползвай heartbeat монитор (твоята услуга праща сигнал, когато е здрава — виж cron-job / heartbeat monitoring).

Ping endpoint-и (ICMP)

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

Hostname / DNS endpoint-и

Мониторинг на DNS резолюция. Инструментът периодично резолвва A, AAAA, MX, NS, TXT и CNAME записи на твоя домейн, прави snapshot на резултатите и алармира при промяна. Хваща: неоторизирано поемане на 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, собствени), хостнейми за ping, DNS записи, SSL сертификати и WHOIS записи за домейни. Конфигурирай по един монитор за всеки тип endpoint.

• Да използвам HTTP проверка или TCP порт?

  HTTP е добрият стандартен избор за всяка уеб услуга. TCP порт е по-подходящ за не-HTTP услуги (бази данни, мейл сървъри, собствени протоколи), когато ти трябва само "дали демонът приема връзки". Използвай TCP за ниско ниво на наличност, HTTP — за "дали приложението наистина отговаря коректно".

• Как се различават heartbeat мониторите (cron-job)?

  Heartbeat мониторът е обърнат — вместо ние да проверяваме твоята услуга, твоята услуга праща signal към нас на известен URL. Ако не получим сигнал навреме, изпращаме аларма. Използва се за cron job-и, batch процеси и всичко, което работи по график, без да има мрежов интерфейс за проверка.

• Може ли един URL да има няколко монитора?

  Да. Можеш да следиш една и съща цел с различни видове проверки — например HTTP проверка за пълна достъпност плюс TCP порт 443, който засича проблеми с TLS handshake. Всеки монитор работи независимо и алармира самостоятельно.

• Трябва ли да наблюдавам SSL и домейна поотделно?

  Не — всеки HTTPS endpoint автоматично получава SSL мониторинг върху своя uptime check, а всеки наблюдаван URL има ежедневно проследяване на изтичането на домейна. Двете са включени, без допълнителна конфигурация. Домейн мониторингът е per-domain — няколко монитора на един и същи домейн споделят WHOIS данните.