- Головна
- Моніторинг
- Моніторинг TCP
Моніторинг TCP: чи сервіс досі приймає з’єднання?
За розкладом відкриваємо TCP-з’єднання з хостом і портом та записуємо, скільки триває рукостискання. Це та сама перевірка, що й моніторинг портів, описана для тих, хто шукає її саме як TCP.
- 30 моніторів безкоштовно
- Без банківської картки
- Збої підтверджуються з інших регіонів
- Amsterdam19мсвідкритий
- London28мсвідкритий
- Час з’єднання19 мс
- Порт25
- Таймаут10 с
Ілюстративний приклад
Перевірте просто зараз, прямо в браузері
Без реєстрації. Моніторинг TCP: введіть адресу й подивіться, що саме відстежує такий монітор. Нічого з введеного не зберігається.
Браузер не може відкрити сирі TCP-, UDP- чи ICMP-з’єднання, а публічний API перевірки говорить лише HTTP(S). Тож замість вигаданого результату ось команда, яку монітор автоматизує: він запускає її за розкладом з кількох регіонів і підтверджує збої.
Що саме перевіряє цей монітор
Вердикт дає рукостискання
Перевірка успішна, коли триетапне рукостискання завершилося. Після цього нічого не надсилається, тож сервіс оцінюють за тим, чи приймає він з’єднання, а не за тим, що відповідає.
Відмова чи мовчання
Відмова у з’єднанні означає, що хост живий, а сервіс не слухає. Таймаут означає, що пакети зникають дорогою. Інцидент називає, який із двох випадків у вас.
Будь-який порт на ваш вибір
Пошта на 25, 465 чи 993, SSH на 22, MySQL на 3306, Postgres на 5432, Redis на 6379 або власний адміністративний порт. Лише публічні хости: приватні діапазони відхиляються.
Історія часу з’єднання
Час кожного рукостискання зберігається, тож хост бази даних, який приймає з’єднання 400 мс, видно на графіку раніше, ніж він почне їх відхиляти.
Моніторинг TCP: як виглядає сповіщення
Та сама подія приходить листом, повідомленням у Telegram або карткою в Slack. Це текст, який надсилають канали; хост, час і числа вигадані.
mail.clienta.com:25
mail.clienta.com:25 · Connection refused on mail.clienta.com:25 · confirmed from Amsterdam (AMS), London (LON)
| Error | Connection refused on mail.clienta.com:25 |
|---|---|
| Confirmed by | Amsterdam (AMS), London (LON) |
| Since | 14:02:11 UTC |
| Target | mail.clienta.com:25 |
| Next step | Check the server / hosting panel. Acknowledge so the team knows you are on it. |
AcknowledgeOpen incident
Tenium · checked from Amsterdam · 14:02 UTC
Tenium alerts
🔴 DOWN · mail.clienta.com:25 · Connection refused on mail.clienta.com:25 · confirmed from Amsterdam (AMS), London (LON)
reply /ack or acknowledge · open incident
TTenium APP 2:02 PM
DOWN · mail.clienta.com:25
mail.clienta.com:25 · Connection refused on mail.clienta.com:25 · confirmed from Amsterdam (AMS), London (LON)
- Error: Connection refused on mail.clienta.com:25
- Confirmed by: Amsterdam (AMS), London (LON)
- Target: mail.clienta.com:25
Підтвердити отриманняOpen incident
Check the server / hosting panel. Acknowledge so the team knows you are on it. · checked from Amsterdam
Моніторинг TCP: e-mail, Discord і Google Chat працюють на всіх тарифах, Slack, Telegram, Teams і Mattermost — з тарифу Starter. SMS і голосових дзвінків немає.
Час відповіді з порогом
Кожна перевірка зберігає, скільки тривала відповідь. Моніторинг TCP: посуньте поріг і подивіться, коли б спрацювало сповіщення про повільну відповідь.
Як швидко ви дізнаєтеся
Оберіть тариф, щоб побачити його інтервал перевірки та скільки збій іде до вас, враховуючи підтвердження.
Моніторинг TCP: збій трапляється у випадковий момент між двома перевірками, тож у середньому ви чекаєте пів інтервалу, а в найгіршому випадку — повний інтервал плюс вікно підтвердження. Одного регіону з помилкою мало: інцидент відкривається, лише коли збій підтверджують обидва регіони. Інші регіони питаються одразу, на відповіді відведено до 60 секунд.
Як налаштувати моніторинг TCP за 30 секунд
Вкажіть адресу
Додайте ім’я хоста чи публічну IP-адресу й TCP-порт, а Tenium підставить розумний таймаут і стандартні налаштування підтвердження.
Оберіть інтервал
Найшвидший інтервал: 30 с на Pro й Agency, 1 хв на Starter, 5 хв на Free. Повільніші інтервали доступні на всіх тарифах.
Виберіть контакти для сповіщень
Оберіть, кому надсилати сповіщення. E-mail, Discord і Google Chat працюють на всіх тарифах, Slack, Telegram, Teams і Mattermost — з тарифу Starter, webhook — з Pro.
Збережіть
Перша перевірка запускається за лічені секунди. Якщо перевірка не пройде, інші регіони перевірять ще раз, перш ніж відкриється інцидент, тож один поганий маршрут вас не розбудить.
Що означає кожна помилка
Це текст, який інцидент показує в рядку «Error», типова причина й що перевірити першим.
ECONNREFUSEDConnection refused on mail.clienta.com:25
Хост працює, але на порту ніхто не слухає: служба впала або її не запускали. Цей збій діагностувати найшвидше.
Виглядає як: Connection refused on mail.clienta.com:25
TIMEOUTTimeout after 10 s connecting to mail.clienta.com:25
На SYN не відповіли. Фаєрвол відкидає пакети, хост перевантажений або група безпеки втратила адресу нашого перевіряльника.
Виглядає як: Timeout after 10 s connecting to mail.clienta.com:25
EHOSTUNREACHHost unreachable
До хоста немає маршруту: збій мережі або зміна маршрутизації між регіоном і вашим провайдером.
Виглядає як: Host unreachable
ECONNRESETConnection reset by peer
Хост прийняв з’єднання й одразу його розірвав, найчастіше через ліміт з’єднань або правило обмеження частоти.
Виглядає як: Connection reset by peer
ENOTFOUNDDNS lookup failed for mail.clienta.com
Ім’я не резолвиться. Перевірте запис, перш ніж звинувачувати службу.
Виглядає як: DNS lookup failed for mail.clienta.com
Моніторинг TCP: що входить у тарифи
| Free $0/міс. | Starter $7/міс. | Pro $29/міс. | Agency $59/міс. | |
|---|---|---|---|---|
| Доступно | ✓ | ✓ | ✓ | ✓ |
| Монітори | 30 | 100 | 300 | 1000 |
| Найшвидший інтервал | 5 хв | 1 хв | 30 с | 30 с |
| Регіони | 1 | 2 | 2 | 2 |
| Власні заголовки | — | — | ✓ | ✓ |
| Сповіщення про повільну відповідь | — | — | ✓ | ✓ |
| Ескалація на другий контакт | — | — | ✓ | ✓ |
| Сторінки статусу | 1 | 3 | 10 | Без обмежень |
Інші типи моніторів
Чому рукостискання — корисний, хоч і вузький сигнал
TCP-монітор робить одну річ: визначає адресу хоста, відхиляє приватні адреси, відкриває з’єднання з обраним портом і зупиняє відлік, коли рукостискання завершено. Після цього він не надсилає жодного байта й нічого не читає у відповідь. Тому однаково добре підходить для поштового сервера, бази даних, ігрового сервера чи SSH-бастіона: ні з одним із них не потрібно говорити його мовою.
Вузькість — це й обмеження. База даних, яка приймає з’єднання, але застрягла на відтворенні журналу, перевірку все одно пройде. Сприймайте TCP-перевірку як першу лінію, «хтось слухає», і додайте вищого рівня перевірку, де вона можлива: HTTP-перевірку для вебзастосунку, перевірку ключових слів для сторінки, що має відображатися, DNS-перевірку для нейм-сервера.
Які порти відстежують і що зазвичай означає збій
На кожному порту трапляються ті самі три результати, і вони вказують у різні боки. Скористайтеся списком причин нижче як порядком, у якому варто шукати, а не як вироком.
- Connection refused (відмова): хост працює, а сервіс не слухає. Процес впав, його зупинив деплой або після зміни конфігурації він слухає лише localhost.
- Таймаут: нічого не повернулося. Спершу думайте про фаєрвол чи групу безпеки, особливо після зміни адреси на боці перевіряльника (див. список IP-адрес перевіряльників), потім про перевантажений хост.
- Reset by peer: сервіс прийняв з’єднання й одразу його розірвав. Так поводяться ліміти з’єднань, правила на кшталт fail2ban і обмежувачі частоти запитів.
- Рукостискання повільне, але успішне: графік росте ще до того, як щось відмовляє. Хост бази даних із вичерпаними слотами черги часто годинами виглядає саме так.
Інтервали, регіони й тарифи
TCP-перевірки є на кожному тарифі. Free виконує їх кожні 5 хв, Starter — кожні 1 хв, а Pro і Agency — кожні 30 с. Перш ніж відкриється інцидент, збій перевіряють ще раз з інших робочих регіонів (зараз працюють 2 регіони), і для TCP це важливіше, ніж для HTTP: проблеми з транзитом між одним регіоном і вашим провайдером з цього регіону виглядають точно як мертвий сервіс.
Відкривати порт бази даних на весь інтернет лише заради моніторингу — невдалий обмін. Краще стежити за публічним сервісом перед нею, а білий список (allow-list) з адресами перевіряльників застосовувати лише до портів, які мають бути публічними, наприклад SMTP.
Запитання: моніторинг TCP
Чи відрізняється TCP-моніторинг від моніторингу портів?
Ні. Це та сама перевірка під назвою, яку багато хто шукає. [Сторінка про моніторинг портів](/monitoring/port) розповідає про ту саму функцію на прикладах із базами даних.
Чи можна перевірити, що сервіс відповідає правильно?
На рівні TCP ні. Він доводить лише те, що порт приймає з’єднання. Для доказу на рівні протоколу скористайтеся перевіркою HTTP, ключових слів чи DNS або heartbeat, який надсилає сам сервіс.
Чи працює це для UDP-сервісів?
Ні, у UDP немає рукостискання. Скористайтеся окремим [UDP-монітором](/monitoring/udp): він надсилає пробний пакет і чекає будь-якої відповіді.
Чи можна відстежувати приватну IP-адресу або сервіс за VPN?
Ні. Приватні діапазони відхиляються, бо регіони перевірки до них не дістають. Натомість налаштуйте heartbeat, який внутрішній сервіс надсилатиме в Tenium.
Почніть моніторинг TCP безкоштовно
30 моніторів на тарифі Free, без банківської картки, а збої підтверджуються з інших регіонів (зараз працюють 2 регіони). Переходьте на вищий тариф, коли клієнтів побільшає.