Shell skripte za monitoring i alerting na Linux terminalu

Article Image

Zašto pisati sopstvene shell skripte za monitoring na terminalu?

Kao administrator ili developer, često vam je potrebna brza i laki način da pratite stanje sistema bez kompleksnih alata. Shell skripte vam omogućavaju da kreirate lagane, prenosive i lako prilagodljive provere koje pokrećete iz terminala ili zakazujete preko cron-a. Vi možete brzo da proverite zauzeće diska, korišćenje memorije, status procesa ili greške u log fajlovima i automatski generišete upozorenja kada nešto nije u redu.

Prednosti vlastitih skripti uključuju: potpuna kontrola nad logikom, mala potrošnja resursa, mogućnost integracije sa postojećim alatima (mail, systemd, slack webhook), i brzina iteracije. U praksi ćete koristiti skripte za rutinske provere, agregiranje rezultata i slanje alert poruka — često pre nego što složeniji sistemi detektuju problem.

Koje koncepte i alate treba da poznajete pre nego što počnete

Osnovne provere koje ćete implementirati

  • Disk usage: proveravanje % zauzeća particija (df, awk) i alarm pri prekoračenju praga.
  • Memorija i swap: praćenje slobodne memorije i neočekivanog rasta potrošnje (free, /proc/meminfo).
  • CPU i load average: kratkoročne i dugoročne anomalije (top, mpstat, /proc/loadavg).
  • Procesi i servisi: da li ključni procesi trče i automatsko restartovanje (ps, pgrep, systemctl).
  • Log fajlovi: praćenje novih error/warn linija i pattern matching (tail, grep, awk).

Alati i tehnike za robusno alertovanje

  • bash/zsh: osnovni interpreter za skripte; pišite čitljiv, modularan kod.
  • cron/systemd timers: zakazivanje periodičnih provera ili postavljanje watchdog logike.
  • mailx/postfix ili sendmail: jednostavno slanje e-mail upozorenja iz skripte.
  • curl ili netcat: slanje notifikacija prema Slack/Discord/Webhook endpointima.
  • logger: upisivanje događaja u syslog radi centralizovanog praćenja.
  • exit kodovi i validacija: koristi se povratni kod (0 = OK, 1 = WARN, 2 = CRITICAL) kako bi druge automatizacije mogle da reaguju.

Pre nego što napišete prvu skriptu, planirajte koje metrike su kritične za vaš sistem, definišite pragove upozorenja i odaberite kanal za alert (terminal, e-mail, webhook). Takođe proverite prava pristupa i putanje (PATH) kako bi skripte mogle neometano da se izvršavaju pod cron-om ili systemd servisem.

U sledećem delu ćete videti konkretnu, jednostavnu skriptu za proveru zauzeća diska i primer kako je povezati sa e-mail alertom i cron zakazivanjem.

Primer: skripta za proveru zauzeća diska i slanje e-mail alerta

Donji primer je jednostavna, ali praktična skripta koja proverava % zauzeća za sve montirane particije i šalje e-mail kada neko zauzeće pređe definisani prag. Skripta takođe loguje događaje u syslog i vraća odgovarajući exit kod (0 = OK, 1 = WARN/ALERT).

#!/bin/bash
# /usr/local/bin/check_disk.sh
THRESHOLD=85
EMAIL="[email protected]"
STATEFILE="/var/tmp/check_disk.state"
OK=0
ALERT=1

# Provera dostupnosti potrebnih komandi
for cmd in df awk mailx logger; do
  command -v $cmd >/dev/null 2>&1 || { echo "$cmd not found"; exit 2; }
done

alerts=""
while read -r usep mount; do
  usep_num=${usep%%}
  if [ "$usep_num" -ge "$THRESHOLD" ]; then
    alerts+="$mount: $usep
"
  fi
done 1 {print $5, $6}')

if [ -z "$alerts" ]; then
  logger -t check_disk "OK: Disk usage below ${THRESHOLD}%"
  echo "OK" > "$STATEFILE"
  exit $OK
else
  # Debounce: pošalji email samo ako prethodno nije bilo alarma
  prev=$(cat "$STATEFILE" 2>/dev/null || echo "OK")
  if [ "$prev" != "ALERT" ]; then
    echo -e "Disk Alert on $(hostname):

$alerts" | mailx -s "CRITICAL: Disk usage" "$EMAIL"
    logger -t check_disk "ALERT: Disk usage >= ${THRESHOLD}% on: $(echo -e $alerts | tr '
' ' ; ')"
  fi
  echo "ALERT" > "$STATEFILE"
  exit $ALERT
fi

Objašnjenje ključnih delova:

  • df -hP: sigurna, parsabilna izlazna forma za sve fajl-sisteme.
  • STATEFILE: jednostavan mehanizam za “debounce” kako se ne bi slali duplikatni alertovi pri svakom pokretanju cron-a.
  • mailx: primer slanja e-maila; kod vas može biti sendmail ili ssmtp zavisno od instaliranog MTA.
  • logger: upis u syslog radi istorije i centralizovanog prikupljanja.
Article Image

Zakazivanje skripte preko cron-a i praktične napomene

Najjednostavniji način da periodično pokrećete skriptu je cron. Ako želite da proveravate zauzeće svakih 5 minuta, dodajte sledeću liniju u crontab korisnika (npr. root):

/5    * /usr/local/bin/check_disk.sh >/dev/null 2>&1

Važne napomene pri korišćenju cron-a:

  • Postavite apsolutne putanje u skripti (npr. /usr/local/bin/check_disk.sh) i ne oslanjajte se na PATH; cron ima ograničen okruženje.
  • Obavezno dodelite odgovarajuće permisije: chmod +x /usr/local/bin/check_disk.sh i osigurajte da statefile (npr. /var/tmp) može da piše korisnik koji pokreće skriptu.
  • Ako koristite mailx preko cron-a, proverite da li cron šalje e-mail ispravno (na nekim sistemima je potrebno podesiti MAILTO ili MTA).
  • Za kritičnije sisteme razmotrite systemd timer umesto cron-a — lakše se integriše sa journald i restart politikom.

Poboljšanja i integracija: suppress, višekratni kanali i webhook

Nakon osnovne implementacije, dodajte funkcije koje će napraviti vaš monitoring robusnijim:

  • Suppressing/interval: pratite broj uzastopnih alarma u state fajlu pre slanja notifikacije (npr. samo nakon 3 uzastopna alarma pošalji e-mail).
  • Mnogi kanali: osim e-maila, možete koristiti curl da pošaljete payload na Slack/Discord webhook ili HTTP endpoint. Primer: curl -X POST -H 'Content-Type: application/json' -d "{"text":"Disk alert"}" $WEBHOOK.
  • Centralizacija: logovanje događaja u syslog omogućava da ih skupljate sa rsyslog/ELK/Graylog za kasniju analizu.

U sledećem delu ćemo pokazati primer skripte za praćenje log fajlova (tailing + pattern matching) i kako automatski restartovati servis kada se otkrije kritična greška.

Article Image

Dalji primer: praćenje logova i automatsko restartovanje servisa

U nastavku planirate da implementirate skriptu koja nadgleda log fajlove (tail -F) i traži kritične obrasce (regex). Kada se obrazac pojavi određeni broj puta u kratkom periodu, skripta može pokušati automatski da restartuje servis (systemctl restart) i pošalje notifikaciju na više kanala. Predlog toka rada u visokom nivou:

  • Koristite tail -F ili journalctl -f za kontinuirano praćenje izvora loga.
  • Filtrirajte linije regex-om i grupišite događaje u vremenskim prozorima (npr. broj grešaka u poslednjih 5 minuta).
  • Dodajte debounce i rate-limit mehanizme da izbegnete restart petlje i preplavljivanje notifikacijama.
  • Pre restartovanja pokušajte bezbedne korake: dump statusa servisa, rotacija loga, backoff pre ponovnog pokušaja.
  • Logujte sve akcije u syslog i čuvajte dovoljno kontekstualnih podataka za post-mortem analizu.

Završne napomene i sledeći koraci

Prilikom uvodjenja skripti u produkciju, fokusirajte se na sigurnost, testiranje i operativnu održivost: pokrenite sve promene prvo u staging okruženju, dodajte monitoring promena i obavezno postavite limit-e za restartovane akcije. Razmotrite prelazak sa cron-a na systemd timers kada želite bolju integraciju sa journald i upravljanje servisima — više informacija o tome možete naći na systemd timers.

Gradite skripte iterativno: počnite sa jednostavnim proverama, pratite metrike i alertove, pa postepeno dodajte višekanalne notifikacije, suppress logiku i centralizovano prikupljanje logova.

Frequently Asked Questions

Kako da sprečim slanje ponovljenih alertova?

Koristite state fajl ili brojač uzastopnih alarmnih događaja i prag (npr. pošalji obaveštenje tek nakon 3 uzastopna alarma). Dodajte cooldown period nakon slanja notifikacije i implementirajte deduplikaciju na nivou notifikacionog kanala (Alertmanager, Slack thread, itd.).

Mogu li umesto mailx koristiti Slack ili webhook?

Da, možete koristiti curl da pošaljete JSON payload na Slack/Discord webhook ili sopstveni HTTP endpoint. Vodite računa o autentifikaciji, retry logici i ograničenjima rate limita na strani primatelja.

Da li je bolje koristiti cron ili systemd timer za pokretanje skripti?

Cron je jednostavan i široko podržan, dobar za osnovne intervale. Systemd timeri nude finiju kontrolu, integraciju sa journald, opcije ponovnog pokretanja i lakše upravljanje životnim ciklusom — za kritične servise često je preporučljivije koristiti systemd timer.

By