Vilka portar kan jag övervaka?

Varje TCP-port från 1 till 65535. Vanliga fall: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), databaslyssnare (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), anpassade applikationsportar.

Kontrollerar monitorn om tjänsten är frisk eller bara tillgänglig?

Bara tillgänglighet – monitorn öppnar en TCP-anslutning och ser om demon accepterar den. Ingen handskakning på protokollnivå. Behöver du protokollmedvetna kontroller (t.ex. verifiering av SMTP-banner, svar på databasfråga), använd en HTTP-check (för HTTP-tjänster) eller self-hosted heartbeat-agent.

Vad är timeout för portkontroller?

Standard är 10 sekunder. Kan ställas in per monitor. Om TCP-anslutningen inte etableras inom timeoutfönstret, misslyckas kontrollen med "connection timeout". Long-haul-förbindelser (t.ex. kontroll av server i Asien från Europa) kan kräva längre timeouter.

Kan jag övervaka UDP-portar?

Inte för närvarande. UDP saknar anslutning – det finns ingen motsvarighet till "connection accepted" att testa. UDP-baserade tjänster kräver vanligtvis protokollspecifika tester (t.ex. DNS-fråga för port 53, SNMP get för 161). Använd heartbeat-övervakning istället.

Räknas portövervakning som TLS/SSL-varningar?

Nej – portkontroller mäter endast TCP-tillgänglighet. Vill du validera TLS-certifikat på porten, använd en HTTPS-kontroll med port i URL (t.ex. https://api.example.com:8443/) som gör både tillgänglighets- och certifikatskontroll.

TCP-portövervakning – databaser, e-post, tjänster

Bekräfta att kritiska tjänster lyssnar – inte bara din webbserver. Övervaka valfri TCP-port på valfri värd.

Utöver HTTP: övervakning av resten av stacken

De flesta tjänster som håller igång företaget är inte webbservrar. Databaser lyssnar på 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Mejl går via 25, 465, 587, 993, 995. SSH på 22. Spelservrar använder portar som utgivaren valt. Interna mikrotjänster bakom brandväggen – på vad plattformsteamet har konfigurerat. Ingen av dessa talar HTTP. Du ser ingen av dem i ett sid-uptimeverktyg. Och var och en, när den slutar lyssna, tar något synligt med sig.

Portövervakning lagar det här hålet. Du anger monitorns värd och port, och vid varje kontroll öppnas en TCP-anslutning som verifierar om tjänsten lyssnar. Om anslutningen misslyckas – för att daemonen har kraschat, brandväggen ändrats, värden är nere, eller nätverket mellan oss och tjänsten är trasigt – får du en varning.

Vad du kan övervaka

Databaser: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
Mailservrar: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
Fjärråtkomst: 22 (SSH), 3389 (RDP), 5900 (VNC).
Filöverföring: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
Specialanpassade eller interna tjänster: GraphQL-gateways, gRPC, köer (RabbitMQ 5672, Kafka 9092), sök (Elasticsearch 9200, Solr 8983), spelservrar, IoT-enheter.

Hur kontrollen fungerar

Monitorn öppnar en rå TCP-anslutning till host:port med 5 sekunders timeout. Om SYN/ACK kommer tillbaka – porten är tillgänglig och tjänsten lyssnar, check up. Om anslutningen vägras, timeout eller no route – check down, och felet från kärnan ("connection refused", "operation timed out", "no route to host") sparas i resultatet – enklare felsökning.

Monitorn försöker inte prata applikationsprotokollet – skickar varken SQL-fråga eller SMTP HELO. Det gör kontrollen snabb och utan bieffekter, vilket är viktigt när du övervakar 100 tjänster per minut. Behöver du applikationsvalidering, kombinera portövervakning med heartbeat eller egen API-monitor.

Kombinera med HTTP och ping

För varje publik tjänst ger tre monitorer en tydlig felsökningsstege. Ping bekräftar att värden lever på nätverket. Portövervakning – tjänsten lyssnar. HTTP-/API-övervakning – tjänsten svarar korrekt. När något slutar fungera, visar det direkt var du ska leta. Bara HTTP dör – applikationen kraschar. Porten är också nere – daemonen har kraschat. Ping är också nere – maskinen är borta eller nätverket har fallit.

Konfiguration

Öppna verktyget, klicka på "Lägg till monitor", välj typ "TCP-port", klistra in värden (utan protokoll), skriv portnummer (1-65535) och ställ in intervall. Spara. Från nästa cykel öppnar monitorn varje minut en TCP-anslutning, loggar round-trip, och larmar direkt om porten stängs – via Email, Telegram, Slack, Discord eller SMS, med samma regler för bekräftelsetröskel och nattro.

Vanliga frågor

Vilka portar kan jag övervaka?
Varje TCP-port från 1 till 65535. Vanliga fall: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), databaslyssnare (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), anpassade applikationsportar.
Kontrollerar monitorn om tjänsten är frisk eller bara tillgänglig?
Bara tillgänglighet – monitorn öppnar en TCP-anslutning och ser om demon accepterar den. Ingen handskakning på protokollnivå. Behöver du protokollmedvetna kontroller (t.ex. verifiering av SMTP-banner, svar på databasfråga), använd en HTTP-check (för HTTP-tjänster) eller self-hosted heartbeat-agent.
Vad är timeout för portkontroller?
Standard är 10 sekunder. Kan ställas in per monitor. Om TCP-anslutningen inte etableras inom timeoutfönstret, misslyckas kontrollen med "connection timeout". Long-haul-förbindelser (t.ex. kontroll av server i Asien från Europa) kan kräva längre timeouter.
Kan jag övervaka UDP-portar?
Inte för närvarande. UDP saknar anslutning – det finns ingen motsvarighet till "connection accepted" att testa. UDP-baserade tjänster kräver vanligtvis protokollspecifika tester (t.ex. DNS-fråga för port 53, SNMP get för 161). Använd heartbeat-övervakning istället.
Räknas portövervakning som TLS/SSL-varningar?
Nej – portkontroller mäter endast TCP-tillgänglighet. Vill du validera TLS-certifikat på porten, använd en HTTPS-kontroll med port i URL (t.ex. https://api.example.com:8443/) som gör både tillgänglighets- och certifikatskontroll.

Portövervakning