🥇Hur jag skrev min övervakning

Jag vill dela med mig av min historia. Kanske kan en sådan budgetlösning vara till hjälp för någon.

När jag var ung och impulsiv och inte visste var jag skulle göra av min energi, beslutade jag mig för att frilansa lite. Jag lyckades snabbt bygga upp mitt rykte och hittade ett par fasta kunder som bad mig att stödja deras servrar på en kontinuerlig basis.

Det första jag tänkte på var behovet av övervakning. Jag beslutade mig för att göra som kloka människor gör, att inte uppfinna hjulet på nytt och istället titta på färdiga lösningar som Munin eller Zabbix. Men jag upptäckte genast att webbversionen kräver en bra internetanslutning, särskilt om man öppnar den första gången på sin telefon. Om man är på landet och långt ifrån staden är det svårt att få en stabil signal. Därför valdes ett konsolalternativ för övervakning.

För konsolövervakning hjälpte atop mig bra, och programmet för att läsa atop-loggarna - atopsar. De har redan nämnts på habr, atop diskuterades till och med,men nästan ingenting nämndes om atopsar.

Installation

Mycket enkel installation, bara tre kommandon.

#Centos

yum install atop

#Debian/Ubuntu

apt-get install atop

Därefter kan man anpassa övervakningen efter sina behov eller använda standardinställningarna.

#Debian/Ubuntu/Centos

/etc/default/atop

Standardfilen:

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

Lägg till i autostart
#Debian/Ubuntu/Centos

systemctl enable atop

Starta atop som en tjänst
#Debian/Ubuntu/Centos

systemctl start atop

För den lata har jag samlat i ett kommando
#Centos

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

#Debian/Ubuntu

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

Atopsar

Tillsammans med atop installeras också atopsar, vilket är en praktisk konsolanalysator för binära loggar som de skriver loggade av atop-tjänsten. Självklart kan man läsa loggarna även med atop, men det är inte så bekvämt om man behöver fånga en lång tidsperiod.

En liten översikt över hur atopsar fungerar.

När man startar atopsar utan några nycklar öppnas loggen för dagens datum och en belastning på varje kärna redovisas separat, tillsammans med idl-raden för alla kärnor.

Nycklarna som jag använder:

-A = visa all information från loggen
-c = visa information om belastning på processorkärnorna, standardnyckel
-m = belastning på det operativa minnet och swap
-d = diskaktivitet
-O = topp-3 processer med belastning på CPU
-G = topp-3 processer med belastning på RAM
, kommer den att lägga den senaste blocken av masterkedjan i den: = topp-3 processer med belastning på disk
-N = topp-3 processer med belastning på nätverket
-r = ange sökvägen till loggen som du vill läsa om du behöver titta på belastningen från tidigare dagar
-b = tid från vilken du vill börja mata ut
-e = tid för när outputen ska avslutas
-M = skapar en extra kolumn i slutet som markerar kritikaliteten av raden (+ finns belastning, * — kritisk belastning)

Genom övervakning kan vi förstå orsaken till felaktigt serverbeteende när som helst.

Meddelanden

Så, det finns övervakning av belastningen, men det ger ändå inte möjlighet att snabbt hitta och lösa problem. Vi behöver aviseringar om uppkomna problem.

Jag är den enda som övervakar servrarna, så aviseringar måste gå till där jag alltid kan se dem och på något sätt reagera.

I början var det SMS — snabbt, pålitligt, gratis. Men sedan stängde mobiloperatörerna ner gratis SMS-utskick genom sina gateways.
E-post — långsamt, det kan finnas problem med leveransen.
Meddelandeappar — måste installeras på telefonen, det behövs skapa bots.

Som resultat av sökandet valdes meddelandeappen Telegram för dess enkelhet och bekväma app på telefon och dator.

Skapade min bot med hjälp av botfather.
Sedan lade jag upp ett par skript på servern som övervakar belastningen på servern (IDL, smartct och andra), förekomsten av fel som "oom killer", fel vid skapande av backup och andra operationer som behöver kontrolleras.

Skripten är ganska enkla, skrivna i bash, till exempel kontroll av LA och meddelande om överskridande av Load Average antal kärnor på servern.

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å servern $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=Topp 5 processer `top -b -n 1 | grep -A 5 'PID USER' | tail -5`"
    fi

Syntaxens enkelhet ger många användningsalternativ (och vem som helst som har lite programmeringskunskap kan skriva/komplettera).

Den enda detaljen — om servern är i Ryssland (och du inte har IPv6 på servern), måste du använda en proxy. För detta behövs en rad för proxyanslutning i början av skriptet:

export https_proxy=http://användarnamn:lösenord@IP.adress:port

Detta är inte slutet

Du går lugnt genom bergen med en ryggsäck på ryggen, njuter av att vara i naturen, och plötsligt får din telefon, som av en händelse hittar en signal, en notifiering om ett problem på din server. Vad göra? Den fridfulla stämningen försvinner som vinden. Ska jag ringa min fru och diktera kommandon? Ha-ha!

Jag behövde snabbt komma på ett sätt att åtgärda problemen utan bra internetanslutning. Här hjälpte messenger (#telegramlever). Jag har lärt min bot att endast kommunicera med mig, och ignorera alla andra. Nu, tillsammans med notifieringen om problemet, får jag lite mer data som hjälper mig att förstå vem som är orsaken till problemet, och jag kan försöka lösa det på distans. Det räcker att helt enkelt skicka ett meddelande till boten, höja telefonen lite så att meddelandet skickas, och voilà – boten går igång med att lösa ditt ärende. På så sätt kan jag, till exempel, döda en oönskad process, starta om en daemon, blockera en IP och så vidare.

Här har jag också överfört framtida nödvändiga förfrågningar från kunder, som exempelvis akut återställning av lösenord till användare (för ”Ååå, vi kan inte komma åt servern, vi förlorar miljoner!”), söka efter en användare med behörighet till en viss mapp, slå på och stänga av webbplatsen och annat. Självklart fortsätter jag att utveckla botens funktioner, eftersom kundernas fantasi ibland ger upphov till oväntade och oförutsedda förfrågningar. Men de flesta är nöjda.

Det finns även en version för VK, men den har på något sätt inte blivit populär.

Nu reser jag lugnt och utforskar denna värld, utan att oroa mig för att något ska gå sönder, och att jag inte kan få veta eller åtgärda det.

Källa: habr.com