Hvordan jeg skrev min overvågning

Jeg vil dele min historie. Måske kan sådan en budgetløsning være nyttig for nogen.

Da jeg var ung og energisk og ikke vidste, hvad jeg skulle lave med min energi, besluttede jeg at freelance lidt. Jeg fik hurtigt opbygget min vurdering, og jeg fandt et par faste kunder, der bad mig om at vedligeholde deres servere løbende.

Det første, jeg tænkte på, var behovet for overvågning. Jeg besluttede at gøre som kloge mennesker gør, ikke genopfinde krukken, men kigge på færdige løsninger som Munin eller Zabbix. Men jeg fandt hurtigt ud af, at webversionen kræver en god internetforbindelse, især hvis man åbner den første gang fra sin telefon. Hvis man er på ferie i naturen langt fra byen, er det svært at få en stabil forbindelse. Derfor valgte jeg en konsolversion af overvågningen.

Som konsolovervågning fik jeg stor hjælp fra atop og programmet til at læse atop-logfilerne — atopsar. De er allerede blevet nævnt på habr, atop er endda blevet analyseret, men næsten ingenting er blevet sagt om atopsar.

Installation

Meget enkel installation, kun tre kommandoer.

#Centos

yum install atop

#Debian/Ubuntu

apt-get install atop

Derefter kan man tilpasse overvågningens funktionalitet eller bruge standardindstillingerne.

#Debian/Ubuntu/Centos

/etc/default/atop 

Standardfil:

 #cat /etc/default/atop
INTERVAL=60                    #Время, через которое создаётся снимок нагрузки в секундах, по умолчанию каждые 10 минут
LOGPATH="/var/log/atop"        #Путь до папки хранения логов
OUTFILE="$LOGPATH/daily.log"   #Название файла логов за сегодняшний день

Tilføj til automatisk opstart
#Debian/Ubuntu/Centos

systemctl enable atop 

Start atop som daemon
#Debian/Ubuntu/Centos

systemctl start atop  

For de dovne har jeg samlet det i én kommando
#Centos

yum install atop && systemctl enable atop && systemctl start atop

#Debian/Ubuntu

apt-get install atop && systemctl enable atop && systemctl start atop

Atopsar

Sammen med atop installeres også atopsar, som er en praktisk konsolanalysetool til de binære logfiler, som daemonen atop fører. Man kan selvfølgelig læse logfilerne med atop, men det er ikke så praktisk, hvis man skal fange en længere tidsperiode.

En kort introduktion til brugen af atopsar.

Når atopsar startes uden parametre, åbnes loggen for i dag, og belastningen på hver kerne vises separat samt en idl-linje for alle kerner.

De parametre, jeg bruger:

-A = vis al information fra loggen
-c = vis information om belastningen på CPU'ens kerner, standardnøgle
-m = belastning på RAM og swap
-d = diskaktivitet
-O = top-3 processer med belastning på CPU
-G = top-3 processer med belastning på RAM
-D = top-3 processer med belastning på disk
-N = top-3 processer med belastning på netværk
-r = angiv stien til loggen, som du gerne vil læse, hvis du vil se belastningen fra tidligere dage
-b = tidspunktet, hvor output skal starte
-e = tidspunktet, hvor output skal slutte
-M = opretter en ekstra kolonne i slutningen, der markerer kritikaliteten af linjen (+ der er belastning, * — kritisk belastning)

Takket være overvågning kan vi forstå årsagen til serverens ukorrekte adfærd når som helst.

Underretninger

Så overvågningen af belastningen er til stede, men den giver stadig ikke mulighed for hurtigt at finde og løse problemer. Vi har brug for underretninger om opståede problemer.

Jeg overvåger serverne alene, så underretningerne skal sendes til steder, hvor jeg altid vil kunne se dem og reagere på dem.

I starten var der SMS — hurtigt, pålideligt, gratis. Men derefter lukkede mobiloperatørerne den gratis SMS-udsendelse gennem deres gateways.
E-mail — langsomt, der kan være problemer med leveringen.
Messenger — man skal installere det på telefonen, man skal oprette bots.

Som et resultat af søgningen blev messenger Telegram valgt for sin enkelhed og praktiske applikation på telefonen og desktop.

Jeg lavede min egen bot ved hjælp af botfather.
Derefter lagde jeg nogle scripts på serveren, der overvåger serverens belastning (IDL, smartct osv.), tilstedeværelsen af fejl af typen 'oom killer', fejl under backup-oprettelse og andre operationer, som skal kontrolleres.

Scripts er ret enkle, skrevet i bash, for eksempel kontrol af LA og underretning om overskridelse af Load Average i forhold til antallet af kerner på serveren.

if [ ${LA[0]} -gt 2000 ] || [ ${LA[1]} -gt 3000 ] || [ ${LA[2]} -gt 4000 ]
    then
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=På serveren $ip LA $LAd"
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=`top -b -n 1 | grep Cpu`"
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=Top 5 processer `top -b -n 1 | grep -A 5 'PID USER' | tail -5`"
    fi

Syntaksens enkelhed giver mange anvendelsesmuligheder (og enhver, der har lidt kendskab til programmeringssproget, kan skrive/tilføje).

Den eneste detalje — hvis serveren befinder sig i Rusland (og du ikke har IPv6 på serveren), er det nødvendigt at bruge proxy. I begyndelsen af scriptet skal man angive forbindelseslinjen til proxyen:

export https_proxy=http://login:password@IP.adresse:port

Det er ikke slutningen

Du går roligt gennem bjergene med en rygsæk på ryggen, tager en pause fra civilisationen, og pludselig sender din telefon, der tilfældigt fanger signal, en besked om et problem på din server. Hvad gør man? Den fredelige stemning forsvinder som dug for solen. Skal man ringe til konen og diktere kommandoer? Ha-ha!

Jeg måtte hurtigt finde på en måde at løse de opståede problemer hurtigt og uden godt internet. Her reddede messenger mig igen (#telegramlever). Jeg har lært min bot kun at kommunikere med mig og ignorere alle andre. Nu, sammen med meddelelserne om problemer, får jeg lidt flere oplysninger, så jeg kan forstå, hvad kilden til problemet er, og jeg kan forsøge at løse det eksternt. Det er nok bare at skrive en besked til botten, løfte telefonen lidt, så beskeden kommer igennem, og voilà — botten klarer dit arbejde. På den måde kan jeg f.eks. dræbe en uønsket proces, genstarte en daemon, blokere en IP og meget mere.

Desuden har jeg flyttet fremtidige nødvendige forespørgsler fra kunderne, såsom hurtige nulstillinger af adgangskoder til brugere (fordi "Aaaah, vi kan ikke komme ind på serveren, vi taber millioner!") , finde brugeren med adgang til den ønskede mappe, tænde og slukke for hjemmesiden og andre. Selvfølgelig forbedrer jeg hele tiden botens funktionalitet, da kundernes fantasi nogle gange giver mig uventede og ikke-forudsete forespørgsler. Men de fleste er tilfredse.

Der er også en version til VK, men den har ikke rigtigt fået fodfæste.

Nu rejser jeg roligt og udforsker denne verden uden at frygte, at noget går i stykker, og at jeg ikke kan finde ud af det eller rette det.

Kilde: habr.com