Acum doi ani am făcut deja o postare Simplu failover pentru un site web despre okerr. Acum există o oarecare dezvoltare a proiectului și am publicat și eu codul sursă okerr pe partea serverului în licență deschisă, de aceea am decis să scriu această scurtă recenzie pe Habr.

[ mărime completă ]

Pe cine i-ar putea interesa

Acest lucru poate fi de interes pentru tine dacă lucrezi într-o echipă mică sau singur. Nu ai monitorizare și nu ești sigur dacă chiar ai nevoie de ea. Fie ai încercat o monitorizare serioasă populară „pentru băieții mari”, dar cumva „nu a decolat” pentru tine, fie funcționează într-o configurație aproape implicită și nu ți-a schimbat prea mult viața. Și, de asemenea, dacă cu siguranță nu intenționați să alocați un întreg angajat (sau chiar un departament) pentru a monitoriza tabloul de bord de monitorizare cel puțin câteva ore pe zi sau pentru a-l configura.

De ce okerr este neobișnuit

În continuare voi arăta caracteristici interesante ale okerrei care o deosebesc de alte sisteme de monitorizare.

Okerr este o monitorizare hibridă

În timpul monitorizării interne, pe mașinile monitorizate rulează un „agent”, care transmite date către serverul de monitorizare (de exemplu, spațiu liber pe disc). Când este extern, serverul efectuează verificări în rețea (de exemplu, ping sau disponibilitatea site-ului web). Fiecare abordare are limitele sale. Okerr folosește ambele opțiuni. Verificările în interiorul serverelor sunt efectuate de un agent foarte ușor (30Kb) sau de propriile scripturi și aplicații, iar verificările de rețea sunt efectuate prin senzori okerr din diferite țări.

okerr nu este doar un software, ci și un serviciu

Partea de server a oricărei monitorizări este mare și complexă, este dificil de instalat și configurat și necesită resurse. Cu okerr vă puteți instala propriul server de monitorizare (este gratuit și opensource), sau puteți pur și simplu să utilizați doar partea client și să utilizați serviciul serverului nostru. De asemenea gratuit.

Dacă monitorizarea vă permite să compensați și să acoperiți lipsa de fiabilitate a serverelor și aplicațiilor, atunci apare o întrebare filozofică - cine este paznicul? Cum ne va spune monitorizarea despre o problemă dacă ea însăși „a murit” dintr-un anumit motiv, separat sau împreună cu celelalte resurse ale dumneavoastră (de exemplu, canalul către centrul de date a căzut)? Când utilizați serviciul extern okerr - această problemă este rezolvată - veți primi o alertă chiar dacă întregul centru de date cu serverele dumneavoastră este fără curent sau este atacat de zombi.

Desigur, există riscul ca serverul okerr în sine să fie indisponibil, acest lucru este adevărat (după cum știți, 90% din fiabilitate este întotdeauna obținută simplu și „gratuit”, 99% cu un minim de efort, iar fiecare nouă ulterioară este exponențial mai dificil). Dar, în primul rând, șansele ca acest lucru să se întâmple sunt mai mici, iar în al doilea rând, problema poate trece neobservată doar dacă coincide cu probleme de pe serverele noastre. Dacă avem o fiabilitate de 99.9% și aveți 99.9% (numerele nu prea mari), atunci șansa unei eșecuri nedetectate este de 0.1% din 0.1% = 0.0001%. Adăugarea a trei nouă la fiabilitatea ta aproape fără efort și fără costuri este foarte bine!

Un alt avantaj al monitorizării ca serviciu este că un furnizor de găzduire sau un studio web poate instala un server okerr și poate oferi acces clienților ca serviciu suplimentar plătit sau gratuit. Concurenții tăi au doar găzduire și site-uri web, dar tu ai găzduire de încredere cu monitorizare.

Okerr este despre indicatori

Indicatorul este un „bec”. Are două stări principale - verde (OK) sau roșu (ERR). Proiectul conține mulți indicatori grupați (de exemplu, pe server). Pe pagina principală a proiectului, vedeți imediat că fie totul este verde (și îl puteți închide), fie ceva este aprins roșu și trebuie corectat. Când treceți între aceste stări, este trimisă o alertă. O dată pe zi, în timp ce îl configurați, este trimis un rezumat al proiectului.

Fiecare indicator okerr are condiții încorporate prin care își schimbă starea (în Zabbix acesta se numește declanșator). De exemplu, încărcarea medie nu trebuie să fie mai mare de 2 (desigur, aceasta este configurabilă). Și pentru fiecare verificare internă (media de încărcare, disc liber, ...) există un watchdog. Dacă din anumite motive nu primim o confirmare de succes la ora stabilită, se înregistrează o eroare și se trimite o alertă.

Modelul nostru obișnuit de lucru este să verificăm e-mailurile dimineața și să ne uităm la rezumatul printre alte scrisori (o programăm la începutul lucrului). Dacă totul este ok în el, facem alte lucruri importante (dar pentru a fi în siguranță, ne putem uita rapid la tabloul de bord okerra și ne asigurăm că totul este verde în acest moment). Dacă apare o alertă, reacționăm.

Desigur, este posibil să păstrați pur și simplu indicatorii „informaționali” (pentru a vedea imaginea rețelei din monitorizare), dar totul este făcut pentru a crea simplu, ușor și rapid indicatori special pentru monitorizarea automată și trimiterea alertelor.

Scopul pentru care configurați okerr este în alerte, astfel încât să puteți crea un indicator într-un minut, acesta ar putea „adormi” timp de un an, doar să accepte actualizări, iar când un an mai târziu se strica ceva, se aprinde și trimite o alertă. Minutul petrecut odată creând un indicator a dat roade; ați aflat despre problemă imediat, înaintea oricui. Este posibil să fi remediat înainte ca cineva să observe. Ceva care se ridică repede nu se consideră că a căzut!

Безопасность

Ar fi păcat dacă ați configura monitorizarea de dragul creșterii fiabilității, dar, ca urmare, sunteți atacat prin intermediul rețelei și există destul de multe vulnerabilități ale rețelei în diferite instrumente de monitorizare (Zabbix, Nagios).

Agent (okerrmod din pachet okerrupdate) care rulează pe sistem nu este un server de rețea, ci un client. Prin urmare, nu există porturi suplimentare deschise pe serverul monitorizat, clientul funcționează cu ușurință în spatele unui firewall sau a unui NAT și este foarte dificil (aș spune „imposibil”) de spart prin rețea, deoarece în principiu nu ascultă rețea priză.

Acoperire completă de monitorizare

Acum regula noastră este că aflăm despre toate problemele tehnice de la okerr. Dacă dintr-o dată regula este încălcată (okerr nu a avertizat despre apariția ei iminentă (dacă acest lucru este posibil) sau că a avut loc deja) - adăugăm verificări la okerr.

Verificări externe

Un set destul de tipic:

• ping
• starea http
• verificarea valabilității și prospețimii certificatului SSL (va avertiza dacă acesta este pe cale să expire)
• deschideți portul TCP și bannerul pe acesta
• http grep (pagina [nu trebuie] să conțină text specific)
• sha1 hash pentru a surprinde modificările paginii.
• DNS (înregistrarea DNS trebuie să aibă o anumită valoare)
• WHOIS (va avertiza dacă domeniul este pe cale să se deterioreze)
• Antispam DNSBL (verificare gazdă împotriva a peste 50 de liste negre antispam simultan)

Verificări interne

De asemenea, un set destul de standard (dar ușor de extins).

• df (spațiu liber pe disc)
• medie de încărcare
• opentcp (socket-uri de ascultare TCP deschise - va anunța dacă ceva a început sau s-a prăbușit)
• uptime - doar uptime pe server. Va anunța dacă s-a schimbat (adică, serverul s-a supraîncărcat)
• client_ip
• disize - îl folosim pentru a urmări când rootf-urile mașinilor noastre virtuale depășesc dimensiunea permisă, fără a introduce restricții stricte și dimensiunea directoarelor de acasă ale utilizatorilor
• empty and nonempty - monitorizează fișierele care ar trebui să fie goale (sau nu goale). De exemplu, jurnalul de erori al serverului okerr în sine ar trebui să fie gol și, dacă există chiar și o linie în el, voi primi o notificare și o voi verifica. Dar mail.log de pe serverul de e-mail NU ar trebui să fie gol (N minute după rotație). Și uneori era gol pentru noi după o actualizare a sistemului, când logrotate nu putea reporni corect rsyslog.
• linecount - numărul de linii din fișier (cum ar fi wc -l). Îl folosim ca un înlocuitor mai moale pentru gol, când jurnalul de erori poate crește, dar numai încet (de exemplu, Googlebot lovește unele pagini închise). Există o limită de 2 linii în 20 de minute. Dacă este mai mare, va exista o alertă

Verificări interne interesante

Dacă ați citit „în diagonală” până în acest moment, acum va fi mai interesant să citiți cu mai multă atenție.

backup-uri

Monitorizează backup-urile din director. Fișierele noastre de rezervă au nume precum „ServerName-20200530.tar.gz”. Pentru fiecare server din okerr, este creat indicatorul ServerName-DATE.tar.gz (data reală se schimbă la linia „DATE”). Însăși prezența unui backup proaspăt și dimensiunea acesteia sunt, de asemenea, monitorizate (de exemplu, acesta nu poate fi mai mic de 90% din backup-ul precedent).

Ce trebuie făcut pentru ca o nouă copie de rezervă să înceapă să fie urmărită după ce am început să o creăm și să o punem în acest director? Nimic! Aceasta este o abordare foarte convenabilă atunci când trebuie să faceți „nimic”, deoarece:

• A nu face „nimic” este destul de rapid, economisește timp
• Este greu să uiți să faci „nimic”
• Este greu să faci „nimic” greșit, cu o eroare. Nimic nu este cea mai fiabilă metodă

Dacă brusc nu mai apar fișiere de rezervă proaspete, va apărea o alertă. Dacă, de exemplu, ați dezactivat unul dintre servere și nu ar trebui să mai existe copii de rezervă, va trebui să ștergeți indicatorul (prin interfața web sau din shell prin API).

maxfilesz

Ține evidența dimensiunii celor mai mari fișiere (de obicei: /var/log/*). Acest lucru vă permite să detectați probleme imprevizibile, de exemplu, parole de forță brută sau trimiterea de spam prin server.

runstatus/runline

Acestea sunt două module proxy importante pentru rularea altor programe pe server. Runstatus raportează codul de ieșire din program la indicator. De exemplu, okerr nu (necesită) un modul pentru a verifica dacă serviciile systemd rulează. Acest lucru se face prin runstatus (vezi mai jos). Runline - raportează serverului linia pe care o produce programul. De exemplu, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" în configurația Runline de pe serverul nostru creează un indicator servername:temp cu temperatura procesorului.

sql

Execută o interogare numerică către MySQL și raportează rezultatul indicatorului. Într-un caz simplu, puteți face, de exemplu, „SELECT 1” - aceasta va verifica dacă SGB-ul în ansamblu funcționează.

Dar o aplicație mult mai interesantă este, de exemplu, urmărirea numărului de comenzi dintr-un magazin online. Dacă știți că aveți 100 sau mai multe comenzi pe oră, puteți seta limita minimă la 100 sau 80. Apoi, dacă vânzările scad brusc, veți primi o alertă și vă puteți da seama.

Rețineți că nu contează din ce motiv imprevizibil s-a întâmplat acest lucru:

• Serverul este pur și simplu indisponibil (deconectat sau fără rețea), iar alerta a venit din faptul că indicatorul era „putred”.
• Serverul este supraîncărcat cu ceva, funcționează încet sau se pierd pachete, este incomod pentru utilizatori și pleacă fără să facă achiziții
• Serverul este inclus în listele de spam și e-mailurile de la acesta nu sunt acceptate, utilizatorii nu se pot înregistra
• Bugetul campaniei de publicitate s-a epuizat, bannerele nu se rotesc.

Pot exista o mulțime de motive și toate nu pot fi prevăzute în avans și este dificil din punct de vedere tehnic de urmărit. Dar puteți monitoriza convenabil parametrul final (comenzile) și puteți determina din aceștia că situația este suspectă și merită să fie tratată.

Indicatori logici

Permite utilizarea expresiilor booleene (sintaxa Python) printr-un modul valida(articol despre Habré). Datele din proiect și indicatorii acestuia sunt disponibile pentru exprimare. De exemplu, în capitolul despre verificarea SQL de mai sus, este posibil să fi observat un punct slab - în timpul zilei putem avea 100 de vânzări pe oră, dar noaptea - 20, iar acest lucru este obișnuit, nu este o problemă. Ce ar trebuii să fac? Indicatorul va intra în panică în mod constant noaptea.

Puteți crea doi indicatori, zi și noapte. Faceți pe ambele „tăcuți” (nu vor trimite alerte). Și creați un indicator logic care necesită ca indicatorul de zi să fie OK înainte de ora 20:00, iar după ora 20:00 este suficient ca indicatorul de noapte să fie OK.

Un alt exemplu de utilizare a unui indicator logic este escaladare. De exemplu, un manager de proiect se dezabonează de la alerte (nu are nevoie să facă acest lucru, administratorii ar trebui să răspundă la problemele normale), dar se abonează la un indicator logic care devine roșu dacă vreun indicator din proiect nu este corectat în timpul alocat.

De asemenea, este posibil să setați ora permisă pentru lucru, de exemplu, de la 3 la 5 dimineața. Nu ne interesează dacă serverele și site-urile se blochează în acest timp. Dar la 5:00 trebuie să lucreze. Dacă nu funcționează oricând - alertă. Indicatorul logic vă permite, de asemenea, să luați în considerare redundanța serverului. Dacă aveți 5 servere web, atunci administratorii pot dezactiva 1-2 servere în orice moment. Dar dacă există mai puțin de 3 din 5 servere în luptă, va exista o alertă.

Exemplele de mai sus nu sunt funcții ok, nu unele caracteristici care trebuie activate și configurate. Okerra nu are toate aceste funcții, dar există un modul logic care vă permite să implementați această funcționalitate (aproximativ ca într-un limbaj de programare - dacă avem operatori aritmetici, atunci nu avem nevoie de o funcție specială pentru calcularea 20% TVA din limbă, puteți oricând să o faceți singur pentru a se potrivi nevoilor dvs.).

Indicatorul logic este probabil unul dintre puținele subiecte relativ complexe din okerr, dar vestea bună este că nu trebuie să-l stăpânești până nu trebuie. Dar, în același timp, extind foarte mult capacitățile, păstrând în același timp sistemul în sine destul de simplu.

Adăugarea propriilor cecuri

Mi-aș dori foarte mult să transmit ideea că okerr nu este un set de mii de cecuri gata făcute pentru toate ocaziile, ci dimpotrivă - în primul rând - un motor simplu cu o simplă abilitate de a crea propriile cecuri. Crearea propriilor verificări în okerr nu este o sarcină pentru hackeri, co-dezvoltatori de sistem sau cel puțin utilizatori avansați de okerr, ci o sarcină fezabilă pentru orice administrator care a instalat Linux pentru prima dată acum o lună.

Verificările asupra salariului minim se fac prin intermediul modulului runstatus:

Această linie din configurația runstatus vă va anunța dacă /bin/true brusc nu pornește sau returnează altceva decât 0.

true_OK=/bin/true

Doar o linie - și aici suntem deja puțin extins funcţionalitate okerr.

Chiar și o astfel de verificare are deja valoarea ei: dacă brusc serverul tău se blochează, indicatorul corespunzător de pe serverul okerr nu va fi actualizat în timp util și, după trecerea timpului, va apărea o alertă.

Această verificare va anunța că serverul apache2 s-a prăbușit (ei bine, nu se știe niciodată...):

apache_OK="systemctl is-active --quiet apache2"

Deci, dacă vorbiți orice limbaj de programare și cel puțin puteți scrie scripturi shell, atunci vă puteți adăuga deja propriile verificări.

Mai dificil - puteți scrie (în orice limbă) propriul dvs. modul pentru okerrmod. În cel mai simplu caz arată așa:

#!/usr/bin/python3

print("STATUS: OK")

Nu este foarte greu? Modulul trebuie să facă singur verificarea și să scoată rezultatele către STDOUT. Un modul mai complex oferă, de exemplu, acesta:

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

Actualizează mai mulți indicatori deodată (separați printr-o linie goală), îi creează dacă este necesar, indică detalii de verificare și o etichetă prin care este ușor să găsești indicatorii necesari în tabloul de bord.

Telegramă

Există un bot Telegram @OkerrBot. Nu trebuie să vă aglomerați telefonul cu aplicații separate (nu îmi place că pentru Pyaterochka aveți nevoie de o aplicație cu o hartă, pentru Lenta alta, pentru MTS o a treia și așa mai departe pentru toată lumea, toți, toți). O telegramă este suficientă. Prin telegram puteți primi imediat alerte, puteți verifica starea proiectului și puteți da o comandă pentru a verifica din nou toți indicatorii problematici. Am părăsit teatrul/avionul, nu ne-am ținut degetul pe puls timp de două ore, am pornit telefonul, am apăsat un buton din chatbot și ne-am asigurat că totul este în regulă.

Pagini de stare

În zilele noastre, paginile de stare sunt aproape un must have pentru orice afacere care are IT, o atitudine responsabilă față de fiabilitate și care își tratează clienții/utilizatorii cu respect.

Imaginați-vă o situație - un utilizator dorește să facă ceva, să vadă informații sau să plaseze o comandă și ceva nu funcționează. Nu știe ce se întâmplă, de partea cui este problema și când va fi rezolvată. Poate că compania dumneavoastră are pur și simplu un site web nefuncțional? Sau s-a stricat acum șase luni și se va repara în doi ani? Dar trebuie să cumperi un frigider acum, este deja în cărucior... Și e cu totul altceva când o persoană vede că ceva nu este în regulă cu tine (cel puțin este clar că problema nu este de partea lui), că problema a fost descoperită, că deja lucrați la ea și poate chiar ați notat timpul aproximativ pentru corectare. Utilizatorul se poate abona și primi o notificare prin e-mail când problema este remediată și poate face ceea ce a dorit (cumpără un frigider).

Problemele și timpul de nefuncționare se întâmplă tuturor. Dar utilizatorii și partenerii au mai multă încredere în cei care sunt mai transparenți și responsabili în abordarea lor față de acest lucru.

Aici revizuirea altor 10 proiecte care vă permit să creați pagini de stare. Iată exemple despre cum arată aceste pagini de proiect Piton и dropbox. pagina de stare okerr.

Failover

Pentru a nu face acest articol și mai lung, mă voi referi din nou la articolul meu anterior - Simplu failover pentru un site web . Dacă puteți crea un server duplicat, apoi folosind failover-ul, practic nu veți avea un timp lung de nefuncționare - de îndată ce o problemă este detectată, utilizatorii vor fi redirecționați automat către un server de rezervă funcțional. Și mi se pare că aceasta este o caracteristică foarte interesantă, strălucitoare, care este rareori disponibilă oriunde.

Cerințe reduse de sistem

Pentru serverele okerr, folosim mașini cu RAM de la 2Gb. Pentru senzorii de rețea, chiar și 512Mb este suficient. Partea client este în general aproape zero. (Punga de plastic okerrupdate cântărește 26 Kb, dar necesită Python3 și biblioteci standard). Clientul rulează dintr-un script cron, deci are un consum de memorie persistent zero. Printre aparatele pe care le-am monitorizat avem senzori (VPS super-ieftin cu 512Mb RAM) și un Raspberry Pi. Este posibil chiar și fără partea client trimite actualizări prin curl! (vezi mai jos)

Ținând cont de asta - okerr, probabil cele mai libere sistem de monitorizare dintre cele disponibile, deoarece chiar și pentru a folosi un alt sistem open-source gratuit precum Zabbix sau Nagios, trebuie să îi alocați resurse (server), iar acestea sunt deja bani. În plus, este încă necesară întreținerea serverului. Cu okerr, această parte poate fi eliminată. Sau nu trebuie să-l eliminați și să utilizați propriul dvs. server, în funcție de ceea ce vă place cel mai mult.

API și integrare în software proprietar

Arhitectură simplă și deschisă. okerr are unul destul de simplu API, cu care este ușor de lucrat. Trebuie să creați 1000 de indicatori? Un script shell de 3-4 linii va face acest lucru. Trebuie să reconfigurați 1000 de indicatori? De asemenea, este foarte ușor. De exemplu, dorim să verificăm toate certificatele noastre HTTPS de la un senzor rus:

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

Puteți actualiza indicatorul folosind modulul nostru client, chiar și fără el, doar prin curl.

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

Puteți actualiza indicatorii direct din programul dvs. De exemplu, trimiterea de semnale de bătăi ale inimii, astfel încât okerr să știe că funcționează și să tragă o alarmă dacă se blochează sau îngheață. Apropo, componentele okerr fac exact asta - okerr se monitorizează singur, iar problemele din aproape orice modul vor fi detectate și vor genera o alertă despre problemă. (Și în cazul acestui „aproape” - sunt verificate încrucișate de pe alt server)

Iată codul (simplificat) în botul nostru telegram:

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

Există o bibliotecă pentru actualizarea indicatorilor din programele Python okerrupdate, pentru orice alte limbi nu există biblioteci, dar puteți fie să apelați scriptul okerrupdate, fie să faceți o solicitare HTTP către serverul okerr.

Cum ne ajută okerr

Okerr ne-a schimbat viața. Într-adevăr. Poate că un alt sistem de monitorizare ar putea face același lucru, dar lucrul cu okerr este ușor și simplu pentru noi și are toate funcțiile de care aveam nevoie (am adăugat ceea ce nu avea). Apropo, dacă lipsesc unele funcții, întrebați și le voi adăuga (nu promit, dar vreau ca okerr să fie cel mai bun sistem de monitorizare pentru proiecte mici-medii). Sau mai bine, adaugă-l singur - este ușor.

Am reușit să trăim după principiul „învățăm despre toate problemele de la Kerra”. Dacă brusc apare o problemă despre care nu am aflat de la okerr, adăugăm o verificare la okerr. (în acest caz, prin „noi” mă refer la noi ca utilizatori ai sistemului, nu co-dezvoltatori). La început era obișnuit, dar acum a devenit foarte rar.

monitorizarea

Prin okerr monitorizăm dimensiunile jurnalelor de pe toate serverele. Este, desigur, imposibil să citiți cu atenție fiecare rând a jurnalului cu ochii, dar simpla monitorizare a ratei de creștere oferă deja multe. Prin aceasta, am descoperit căutări prin corespondență spam și cu parole de forță brută, iar când unele dintre aplicații „înnebunesc”, ceva nu le merge și le repetă din nou și din nou (adăugând de fiecare dată câteva rânduri în jurnal). ).

Certificate SSL. Aproape imediat după lansare LetsEncrypt clientul nostru a început să ofere certificate SSL gratuite clienților săi (aproximativ o mie dintre ei). Și s-a dovedit a fi doar un iad pentru administrație! Cert este că site-urile sunt „live”, clienții le cer periodic să facă ceva, programatorii o fac. Ei pot transfera complet liber site-ul pe alt DocumentRoot, de exemplu. Sau adăugați o rescriere necondiționată la configurația virtualhost. Desigur, după aceasta, reînnoirea automată a certificatelor se defectează. Acum avem toate gazdele SSL adăugate la okerr în mod automat printr-un alt util din pachet a2conf. Hai să lansăm a2okerr.py — și dacă pe server apar mai multe site-uri noi, acestea vor apărea automat în okerr. Dacă dintr-o dată, dintr-un motiv oarecare, certificatul nu este reînnoit, cu trei săptămâni înainte de expirarea certificatului, suntem la curent și ne vom da seama de ce nu este actualizat, un astfel de câine. a2certbot.py din același pachet - ajută foarte mult cu asta (verifică imediat cele mai probabile probleme - și scrie bine ce a fost verificat, și unde este cel mai probabil o problemă).

Monitorizăm data de expirare a tuturor domeniilor noastre. Și toate serverele noastre de e-mail care trimit e-mail sunt, de asemenea, verificate cu peste 50 de liste negre diferite. (Și uneori cad în ele). Apropo, știați că serverele de e-mail Google sunt și ele pe lista neagră? Doar pentru auto-testare, am adăugat mail-wr1-f54.google.com la serverele monitorizate și este încă pe lista neagră SORBS! (Acesta este despre valoarea „anti-spammeri”)

Backup-uri - Am scris deja mai sus cât de ușor este să le monitorizezi cu okerr. Dar monitorizăm atât cele mai recente backup-uri de pe serverul nostru, cât și (folosind un utilitar separat care folosește okerr) backup-urile pe care le încărcăm pe Amazon Glacier. Și, da, probleme apar din când în când. Nu e de mirare că se uitau.

Folosim indicatorul de escaladare. Arată dacă o problemă nu a fost rezolvată de mult timp. Și eu însumi, când rezolv unele probleme, uneori pot să uit de ele. Escaladarea este un bun memento, chiar dacă vă monitorizați.

În general, cred că calitatea muncii noastre a crescut cu un ordin de mărime. Aproape că nu există timpi de nefuncționare (sau clientul nu are timp să-l observe. Doar shh!), în timp ce volumul de muncă a devenit mai mic și condițiile de lucru au devenit mai calme. Am trecut de la lucrul de urgență cu peticerea găurilor cu bandă la lucru calm și măsurat, când multe probleme sunt preconizate din timp și este timp să le prevenim. Chiar și problemele care s-au întâmplat au devenit, de asemenea, mai ușor de rezolvat: în primul rând, aflăm despre ele înainte ca clienții să intre în panică și, în al doilea rând, se întâmplă adesea ca problema să fie legată de munca recentă (în timp ce făceam un lucru, am rupt altul) - deci e fierbinte Este mai ușor pentru urme să se ocupe de asta.

Dar a mai fost un caz...

Știați că în popularul Debian 9 (Stretch) un pachet atât de popular precum phpmyadmin este încă (de multe luni!) în starea vulnerabilă? (CVE-2019-6798). Când vulnerabilitatea a apărut, am acoperit-o rapid în diferite moduri. Dar am configurat monitorizarea paginii de urmărire a securității în okerr pentru a ști când va apărea o soluție „frumoasă” (prin suma SHA1 a conținutului). Indicatorul m-a zvâcnit de mai multe ori, pagina s-a schimbat, dar, după cum puteți vedea, încă (din ianuarie 2019!) nu indică că problema a fost rezolvată. Poate, apropo, cineva știe care este problema că un pachet atât de important este încă vulnerabil de mai bine de un an?

Altă dată într-o situație similară: după o vulnerabilitate în SSH, a fost necesară actualizarea tuturor serverelor. Și când setați o sarcină, trebuie să controlați execuția. (Subordonații tind să înțeleagă greșit, să uite, să se încurce și să facă greșeli). Prin urmare, mai întâi am adăugat o verificare a versiunii SSH la okerr pe toate serverele și prin okerr ne-am asigurat că actualizările au fost lansate pe toate serverele. (Convenient! Am ales acest tip de indicator și puteți vedea imediat ce server are ce versiune). Când am fost siguri că sarcina a fost finalizată pe toate serverele, am eliminat indicatorii.

De câteva ori a existat o situație în care apare o anumită problemă și apoi dispare de la sine. (probabil familiar tuturor?). Până când observi, până când verifici – și nu ai nimic de verificat – totul funcționează deja bine. Dar apoi se rupe din nou. Acest lucru sa întâmplat, de exemplu, cu produsele pe care le-am încărcat pe Amazon Marketplace (MWS). La un moment dat, inventarul încărcat a fost incorect (cantități greșite de mărfuri și prețuri greșite). Ne-am dat seama. Dar pentru a-l da seama, era important să aflăm imediat despre problemă. Din păcate, MWS, la fel ca toate serviciile Amazon, este puțin lent, așa că a existat întotdeauna un decalaj, dar totuși, am reușit să înțelegem cel puțin aproximativ legătura dintre problemă și scripturile care o cauzează (am făcut o verificare, ne-am blocat la okerr și a verificat-o imediat primind o alertă).

Un caz interesant a fost adăugat recent la colecție de un hoster european mare și scump, pe care îl folosește clientul nostru. Brusc, TOATE serverele noastre au dispărut de pe radar! În primul rând, clientul însuși (mai rapid decât okerra!) a observat că site-ul cu care lucra nu se deschidea și a făcut un bilet despre asta. Dar nu doar un site a căzut, ci toate! (Natasha, am scăpat totul!). Aici Okerr a început să trimită împachetări lungi pentru picioare cu toate indicatoarele care s-au aprins pentru el. Panică, panică, alergăm în cerc (ce mai putem face?). Apoi totul a crescut. Se pare că în centrul de date a existat întreținere de rutină (o dată la mulți ani) și, bineînțeles, ar fi trebuit să fim avertizați. Dar li s-a întâmplat un fel de problemă și nu ne-au avertizat. Ei bine, mai multe atacuri de cord, mai puține atacuri de cord. Dar după ce totul este restaurat, trebuie să verificați totul! Nu-mi pot imagina cum aș face-o cu mâinile mele. Okerr a testat totul în câteva minute. S-a dovedit că majoritatea serverelor au fost pur și simplu temporar indisponibile, dar au funcționat. Unii erau supraîncărcați, dar și s-au ridicat așa cum ar trebui. Dintre toate pierderile, am pierdut două copii de rezervă, care, conform coroanei, ar fi trebuit să fie create și încărcate în timp ce această banană plină se desfășura. Nici măcar nu m-am obosit să le creez, doar o zi mai târziu au sosit alerte că totul este OK, au apărut copiile de rezervă. Îmi place foarte mult acest exemplu pentru că okerr s-a dovedit a fi foarte util într-o situație la care nici măcar nu ne-am gândit dinainte, dar acesta este scopul monitorizării - să reziste imprevizibilului.

Pentru senzorii Okerr, folosim cea mai ieftină găzduire posibilă (unde calitatea și fiabilitatea nu sunt importante, se asigură reciproc). Așadar, recent am găsit o găzduire foarte bună și super ieftină, benchmark-urile sunt grozave. Dar... uneori se dovedește că conexiunile de ieșire de la mașina virtuală sunt realizate de la un alt IP (învecinat). Miracole. Modulul Client_ip cu https://diagnostic.opendns.com/myip primește IP greșit. Și din jurnalele de server ale indicatorului este clar că actualizarea a venit și de la acest IP vecin. Să ne ocupăm acum de sprijin. E bine că am observat asta în timp de pace. Dar, de exemplu, se întâmplă adesea ca accesul să fie înregistrat conform listei albe de IP - iar dacă serverul clipește uneori astfel pentru o perioadă scurtă de timp - puteți încerca să prindeți această problemă pentru o perioadă foarte lungă de timp.

Ei bine, încă ceva – din moment ce vorbim de găzduire VPS – folosim întotdeauna cele ieftine (hetzner, ovh, scaleway). Îmi place foarte mult atât ca benchmark-uri, cât și ca stabilitate. De asemenea, folosim mult mai scump Amazon EC2 pentru alte proiecte. Deci, datorită lui okerr, avem propria noastră opinie informată. Cad amandoi. Și nu aș spune că pe parcursul lungii perioade de observații noastre, găzduiri ieftine precum hetzner s-au dovedit a fi vizibil mai puțin stabile decât EC2. Prin urmare, dacă nu sunteți legat de alte funcții Amazon, de ce să plătiți mai mult? 🙂

Ce urmeaza?

Dacă în acest stadiu nu te-am speriat încă de Okerr, atunci încearcă! Puteți accesa direct acest link cont demo okerr (Faceți clic acum!) Dar rețineți că există un singur cont demo pentru toată lumea, așa că dacă faceți ceva, altcineva din același cont poate interfera cu dvs. în același timp. Sau (mai bine) înregistrează-te prin link-ul către offsite okerr - totul este simplu, fără SMS. Dacă nu-ți place să folosești e-mailul tău real, poți folosi unul de unică folosință, cum ar fi mailinator (recomand getnada.com). Astfel de conturi pot fi șterse în timp, dar vor fi bine pentru testare.

După înregistrare, vi se va cere să urmați un antrenament (efectuați mai multe sarcini de antrenament nu foarte dificile). Limitele inițiale sunt foarte mici, dar pentru antrenament sau un server sunt suficiente. După finalizarea instruirii, limitele (de exemplu, numărul maxim de indicatori) vor fi mărite.

Din documentație - în primul rând WIKI pe partea de server și pe client (okerrupdate wiki). Dar dacă ceva nu este clar, scrieți la support (la) okerr.com sau lăsați un bilet - vom încerca să rezolvăm totul rapid.

Dacă îl folosești cu seriozitate și aceste limite crescute nu sunt suficiente, scrie la asistență și o vom crește (gratuit).

Doriți să instalați serverul okerr pe serverul dvs.? Aici depozitul okerr-dev. Vă recomandăm să instalați pe o mașină virtuală curată, apoi o puteți face pur și simplu cu un script de instalare. Pe mașina ta virtuală - fără restricții :-). Ei bine, din nou, dacă se întâmplă ceva, vom încerca mereu să ajutăm.

Ne dorim ca acest proiect să decoleze, astfel încât lumea să devină mai de încredere datorită noastră. Datorită software-ului și serviciilor gratuite, lumea a devenit mai prietenoasă și se dezvoltă mai dinamic. Sursele pot fi stocate în github-ul gratuit, iar pentru mail poți folosi gmail-ul gratuit. Folosim gratuit freshworks pentru suport. Pentru toate acestea, nu trebuie să plătiți pentru servere, nu trebuie să descărcați și să configurați și nu trebuie să rezolvați diverse probleme operaționale. Fiecare proiect nou, fiecare echipă are imediat e-mail, depozite și CRM. Și toate acestea sunt de foarte bună calitate și gratuite și imediat. Ne dorim să fie la fel pentru monitorizare - companiile mici și proiectele ar putea folosi okerr gratuit și chiar și în stadiul de naștere și creștere au fiabilitatea proiectelor serioase pentru adulți.

Sursa: www.habr.com