Auditarea bazelor de date la Grid Partea 2: Observații post-implementare

În postarea anterioară pentru această serie, am vorbit despre cum am procedat la colectarea cerințelor pentru acest proiect, cum am luat o decizie cu privire la ce instrument să folosim și cum am planificat implementarea pentru a evita întreruperile serviciului. După cum am promis, această postare ulterioară se concentrează pe observațiile ulterioare implementării și pe ce factori au făcut ca aceasta să fie o poveste de succes pentru noi.

Instrucțiuni pregătite și filtrarea clasei de comandă

Designul nostru inițial pentru acest proiect a intenționat să utilizeze o caracteristică a pluginului percona care vă permite să filtrați evenimentele emise fie să utilizați o listă de comenzi incluse, fie de comenzi excluse ca o modalitate de a limita domeniul de aplicare la ceea ce avem de fapt nevoie să audităm.

Caracteristica se bazează pe pluginul care marchează fiecare comandă sql detectată cu o clasă bazată pe o listă inerentă mysql și de acolo decide în stratul de ieșire dacă clasa de comandă detectată ar trebui suprimată sau emisă.

Așa că am scris modelul inițial pentru a folosi funcția audit_log_exclude_commands pentru a exclude orice comenzi sql care nu au cauzat scrieri sau modificări ale datelor de rând. Am optat pentru o listă de excludere, deoarece am simțit că o listă de includere presupune riscul de a pierde oricare dintre clasele de comandă din domeniu și ar putea deveni un motiv pentru a avea lacune în jurnalele noastre de audit.

Cu toate acestea, la primul cluster pe care l-am testat, am văzut că toate comenzile auditate au fost clasificate ca erori , deși era clar că aceste instrucțiuni rulau cu succes și, în cazul modificării datelor, făceau și asta cu succes. Am văzut, de asemenea, că toate interogările au fost emise către serverul syslog centralizat, indiferent de lista de excludere care pare corelată cu acea clasificare a erorilor.

Acest lucru însemna că stocam mult mai multe evenimente în elasticsearch decât aveam de fapt nevoie, ceea ce va afecta cu siguranță capacitatea noastră de a analiza și detecta comportamentul neregulat în timp util. În colaborare cu echipa de securitate, am decis să informăm Percona despre problemă prin intermediul instrumentului de urmărire a erorilor, dar și să mutăm filtrarea bazată pe comandă în jos la stratul central de syslog.

Ca tot în inginerie, compromisul aici a fost de a trimite mai multe date prin stratul de rețea DB și de a face filtrarea în stratul de syslog centralizat mai complexă și, în schimb, a făcut nevoile noastre elastice de scalare de căutare mai ușor de gestionat și configurația din partea bazei de date mai simplă.

Performanţă

Una dintre cele mai cruciale decizii din acest proiect, care ne-a scutit de multe dureri de inimă, este decizia de a folosi facilitatea rsyslog pentru captarea și expedierea acestor log-uri către un server syslog centralizat.

Dar nimic nu este fără avantaje și dezavantaje.

Această decizie a însemnat că timpul de funcționare al unui sistem separat și fiabilitatea stivei de rețea între ele au devenit cruciale pentru a oferi SLA de care aveam nevoie pentru a oferi echipei noastre de audit încrederea în această soluție de audit.

Pentru cei care nu sunt dispuși să facă acest compromis și care au nevoie să păstreze responsabilitatea persistenței jurnalelor de audit în cadrul stivei DB, recomand să utilizeze handler-ul FILE în pluginul de audit, apoi să folosească logstash local pentru a prelua jurnalele și a le transmite către sistemul lor de analiză. alegere.

Această ultimă alegere înseamnă mult mai multe IOP-uri de disc consumate în afara procesului bazei de date și preluate de pluginul de audit și logstash și înseamnă că trebuie să echilibrați cu atenție spațiul pe disc de pe instanțele dvs. între fișierele tabelului bazei de date, jurnalele operaționale și auditul. jurnalele de pluginuri. Cântărirea opțiunilor dvs. se bazează exclusiv pe care este mai ușor de operat/acceptat de companie, dar aveți totuși opțiuni.

În cazul nostru, alegerea rsyslog s-a dovedit a avea cel mai puțin impact pentru bazele noastre de date mai aglomerate, atingând un vârf de aproximativ 5400 de tranzacții/sec, în timpul operațiunilor normale nu am văzut niciun impact asupra performanței. Plugin-ul de audit a continuat, trimițând evenimentele fără impact asupra performanței bazei de date. Totul pentru că am ales o arhitectură care a evitat consumul de operațiuni bazate pe disc din partea bazei de date.

Deciziile trecute au dat roade

Una dintre primele preocupări pe care le-am avut atunci când ne-am angajat în acest proiect a fost impactul acestuia asupra performanței. Unul dintre clusterele de baze de date din domeniu a cunoscut perioade foarte aglomerate, iar aplicațiile sale sunt sensibile la întârziere, așa că trebuia să ne asigurăm că ținem evidența valorilor de performanță, cum ar fi tranzacțiile pe secundă, utilizarea discului și a procesorului, pentru a compara numerele după implementarea pluginului și vezi care este pedeapsa pentru asta.

A fost o surpriză fericită să văd că nu am suferit prea multe penalizări în operațiunile normale. După cum am menționat mai devreme, pentru că am decis să folosim handlerul SYSLOG, asta însemna că în mod normal nu aveam nevoie să folosim nicio capacitate locală de disc pentru urmărirea acestor evenimente de audit.

Dar nici nu am vrut să planificăm doar pe baza orelor de „funcționare normală”.

De asemenea, trebuia să știm că, atunci când rsyslog trebuie să se retragă la fișierele spool locale, aceste evenimente nu se agravează în întreruperi ale serviciului care afectează clusterele DB mai critice. Testând comportamentul de spooling rsyslog sub atentă supraveghere în producție, ne-am dat seama că ultimii ani de muncă pentru a fragmenta funcțional bazele noastre de date ne-au adus beneficiul neplanificat al multor capacități de IOP-uri pe disc de a absorbi evenimente precum spooling-ul rsyslog pe disc, apoi necesar pentru a retrimite. toate aceste evenimente.

Cu siguranță am remarcat creșterea utilizării discului în timpul acestor evenimente, dar nu a dus niciodată instanțelor db într-o stare critică sau a afectat activitatea față de clienți.

Compensații

Ca tot în inginerie software, există întotdeauna compromisuri. În acest proiect, am luat în considerare o metodă de livrare a jurnalelor care era mai fiabilă și avea mai puțin potențial de pierdere a buștenilor. Asta ar implica scrierea jurnalelor pe disc, apoi folosirea a ceva de genul logstash pentru a le ingera și a le trimite către destinații de analiză pentru ca echipa de securitate să le folosească.

Dar asta ar fi însemnat un consum semnificativ de IOP-uri pe disc din partea bazei de date, despre care știam că ar putea avea un impact potențial asupra calității serviciului apelurilor adresate clienților către aceste baze de date.

Am decis că nevoile noastre de afaceri vor fi satisfăcute în mod suficient prin utilizarea înregistrării rezistente în rsyslog, folosind un spool de dimensiuni rezonabile și folosind TCP pentru a trimite evenimentele către stiva noastră de monitorizare a jurnalelor. Ca totul în viață, nimic nu este pentru totdeauna. Și suntem conștienți de faptul că această decizie ar putea fi nevoie să fie revizuită în viitor.

In cele din urma

Acest proiect, deși a cuprins o jumătate de duzină de clustere și un număr mare de instanțe, a fost finalizat într-un singur trimestru, în timp ce echipa de operațiuni DB încă a ținut lumina aprinsă într-o afacere în continuă creștere. Acest lucru nu s-ar fi putut întâmpla fără o colaborare strânsă între DBE și echipa de securitate și nu fără un management puternic al produsului care a menținut domeniul de aplicare limitat și cunoscut pentru a ne asigura că ne-am păstrat cu toții ochii pe obiectivul final de a ne face afacerea mai sigură.