Cum diferă agregarea metricilor de agregarea logurilor? Nu pot jurnalele să includă metrici? Sistemele de agregare a logurilor nu pot face aceleași lucruri ca și sistemele de agregare a metricilor?

Acestea sunt întrebări pe care le aud des. Am văzut, de asemenea, vânzători care își prezintă sistemul lor de agregare a jurnalelor ca fiind soluția la toate problemele de observabilitate. Agregarea logurilor este un instrument valoros, dar, în mod normal, nu este un instrument bun pentru datele din serii de timp.

Câteva caracteristici valoroase ale unui sistem de agregare a măsurătorilor din serii de timp sunt intervalul regulat și sistemul de stocare personalizat special pentru datele din serii de timp. Intervalul regulat permite unui utilizator să obțină rezultate matematice reale în mod constant. În cazul în care un sistem de agregare a jurnalelor colectează metrice într-un interval regulat, acesta poate funcționa potențial în același mod. Cu toate acestea, sistemul de stocare nu este optimizat pentru tipurile de interogări care sunt tipice pentru un sistem de agregare a metricilor. Aceste interogări vor necesita mai multe resurse și mai mult timp pentru a fi procesate cu ajutorul sistemelor de stocare găsite în instrumentele de agregare a jurnalelor.

Donc, știm că un sistem de agregare a jurnalelor nu este probabil potrivit pentru datele din serii de timp, dar la ce este bun? Un sistem de agregare a jurnalelor este un loc excelent pentru colectarea datelor de eveniment. Acestea sunt activități neregulate care sunt semnificative. Un exemplu ar putea fi jurnalele de acces pentru un serviciu web. Acestea sunt semnificative deoarece dorim să știm ce accesează sistemele noastre și când. Un alt exemplu ar fi o condiție de eroare a aplicației – deoarece nu este o condiție normală de funcționare, ar putea fi valoroasă în timpul depanării.

O mână de reguli pentru logare:

• DO includeți un timestamp
• DO formatați în JSON
• Nu înregistrați evenimente nesemnificative
• DO înregistrați toate erorile aplicației
• MAI poate înregistra avertismente
• DO activați înregistrarea
• DO scrieți mesajele într-un format uman-.citibilă de către om
• Nu înregistrați date informative în producție
• Nu înregistrați nimic la care un om nu poate citi sau reacționa

Costuri de cloud

Când investigați instrumentele de agregare a jurnalelor, cloud-ul ar putea părea o opțiune atractivă. Cu toate acestea, ea poate veni cu costuri semnificative. Jurnalele reprezintă o mulțime de date atunci când sunt agregate pe sute sau mii de gazde și aplicații. Ingestia, stocarea și recuperarea acestor date sunt costisitoare în sistemele bazate pe cloud.

Ca punct de referință dintr-un sistem real, o colecție de aproximativ 500 de noduri cu câteva sute de aplicații rezultă în 200 GB de date de jurnal pe zi. Probabil că există loc pentru îmbunătățiri în acel sistem, dar chiar și reducerea la jumătate va costa aproape 10.000 de dolari pe lună în multe oferte SaaS. Acest lucru include adesea o reținere de numai 30 de zile, ceea ce nu este foarte mult timp dacă doriți să vă uitați la tendințele datelor de la un an la altul.

Acest lucru nu este pentru a descuraja utilizarea acestor sisteme, deoarece ele pot fi foarte valoroase – în special pentru organizațiile mai mici. Scopul este de a sublinia faptul că ar putea exista costuri semnificative și poate fi descurajant atunci când acestea sunt realizate. Restul acestui articol se va concentra pe soluțiile open source și comerciale care sunt auto-hublicate.

Opțiuni de instrumente

ELK

ELK, prescurtare de la Elasticsearch, Logstash și Kibana, este cel mai popular instrument open source de agregare a jurnalelor de pe piață. Este folosit de Netflix, Facebook, Microsoft, LinkedIn și Cisco. Toate cele trei componente sunt dezvoltate și întreținute de Elastic. Elasticsearch este, în esență, o implementare a motorului de căutare NoSQL, Lucene. Logstash este un sistem de log pipeline care poate ingera date, le poate transforma și le poate încărca într-un magazin precum Elasticsearch. Kibana este un strat de vizualizare deasupra Elasticsearch.

Cu câțiva ani în urmă, au fost introduse Beats. Beats sunt colectori de date. Ei simplifică procesul de expediere a datelor către Logstash. În loc să fie nevoie să înțeleagă sintaxa corectă a fiecărui tip de jurnal, un utilizator poate instala un Beat care va exporta jurnalele NGINX sau jurnalele proxy Envoy în mod corespunzător, astfel încât acestea să poată fi utilizate în mod eficient în cadrul Elasticsearch.

Când se instalează o stivă ELK la nivel de producție, pot fi incluse alte câteva piese, cum ar fi Kafka, Redis și NGINX. De asemenea, este obișnuit să se înlocuiască Logstash cu Fluentd, despre care vom discuta mai târziu. Acest sistem poate fi complex de operat, ceea ce, la începuturile sale, a dus la o mulțime de probleme și plângeri. Acestea au fost în mare parte rezolvate, dar este încă un sistem complex, așa că s-ar putea să nu doriți să îl încercați dacă sunteți o operațiune mai mică.

Acesta fiind spus, există servicii disponibile, astfel încât nu trebuie să vă faceți griji în această privință. Logz.io îl va rula pentru dvs., dar prețul său de listă este puțin cam piperat dacă aveți o mulțime de date. Desigur, probabil că sunteți mai mic și s-ar putea să nu aveți multe date. Dacă nu vă puteți permite Logz.io, ați putea să vă uitați la ceva precum AWS Elasticsearch Service (ES). ES este un serviciu pe care Amazon Web Services (AWS) îl oferă și care face ca Elasticsearch să funcționeze foarte ușor și rapid. De asemenea, are instrumente pentru a obține toate jurnalele AWS în ES folosind Lambda și S3. Aceasta este o opțiune mult mai ieftină, dar este necesară o anumită gestionare și există câteva limitări.

Elastic, compania mamă a stivei, oferă un produs mai robust care utilizează modelul de bază deschis, care oferă opțiuni suplimentare în jurul instrumentelor de analiză și raportare. De asemenea, poate fi găzduit pe Google Cloud Platform sau AWS. Aceasta ar putea fi cea mai bună opțiune, deoarece această combinație de instrumente și platforme de găzduire oferă o soluție mai ieftină decât majoritatea opțiunilor SaaS și oferă în continuare multă valoare. Acest sistem ar putea să înlocuiască în mod eficient sau să vă ofere capacitatea unui sistem de gestionare a informațiilor și evenimentelor de securitate (SIEM).

Stiva ELK oferă, de asemenea, instrumente de vizualizare excelente prin Kibana, dar îi lipsește o funcție de alertă. Elastic oferă o funcționalitate de alertă în cadrul add-on-ului plătit X-Pack, dar nu există nimic încorporat pentru sistemul open source. Yelp a creat o soluție la această problemă, numită ElastAlert, și probabil că există și altele. Acest software suplimentar este destul de robust, dar sporește complexitatea unui sistem deja complex.

Graylog

Graylog a crescut recent în popularitate, dar și-a început activitatea atunci când Lennart Koopmann l-a creat în 2010. Doi ani mai târziu s-a născut o companie cu același nume. În ciuda utilizării sale din ce în ce mai frecvente, este încă mult în urma stivei ELK. Acest lucru înseamnă, de asemenea, că are mai puține caracteristici dezvoltate de comunitate, dar poate folosi aceleași Beats pe care le folosește stiva ELK. Graylog a câștigat laude în comunitatea Go odată cu introducerea Sidecar Graylog Collector scris în Go.

Graylog folosește Elasticsearch, MongoDB și Graylog Server sub capotă. Acest lucru îl face la fel de complex de rulat ca și stiva ELK și poate un pic mai mult. Cu toate acestea, Graylog vine cu alerte integrate în versiunea open source, precum și cu alte câteva caracteristici notabile, cum ar fi streamingul, rescrierea mesajelor și geolocalizarea.

Caracteristica de streaming permite ca datele să fie direcționate către fluxuri specifice în timp real, în timp ce acestea sunt procesate. Cu această caracteristică, un utilizator poate vedea toate erorile bazei de date într-un singur Stream și erorile serverului web într-un alt Stream. Alertele se pot baza chiar și pe aceste Fluxuri pe măsură ce se adaugă elemente noi sau când se depășește un prag. Latența este probabil una dintre cele mai mari probleme cu sistemele de agregare a jurnalelor, iar fluxurile elimină această problemă în Graylog. De îndată ce jurnalul intră, acesta poate fi direcționat către alte sisteme prin intermediul unui Stream fără a fi procesat complet.

Funcția de rescriere a mesajelor utilizează motorul de reguli open source Drools. Acest lucru permite ca toate mesajele primite să fie evaluate în funcție de un fișier de reguli definit de utilizator, permițând eliminarea unui mesaj (numită Blacklisting), adăugarea sau eliminarea unui câmp sau modificarea mesajului.

Cea mai interesantă caracteristică ar putea fi capacitatea de geolocalizare a Graylog, care suportă trasarea adreselor IP pe o hartă. Aceasta este o caracteristică destul de comună și este disponibilă și în Kibana, dar adaugă multă valoare – mai ales dacă doriți să o folosiți ca sistem SIEM. Funcționalitatea de geolocalizare este furnizată în versiunea open source a sistemului.

Compania Graylog taxează suportul pentru versiunea open source, dacă doriți acest lucru. De asemenea, oferă un model de bază deschis pentru versiunea sa Enterprise, care oferă arhivare, logare de audit și asistență suplimentară. Nu există multe alte opțiuni pentru suport sau găzduire, așa că veți fi probabil pe cont propriu dacă nu folosiți Graylog (compania).

Fluentd

Fluentd a fost dezvoltat la Treasure Data, iar CNCF l-a adoptat ca proiect în incubare. A fost scris în C și Ruby și este recomandat de AWS și Google Cloud. Fluentd a devenit un înlocuitor comun pentru Logstash în multe instalații. Acesta acționează ca un agregator local pentru a colecta toate jurnalele nodurilor și a le trimite către sistemele de stocare centrale. Nu este un sistem de agregare a jurnalelor.

Utilizează un sistem robust de plugin-uri pentru a oferi integrări rapide și ușoare cu diferite surse de date și ieșiri de date. Având în vedere că sunt disponibile peste 500 de plugin-uri, majoritatea cazurilor de utilizare ar trebui să fie acoperite. Dacă nu sunt, aceasta sună ca o oportunitate de a contribui din nou la comunitatea open source.

Fluentd este o alegere comună în mediile Kubernetes datorită cerințelor sale reduse de memorie (doar câteva zeci de megabytes) și a debitului ridicat. Într-un mediu precum Kubernetes, în care fiecare pod are un sidecar Fluentd, consumul de memorie va crește liniar cu fiecare pod nou creat. Utilizarea Fluentd va reduce drastic utilizarea sistemului dumneavoastră. Aceasta devine o problemă frecventă în cazul instrumentelor dezvoltate în Java care sunt destinate să ruleze câte unul pe nod, unde supraîncărcarea memoriei nu a reprezentat o problemă majoră.

.