Portovervåking

Utenfor HTTP: overvåking av resten av stacken

De fleste tjenestene som holder en bedrift i gang er ikke webservere. Databaser lytter på 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). E-post går over 25, 465, 587, 993, 995. SSH på 22. Spilleservere på porter valgt av utgiveren. Interne mikrotjenester bak brannmur – på det plattformteamet har satt opp. Ingen av disse snakker HTTP. Ingen syns i vanlige oppetidsverktøy for nettsider. Og alle, når de slutter å lytte, tar med seg noe synlig.

Portovervåkning dekker dette hullet. Du gir monitoren en vert og port, og for hvert sjekk åpnes en TCP-forbindelse for å verifisere at tjenesten lytter. Hvis tilkoblingen feiler – fordi daemonen har krasjet, brannmuren har endret seg, verten er nede eller nettverket mellom oss og tjenesten er skadet – får du et varsel.

Hva kan du overvåke

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

Slik fungerer sjekken

Monitoren åpner en rå TCP-forbindelse til vert:port med 5 sekunders timeout. Hvis det kommer tilbake en SYN/ACK – porten er tilgjengelig og tjenesten lytter, sjekk opp. Hvis connection refused, timeout eller ingen rute – sjekk ned, og feilmeldingen fra kjernen lagres ("connection refused", "operation timed out", "no route to host") – lettere å feilsøke.

Monitoren prøver ikke å snakke applikasjonsprotokollen – den sender ikke SQL-spørring eller SMTP HELO. Det gjør sjekken rask og uten bivirkninger, noe som teller når du overvåker 100 tjenester hvert minutt. Hvis du trenger applikasjonsverifikasjon, kombiner portovervåking med heartbeat eller en egen API-monitor.

Kombinasjon med HTTP og ping

For hver offentlig tjeneste gir tre monitorer en tydelig diagnostisk stige. Ping bekrefter at verten lever på nettverket. Portovervåking – tjenesten lytter. HTTP/API-overvåking – tjenesten svarer riktig. Når noe feiler, sier laget som feiler med en gang hvor du skal lete. Bare HTTP feiler – applikasjonen krasjer. Port feiler også – daemonen har krasjet. Ping også nede – boksen er borte eller nettet har falt.

Konfigurasjon

Åpne verktøyet, klikk "Legg til monitor", velg type "TCP port", lim inn vert (uten protokoll), skriv inn portnummer (1-65535) og sett intervall. Lagre. Fra neste syklus åpner monitoren hvert minutt en TCP-forbindelse, måler round-trip, og varsler i sekundet porten stenges – via E-post, Telegram, Slack, Discord eller SMS, med samme regler for bekreftelsesterskel og nattestille.

Ofte stilte spørsmål

• Hvilke porter kan jeg overvåke?

  Alle TCP-porter fra 1 til 65535. Vanlige tilfeller: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), database-lydere (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), egendefinerte applikasjonsporter.

• Sjekker monitoren om tjenesten er sunn eller bare tilgjengelig?

  Bare tilgjengelighet – monitoren åpner en TCP-forbindelse og sjekker om daemonen aksepterer den. Ingen håndtrykk på protokollnivå. Hvis du trenger protokollbevisste sjekker (f.eks. verifisering av SMTP-banner, svar på databasespørring), bruk en HTTP-sjekk (for HTTP-tjenester) eller en selvhostet heartbeat-agent.

• Hva er timeout for port-sjekker?

  Standard er 10 sekunder. Kan konfigureres per monitor. Hvis TCP-forbindelsen ikke opprettes innen timeout-vinduet, feiler sjekken med "connection timeout". Langdistanseforbindelser (f.eks. sjekke en server i Asia fra Europa) kan kreve lengre timeout.

• Kan jeg overvåke UDP-porter?

  Foreløpig ikke. UDP er tilkoblingsløst – det finnes ingen tilsvarende "connection accepted" å sjekke. Tjenester basert på UDP krever ofte protokollspesifikke probes (f.eks. DNS-spørring på port 53, SNMP get på 161). Bruk heartbeat-overvåking i stedet.

• Teller portovervåking for TLS/SSL-varsler?

  Nei – portsjekker er ren TCP-tilgjengelighet. Hvis du vil validere TLS-sertifikat på en port, bruk en HTTPS-sjekk med porten i URL-en (f.eks. https://api.example.com:8443/) som både sjekker tilgjengelighet og sertifikat.