Мониторинг на портове

Извън HTTP: мониторинг на останалата част от стека

Повечето услуги, които поддържат бизнеса, не са уеб сървъри. Базите слушат на 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Пощата минава през 25, 465, 587, 993, 995. SSH е на 22. Игрните сървъри са на портове избрани от издателя. Вътрешни микросървиси зад firewall-а – на всичко, което е конфигурирал платформеният екип. Нито една от тях не говори по HTTP. Нито една няма да я видиш в инструмент за uptime на сайтове. И всяка, щом спре да слуша, повлича нещо видимо със себе си.

Мониторингът на портове запълва тази дупка. Давате на монитора хост и порт, и при всяка проверка се отваря TCP връзка за верифициране дали услугата слуша. Ако връзката се провали – защото демонът е паднал, firewall-ът се е сменил, хостът е долу, мрежата между нас и услугата е увредена – получаваш аларма.

Какво можеш да мониторираш

• Бази данни: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Пощенски сървъри: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Отдалечен достъп: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Трансфер на файлове: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Нетипични или вътрешни: GraphQL проксита, gRPC, опашки (RabbitMQ 5672, Kafka 9092), търсене (Elasticsearch 9200, Solr 8983), игрални сървъри, IoT устройства.

Как работи проверката

Мониторът отваря сурова TCP връзка до host:port с 5-секунден timeout. Ако върне SYN/ACK – портът е достъпен и услугата слуша, проверката е успешна. Ако connection refused, timeout или no route – проверката е неуспешна, а в резултат се записва ядреният error ("connection refused", "operation timed out", "no route to host") – по-лесно за диагностика.

Мониторът не опитва да комуникира по приложен протокол – не изпраща SQL заявки или SMTP HELO. Това държи проверката бърза и без странични ефекти, което е важно, ако проверяваш 100 услуги всяка минута. Ако ти трябва приложна верификация, комбинирай мониторинга на порт с heartbeat или собствен API монитор.

Комбиниране с HTTP и ping

За всяка публична услуга три монитора дават чиста диагностична стълбица. Ping потвърждава, че хостът е жив в мрежата. Мониторингът на порт – услугата слуша. Мониторингът HTTP / API – услугата отговаря коректно. Когато нещо падне, падащият слой веднага казва къде да се търси. Само HTTP пада – приложението се срине. Портът също пада – демонът е паднал. Ping също – кутията е изчезнала или мрежата е паднала.

Конфигурация

Отвори инструмента, кликни "Добави монитор", избери тип "TCP port", постави хоста (без протокол), въведи номер на порт (1-65535) и настрои интервала. Запиши. От следващия цикъл мониторът всяка минута отваря TCP връзка, записва round-trip, и алармира в секундата, в която портът се затвори – чрез Email, Telegram, Slack, Discord или SMS, със същите правила за потвърждение и заглушаване през нощта.

Често задавани въпроси

• Кои портове мога да наблюдавам?

  Всеки TCP порт от 1 до 65535. Разпространени случаи: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), слушалки на бази данни (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), собствени портове на приложения.

• Дали мониторът проверява дали услугата е здрава или само достъпна?

  Само достъпност — мониторът отваря TCP връзка и проверява дали демонът я приема. Без handshake на ниво протокол. Ако ти трябва проверки, осъзнаващи протокола (например верификация на SMTP банер, отговор от базата данни), използвай HTTP check (за HTTP услуги) или self-hosted агент heartbeat.

• Какъв е timeout-ът за порт чекове?

  По подразбиране 10 секунди. Може да се настрои за всеки монитор. Ако TCP връзката не се установи в прозореца на timeout-а, проверката се проваля с "connection timeout". Връзки на големи разстояния (например проверка на сървър в Азия от Европа) може да изискват по-дълъг timeout.

• Мога ли да наблюдавам UDP портове?

  В момента не. UDP е безсесийна — няма еквивалент на "connection accepted" за проверка. Услугите, базирани на UDP, обикновено изискват специфични проби по протокол (напр. DNS заявка за порт 53, SNMP get за 161). Използвай heartbeat мониторинг вместо това.

• Следи ли мониторингът на портове за TLS/SSL предупреждения?

  Не — портовите чекове са чиста TCP достъпност. Ако искаш валидиране на TLS сертификат на порта, използвай HTTPS check с порта в URL-a (напр. https://api.example.com:8443/), който прави и достъпност, И проверка на сертификата.