Tracker.ru / Документация

TCP-мониторинг: порттардың қолжетімділігін тексеру (SSH, MySQL, Redis және т.б.)

4 мин чтения
Обновлено 12 мая 2026

TCP-мониторинг — бұл HTTP-сұрау орнына нақты порттың TCP арқылы қолжетімділігін тексеру. Tracker.ru көрсетілген host:port жұбына TCP қосылу ашады және handshake сәтті өткенін тіркейді. Қосылым орнатылмаса — порт жабық, сервис тыңдамайды немесе желі қолжетімсіз — URL down күйіне ауысады, хабарламалар жіберіледі.

HTTP-мониторингтен айырмашылығы — мұнда статус-код те, жауап денесі де жоқ: біз «қосылым өтті / өтпеді» деген екілік жауап аламыз. Бұл фондық мәліметтер базасы, хабар кезегі немесе SMTP-сервері шынында да кіретін қосылымдарды қабылдайтынын растаудың ең тікелей тәсілі.

TCP-ні HTTP орнына қашан таңдау керек

TCP-мониторинг HTTP-тексеру не артық, не мүлдем жұмыс істемейтін есептер класын жабады:

  • Дерекқор HTTP бермейді. MySQL — 3306-да, PostgreSQL — 5432-де, Redis — 6379-да, MongoDB — 27017-де. Олардың өздерінің бинарлы протоколдары бар. Бұл порттарға HTTP-чек әрқашан қате қайтарады, TCP-чек шындықты айтады.
  • Кезектер мен брокерлер. RabbitMQ (5672), NATS (4222) — сол ой. Health-чек брокердің портты тыңдап тұрғанын растауы керек.
  • gRPC және кастом TCP-сервистер. TCP үстіндегі кез келген бинарлы протокол дәл осылай тексеріледі, HTTP-жауапты талдаусыз.
  • Пошта сервистері. SMTP (25, 587), IMAP (993), POP3 (995) — TCP-чек пошта серверінің көтеріліп, тиісті портты тыңдап тұрғанын растайды.
  • Басқару порттарының қолжетімділігі. SSH (22), FTP (21), DNS (53). Әсіресе көшіру, firewall жаңарту немесе бұлттағы инстанстарды ауыстырғаннан кейін пайдалы.
  • Шеткі сценарий: HTTPS пен SSH қатарлас. Бір сервер веб-ті де (443), SSH-ты да (22) қызмет ететін болса, 22-ге TCP-чек — сайт әлі жауап беріп тұрғанда админдік қолжетімділіктің жоғалғанын байқаудың жалғыз жолы.

Жұртшылыққа арналған веб-сайт немесе REST API туралы сөз болса — HTTP-мониторингте қалыңыз: ол көп ақпарат береді (status, headers, body-дегі keyword, скриншот).

Қолдау көрсетілетін порттар

UI және API-да Url::TCP_PRESETS ішіндегі 16 пресет қолдау көрсетіледі — TCP-бақылау нақты мағынаға ие ең жиі кездесетін порттар. Олардың кез келгенін бір шертумен таңдауға болады, не 1-ден 65535-ке дейінгі еркін нөмірді енгізуге болады.

Порт Сервис
21 FTP
22 SSH
25 SMTP
53 DNS
80 HTTP
443 HTTPS
587 SMTP (TLS)
993 IMAP (SSL)
995 POP3 (SSL)
3306 MySQL
4222 NATS
5432 PostgreSQL
5672 RabbitMQ
6379 Redis
8080 HTTP Alt
27017 MongoDB

80, 443, 8080 порттары тізімде әдейі тұр: кейде толыққанды HTTP-сұраусыз тек TCP-чек қажет (мысалы, рестарттан кейін nginx 443-ті тыңдап тұрғанын тексеру).

Қалай баптау керек

Жеке кабинетте «URL қосу» басып, мониторинг түрін TCP-ға ауыстырыңыз. Формада host пен port өрістері пайда болады — hostname-ді протоколсыз (db.example.com) және портты енгізіңіз. Тексеру кезеңі мен хабарлама арналары HTTP сияқты бапталады.

API арқылы:

curl -X POST https://tracker.ru/api/v1/urls \
  -H "Authorization: Bearer <api_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "db.example.com",
    "monitor_type": "tcp",
    "port": 3306,
    "period": 60,
    "notify_telegram": true
  }'

TCP-мониторлар үшін port өрісі міндетті (required|integer|min:1|max:65535); protocol өрісі — міндетті емес. http_method және expected_keyword өрістері TCP типі үшін еленбейді, оларды null ретінде беруге не түсіріп тастауға болады.

Тариф лимиттері HTTP-мониторингтегідей жұмыс істейді: TCP-чек әдеттегі URL ретінде есептеледі және тарифтің max_urls лимитін жұмсайды. Минималды кезеңді тариф анықтайды.

Не тексеріледі

Чекер TCP-қосылым ашады және handshake аяқталуын күтеді. Үш ықтимал нәтиже бар:

  • OK — handshake өтті, қосылым орнатылды. URL up күйінде.
  • tcp_refused — порт жабық (RST немесе connection refused алынды). Көбіне сервис құлағанын немесе портты тыңдамайтынын білдіреді.
  • timeout — handshake таймаутқа сыймады (әдепкі бойынша 60 секунд, custom_timeout арқылы реттеуге болады). Желілік блоктау, маршруттау мәселесі немесе қатты жүктелген сервер.
  • host_not_found — DNS hostname-ді шеше алмады. Қате жазу, жойылған DNS-жазба немесе резолвер мәселесі.

Бұл кодтардың әрқайсысы check_log.error_status-қа түседі және хабарламаларды құрастыруда және URL журналында қолданылады.

HTTP-тен айырмашылығы

TCP-мониторинг HTTP-тен әдейі қарапайым. TCP типі үшін қол жетпейтін:

  • HTTP-статус жоқ. Хабарламада «Status: 500» орнына TCP-қателіктің себебі көрсетіледі (tcp_refused, timeout, host_not_found).
  • Body жоқ. Сәйкесінше, keyword тексеру жоқ — expected_keyword өрісі TCP үшін еленбейді.
  • Скриншоттар жоқ. Скриншотты chromedp HTTP-URL бойынша жасайды, TCP-сервистің рендерленетін «беті» жоқ.
  • SSL-валидация жоқ. TCP handshake TLS-сертификатты ашпайды. SSL тексерулері (мерзімі, тізбектің жарамдылығы) тек HTTP/HTTPS-чектер үшін автоматты түрде орындалады. MySQL/Postgres сертификатын бақылау керек болса — сол сервердің ашық API-ы бойынша жеке HTTPS-мониторды қосыңыз.

Орнына TCP-чек:

  • Жылдамырақ. HTTP жіберусіз және парсингсіз бір SYN/SYN-ACK/ACK.
  • Стандартты емес протоколдар үшін сенімдірек. Жауапты түсіндіруге тырыспайды — «HTTP емес» payload себебінен жалған сигнал болмайды.
  • Сервис үшін арзанырақ. Тексерілетін серверге толыққанды HTTP-сұрауға қарағанда жүктеме аз.

Хабарламалар

TCP-мониторлар HTTP-пен бірдей арналар мен үлгілерді қолданады: Telegram, MAX, Email, Webhook. Алерт пішімі TCP ерекшелігін есептейді — хабарламада HTTP-кодтың орнына TCP-қателік коды мен мәтіндік сипаттамасы басылады:

Сайт қолжетімсіз! db.example.com:3306
Қателік: TCP connection refused
Қолжетімсіз 2026-05-01 19:15:09 бастап

Webhook-payload-да error_status өрісі tcp_refused, timeout, host_not_found мәндерін қабылдайды — бұл оркестрация жүйелерінде (PagerDuty, Opsgenie) алерттерді бағыттауға ыңғайлы. Қызмет көрсету терезелері және қалпына келу хабарламалары HTTP-мониторингтегідей жұмыс істейді.

Байланысты мақалалар