HTTP-koll ser webbplatsen. Den ser inte allt annat som håller den igång
En vanlig uptime-koll gör en sak: den hämtar en webbsida och tittar på statuskoden. Får den ett 200-svar är allt "uppe". Det är en rimlig första försvarslinje, men den täcker bara ett protokoll och en port — vanligtvis HTTP eller HTTPS på port 80/443. Allt annat som sajten faktiskt beror på: mejlservern, databasen, API:er mot tredje part, en kölyssnare — ligger utanför den bilden.
Det är här TCP-övervakning kommer in. I stället för att fråga "visar sidan rätt innehåll?" frågar den en enklare och mer grundläggande fråga: "svarar den här porten överhuvudtaget?" Det låter trivialt, men det är exakt den frågan som avslöjar en hel kategori av fel som en HTTP-koll aldrig ser — för att HTTP-kollen aldrig tittar åt det hållet.
Varför en webbsida kan se frisk ut medan tjänsten bakom den är trasig
Många moderna sajter är inte en enda process. De är en webbserver som pratar med en databas, en mejltjänst, en betalningsleverantör, ett API för lager eller bokning, kanske en separat cache- eller sökserver. Webbservern kan svara på HTTP-anrop även om en eller flera av dessa bakomliggande tjänster har slutat fungera — särskilt om koden är skriven för att visa en cachad eller förenklad sida vid fel, eller om felet bara drabbar en specifik funktion och inte startsidan.
Resultatet: din uptime-monitor rapporterar grönt. Kunderna möts samtidigt av trasiga formulär, uteblivna orderbekräftelser eller en kassa som hänger sig. Problemet är verkligt, men det syns inte i det enda måttet du bevakar.
Tre tysta tjänstefel som bara en portkontroll fångar
- Mejlservern har slutat lyssna. SMTP-porten (vanligen 25, 465 eller 587) kan sluta svara utan att webbplatsen påverkas alls. Kontaktformulär, orderbekräftelser, lösenordsåterställningar och aviseringar till kunder försvinner tyst. Ingen felsida visas för besökaren — mejlet skickas bara aldrig. Utan en TCP-koll mot den porten upptäcker du det först när en kund ringer och undrar varför de aldrig fick sin bekräftelse.
- Databasen svarar på anslutningsnivå men är överbelastad eller låst. En databasport (t.ex. 3306 för MySQL eller 5432 för PostgreSQL) kan ta emot anslutningsförsök men vägra eller fördröja dem på grund av för många samtidiga lås, slut på anslutningspooler eller disk-I/O som krupit till nästan stillastående. Webbservern kan fortfarande leverera en cachad startsida medan varje dynamisk sida — kundkonto, kassa, admin — hänger eller timeoutar. En portkontroll som mäter anslutningstid, inte bara "öppen/stängd", fångar denna gradvisa försämring innan den blir ett totalt avbrott. En varning: kontrollera bara en databasport utifrån om den redan är tänkt att nås på det sättet. MySQL- och PostgreSQL-portar ska normalt vara stängda mot internet – öppna aldrig en bara för att kunna övervaka den. Bevaka databasen indirekt i stället, med en HTTP-kontroll av en sida som måste fråga databasen, eller en heartbeat som skickas av ett jobb på servern.
- Ett internt eller tredjeparts-API har tystnat. Lagersystem, fraktberäkningar, betalningsgateways och bokningsmotorer exponerar ofta egna portar eller endpoints som inte är samma sak som huvudwebbplatsen. Om det APIet slutar svara kan hela köpflödet brytas samman — "lägg i varukorg" fungerar, men "beräkna frakt" gör det inte — medan din vanliga uptime-koll mot startsidan fortsätter att rapportera allt som normalt.
Vad en TCP-koll faktiskt mäter
En TCP-monitor försöker öppna en anslutning direkt mot en specifik port på en specifik server, utan att bry sig om vad som pratas ovanpå den (HTTP, SMTP, SQL eller något eget protokoll). Den mäter i praktiken tre saker:
- Går det att ansluta alls? Ett nekat eller tidsutlöst anslutningsförsök betyder att tjänsten bakom porten inte tar emot trafik — oavsett vad webbplatsen i övrigt visar.
- Hur lång tid tar handskakningen? En TCP-anslutning som tar betydligt längre tid än normalt är ofta det första tecknet på en tjänst under belastning, innan den helt slutar svara.
- Är porten stabilt tillgänglig över tid? Intermittenta anslutningsfel — fungerar ibland, inte alltid — pekar ofta mot resursbrist (minne, anslutningspooler, trådar) snarare än ett totalt haveri, och är ofta svårast att felsöka i efterhand utan loggning över tid.
Hur det kompletterar resten av din övervakning
TCP-koll ska inte ersätta HTTP-övervakning — den kompletterar den. HTTP-kollen talar om att besökaren kan ladda sidan. TCP-kollen mot bakomliggande portar talar om att de tjänster sidan är beroende av faktiskt lever. Tillsammans ger de en mer ärlig bild av driftstatus än endera ensam.
I Ravnsight bekräftas ett misslyckat TCP-anslutningsförsök från ett andra land innan det utlöser ett larm — samma princip som gäller för HTTP-koller. Det skiljer en verklig tjänstestörning från ett tillfälligt nätverksglapp mellan vår kontrollnod och din server, så du larmas för faktiska problem, inte brus.
Om du ansvarar för sajter som skickar transaktionsmejl, kör egna databaser eller pratar med externa API:er är en TCP-koll mot dessa portar inte en extrafunktion — det är den enda vägen till att veta att hela kedjan fungerar, inte bara fasaden.
