Kā pareizi uzraudzīt servera darbspējas laiku
Publicēts 2026. gada 26. maijā
Ja vēlaties zināt, kā uzraudzīt servera darbspējas laiku bez minēšanas, sāciet ar pārbaudēm no ārpuses, nevis tikai servera iekšienē. Pakalpojums lokālajos žurnālos var izskatīties vesels, kamēr lietotāji skatās uz noildzes lapu. Pirmais uzdevums ir vienkāršs - apstiprināt, vai serveris atbild no neatkarīgas atrašanās vietas, vai pareizais ports ir atvērts un vai pats pakalpojums atgriež derīgu atbildi. Tā ir tā daļa, kas ietaupa laiku plkst. 3:14 naktī. kad neviens nevēlas filozofiju.
Kā uzraudzīt servera darbspējas laiku bez aklajām zonām
Darbspējas laika uzraudzība nav viena pārbaude. Tā ir neliela pārbaužu ķēde, kas atbild uz dažādiem jautājumiem. Vai resursdators ir sasniedzams tīklā? Vai tīmekļa serveris atbild 80. vai 443. portā? Vai lietotne atgriež veselu lapu, nevis 500 kļūdu? Vai datubāze joprojām pieņem savienojumus? Ja uzraugāt tikai vienu slāni, varat palaist garām ļoti reālu dīkstāvi.
Pamata ICMP ping var pateikt, vai serveris ir sasniedzams, taču tas nepierāda, ka vietne vai API darbojas. TCP porta pārbaude ir labāka, jo tā apstiprina, ka konkrēts pakalpojums klausās. HTTP vai HTTPS pārbaude iet tālāk un pārbauda statusa kodu, atbildes saturu, sertifikāta derīgumu un atbildes laiku. Lielākajai daļai biznesa darba slodžu HTTP pārbaudes ir īstais patiesības centrs, jo tieši to izmanto klienti.
Te daudzas konfigurācijas kļūst mazliet pārāk optimistiskas. Zaļš ping rezultāts var visiem radīt drošības sajūtu, kamēr lietotne aiz tā nepavisam nav mierīgā stāvoklī.
Sāciet ar pareizajām darbspējas laika pārbaudēm
Vietnei uzraugiet publisko URL, izmantojot HTTPS, validējiet gaidīto atbildes kodu un pārbaudiet zināmu atslēgvārdu atbildes pamattekstā. Tas jums pasaka, ka lapa ielādējas, kā paredzēts, nevis nejauši atgriež kļūdas veidni ar 200 statusu.
API gadījumā pārbaudiet veselības galapunktu, ja tāds pastāv, taču uzmanieties no virspusējām veselības pārbaudēm. Ja galapunkts tikai saka, ka process ir dzīvs, tas var slēpt bojātus datubāzes savienojumus, neveiksmīgas kešatmiņas aizmugursistēmas vai krātuves problēmas. Noderīgāks veselības galapunkts testē atkarības, kas lietotnei patiešām ir svarīgas.
Pasta serveriem uzraugiet SMTP, IMAP vai POP3 portus tieši. Datubāzēm izmantojiet iekšējo uzraudzību, nevis publisku pārbaužu atklāšanu. Mērķis nav padarīt katru pakalpojumu publisku. Mērķis ir pārbaudīt pakalpojumu no pareizās vietas ar pareizo metodi.
Praktiska uzraudzības kopa parasti ietver ārējās darbspējas laika pārbaudes, iekšējās pakalpojumu pārbaudes un sistēmas metriku. Ārējās pārbaudes pasaka, ko piedzīvo lietotāji. Iekšējās pārbaudes pasaka, kāpēc kaut kas neizdevās. Metrika palīdz pamanīt problēmas, pirms tās kļūst par dīkstāvi.
Par ko sūtīt brīdinājumus un par ko ne
Ja katrs mazākais pīķis rada brīdinājumu, jūsu komanda pārstās uzticēties brīdinājumiem. Tā īsti incidenti tiek ignorēti. Laba darbspējas laika uzraudzība nav skaļa. Tā ir precīza.
Iestatiet brīdinājumus apstiprinātām kļūmēm, nevis pirmajām aizķeršanām. Izplatīta pieeja ir sūtīt brīdinājumu tikai pēc divām vai trim neveiksmīgām pārbaudēm pēc kārtas no vairākām vietām. Tas palīdz atfiltrēt īslaicīgus pakešu zudumus vai vienu uzraudzības mezglu, kam ir slikts rīts. Tajā pašā laikā neatlieciet brīdinājumus tik ļoti, ka klienti pamana pirmie. Līdzsvars ir atkarīgs no pakalpojuma. Tiešsaistes veikalam norēķinu stundās ir vajadzīgi stingrāki sliekšņi nekā privātam iekšējam rīkam.
Arī atbildes laikam vajadzētu būt sliekšņiem, bet uzmanīgi. Lēns nav tas pats, kas nedarbojas. Ja sākumlapa parasti ielādējas 300 ms un pēkšņi desmit minūtes aizņem 4 sekundes, tas ir pelnījis uzmanību, pat ja darbspējas laika monitors joprojām rāda zaļu. Veiktspējas pasliktināšanās bieži parādās pirms faktiskas kļūmes.
Sertifikātu derīguma termiņa beigu brīdinājumi pieder tai pašai sarunai. Tehniski SSL derīguma termiņa beigas nav servera dīkstāve, taču klienti jebkurā gadījumā redzēs bojātu pakalpojumu. No darbības viedokļa rezultāts ir pietiekami līdzīgs.
Iekšējā metrika padara darbspējas laika uzraudzību noderīgu
Ja vācat tikai darbojas vai nedarbojas pārbaudes, jūs zināsiet, ka kaut kas salūza, bet ne kāpēc. Pievienojiet sistēmas metriku un pakalpojumu metriku, lai incidentam būtu konteksts jau no pirmās minūtes.
CPU izmantojums, atmiņas noslodze, diska vieta, diska I/O gaidīšana, vidējā slodze, inode izmantojums un tīkla caurlaidspēja ir parastie sākuma punkti. Mūsdienu lietojumserveros atmiņas un krātuves problēmas ir bieži novēršamas dīkstāves cēloņi. Pilns disks ar vienu visai rupju gājienu var salauzt žurnalēšanu, datubāzes rakstīšanu, kešatmiņas darbību, dublējumkopijas un pakotņu atjauninājumus.
Lietotnes slānī sekojiet līdzi tīmekļa servera savienojumiem, pieprasījumu biežumam, kļūdu biežumam, datubāzes latentumam, rindas garumam un procesu restartiem. Ja izmantojat konteinerus, uzraugiet konteineru iziešanas un resursu limitus. Ja darbināt SaaS platformu, vērojiet arī atkarības - datubāzes replikācijas aizturi, Redis atmiņas izmantojumu, objektu krātuves pieejamību un ārējo API noildzes — tas viss var ietekmēt darbspējas laiku no klienta skatpunkta.
Rīki, kas eksportē metriku uz Prometheus un vizualizē to Grafana, labi darbojas komandām, kas vēlas detalizāciju un elastību. Vienkāršāki mitināti uzraudzības rīki bieži ir pietiekami mazākām komandām, kurām vajag uzticamus brīdinājumus bez pilnas novērojamības platformas būvēšanas. Tas ir atkarīgs no tā, cik daudz kontroles jums vajag un cik daudz laika vēlaties tērēt pašas uzraudzības uzturēšanai.
Kā uzraudzīt servera darbspējas laiku dažādās vidēs
Vienam VPS, kas mitina vienu biznesa vietni, vajag vienkāršu konfigurāciju. Ārēja HTTPS pārbaude, pamata sistēmas metrika, diska brīdinājumi, SSL derīguma termiņa uzraudzība un dublējumkopiju verifikācija nosegs lielāko daļu risku. Vienkāršai kopai jums nav vajadzīga ļoti grandioza uzraudzības impērija.
Pārvaldītam VPS vai vairāku vietņu aģentūras serverim vajag lielāku nošķīrumu. Uzraugiet katru vietni atsevišķi, nevis tikai serveri. Viena klienta vietne var atteikties bojāta PHP procesa vai datubāzes problēmas dēļ, kamēr pārējā mašīna tehniski ir kārtībā. Ja uzraugāt tikai servera līmeņa darbspējas laiku, jūs palaidīsiet garām klientiem redzamus incidentus.
Atvēlētajiem serveriem un klasterētām lietotnēm vajag mezglu līmeņa un pakalpojumu līmeņa uzraudzību. Ja viens mezgls atsakās, bet datplūsma joprojām tiek maršrutēta pareizi, pakalpojums var palikt pieejams. Tas ir labi darbspējas laikam, taču jūs joprojām vēlaties tūlītēju redzamību par atteikušos mezglu, lai redundance klusi nepazustu.
E-komercijai un SaaS darījumu pārbaudes ir pūļu vērtas. Tā vietā, lai pārbaudītu tikai sākumlapu, simulējiet galveno darbību, piemēram, pieteikšanos, meklēšanu vai produkta pievienošanu grozam. Tas noķer neveiklās situācijas, kad vietne ir tiešsaistē, bet ieņēmumi nav.
Brīdinājumu piegāde ir svarīgāka, nekā cilvēki atzīst
Uzraudzība ir noderīga tikai tad, ja pareizais cilvēks saņem brīdinājumu pietiekami ātri, lai rīkotos. Ar e-pastu vien ir pārāk lēni reāliem incidentiem. Izmantojiet vismaz vienu tūlītēju kanālu, piemēram, SMS, tālruņa eskalāciju vai uz pašpiegādi balstītu incidentu lietotni. Maršrutējiet brīdinājumus pēc nopietnības un diennakts laika. Neveiksmīgam dublējumkopijas ziņojumam nevajadzētu kādu pamodināt naktī. Beigtai ražošanas datubāzei droši vien vajadzētu.
Pārliecinieties arī, ka brīdinājumos ir pietiekami daudz konteksta. Ziņojums, kas saka "Server down", ir tehniski godīgs un operacionāli slinks. Labāks brīdinājums norāda, kura pārbaude neizdevās, no kuriem reģioniem, cik ilgi, kas nesen mainījās un kuras saistītās metrikas izskatās aizdomīgas. Tas saīsina pirmo izmeklēšanas soli, kur pazūd minūtes.
Ja jūsu nodrošinātājs piedāvā aktīvu uzraudzību un cilvēka reakciju, tas var samazināt daudz operacionālās berzes. Šī ir viena no vietām, kur pārvaldīta infrastruktūra atpelna savu vērtību. Piemēram, kodu.cloud uzraudzība un atbalsts ir veidoti tā, lai samazinātu laiku starp konstatēšanu un rīcību, kas pārrāvuma laikā ir svarīgāk nekā skaisti paneļi.
Biežākās kļūdas, kas padara darbspējas laika datus maldinošus
Viena kļūda ir servera privātās IP adreses uzraudzīšana publiskā ieejas punkta vietā. Tas pierāda, ka kaste ir dzīva, bet ne to, ka lietotāji to var sasniegt caur DNS, slodzes līdzsvarotājiem, ugunsmūriem vai TLS.
Vēl viena kļūda ir izmantot tikai vienu uzraudzības atrašanās vietu. Reģionālas maršrutēšanas problēmas notiek. Pakalpojums var būt vesels no Ņujorkas un nepieejams no Dalasas nodrošinātāja maršruta problēmas dēļ. Vairāki pārbaudes reģioni palīdz nošķirt lokālu troksni no īstiem incidentiem.
Trešā kļūda ir ignorēt apkopes logus un plānotās izmaiņas. Ja katra izvietošana izraisa viltus dīkstāves brīdinājumus, komandas kļūst nejutīgas. Kur iespējams, izmantojiet apkopes plānošanu un no atkarībām atkarīgu brīdinājumu apspiešanu.
Un tad vēl ir pārliecība par dublējumkopijām bez dublējumkopiju verifikācijas. Serverim var būt lielisks darbspējas laiks līdz pat brīdim, kad ir vajadzīga atkopšana. Uzraugiet dublējumkopiju pabeigšanu, glabāšanas ilgumu, krātuves veselību un testējiet atjaunošanu. Stingri runājot, tā nav darbspējas laika uzraudzība. Reālajā pasaulē tā pieder tai pašai drošības sistēmai.
Izveidojiet uzraudzības rutīnu, nevis tikai paneli
Spēcīgākā konfigurācija ir garlaicīga labā nozīmē. Pārbaudes notiek katru minūti vai divas. Brīdinājumi tiek testēti. Sliekšņi tiek pielāgoti pēc reāliem incidentiem. Paneļi rāda pašreizējo stāvokli, bet pārskati rāda arī tendences nedēļu un mēnešu griezumā. Jūs uzzināt, vai dīkstāvi izraisīja koda izmaiņas, izsmelti resursi, trokšņaini kaimiņi, sertifikāti ar beigušos derīguma termiņu vai vecmodīga cilvēka kļūda.
Ja šo konfigurējat no nulles, sāciet ar vienu ārēju HTTPS pārbaudi, vienu iekšēju metrikas savācēju un vienu brīdinājumu maršrutu, uz kuru kāds patiešām reaģē. Pēc tam pievienojiet pakalpojumam specifiskas pārbaudes tām kopas daļām, kas visvairāk sāp, kad tās atsakās. Uzraudzībai vajadzētu augt līdz ar biznesa risku, nevis ego.
Pareizi veikta darbspējas laika uzraudzība sniedz divas lietas: ātrāku incidentu reaģēšanu un mazāk pārsteigumu. Parasti tieši to cilvēki visu laiku ir gribējuši, pat ja sākumā prasīja paneli ar daudzām ļoti iespaidīgām līnijām.
Andres Saar klientu apkalpošanas inženieris