HTTP vs TCP vs Ping monitoring: Hvilket protokol skal du bruge?
En praktisk sammenligning af HTTP-, TCP- og Ping-monitoringprotokoller. Lær hvornår du bruger hver, og hvordan du bygger omfattende monitoring-dækning.
Når du sætter uptime monitoring op, er et af de første valg hvilket protokol du skal bruge til dine tjek. HTTP, TCP og Ping (ICMP) tester forskellige lag af din infrastruktur, og det rigtige valg bestemmer hvilke problemer du kan fange.
Forstå lagene
Din applikationsstack har flere lag, og hver monitoringprotokol tester en anden dybde:
```
┌─────────────────────────┐
│ Application (HTTP) │ ← HTTP monitoring tester her
├─────────────────────────┤
│ Service (TCP ports) │ ← TCP monitoring tester her
├─────────────────────────┤
│ Network (ICMP) │ ← Ping monitoring tester her
├─────────────────────────┤
│ Physical / Cloud │
└─────────────────────────┘
```
Et lag kan fejle mens lagene under forbliver sunde. Din server kan være pingbar (nettet er fint) mens din webserverproces er crashet (HTTP ville fejle, TCP på port 80 ville fejle). At forstå det hjælper dig med at vælge det rigtige protokol for hver tjeneste.
HTTP / HTTPS-monitoring
Sådan virker det
En HTTP-monitor sender en fuld HTTP-forespørgsel (typisk GET) til en URL og vurderer svaret. Den tjekker:
- Forbindelse: Kan vi etablere TCP og gennemføre TLS-handshake?
- Statuskode: Returnerede serveren den forventede status (200, 301 osv.)?
- Svarorgan: Indeholder svaret (eller indeholder det ikke) specifikt indhold?
- Response time: Hvor lang tid tog hele forespørgsel/svar-cyklussen?
- SSL-certifikat: Er certifikatet gyldigt og ikke ved at udløbe?
Hvornår du bruger HTTP-monitoring
Websites og webapps: Enhver URL tilgængelig via browser. Standardvalg for de fleste behov.
REST API'er: Overvåg health check-endpoints (/health, /api/status) for at verificere at jeres API svarer korrekt.
Webhooks: Verificér at webhook-endpoints accepterer forespørgsler.
Indholdsverifikation: Når du skal verificere ikke kun at en side loader, men at den indeholder det rigtige indhold. En server kan returnere 200 OK med en fejlside — HTTP keyword-monitoring fanger det.
Fordele
- Tester hele applikationsstacken inkl. applikationskode
- Kan verificere svarindhold, ikke kun forbindelse
- Overvåger SSL-certifikatets gyldighed og udløb
- Måler reelle brugeroplevede response times
- Understøtter autentifikation (headers, cookies)
Begrænsninger
- Virker kun med HTTP/HTTPS-tjenester
- Højere overhead per tjek end TCP eller Ping
- Kan ikke overvåge ikke-web-tjenester (databaser, mailservere, gameservere)
Eksempel-use cases
| Mål | URL | Forventet |
|-----|-----|-----------|
| Forside | https://example.com | Status 200 |
| API health | https://api.example.com/health | Status 200, organ indeholder "ok" |
| Login-side | https://app.example.com/login | Status 200 |
| Webhook | https://hooks.example.com/ingest | Status 200 eller 405 |
TCP-monitoring
Sådan virker det
En TCP-monitor forsøger at åbne en forbindelse til en specifik IP-adresse og portnummer. Den verificerer:
- Port er åben: Kan en TCP-forbindelse etableres?
- Forbindelsestid: Hvor hurtigt accepterer porten forbindelsen?
- Portsvar: Svarer tjenesten inden for timeout?
TCP-monitoring sender ingen applikationsdata — den tester kun om porten lytter og accepterer forbindelser.
Hvornår du bruger TCP-monitoring
Databaser: Overvåg PostgreSQL (5432), MySQL (3306), MongoDB (27017), Redis (6379) for at verificere at de accepterer forbindelser.
Mailservere: SMTP (25/587), IMAP (143/993), POP3 (110/995).
Custom-tjenester: Enhver tjeneste der lytter på en TCP-port men ikke taler HTTP — gameservere, MQTT-brokere, FTP, SSH.
Load balancers: Verificér at load balancerens port er åben og accepterer forbindelser.
Fordele
- Virker med enhver TCP-tjeneste, ikke kun HTTP
- Lavere overhead end HTTP-tjek
- Ingen applikationsniveau-konfiguration nødvendig
- Fanger portniveau-problemer (tjeneste crashet, firewall forkert konfigureret)
Begrænsninger
- Tester kun at porten er åben, ikke at applikationen fungerer korrekt
- Kan ikke verificere svarindhold
- Tester ikke applikationslogik (en database kan acceptere forbindelser men fejle alle forespørgsler)
Eksempel-use cases
| Mål | Host:Port | Formål |
|-----|-----------|--------|
| PostgreSQL | db.internal:5432 | Database-tilgængelighed |
| Redis | cache.internal:6379 | Cache-tilgængelighed |
| SSH | bastion.example.com:22 | Jump server-adgang |
| SMTP | mail.example.com:587 | E-mail-levering |
| Custom API | service.internal:8080 | Microservice-sundhed |
Ping (ICMP)-monitoring
Sådan virker det
Ping sender ICMP Echo Request-pakker til en vært og venter på Echo Reply-pakker. Den tester:
- Værtsrækkevidde: Svarer værten på netværksniveau?
- Round-trip time: Hvor lang tid tager pakken ud og tilbage?
- Packet loss: Bliver pakker tabt?
Hvornår du bruger Ping-monitoring
Netværksinfrastruktur: Routere, switches, firewalls og andre netværksenheder uden applikationstjenester.
Server-tilgængelighed: Hurtigt tjek at en server er tændt og netværksforbundet uanset hvilke tjenester den kører.
Netværksperformance: Ping response times og packet loss indikerer netværkssundheden mellem jeres monitoring-lokation og målet.
Baseline-monitoring: Som supplement til HTTP/TCP-tjek hjælper Ping med at skelne mellem «serveren er helt utilgængelig» og «serveren er rækbar men applikationen er i stykker».
Fordele
- Laveste overhead af alle monitoringprotokoller
- Tester det mest grundlæggende forbindelsesniveau
- Nyttigt til enheder uden applikationstjenester
- Hjælper med at diagnosticere om problemer er på netværks- eller applikationsniveau
Begrænsninger
- Tester kun netværksrækkevidde — ikke applikationssundhed
- Nogle værter og firewalls blokerer ICMP, hvilket gør Ping upålideligt
- Cloud-miljøer understøtter ofte ikke ICMP til visse ressourcer
- Kan ikke verificere at en specifik tjeneste kører
Eksempel-use cases
| Mål | Vært | Formål |
|-----|------|--------|
| VPN-gateway | vpn.example.com | Netværksadgang |
| Router | 10.0.0.1 | Netværksinfrastruktur |
| Server | web-1.internal | Grundlæggende rækkevidde |
| ISP-hop | isp-gateway.net | Netværkssti-sundhed |
Vælg det rigtige protokol
Her er et beslutningsramme:
Er det et website, en webapp eller en REST API?
→ Brug HTTP-monitoring. Det tester hele stacken og giver de mest nyttige data.
Er det en tjeneste der lytter på en TCP-port men ikke taler HTTP?
→ Brug TCP-monitoring. Databaser, mailservere, gameservere, custom-tjenester.
Er det en netværksenhed, eller skal du kun verificere grundlæggende rækkevidde?
→ Brug Ping-monitoring. Routere, switches, VPN-gateways, grundlæggende server-sundhed.
Usikker?
→ Start med HTTP for alt med en URL, TCP for alt med en port, og Ping for infrastruktur.
Kombinér protokoller for fuld dækning
De bedste monitoring-strategier bruger flere protokoller til at dække forskellige fejltilstande. For en typisk webapplikationsstack:
| Component | Protokol | Tjek |
|-----------|----------|------|
| Website | HTTP | https://example.com → 200 |
| API | HTTP | https://api.example.com/health → 200 |
| Database | TCP | db.internal:5432 |
| Redis-cache | TCP | cache.internal:6379 |
| Server | Ping | web-1.internal |
Når HTTP-tjekket fejler men TCP og Ping består, ved du at serveren er oppe og porten åben — problemet ligger i applikationskoden. Når alt fejler, ved du det er server- eller netværksniveau. Dette lagdelte tilgang accelererer diagnosen markant.
Konklusion
Der er ikke ét «bedste» monitoringprotokol — hver tester et andet lag af dit stack. HTTP-monitoring er mest omfattende for webtjenester, TCP-monitoring dækker ikke-HTTP-tjenester, og Ping-monitoring giver grundlæggende netværksniveau-synlighed.
For de fleste teams er svaret «brug alle tre på de rigtige mål.» Start med HTTP-monitoring for jeres brugerrettede tjenester, tilføj TCP-monitoring for infrastrukturtjenester, og brug Ping til netværksniveau-sundhed.
Overvåg hvert lag af dit stack. Start gratis — HTTP-, TCP- og Ping-monitoring på alle planer.