Portovervågning

Ud over HTTP: overvågning af resten af stacken

De fleste tjenester, der holder forretningen kørende, er ikke webservere. Databaser lytter på 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Mail kører via 25, 465, 587, 993, 995. SSH på 22. Spilservere på de porte, som udbyderen har valgt. Interne mikrotjenester bag firewallen – på hvad end platformteamet har konfigureret. Ingen af dem taler HTTP. Ingen af dem vil du se i et uptime-værktøj til hjemmesider. Og hver gang én af dem holder op med at lytte, forsvinder der noget synligt med den.

Portovervågning lapper det hul. Du angiver vært og port til monitoren, og ved hver kontrol åbnes der en TCP-forbindelse for at verificere, om tjenesten lytter. Hvis forbindelsen fejler – fordi dæmonen er nede, firewallen har ændret sig, værten er nede, eller netværket mellem dig og tjenesten er beskadiget – får du en advarsel.

Hvad du kan overvåge

• Databaser: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Mailservere: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Fjernadgang: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Filoverførsel: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Brugerdefinerede eller interne: GraphQL gateways, gRPC, køer (RabbitMQ 5672, Kafka 9092), søgning (Elasticsearch 9200, Solr 8983), spilservere, IoT-enheder.

Sådan fungerer tjekket

Monitoren åbner en rå TCP-forbindelse til host:port med 5 sekunders timeout. Hvis der kommer SYN/ACK retur – porten er tilgængelig og tjenesten lytter, check up. Hvis forbindelsen afvises, timeout eller ingen rute – check down, og fejl fra kernen gemmes ("connection refused", "operation timed out", "no route to host") – nemmere fejlfinding.

Monitoren forsøger ikke at tale applikationsprotokollen – sender hverken SQL-forespørgsel eller SMTP HELO. Det holder tjekket hurtigt og uden bivirkninger, hvilket er vigtigt når du tjekker 100 tjenester i minuttet. Hvis du har brug for applikationsverificering, kombiner portovervågning med heartbeat eller din egen API-monitor.

Kobling med HTTP og ping

For hver offentlig tjeneste giver tre monitorer et klart diagnostisk trappetrin. Ping bekræfter at værten lever på netværket. Portovervågning – tjenesten lytter. HTTP/API-overvågning – tjenesten svarer korrekt. Når noget fejler, viser det fejlende lag straks hvor du skal lede. Kun HTTP fejler – applikationen crasher. Porten fejler også – dæmonen er nede. Ping fejler også – boksen er forsvundet eller netværket er nede.

Opsætning

Åbn værktøjet, klik på "Tilføj monitor", vælg typen "TCP-port", indsæt værten (uden protokol), indtast portnummeret (1-65535) og sæt intervallet. Gem. Fra næste cyklus åbner monitoren hvert minut en TCP-forbindelse, registrerer round-trip, og advarer i det øjeblik porten lukkes – via Email, Telegram, Slack, Discord eller SMS, med samme regler for bekræftelsesgrænser og natte-ro.

Ofte stillede spørgsmål

• Hvilke porte kan jeg overvåge?

  Alle TCP-porte fra 1 til 65535. Almindelige eksempler: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), database-lyttere (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), brugerdefinerede applikationsporte.

• Tjekker monitoren om tjenesten er sund, eller kun om den er tilgængelig?

  Kun tilgængelighed — monitoren åbner en TCP-forbindelse og tjekker om dæmonen accepterer den. Uden handshake på protokolniveau. Hvis du har brug for protokolbevidste check (f.eks. verifikation af SMTP-banner, database-forespørgsels-svar), brug et HTTP-check (for HTTP-tjenester) eller en self-hosted heartbeat-agent.

• Hvad er timeout for port-checks?

  Som standard 10 sekunder. Kan konfigureres pr. monitor. Hvis TCP-forbindelsen ikke oprettes inden for timeout-vinduet, fejler checket med "connection timeout". Long-haul forbindelser (f.eks. kontrol af server i Asien fra Europa) kan kræve længere timeouts.

• Kan jeg overvåge UDP-porte?

  Ikke på nuværende tidspunkt. UDP er forbindelsesløst — der er ikke nogen "connection accepted" analog at tjekke. UDP-baserede tjenester kræver typisk protokolspecifikke probes (f.eks. DNS-forespørgsler for port 53, SNMP get for 161). Brug i stedet heartbeat-overvågning.

• Tæller portovervågning med i TLS/SSL-advarsler?

  Nej — portchecks handler kun om rå TCP-tilgængelighed. Hvis du vil have validering af TLS-certifikat på en port, brug et HTTPS-check med porten i URL'en (f.eks. https://api.example.com:8443/), som både tjekker tilgængelighed og certifikat.