VPS ni dovolj nastaviti: treba ga je tudi spremljati. Večina izpadov ne pride iz nič, temveč ima znake: počasi polnjen disk, proces, ki porablja vedno več pomnilnika, ponavljajoča se napaka v dnevniku, potrdilo, ki poteče med vikendom. Če jih vidiš pravočasno, napako opaziš pred obiskovalci in izpad lahko preprečiš.

V tem vodniku povzemamo, kaj je vredno meriti na VPS, s katerimi orodji, kako nastaviti opozorila, da se ne utopiš v obvestilih, in kaj narediti z izmerjenimi podatki.

Kaj meriti?

Dosegljivost od zunaj

Najpomembnejše vprašanje: ali obiskovalec doseže spletno stran? To je treba meriti zunaj strežnika, saj ob izpadu strežnika tudi njegovo lastno spremljanje ne more opozoriti. Zunanji nadzornik razpoložljivosti (uptime) vsakih nekaj minut pokliče stran (in v njej lahko išče tudi ključno besedo) ter opozori, če se ne odzove.

Procesor

• Poraba CPU: trajna poraba nad 80–90 % kaže, da je procesorja premalo ali da je proces ušel izpod nadzora.
• Load average: povprečno število procesov, ki čakajo na izvajanje, za 1, 5 in 15 minut. Sumljivo je, če trajno presega število vCPU. Kaj pomeni load v Linuxu, opisuje naš članek baze znanja.
• Steal time (st): na VPS kaže, koliko časa je navidezni stroj čakal na fizični procesor. Trajno visoka vrednost kaže na preobremenjenost fizičnega strežnika; na KVM VPS z zagotovljenimi viri mora biti nizka.
• I/O wait (wa): koliko časa procesor čaka na disk. Če je visok, je ozko grlo shramba.

Pomnilnik

• Porabljen in razpoložljiv pomnilnik: Linux prosti pomnilnik uporablja kot predpomnilnik, zato je vrednost »free« lahko nizka, tudi ko je vse v redu. Spremljaj vrednost available (razpoložljivo).
• Swap: če sistem redno uporablja swap, je pomnilnika premalo in se upočasni.
• OOM killer: ko zmanjka pomnilnika, jedro ustavi proces (pogosto prav podatkovno bazo). Na to kažejo vnosi »Out of memory« v dnevniku; o tem piše članek o OOM killerju in ustvarjanju datoteke swap.

Disk

• Prosti prostor: poln disk je eden najpogostejših vzrokov izpada (dnevniki, varnostne kopije, nalaganja). Opozorilo nastavi pri 80–85 %.
• Inodi: pri veliko majhnih datotekah (predpomnilnik, seje) lahko inodi zmanjkajo, preden zmanjka prostora.
• Operacije diska (IOPS, prenos) in zakasnitev.

O preverjanju porabe diska govori članek o ukazih du in df.

Omrežje

Dohodni in odhodni promet, število povezav, napake. Nenaden porast prometa je lahko uspešna kampanja, lahko pa tudi napad ali pošiljanje neželene pošte z vdrtega strežnika.

Storitve in aplikacija

• Ali tečejo pomembne storitve (spletni strežnik, PHP-FPM, podatkovna baza, e-pošta)?
• Odzivni čas aplikacije, delež napačnih zahtev (5xx).
• Počasne poizvedbe podatkovne baze.
• Iztek potrdila SSL, iztek domene.
• Varnostne kopije: ali se je izvedla zadnja varnostna kopija.

Dnevniki

Sistemski in aplikacijski dnevniki (journald, /var/log, dnevniki napak in dostopa spletnega strežnika) pokažejo, kaj se je zgodilo. Ponavljajoče se napake, neuspešni poskusi prijave in nenavadne zahteve so zgodnja opozorila. O branju dnevnikov govorita članek o journalctl in mapi /var/log ter naš prispevek o analizi dnevnikov spletnega strežnika.

Orodja

Hitra diagnoza v ukazni vrstici

• htop ali btop: procesi, CPU in pomnilnik v živo. O tem piše članek o uporabi top in htop.
• vmstat 1: CPU, pomnilnik, swap, I/O wait in steal vsako sekundo.
• iostat -x 1 (paket sysstat): obremenitev in zakasnitev diska.
• df -h, df -i, du: prostor na disku in inodi.
• ss -tulpn: odprta vrata in povezave.
• journalctl -p err -b: napake sistema od zadnjega zagona.

Ta so potrebna za iskanje napak; za stalno spremljanje in opozorila so namenjena spodnja orodja.

Sistemi za spremljanje

Orodje	Za kaj je dober	Opomba
Netdata	Podrobno merjenje v realnem času v nekaj minutah, s pripravljenimi opozorili	Za en ali dva strežnika najpreprostejše; odprtokodno, tudi s storitvijo v oblaku
Prometheus + Grafana	Merjenje časovnih vrst, prilagojene nadzorne plošče in opozorila	Z node_exporterjem je mogoče meriti sistemske metrike, z exporterji tudi aplikacije; idealno za več strežnikov
Zabbix	Celovito podjetniško spremljanje	Za veliko strežnikov, zapletenejša nastavitev
Glances	Preprost, pregleden terminalski in spletni pogled	Za hiter pregled
Monit	Spremljanje storitev in njihov samodejni ponovni zagon	Majhen in zanesljiv, glej spodaj

Zunanje spremljanje dosegljivosti

• Uptime Kuma: odprtokodni nadzornik razpoložljivosti, ki ga upravljaš sam, z lepo stranjo stanja. Zaženi ga na drugem strežniku, ne na tistem, ki ga spremlja.
• Kot storitev: UptimeRobot, Better Stack, HetrixTools in podobni; tudi z brezplačnim paketom ponujajo preverjanje vsakih nekaj minut.

Opozorila

Dobro opozorilo se oglasi, ko je treba nekaj narediti, in le takrat. Nekaj nasvetov:

• Prag in trajanje: ne opozarjaj na trenutni skok, temveč na trajno stanje (na primer »CPU 5 minut nad 90 %«).
• Dve ravni: opozorilo (na primer disk pri 80 %) in kritično opozorilo (pri 95 %).
• Spremljaj simptom, ne le vzroka: »spletna stran se ne odziva« je pomembnejše od »load je visok«.
• Kanal: opozorila po e-pošti se zlahka izgubijo; kritična pošiljaj na mobilni telefon (potisno obvestilo, Telegram, Slack, SMS).
• Ne opozarjaj po nepotrebnem: če ob opozorilu redno ni treba narediti ničesar, ga prilagodi ali izbriši, sicer boš spregledal tudi pomembnega.

Nekaj preizkušenih izhodiščnih pragov:

Merilo	Opozorilo	Kritično
Poraba diska	80%	90–95%
Razpoložljiv pomnilnik	pod 15 %	pod 5 %
CPU (trajno)	80%	95%
Load (trajno)	število vCPU	dvakratnik števila vCPU
Iztek SSL	21 dni	7 dni
Dosegljivost spletne strani	–	2–3 zaporedna neuspešna preverjanja

Samodejna obnova

Monit lahko ustavljeno storitev samodejno znova zažene in o tem obvesti. Na primer za spletni strežnik:

check process nginx with pidfile /run/nginx.pid
  start program = "/usr/bin/systemctl start nginx"
  stop program  = "/usr/bin/systemctl stop nginx"
  if failed host 127.0.0.1 port 80 protocol http then restart
  if 5 restarts within 5 cycles then alert

Samodejni ponovni zagon je zdravljenje simptoma: če se storitev redno ustavlja, je treba poiskati vzrok.

Kaj narediti s podatki?

• Premalo pomnilnika, redna uporaba swapa, OOM: nastavi aplikacije (število procesov PHP-FPM, velikost medpomnilnika podatkovne baze) ali preklopi na večji paket.
• Visok CPU pri enem procesu: preveri, kateri in zakaj (vtičnik, opravilo cron, promet robotov, vdor).
• Visok I/O wait: počasne poizvedbe, preveč beleženja ali velika varnostna kopija med delovnim časom.
• Polnjenje diska: rotacija dnevnikov, brisanje starih varnostnih kopij, čiščenje predpomnilnika; če du ne pokaže, kje je prostor, pomaga članek o skritih vzrokih polnega diska.
• Redno dosežene meje: na KVM VPS aWh lahko na portalu za stranke preklopiš na večji paket; o skaliranju virov VPS govori ločen vodnik.

Izmerjeni podatki so potrebni tudi za načrtovanje: iz tedenskih in mesečnih trendov je razvidno, kdaj bo zmanjkalo prostora ali pomnilnika, tako da lahko pravočasno povečaš.

Kdo spremlja strežnik?

Na neupravljanem VPS je spremljanje tvoja naloga. Če nimaš časa ali znanja zanj, v naši storitvi upravljanega VPS nadzor strežnika, obravnavo opozoril in odpravljanje napak opravimo mi. Strežniki KVM VPS aWh so na voljo z zagotovljenim procesorjem in pomnilnikom, NVMe SSD, dnevno varnostno kopijo in 99,9-odstotno razpoložljivostjo; zaradi zagotovljenih virov so izmerjene vrednosti predvidljive in niso odvisne od prometa sosednjih strank.

Povzetek

Od zunaj meri dosegljivost, od znotraj pa CPU (skupaj z vrednostma steal in I/O wait), pomnilnik, disk, omrežje, storitve, potrdila in varnostne kopije. Za en ali dva strežnika zadoščata Netdata in zunanji nadzornik razpoložljivosti, za več strežnikov Prometheus in Grafana. Nastavi malo, a smiselnih opozoril, iz trendov pa načrtuj povečanje.

Pogosta vprašanja

Kateri je najpreprostejši način spremljanja VPS?

Zunanji nadzornik razpoložljivosti (na primer UptimeRobot ali Uptime Kuma na drugem strežniku) in Netdata, nameščen na strežnik. To nastaviš v nekaj minutah in večino težav sporoči pravočasno.

Kaj pomeni steal time?

Čas, ko je navidezni stroj čakal na fizični procesor, ker je bil ta zaposlen z drugim. Na KVM VPS z zagotovljenimi viri je nizek; če je trajno visok, to sporoči ponudniku.

Ali spremljanje upočasni strežnik?

Lahki agenti (node_exporter, Netdata) pomenijo zanemarljivo obremenitev. Na zelo majhnem VPS izberi lažje orodje in podatkov ne zbiraj po nepotrebnem pogosto.

Kako pogosto naj preverjam dosegljivost?

Vsako 1–5 minut. Opozorilo pošlji šele po 2–3 zaporednih neuspešnih preverjanjih, da trenutna napaka omrežja ne povzroči lažnega opozorila.

Kje naj hranim podatke spremljanja?

Po možnosti ne na istem strežniku, ki ga spremljaš: v zunanji storitvi ali na drugem strežniku. Tako tudi ob izpadu strežnika vidiš, kaj se je zgodilo pred njim.

Ali tudi majhen VPS potrebuje spremljanje?

Da, vsaj zunanji nadzornik dosegljivosti in opozorilo o prostoru na disku, saj sta poln disk in ustavljena storitev tudi pri majhnih strežnikih najpogostejši napaki.

• vps
• nadzor
• upravljanje strežnikov
• razpoložljivost
• vodniki