Kā uzraudzīt Linux serveri ar bezmaksas rīkiem

Tev nav vajadzīga maksas monitoringa sistēma, lai zinātu, kas notiek ar tavu Linux serveri. Katrā distribūcijā jau ir rīki, kas atbild uz ikdienas jautājumiem: vai CPU ir pārslogots, vai diskam iet grūti, kāpēc nomira serviss, kas ir pieslēdzies. Šī rokasgrāmata iziet cauri šiem rīkiem ar konkrētiem sliekšņiem un beigās parāda piecu minūšu cron pārbaudi, kas nosūta brīdinājumu uz Telegram vai e-pastu, kad tava vietne nokrīt.

CPU un atmiņa: top un htop

top ir iepriekš instalēts visur; htop ir vieglāk lasāms, un to ir vērts ieinstalēt:

apt install htop      # Debian/Ubuntu
dnf install htop      # RHEL/Alma/Rocky
htop

Vispirms nolasi vidējo slodzi (load average): trīs skaitļi, kas rāda 1, 5 un 15 minūšu vidējās vērtības. Noteikums ir vienkāršs: salīdzini slodzi ar kodolu skaitu, ko izdrukā nproc. Slodze 4.0 uz 4 kodolu servera nozīmē, ka CPU ir pilnībā aizņemts. Ja slodze ilgstoši turas virs kodolu skaita, procesi stāv rindā un viss kļūst lēnāks. Slodze 2.5 uz 8 kodoliem nav nekas; slodze 2.5 uz 1 kodola ir problēma.

Svarīgi ir vēl divi lauki. wa (iowait) CPU rindā ir laika daļa, ko CPU pavada, gaidot disku: ja tā pastāvīgi ir virs 10 procentiem, tavs šaurais kakls ir disks, nevis CPU, tāpēc ej tālāk pie iostat. Atmiņai skaties RES kolonnu katram procesam (reāli izmantotā RAM, atšķirībā no gandrīz bezjēdzīgās VIRT) un vērtē pēc pieejamās atmiņas, nevis brīvās: Linux apzināti izmanto brīvo RAM diska kešam un atbrīvo to pēc pieprasījuma.

Diska I/O: iostat un ko nozīmē await

iostat atrodas sysstat pakotnē:

apt install sysstat
iostat -x 5

Tas izdrukā paplašinātu statistiku ik pēc 5 sekundēm. Pirmo bloku ignorē, tas ir vidējais rādītājs kopš ielādes. Svarīgas ir divas kolonnas:

• r_await / w_await: vidējais laiks milisekundēs, ko aizņem lasīšanas vai rakstīšanas pieprasījums, ieskaitot gaidīšanu rindā. Tas ir labākais atsevišķais skaitlis jautājumam "vai manam diskam iet grūti".
• %util: cik aizņemta ir ierīce. 100 procenti uz moderna SSD nav automātiski liktenīgi, jo tas apkalpo pieprasījumus paralēli, bet kopā ar augstu await tas apstiprina piesātinājumu.

Atskaites punkti await vērtībai: NVMe jābūt zem 1 ms, SATA SSD 1 līdz 5 ms, rotējošiem diskiem 5 līdz 15 ms. Ilgstoši desmiti milisekunžu nozīmē, ka disks ir šaurais kakls: vai nu kāds process moka disku (atrodi to ar iotop vai pidstat -d 5), vai arī sējums patiešām ir par lēnu šai slodzei.

Diska vieta: df, du un 80 procentu noteikums

df -h parāda izmantojumu katrai failu sistēmai. Darba noteikums: rīkojies pie 80 procentiem. Pēc tam datubāzēm un servisiem ar daudz logiem rezerve beidzas ātri, un pilnīgi pilna saknes sadaļa lauž lietas neglītā veidā: servisi nevar ierakstīt PID failus, atjauninājumi apstājas pusceļā, dažreiz nevar pat normāli ielogoties.

df -h
df -i

df -i pārbauda inode skaitu: sadaļa var būt pilna, kaut brīvi ir gigabaiti, ja miljoniem sīku failu (sesijas, kešs, pasta rinda) ir apēduši visus inode. Lai atrastu, kas patiesībā aizņem vietu, ej dziļumā ar du:

du -xh --max-depth=1 / | sort -h | tail -15
du -sh /var/log/* | sort -h | tail -10

Parastie aizdomās turamie ir /var/log, veci backup faili un systemd žurnāls. Ierobežo žurnālu, lai tas vairs neaug:

journalctl --vacuum-size=500M

Logi un savienojumi: journalctl un ss

Kad kaut kas neuzvedas pareizi, pajautā žurnālam, pirms sāc minēt:

journalctl -p err -b
journalctl -u nginx --since "1 hour ago"
journalctl -f
journalctl -k --grep=oom

Pirmā komanda parāda visas kļūdas kopš ielādes, otrā aprobežojas ar vienu servisu, trešā seko dzīvajā režīmā. Pēdējā meklē kodola ziņojumos OOM killer: ja process pazuda bez pēdām, kodols to visticamāk nogalināja par visas RAM apēšanu, un tieši šeit tas tiek pierakstīts.

Tīkla jautājumiem ss ir aizstājis netstat:

ss -tulpn
ss -s
ss -tn state established | wc -l

ss -tulpn parāda katru klausošos soketu un procesu aiz tā. Palaid to pēc katra deploy; viss, ko neatpazīsti, ir pelnījis izmeklēšanu. ss -s izdrukā kopsummas, un izveidoto savienojumu skaitīšana laika gaitā pasaka, vai pīķis ir īsta plūsma vai savienojumi, kas iestrēguši atvērti dēļ salūzuša klienta vai lēna backend.

Cron pārbaude ar Telegram vai e-pasta brīdinājumiem

Vienkāršu pieejamības brīdināšanu vari uzbūvēt pats piecās minūtēs. Izveido botu caur @BotFather Telegram, nokopē tokenu, nosūti botam vienu ziņu un tad iegūsti savu skaitlisko chat id:

curl -s "https://api.telegram.org/bot$TOKEN/getUpdates"

Saglabā šo kā /usr/local/bin/healthcheck.sh un padari to izpildāmu:

#!/bin/bash
URL="https://example.com/health"
TOKEN="123456:AA...tava-bota-tokens"
CHAT="987654321"

CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$URL")
if [ "$CODE" != "200" ]; then
    curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" \
        -d chat_id="$CHAT" -d text="ALERT: $URL atgrieza HTTP $CODE"
fi

Tad ieplāno to ik pēc 5 minūtēm:

*/5 * * * * /usr/local/bin/healthcheck.sh

Labāk e-pastu? Aizstāj Telegram izsaukumu ar echo "$URL atgrieza $CODE" | mail -s "Servera brīdinājums" tu@example.com, kam vajag mailutils un nokonfigurētu MTA. Tas pats skripts var uzraudzīt arī 80 procentu diska noteikumu: nolasi izmantojumu ar df -P / | awk 'NR==2 {print $5}' un brīdini, kad tas pārkāpj robežu.

Viens godīgs brīdinājums: palaid pārbaudi no citas mašīnas, nevis no tās, kuru uzraugi. Serveris, kas ir nokritis, nevar pats par sevi ziņot. Pietiek ar lētāko otro VPS vai Raspberry Pi mājās.

Kad pāriet uz īstu monitoringu

Manuālais rīku komplekts pārstāj pietikt paredzamā brīdī. Pāriet uz pilnvērtīgu sistēmu, kad kaut kas no šī kļūst patiess:

• Tev ir vairāk nekā divi vai trīs serveri, un tu ielogojies katrā, lai tos pārbaudītu.
• Tev vajag vēsturi: htop nevar atbildēt uz "vai disks bija lēns vakar 14:30".
• Tu gribi brīdinājumus par tendencēm, piemēram, disku, kas pēc trim dienām sasniegs 80 procentus, nevis tikai strādā vai nestrādā.
• Sistēmas stāvokli vajag redzēt vēl kādam bez tevis.

Standarta bezmaksas pašizvietotā atbilde ir Prometheus ar node_exporter un Grafana, vai Zabbix, ja gribi vienu integrētu sistēmu; Netdata dod tūlītēju sekundes precizitātes skatu uz vienu mašīnu. Visi ir bezmaksas rīki ar reālām izmaksām uzstādīšanas un uzturēšanas laikā, tāpēc ievies tos tad, kad manuālās pārbaudes sāk ēst stundas.

Un esi godīgs pret to, ko rāda skaitļi. Ja slodze ilgstoši turas virs kodolu skaita vai await uz noslogota diska turpina augt, risinājums ir vairāk dzelžu, nevis vairāk grafiku: salīdzini savus skaitļus ar mūsu VPS plāniem, pirms tērē nedēļu optimizācijai. Un ja negribi lasīt grafikus trijos naktī, mūsu IT atbalsta komanda var pārņemt monitoringu un reaģēšanu uz incidentiem.