Pemantauan Port

Selain HTTP: memantau bagian lain dari stack

Kebanyakan layanan yang menjalankan bisnis bukanlah web server. Database berjalan di 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Email lewat 25, 465, 587, 993, 995. SSH di 22. Server game ada di port yang dipilih penerbitnya. Layanan mikro internal di balik firewall - di port berapapun yang dikonfigurasikan oleh tim platform. Tidak ada yang pakai HTTP. Tidak akan terlihat di alat uptime website. Dan setiap kali salah satu berhenti mendengarkan, akan ada efek pada sesuatu yang terlihat.

Pemantauan port menutup celah ini. Anda memberikan host dan port ke monitor, dan pada setiap pengecekan akan dibuka koneksi TCP untuk memverifikasi apakah layanan mendengarkan. Jika koneksi gagal - karena daemon mati, firewall berubah, host down, jaringan antara kita dan layanan rusak - Anda mendapat pemberitahuan.

Apa yang bisa dipantau

• Database: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Server email: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Akses jarak jauh: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Transfer file: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Kustom atau internal: gateway GraphQL, gRPC, antrean (RabbitMQ 5672, Kafka 9092), pencarian (Elasticsearch 9200, Solr 8983), server game, perangkat IoT.

Cara kerja pengecekan

Monitor membuka koneksi TCP mentah ke host:port dengan timeout 5 detik. Jika menerima SYN/ACK - port dapat diakses dan layanan mendengarkan, check up. Jika connection refused, timeout, atau no route - check down, dan hasilnya akan tercatat pesan kesalahan dari kernel ("connection refused", "operation timed out", "no route to host") - memudahkan triage.

Monitor tidak mencoba berbicara dengan protokol aplikasi - tidak mengirimkan query SQL atau SMTP HELO. Ini menjaga pengecekan tetap cepat dan tanpa efek samping, yang penting saat Anda memeriksa 100 layanan setiap menit. Jika butuh verifikasi aplikasi, gabungkan pemantauan port dengan heartbeat atau monitor API buatan sendiri.

Menggabungkan dengan HTTP dan ping

Untuk setiap layanan publik, tiga monitor memberi tangga diagnosis yang jelas. Ping memastikan host hidup di jaringan. Monitoring port - layanan sedang mendengarkan. Monitoring HTTP / API - layanan merespons dengan benar. Ketika sesuatu gagal, lapisan yang gagal langsung menunjukkan area masalah. Hanya HTTP yang gagal - aplikasi crash. Port juga gagal - daemon mati. Ping juga mati - mesin hilang atau jaringan mati.

Konfigurasi

Buka alatnya, klik "Tambah monitor", pilih tipe "TCP port", tempelkan host (tanpa protokol), masukkan nomor port (1-65535) dan atur intervalnya. Simpan. Mulai siklus berikutnya, monitor akan membuka koneksi TCP setiap menit, mencatat round-trip, dan memberikan alarm begitu portnya tertutup - lewat Email, Telegram, Slack, Discord, atau SMS, dengan aturan konfirmasi ambang dan mode senyap malam yang sama.

Pertanyaan yang Sering Diajukan

• Port apa saja yang bisa saya pantau?

  Setiap port TCP dari 1 hingga 65535. Contoh kasus umum: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listener database (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), port aplikasi kustom.

• Apakah monitor mengecek kesehatan layanan atau hanya ketersediaan?

  Hanya ketersediaan — monitor membuka koneksi TCP dan memeriksa apakah daemon menerimanya. Tanpa handshake di tingkat protokol. Jika butuh pengecekan yang sadar protokol (misal verifikasi banner SMTP, balasan query database), gunakan pengecekan HTTP (untuk layanan HTTP) atau agen heartbeat yang di-host sendiri.

• Berapa timeout untuk pengecekan port?

  Default 10 detik. Dapat disesuaikan per monitor. Jika koneksi TCP tidak tersambung dalam waktu timeout, cek gagal dengan "connection timeout". Koneksi long-haul (misal pengecekan server di Asia dari Eropa) bisa butuh timeout lebih lama.

• Apakah saya bisa memantau port UDP?

  Saat ini belum bisa. UDP tidak tersambung — tidak ada padanan "connection accepted" untuk dicek. Layanan yang berbasis UDP biasanya butuh probe khusus protokol (misal query DNS untuk port 53, SNMP get untuk 161). Gunakan monitoring heartbeat sebagai gantinya.

• Apakah pemantauan port memperhitungkan peringatan TLS/SSL?

  Tidak — pengecekan port hanya mengecek ketersediaan TCP. Jika Anda ingin validasi sertifikat TLS di port, gunakan pengecekan HTTPS dengan port di URL (misal https://api.example.com:8443/) yang melakukan ketersediaan dan pengecekan sertifikat.