Servera uzraudzības iestatīšanas ceļvedis, kas darbojas
Publicēts 2026. gada 15. jūnijā
Jūsu servera uzraudzības iestatīšanas ceļvedim jāsākas ar vienu stingru noteikumu: ja brīdinājums jūs pamodina, tam jābūt tā vērtam. Lielāko daļu uzraudzības problēmu neizraisa trūkstoši rīki. Tās rodas no trokšņainiem sliekšņiem, neskaidrām pārbaudēm un paneļiem, kas izskatās aizņemti, bet neko neatbild. Risinājums ir vienkāršāks, nekā izklausās. Pārbaudiet pareizos slāņus, izsūtiet brīdinājumus tikai par stāvokļiem, kuros nepieciešama rīcība, un pārliecinieties, ka kāds var saprast, kas noticis, mazāk nekā divās minūtēs.
Tas ir praktiskais pamats. Ja izmantojat VPS klientu vietnēm, SaaS lietotni uz dedicated server vai e-komercijas steku ar maksājumu plūsmu, jūsu uzraudzībai ir viens uzdevums - parādīt problēmas pietiekami agri, lai jums vēl būtu iespējas. Nevis pēc traucējumu lapas, nevis pēc klienta e-pasta un noteikti ne pēc tam, kad datubāze jau ir ieslīgusi nelielā traģēdijā ar swap izmantošanu.
Ko vajadzētu aptvert servera uzraudzības iestatīšanas ceļvedim
Noderīgs servera uzraudzības iestatīšanas ceļvedis nav tikai par CPU un atmiņas grafikiem. Tam jāaptver resursdatora veselība, pakalpojumu veselība, lietotnes darbība, krātuves noslodze, tīkla kvalitāte un ceļš, ko lietotāji faktiski veic. Ja kāda no šīm daļām trūkst, rodas klasiskā situācija, kurā serveris izskatās "darbojas", kamēr bizness faktiski ir apstājies.
Sāciet ar infrastruktūras slāni. Uzraugiet CPU piesātinājumu, atmiņas lietojumu, swap aktivitāti, diska vietu, diska I/O gaidīšanu, load average un tīkla caurlaidspēju. Tās ir pazīmes, ka pats serveris ir pakļauts slodzei. Virtuālajos serveros sekojiet līdzi burst modeļiem un ilgstošai noslodzei, ne tikai pīķiem. Piecu sekunžu pīķis bieži ir nekaitīgs. Trīsdesmit minūtes diska gaidīšanas ir pavisam cits stāsts.
Pēc tam pārejiet pie pakalpojumiem. Pārbaudiet, vai Nginx vai Apache atbild, vai PHP-FPM procesi nav iestrēguši, vai MySQL vai PostgreSQL pieņem savienojumus, vai Redis atbild pietiekami ātri un vai cron uzdevumi pabeidzas laikā. Sistēmām ar e-pasta iespējām vēlaties uzraudzīt arī SMTP rindas dziļumu un piegādes kļūmes. Konteinerizētām slodzēm uzraugiet restartēšanas, neveiksmīgas probes un mezgla noslodzi.
Visbeidzot, uzraugiet no ārpuses. Sintētiskās pārbaudes no citas atrašanās vietas parāda, ko redz lietotāji. Sākumlapas ielāde, API veselības galapunkti, pieteikšanās ceļi, SSL derīgums, DNS atrisināšana un atbildes laika tendences ir svarīgas, jo tās sasaista servera veselību ar reālu pakalpojuma darbību. Iekšējie rādītāji var izskatīties mierīgi, kamēr ugunsmūra izmaiņas vai beidzies sertifikāts jau ir salauzis piekļuvi.
Veidojiet iestatījumu slāņos, nevis vienā kaudzē
Vispārskatāmākajās uzraudzības konfigurācijās tiek izmantoti trīs slāņi.
Pirmais slānis ir resursu uzraudzība. Tā ir klasiskā sistēmas telemetrija, ko apkopo ik pēc dažām sekundēm vai minūtēm. Tā atbild uz jautājumu, vai mašīna ir ierobežota, tai ir atmiņas noplūde vai tā tuvojas pilnam diskam. Labi rādītāji šeit ietver CPU lietojumu pa režīmiem, brīvo atmiņu, swap ieeju un izeju, failu sistēmas lietojumu pa montēšanas punktiem, inode lietojumu, I/O latentumu un tīkla kļūdas.
Otrais slānis ir pakalpojumu uzraudzība. Tas apstiprina, ka svarīgie procesi ne tikai darbojas, bet uzvedas normāli. Tas, ka tīmekļa servera process eksistē atmiņā, nepierāda, ka pieprasījumi darbojas. Tas, ka datubāzes ports ir atvērts, nepierāda, ka vaicājumi tiek pabeigti. Šajā slānī jāiekļauj atbildes laiks, kļūdu rādītāji, rindas dziļums un neveiksmīgas restartēšanas.
Trešais slānis ir brīdinājumi ar kontekstu. Šeit daudzas komandas nogurst. Ja katrs brīdinājums pienāk bez resursdatora nosaukuma, metrikas vērtības, nesenās tendences un pamata novēršanas piezīmēm, cilvēki tērē laiku, tikai atšifrējot ziņojumu. Labs brīdinājums pasaka, kas neizdevās, kur, cik nopietni tas ir un kas ir mainījies. Žurnāli tagad stāsta to pašu stāstu - un arī jūsu brīdinājumam tas būtu jādara.
Izvēlieties sliekšņus, kas atspoguļo realitāti
Statiskie sliekšņi ir labi kā sākumpunkts, bet tiem nepieciešama pielāgošana. CPU virs 90% vienu minūti var būt normāli dublējumu vai izvietošanas laikā. Diska lietojums 80% līmenī var būt riskants datubāzes resursdatorā ar lielu žurnālu apjomu, bet pieņemams pārsvarā statiskā tīmekļa mezglā. Atmiņas brīdinājumi ir īpaši viltīgi, jo Linux pēc būtības agresīvi izmanto pieejamo RAM.
Labāka pieeja ir apvienot slieksni un ilgumu. Tā vietā, lai sūtītu brīdinājumu vienu reizi par CPU virs 85%, sūtiet brīdinājumu, ja tas saglabājas virs 85% 10 minūtes un atbildes laiks arī pieaug. Tā vietā, lai sūtītu brīdinājumu tikai par diska vietu, sūtiet brīdinājumu par zemu atlikušo ietilpību un strauju patēriņa tempu. Ja failu sistēmā palikuši 15%, bet tā piepildās ar ātrumu 10 GB stundā, tas pelna uzmanību ātrāk, nekā liecina neapstrādātais procents.
Tas ir viens no galvenajiem kompromisiem jebkurā servera uzraudzības iestatīšanas ceļvedī. Ja sliekšņus turat pārāk jutīgus, komanda sāk ignorēt trauksmes. Ja padarāt tos pārāk pielaidīgus, par problēmu uzzināt no klientiem. Neviena no šīm iespējām nav īpaši eleganta.
Metrikas ir noderīgas, bet attēlā jābūt arī žurnāliem un dublējumiem
Uzraudzība nedrīkst pastāvēt izolēti. Kad tiek aktivizēts brīdinājums, nākamais solis parasti ir žurnāli. Sistēmas žurnāli, tīmekļa servera žurnāli, datubāzes žurnāli un lietotnes žurnāli palīdz apstiprināt, vai problēma ir slodze, neveiksmīga izvietošana, uzbrukuma plūsma, sertifikāta problēma vai bojāta krātuve. Ja jūsu uzraudzības platforma nevar vismaz norādīt jūs uz šiem pierādījumiem, reakcijas laiks kļūst garāks, nekā tam vajadzētu būt.
Arī dublējumi šeit ir svarīgi, lai gan tehniski tā nav uzraudzība. Ja brīdinājumi parāda bojājumus, neveiksmīgus jauninājumus vai pēkšņu datu zudumu, jūsu pārliecība ir tieši saistīta ar dublējumu redzamību. Uzraugiet backup job success, dublējuma vecumu, repozitorija sasniedzamību un atjaunošanas testu rezultātus. Zaļa dublējuma nozīmīte, kas nekad nav pārdzīvojusi atjaunošanu, ir vairāk optimisms nekā darbība.
Minimālās pārbaudes, kas lielākajai daļai komandu tiešām ir vajadzīgas
Ja vēlaties praktisku sākumpunktu, uzraugiet šo pirms visa eksotiskā: servera sasniedzamību, CPU, atmiņu, swap, diska ietilpību, diska I/O gaidīšanu, tīmekļa servera atbildi, datubāzes savienojumus, SSL expiration, dublējuma uzdevuma statusu un vienkāršu ārēju darbspējas pārbaudi. E-komercijas vietnei pievienojiet norēķināšanās ceļa uzraudzību un maksājumu webhook kļūmes. SaaS gadījumā pievienojiet API latentumu, darba procesu rindas dziļumu un datubāzes replikācijas aizturi, ja tas ir būtiski.
Ar to pietiek, lai novērstu daudzas aklās zonas, nepārvēršot iestatījumu par hobija projektu. Lietotnes metrikas vienmēr var pievienot vēlāk. Sāciet ar to, kas vispirms ietekmē ieņēmumus, piekļuvi vai atkopšanu.
Kā iestatīt brīdinājumus, neradot brīdinājumu nogurumu
Brīdinājumu maršrutēšana ir gandrīz tikpat svarīga kā pašas pārbaudes. Kritiskiem notikumiem nekavējoties jānonāk dežūras ceļā. Zemākas prioritātes brīdinājumi var nonākt koplietotā kanālā pārskatīšanai darba laikā. Ja katrs diska brīdinājums, sertifikāta atgādinājums un īss slodzes pīķis nonāk vienā un tajā pašā vietā ar vienādu steidzamību, svarīgie notikumi pazūd juceklī.
Izmantojiet nopietnības līmeņus ar skaidru nozīmi. Critical nozīmē tūlītēju rīcību. Warning nozīmē drīzu izmeklēšanu. Info nozīmē izsekošanu vai pārskatīšanu. Saglabājiet formulējumu mierīgu un precīzu. "Augsts datubāzes latentums uz app-db-02 12 minūtes, rakstīšana palēninās" ir daudz noderīgāk nekā "Konstatēta veiktspējas problēma."
Eskalācijas noteikumi palīdz, videi augot. Ja kritisks brīdinājums netiek apstiprināts dažu minūšu laikā, novirziet to sekundārajam kontaktam. Ja viens un tas pats brīdinājums atkārtojas vairākos resursdatoros, grupējiet to vienā incidentā. Dublikātu paziņojumu vētra nepalīdz nevienam un iespaido vēl mazāk cilvēku.
Rīki ir mazāk svarīgi nekā pārklājums un disciplīna
Tam ir daudz labu steku. Dažas komandas dod priekšroku Prometheus un Grafana metrikām un vizualizācijai. Citas izmanto integrētu hostinga uzraudzību vai pārvaldītas novērojamības platformas, jo vēlas mazāk uzturēšanas. Izvēle ir atkarīga no komandas prasmēm, budžeta un nepieciešamā pielāgošanas apjoma.
Ja jums ir spēcīgas iekšējās operāciju prasmes, elastīgs metriku steks var būt laba izvēle. Ja vēlaties mazāk kustīgu daļu un ātrāku vērtības sasniegšanu, pārvaldīta uzraudzība bieži ir saprātīgāka. Maziem un vidējiem uzņēmumiem parasti vairāk noder otrā iespēja, ja vien novērojamība pati par sevi nav produkta daļa. Neviens neatver veikalu tāpēc, ka būtu sapņojis par alertmanager pielāgošanu plkst. 2:13 naktī.
Šeit pakalpojumu sniedzējs ar operacionālo atbalstu var samazināt risku. At kodu.cloud vērtība nav tikai tajā, ka pārbaudes pastāv. Tā ir tajā, ka kāds uzrauga ar infrastruktūras kontekstu, dublējumi ir daļa no plašāka drošības tīkla un vadības virsma nav veidota tikai pilna laika sistēmadministratoriem.
Servera uzraudzības iestatīšanas ceļvedis augošām vidēm
Jūsu infrastruktūrai augot, nošķiriet uzraudzību pēc lomām. Tīmekļa mezgliem, datubāzes mezgliem, kešatmiņas mezgliem un darba mezgliem nevajadzētu visiem koplietot identiskas pārbaudes. To atteices modeļi atšķiras. Datubāzēm ļoti svarīgs ir I/O latentums, replikācija, bloķēšanas un diska pieaugums. Tīmekļa mezgliem svarīgāks ir pieprasījumu ātrums, kļūdu atbildes, procesu veselība un sertifikāta stāvoklis. Fona darba procesiem nepieciešams rindas laiks, neveiksmīgi uzdevumi un ārējo atkarību pārbaudes.
Jums vajadzētu arī pārskatīt savu uzraudzību pēc katra nozīmīga incidenta. Uzdodiet trīs jautājumus: kura pazīme parādījās pirmā, vai tā pareizi izraisīja brīdinājumu un kas būtu saīsinājis diagnostiku. Tieši šajā pārskatā uzraudzība kļūst labāka. Nevis pievienojot divdesmit jaunus grafikus, bet novēršot nenoteiktību.
Mierīga uzraudzības konfigurācija ir tāda, kas brīdina pirms kaitējuma, klusē, kad sistēma ir veselīga, un padara nākamo darbību acīmredzamu, kad kaut kas nav kārtībā. Veidojiet uz to, un pakalpojums atkal būs mierīgs biežāk nekā ne.
Andres Saar Klientu apkalpošanas inženieris