Äriserveri seire kontrollnimekiri: 12 kontrolli
Avaldatud 2. augustil 2026
Server võib vastata pingipäringutele ja olla siiski vaid ühe taaskäivituse kaugusel väga pikast pärastlõunast. See äriserveri seire kontrollnimekiri keskendub kõigepealt signaalidele, mis mõjutavad kliente, töötajaid ja tulu: käideldavus, rakenduse käitumine, mahutavus, turvalisus ja taastatavus. Eesmärk ei ole tekitada häireid iga pisimagi muutuse peale. Eesmärk on varakult teada saada, millal kujuneb välja tegelik teenuseprobleem.
Alusta sellest, mida äri tegelikult kasutab
Seire on kasulik ainult siis, kui see järgib klienditeekonda. CPU diagramm ei ütle sulle, kas kassaprotsess töötab, kas kliendiportaal saadab e-kirju või kas API tagastab kehtivaid vastuseid. Alusta loeteluga teenustest, mis peavad jääma kättesaadavaks: veebisaidid, andmebaasid, meiliteenused, VPN-id, taustatöölised, failisalvestus, ajastatud tööd ja kolmanda osapoole integratsioonid.
Määra iga teenuse jaoks vastutaja, defineeri vastuvõetav reageerimisaeg ja otsusta, mida loetakse katkestuseks. Turundussait võib taluda mõnesekundilist lisakoormust. Maksete lõpp-punkt või tootmis-API tavaliselt ei saa seda lubada. Siin saavad väiksemad meeskonnad eelise: loetelu võib olla lühike, selge ja seotud tegeliku ärimõjuga.
Äriserveri seire kontrollnimekiri: 12 põhikontrolli
1. Väline uptime ja reageerimisaeg
Kontrolli oma kõige olulisemaid avalikke URL-e ja teenuseporte väljastpoolt serverit. Sisemine seire võib öelda, et kõik on korras, samal ajal kui DNS-i probleem, tulemüürireegel, aegunud sertifikaat või ülesvoolu marsruutimisviga blokeerib tegelikud külastajad.
Jälgi HTTP olekukoode, lehe või API reageerimisaega ning võimalusel sisulist sisu kontrolli. Veebipoe puhul on kasulik kinnitada, et avaleht tagastab 200. Veel parem on kinnitada, et tooteotsingu või ostukorvi lõpp-punkt töötab.
2. CPU kasutus, load average ja steal time
Püsiv CPU küllastumine aeglustab andmebaase, veebitöölisi, cron-töid ja kaughaldust. Jälgi keskmist CPU kasutust, kuid võrdle load average’it ka saadaolevate CPU tuumade arvuga. Kõrge load average võib viidata CPU survele, protsessidele, mis ootavad ketta I/O-d, või blokeeritud ülesannetele.
Virtuaalses privaatserveris väärib tähelepanu CPU steal time. Kõrge steal time tähendab, et hüperviisor kulutab liiga palju aega teiste töökoormuste teenindamisele, enne kui sinu oma järjekorda jõuab. See ei ole alati rakenduse probleem ja PHP häälestamine ei lahenda mürarikka naabri olukorda.
3. Mälu kättesaadavus ja swap’i aktiivsus
Ainuüksi vähene vaba mälu ei ole tingimata halb. Linux kasutab kasutamata mälu vahemäluna, mis on normaalne käitumine. Hoiatusmärgid on kasvav swap’i kasutus, sagedased page fault’id, out-of-memory sündmused või protsess, mille kernel lõpetab.
Jälgi saadaolevat mälu, mitte ainult vaba mälu. Kui swap kasvab tavapärase liikluse ajal pidevalt, uuri enne järgmist liiklustippu rakendust, andmebaasi puhvrite seadeid, tööliste piiranguid või serveri suurust.
4. Ketta maht, inode’ide kasutus ja kasvukiirus
Täis ketas võib peatada andmebaasid, takistada logide kirjutamist, rikkuda varukoopiad ja panna muidu terve veebisaidi ootamatul viisil tõrkuma. Jälgi kõiki asjakohaseid haakepunkte, mitte ainult peamist failisüsteemi. Kaasa rakenduse köited, andmebaasi salvestusruum, varukoopiate vahealad ja ajutised kataloogid.
Jälgi ka inode’ide tarbimist. Miljonid väikesed failid võivad inode’id ammendada ka siis, kui kettaruumi on veel küllaga. Jälgi ka kasvukiirust. 70% juures failisüsteem võib olla rahulik; üks, mis kasvab 10% päevas, saadab probleemidest üsna selge postkaardi.
5. Ketta I/O latentsus ja failisüsteemi vead
Kettakasutus on maht. Ketta latentsus on jõudlus. Kõrged lugemis- või kirjutamisooted võivad panna serveri tunduma hangununa isegi siis, kui CPU kasutus on madal. Andmebaasimahukad teenused on aeglase salvestuse suhtes eriti tundlikud.
Sea häired ebatavalise I/O ootuse, pikaajalise ketta latentsuse, failisüsteemi vigade ja korduvate haakimisprobleemide jaoks. Kui andmebaasipäring muutub järsku kõikjal aeglaseks, tuleks enne eeldamist, et andmebaas vajab suuremat vahemälu, kontrollida salvestuse käitumist.
6. Võrguliiklus, paketikadu ja ühendusvead
Jälgi sisse- ja väljaminevat läbilaset võrreldes serveri pordi mahutavusega, kuid ära piirdu sellega. Paketikadu, kordusedastused, liidesevead, mahavisatud paketid ja ootamatult suur ühenduste arv selgitavad sageli aeglast või ebausaldusväärset teenust.
Liikluspiik võib olla hea uudis, näiteks edukas kampaania. Või võib see olla robotliiklus, kraapimistsükkel, valel ajal ajastatud varukoopia ülekandmine või rünnak. Seire annab sulle tõendid selle otsuse tegemiseks, selle asemel et väga värvilise graafiku põhjal oletada.
7. Veebiserveri ja rakenduse seisund
Sinu veebiserverit tuleks kontrollida rohkem kui lihtsalt seda, kas protsess töötab. Jälgi aktiivseid ühendusi, päringute määra, vastuskoode, tööliste kättesaadavust, järjekorra sügavust ja rakenduse veamäärasid. Protsess võib jääda elusaks samal ajal, kui iga päring tagastab 500 vea.
PHP, Node.js-i, Java, Pythoni või sarnaste rakenduspakkide puhul jälgi tööliste taaskäivitusi, mälu kasvu, püüdmata erandeid ja päringu latentsust lõpp-punkti kaupa. Parim häire ei ole sageli „protsess peatus”. See on „kassaprotsessi lõpp-punkt on viis korda aeglasem kui tavaliselt”.
8. Andmebaasi jõudlus ja replikatsiooni olek
Andmebaasid väärivad omaette seireplaani, sest need tõrguvad teisiti kui veebiserverid. Jälgi ühenduste kasutust, aeglasi päringuid, päringu latentsust, lukke, puhvri või vahemälu tõhusust, salvestuse kasvu ja vealoge.
Kui kasutad replikatsiooni, jälgi replikatsiooni viidet ja replika seisundit. Tundide võrra maha jäänud replika võib endiselt paista võrgus olevat, kuid see ei ole valmis toetama aruandlust, ümberlülitust ega taastamist. Hallatud andmebaasitöökoormuste puhul otsusta, kes vaatab üle aeglaste päringute mustrid ja kui sageli. Selle jätmine hetkeni, mil rakendus on nähtavalt aeglane, on kallis ajastus.
9. Varukoopiate lõpuleviimine ja taastamise valmisolek
Varukoopiatöö, mis käivitub, ei ole automaatselt varukoopia, mis suudab sind päästa. Jälgi, kas tööd lõppesid edukalt, kui kaua need kestsid, varukoopia suurust, sihtsalvestuse kättesaadavust, kasutuse korral krüptimise olekut ja kõiki varundustööriista hoiatusi.
Kõige tähtsam on ajastada taastamistestid. Testi faili taastamist, andmebaasi taastamist ja võimaluse korral kogu teenuse täielikku taastamist eraldi keskkonda. Logid räägivad sama lugu alles siis, kui taastamist on testitud. Varukoopia ilma taastamise tõenduseta on endiselt vaid lootusrikas korraldus.
10. Turvasündmused ja paikade olek
Jälgi nurjunud sisselogimiste mustreid, õiguste muudatusi, uusi kasutajakontosid, SSH juurdepääsu, tulemüüri blokeeringuid, pahavara häireid, sertifikaatide aegumist ja ebatavalisi väljaminevaid ühendusi. Mitte iga nurjunud sisselogimine ei vaja kesköist kõnet, kuid äkiline rünnak administratiivse konto vastu väärib lähemat vaatlust.
Paikade seire peaks teatama nii saadaolevatest uuendustest kui ka hilinenud kriitilistest parandustest. Rakenda uuendusi teenusega sobiva hooldusplaani järgi. Arendus-VPS võib lubada kiiret taaskäivitust. Kliendile suunatud tootmisserver võib vajada testimist, varukoopia kontrolli ja planeeritud muudatusakent.
11. SSL, DNS ja domeenisõltuvused
Sertifikaadi aegumine võib muuta töötava veebisaidi koheseks usaldusprobleemiks. Sea häired aegsasti enne sertifikaatide aegumist ja jälgi automaatse uuendamise tulemusi. Kontrolli, et sertifikaat vastaks kavandatud hostinimele ja et kogu ahelat serveeritaks õigesti.
DNS väärib samasugust tähelepanu. Jälgi peamisi DNS-kirjeid, nimeserverite kättesaadavust ja ootamatuid kirjemuudatusi. Kui DNS läheb valesti, ei ole see just kõige kaunim olukord, kuid see on kontrolli all, kui sul on teadaolev baasjoon ja häire enne, kui kliendid sellest teatavad.
12. Logid, ajastatud tööd ja häirete kohaletoimetamine
Koonda võimaluse korral kasulikud logid keskseks ja jälgi korduvaid vigu, autentimisnurjumisi, rakenduse erandeid ja teenuse taaskäivitusi. Ka logimaht on signaal. Äkiline tulv võib täita salvestusruumi; äkiline vaikus võib tähendada, et logiagent tõrkus.
Jälgi cron-töid, järjekordi, ajastatud importe, aruannete genereerimist ja uuendamistoiminguid. Need tööd tõrguvad sageli vaikselt, sest veebisait ise jääb võrku. Lõpuks testi häirete kohaletoimetamist. Häire, mis jõuab postkasti, mida keegi kell 3 öösel ei kontrolli. on pigem päevikumärge kui operatiivne kontrollimeede.
Sea läved, mis käivitavad tegevuse, mitte müra
Väldi kõigile sobivaid lävesid. 90% CPU häire võib olla kiireloomuline väikesel VPS-il, mis töötab tavaliselt 15% juures, kuid kahjutu paketttöötlusserveri jaoks, mis on loodud töötama kuumana igal ööl tund aega. Loo baasjoon tavapärase liikluse ajal, seejärel sea häired püsiva kõrvalekalde ja ärimõju põhjal.
Kasuta raskusastmeid koos selgete tegevustega. Hoiatus võib paluda valves oleval inimesel tööpäeva jooksul üle vaadata kasvava kettakasutuse. Kriitiline häire peaks tähendama, et keegi peab kohe tegutsema, sest kliendile suunatud teenus on maas, andmekaitse on ohus või mahutavus saab peagi otsa.
Iga oluline häire peaks vastama kolmele küsimusele: mis tõrkus, mida see mõjutab ja mida tuleks esimesena kontrollida. Lisa häireteatesse serveri nimi, teenus, ajatempel, asjakohane mõõdik ja lühike viide käitusjuhendile. Selle vastuvõttev inimene võib olla väsinud, keskkonnas uus või mõlemat. Anna talle aus stardipositsioon.
Loo eskaleerimistee enne, kui surve tekib
Seirepakk ei asenda operatiivset vastutust. Dokumenteeri, kes häireid vastu võtab, kes saab taaskäivituse või tagasipööramise heaks kiita, kus mandaate turvaliselt hoitakse ja kuidas kliente kinnitatud intsidendi ajal teavitatakse. Agentuuride jaoks on see eriti väärtuslik, sest üks taristusündmus võib korraga mõjutada mitut kliendikontot.
Hallatud seire võib siin koormust vähendada. Sellised teenused nagu FASTCARE monitoring on kasulikud, kui su meeskond vajab inimeste pilku serveri signaalidel, eriti väljaspool tööaega, kuid siiski tuleks kokku leppida eskaleerimiskontaktid ja lubatud tegevused. Kiire reageerimine toimib kõige paremini siis, kui keegi ei pea otsima telefoninumbrit samal ajal, kui ketas jõuab 100%-ni.
Vaata kontrollnimekiri üle kord kuus ja pärast iga intsidenti. Eemalda häired, mis tekitavad müra, lisa kontrolle tõrgete jaoks, mis jäid avastamata, ja uuenda lävesid töökoormuse kasvades. Rahulik taristu ei ole vaikiv taristu. See on keskkond, kus õiged inimesed saavad õige signaali piisavalt vara, et teenus uuesti rahulikuks muuta.
Andres Saar klienditeeninduse insener