Porttien valvonta

HTTP:n ulkopuolella: muu stackin monitorointi

Suurin osa liiketoimintaa ylläpitävistä palveluista ei ole web-palvelimia. Tietokannat kuuntelevat porteilla 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Sähköposti kulkee porttien 25, 465, 587, 993, 995 kautta. SSH portissa 22. Pelipalvelimet valitun portin mukaan. Sisäiset mikropalvelut palomuurin takana – millä tahansa, jonka platform-tiimi on määritellyt. Mikään näistä ei käytä HTTP:tä. Et näe niitä nettisivujen uptime-työkalusta. Ja jokainen, kun lakkaa kuuntelemasta, vie mukanaan jotain näkyvää.

Porttien monitorointi paikkaa tämän aukon. Syötät valvontaan isännän ja portin, ja jokaisella tarkistuksella avataan TCP-yhteys, joka varmistaa, että palvelu kuuntelee. Jos yhteys epäonnistuu – daemon on kaatunut, palomuurisääntö muuttunut, hosti alhaalla tai verkko välissä rikki – saat hälytyksen.

Mitä voit monitoroida

• Tietokannat: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
• Sähköpostipalvelimet: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
• Etäyhteydet: 22 (SSH), 3389 (RDP), 5900 (VNC).
• Tiedostonsiirto: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
• Räätälöidyt tai sisäiset: GraphQL-gatewayt, gRPC, jonot (RabbitMQ 5672, Kafka 9092), haku (Elasticsearch 9200, Solr 8983), pelipalvelimet, IoT-laitteet.

Miten tarkistus toimii

Monitori avaa raakaa TCP-yhteyttä osoitteeseen host:port 5 sekunnin aikakatkaisulla. Jos vastauksena tulee SYN/ACK, portti on saavutettavissa ja palvelu kuuntelee – tarkistus onnistui. Jos connection refused, timeout tai no route, tarkistus epäonnistuu, ja tulokseksi kirjataan ytimen virhe ("connection refused", "operation timed out", "no route to host") – helpottaa vianrajausta.

Monitori ei yritä kommunikoida sovellusprotokollan tasolla – ei lähetä SQL-kyselyä tai SMTP HELO:ta. Näin tarkistus pysyy nopeana ja ilman sivuvaikutuksia, mikä on tärkeää kun tarkastetaan 100 palvelua joka minuutti. Jos tarvitset sovellustason varmistusta, yhdistä portin monitorointi heartbeat- tai omaan API-valvojaan.

Yhdistäminen HTTP:hen ja pingiin

Jokaiselle julkiselle palvelulle kolme monitoria muodostaa selkeän diagnostiikkapolun. Ping varmistaa, että hosti on verkossa. Porttien monitorointi kertoo, että palvelu kuuntelee. HTTP/API-monitorointi varmistaa, että palvelu vastaa oikein. Kun jokin osa kaatuu, heti näkee miltä tasolta etsintä aloittaa. Vain HTTP kaatuu – sovellus kaatuu. Porttikin – daemon kaatunut. Myös ping – rauta kadonnut tai verkko poikki.

Konfigurointi

Avaa työkalu, klikkaa "Lisää monitori", valitse tyyppi "TCP-portti", liitä host (ilman protokollaa), syötä portin numero (1–65535) ja aseta intervalli. Tallenna. Seuraavasta syklistä alkaen monitori avaa TCP-yhteyden minuutin välein, tallentaa round-tripin ja hälyttää heti portin sulkeutuessa – sähköpostilla, Telegramilla, Slackilla, Discordilla tai tekstiviestillä, samoilla vahvistus- ja hiljaisuussääntöillä kuin muissakin.

Usein kysyttyä

• Mitä portteja voin monitoroida?

  Kaikki TCP-portit väliltä 1–65535. Tyypillisiä tapauksia: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), tietokantojen listenerit (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), sovellusten omat portit.

• Tarkistaako monitori palvelun toimintakunnon vai vain saavutettavuuden?

  Vain saavutettavuuden – monitori avaa TCP-yhteyden ja tarkistaa hyväksyykö daemon sen. Ei protokollatason handshakea. Jos tarvitset protokollatietoista tarkistusta (esim. SMTP-bannerin tarkistus, tietokantan kyselyn vastaus), käytä HTTP-checkiä (HTTP-palveluille) tai itsetoteutettua heartbeat-agenttia.

• Mikä on porttitrekin aikakatkaisu?

  Oletuksena 10 sekuntia. Säädettävissä monitorikohtaisesti. Jos TCP-yhteys ei muodostu aikakatkaisun sisällä, tarkistus epäonnistuu "connection timeoutilla". Pitkien yhteyksien (esim. palvelin Aasiassa, valvonta Euroopasta) kohdalla saattaa tarvita pidempää aikakatkaisua.

• Voinko monitoroida UDP-portteja?

  Tällä hetkellä et voi. UDP on yhteydetön – ei ole "connection accepted" -vastinetta tarkastukseen. UDP-palvelut vaativat tyypillisesti protokollakohtaisia probeja (esim. DNS-kysely portille 53, SNMP get portille 161). Käytä heartbeat-monitorointia niiden sijaan.

• Lasketaanko porttimonitorointi TLS/SSL-varoituksiin?

  Ei – porttitarkistukset mittaavat vain TCP-saavutettavuutta. Jos haluat tarkistaa TLS-sertifikaatin portilla, käytä HTTPS-tarkistusta portilla URL:ssa (esim. https://api.example.com:8443/), joka tekee sekä saavutettavuuden että sertifikaatin tarkistuksen.