Graylog: managementul de loguri open source care te scapa de grep pe sase servere la 3 dimineata

E 3 dimineata, ceva s-a stricat si ai zece servere in productie. Intri prin SSH pe primul, tail -f /var/log/nginx/error.log, nu vezi nimic util, intri pe al doilea, repeti, intri pe al treilea si incepi sa iti pui intrebari despre alegerile de cariera. Pana ajungi la al saptelea, orice a cauzat spike-ul deja s-a rezolvat singur, iar tu ramai cu un morman de tab-uri de terminal si zero idee despre ce s-a intamplat.

Exact aceasta problema o rezolva logging-ul centralizat, si de aceea un instrument precum Graylog a rezistat mai bine de un deceniu. Graylog e o platforma open source de management si analiza de loguri: ingereaza loguri din tot ce rulezi, le stocheaza intr-un index cautabil, si iti pune deasupra streams, dashboard-uri si alerting. Codul e la github.com/Graylog2/graylog2-server , iar serverul de baza vine sub licenta SSPL cu unele componente sub GPL, deci licentierea e o chestiune de “citeste componenta specifica”, nu un raspuns unic. Noi nu rulam Graylog si nu il oferim ca serviciu gestionat, dar merita o privire serioasa daca evaluezi ce sa hostezi singur pentru loguri.

Ce este, mai exact, Graylog

Graylog nu e un singur binar, sunt trei piese care lucreaza impreuna. Serverul Graylog e creierul: primeste mesajele care vin, aplica orice regula de rutare si procesare ai configurat-o, si serveste interfata web plus API-ul REST. Sub el sta OpenSearch sau Elasticsearch, care face munca grea reala de stocare si indexare a fiecarui mesaj ca sa poti cauta prin milioane de linii in sub o secunda, acelasi stack tehnologic care sta la baza lumii “ELK”. Alaturi sta MongoDB, usor de trecut cu vederea dar face ceva diferit: stocheaza configuratia si metadata, useri, dashboard-uri, definitii de streams, conditii de alerta, index sets, tot ce descrie cum e configurata instanta ta. Logurile tale intra in OpenSearch; regulile despre ce se intampla cu ele traiesc in MongoDB. Aceasta impartire e o trasatura definitorie a modului in care e construit Graylog, si inseamna ca operezi trei servicii, nu unul.

Logurile intra prin inputuri: Syslog (UDP sau TCP), GELF (Graylog Extended Log Format, formatul lor propriu structurat, gandit sa care mai multa informatie decat o linie plata de syslog), Beats (deci Filebeat, Winlogbeat si restul familiei Elastic Beats trimit direct in el), TCP/UDP brut, HTTP, si inca cateva. Orice deja emite loguri in infrastructura ta are aproape sigur o cale de intrare.

De ce conteaza

Cand un incident se intinde pe mai multe host-uri, containere sau servicii, intrebarea nu e niciodata “ce a logat serverul A”, e “ce s-a intamplat, in ordine, pe tot, in jurul defectiunii”. Grep-ul per-host nu raspunde la asta; un index partajat, cautabil, corelat in timp, raspunde. Inseamna si ca logurile supravietuiesc masinii care le-a produs: daca un container face OOM si e reprogramat, logurile lui sunt deja in alta parte.

Logging-ul centralizat si monitorizarea bazata pe metrici rezolva probleme adiacente dar diferite: metricile iti spun ca ceva e in neregula si cam cand, logurile iti spun ce s-a intamplat de fapt si de ce. Merita citit articolul nostru despre Grafana pe partea de metrici a acestei perechi. Un setup matur tinde sa aiba ambele: Grafana pentru “e ceva in neregula chiar acum”, Graylog pentru “hai sa aflam exact ce s-a intamplat” de dupa.

Ce primesti din cutie

Streams-urile ruteaza mesajele in bucket-uri logice in timp real, pe baza unor reguli pe care le definesti tu: sursa, facility, valoarea unui camp, o potrivire regex. Un stream nu e o copie a datelor, e un filtru live care lasa o echipa sau o aplicatie sa vada doar felia lor din tot ce curge. Exemplu realist: ruteaza tot ce vine din inputurile de nginx unde response_code e 5xx intr-un stream “nginx-errors”, ca dashboard-ul de garda sa arate mereu doar lucruri chiar stricate.

Pipeline rules e locul unde sta puterea reala de procesare, un limbaj mic bazat pe reguli pentru parsare, imbogatire, rescriere sau eliminare de mesaje pe masura ce sosesc. Tipar comun: extragi o adresa IP dintr-o linie de log nestructurata cu un regex, faci un lookup GeoIP, atasezi tara ca un camp nou, inainte ca mesajul sa fie indexat.

Extractors sunt fratele mai simplu: extragere de campuri prin regex sau in stil grok, definita direct pe un input, buna pentru extrageri simple ale unui singur camp care nu au nevoie de tot limbajul de pipeline.

Search-ul e partea in care vei trai zi de zi: un limbaj de interogare peste mesajele indexate, cu selectoare de interval de timp si statistici pe campuri, sprijinit de OpenSearch ca sa ramana rapid la volum real. Dashboard-urile sunt construite din cautari salvate si agregari: rata de erori in timp, top surse dupa IP, volum de request-uri pe cod de status, aranjate pe un singur ecran. Alerting-ul ruleaza pe definitii de evenimente, conditii evaluate impotriva datelor tale (de exemplu, mai mult de 50 de evenimente care se potrivesc unui stream intr-o fereastra de 5 minute) care declanseaza o notificare, un email, un webhook, sau alta integrare. Exemplu tipic: alerta cand rata de erori din stream-ul “nginx-errors” trece de un prag intr-o fereastra glisanta, ca sa afli de la Graylog, nu de la un client.

Graylog e folosit destul de mult si pentru munca de securitate si tip SIEM: corelarea evenimentelor intre sisteme, alertarea pe tipare suspecte. E cu adevarat util acolo, dar un SIEM complet de obicei vrea mai mult decat vine cu Graylog open source, gestionare de cazuri, continut de detectie curatat, feed-uri de threat intelligence, ceva ce face parte din motivul pentru care exista tier-ul comercial Graylog Security.

Instalare Graylog pe un VPS

Graylog publica imagini oficiale Docker pentru el insusi, pentru OpenSearch si pentru MongoDB, deci Compose e cel mai rapid drum realist catre o instanta functionala:

services:
  mongodb:
    image: "mongo:6.0"
    volumes:
      - "mongo_data:/data/db"
    restart: "on-failure"

  opensearch:
    image: "opensearchproject/opensearch:2.19.1"
    environment:
      - "OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g"
      - "bootstrap.memory_lock=true"
      - "discovery.type=single-node"
      - "action.auto_create_index=false"
      - "plugins.security.ssl.http.enabled=false"
      - "plugins.security.disabled=true"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - "opensearch_data:/usr/share/opensearch/data"
    restart: "on-failure"

  graylog:
    image: "graylog/graylog:6.1"
    environment:
      GRAYLOG_PASSWORD_SECRET: "schimba-cu-un-string-lung-si-aleator"
      GRAYLOG_ROOT_PASSWORD_SHA2: "pune-aici-un-hash-sha256-al-parolei-de-admin"
      GRAYLOG_HTTP_EXTERNAL_URI: "https://logs.exemplu.ro/"
    entrypoint: "/usr/bin/tini -- wait-for-it opensearch:9200 --  /docker-entrypoint.sh"
    ports:
      - "9000:9000/tcp"
      - "1514:1514/tcp"
      - "1514:1514/udp"
      - "12201:12201/tcp"
      - "12201:12201/udp"
    depends_on:
      - "mongodb"
      - "opensearch"
    volumes:
      - "graylog_data:/usr/share/graylog/data"
    restart: "on-failure"

volumes:
  mongo_data:
  opensearch_data:
  graylog_data:

Genereaza hash-ul SHA256 al parolei de root inainte sa pornesti:

echo -n "parola-ta-reala-de-admin" | sha256sum

Porneste stack-ul, asteapta ca OpenSearch si MongoDB sa termine primul boot, apoi acceseaza portul 9000:

docker compose up -d
docker compose logs -f graylog

Odata ce e accesibil, inchide porturile cum trebuie in loc sa lasi totul deschis catre lume. Vrei ca interfata web sa fie accesibila doar din reteaua ta de administrare sau in spatele unui reverse proxy cu TLS, iar porturile de trimitere a logurilor deschise doar catre host-urile care chiar iti trimit loguri:

ufw allow from 203.0.113.0/24 to any port 9000 proto tcp comment "UI web Graylog, doar retea admin"
ufw allow from 10.0.0.0/16 to any port 1514 proto tcp comment "Syslog TCP, hosturi interne"
ufw allow from 10.0.0.0/16 to any port 1514 proto udp comment "Syslog UDP, hosturi interne"
ufw allow from 10.0.0.0/16 to any port 12201 comment "GELF, hosturi interne"
ufw deny 9000
ufw deny 1514
ufw deny 12201

Asta e exact tipul de workload pe care il gestioneaza bine un VPS: nu e uriasa de una singura, dar a rula trei servicii inseamna ca vrei o masina cu memorie reala, dedicata, nu o instanta mica de tip burstable unde OpenSearch se va bate cu tine pentru RAM. Un VPS DreamServer cu cateva gigabyte de RAM in plus e un punct de plecare rezonabil pentru volum mic-mediu de loguri; scaleaza heap-ul OpenSearch si spatiul de disc pe masura ce cresc nevoile de retentie.

Tipare de configurare care merita stiute

Rotatia si retentia indecsilor. Graylog organizeaza indecsii in “index sets” cu strategii de rotatie (dupa marime sau dupa timp) si strategii de retentie care decid cand indecsii vechi se inchid, se arhiveaza sau se sterg. Daca gresesti aici, fie arzi spatiu de disc pastrand date pe care nimeni nu se uita, fie rotesti atat de agresiv incat pierzi istoricul de care chiar aveai nevoie la o analiza post-incident. Seteaza retentia deliberat, per index set, nu ca o idee de dupa ce alertele de spatiu pe disc au inceput sa sune.

Streams-uri ca granite intre echipe si aplicatii. In loc de un singur flux urias la care se uita toata lumea, foloseste streams-uri ca sa dai fiecarei echipe sau aplicatii propria felie: un stream “database”, unul “web”, unul “security”. Streams-urile pot avea propriile setari de retentie si permisiuni de acces, deci o echipa capata vizibilitate pe propriile loguri fara sa i se dea datele intregului cluster.

Pipeline rules versus extractors. Extractors-urile sunt mai simple si stau direct pe input, bune pentru o extragere rapida a unui singur camp, fara logica conditionala. Pipeline rules e instrumentul potrivit odata ce ai nevoie de conditii, transformari multiple, imbogatire GeoIP sau prin tabele de lookup, sau decizii de rutare bazate pe continut parsat. Regula empirica: daca scrii mai mult de un extractor ca sa acoperi variatii ale aceluiasi mesaj, e timpul sa muti logica in pipeline rule.

Securizarea interfetei web. Graylog vine cu propriul sistem de useri si roluri, dar pentru orice depaseste un singur admin, planifica deliberat controlul accesului: separa conturile de admin de rolurile de vizualizare read-only, si nu expune portul 9000 direct pe internet fara TLS in fata. Daca ai deja o autentificare centralizata in alta parte, verifica optiunile de furnizor de autentificare ale Graylog inainte sa adaugi useri locali.

Unde Graylog nu e raspunsul potrivit

Daca rulezi un singur server sau doua, journalctl si fisiere de log rotite cu grep/awk acopera cu adevarat majoritatea nevoilor, iar a rula Graylog, OpenSearch si MongoDB doar ca sa urmaresti logurile de pe o singura masina e mult overhead operational pentru foarte putin castig.

Daca echipa ta ruleaza deja un stack Elastic/OpenSearch pentru alte scopuri (cautare in produs, analytics), a adauga Graylog deasupra inseamna un al doilea lucru de operat peste o infrastructura de date pe care deja o ai, si poate avea mai mult sens sa construiesti ingestia de loguri direct in ce ai deja.

Overhead-ul de resurse e real: trei servicii, fiecare cu propria amprenta de memorie si disc, e semnificativ mai mult decat un singur binar de agregare a logurilor, iar OpenSearch in special vrea memorie reala ca sa ramana rapid. Pentru workload-uri mici, asta poate fi disproportionat fata de problema pe care o rezolvi.

Si daca chiar ai nevoie de un SIEM cu gestionare de cazuri la nivel de conformitate, continut de detectie curatat si feed-uri de threat intelligence, editia open source singura nu te duce acolo; acesta e golul pe care exista tier-ul comercial Graylog Security sa il umple.

Alternative pe care le-am luat in calcul

Elastic Stack (elastic.co ), Elasticsearch, Logstash, Kibana, e platforma de care e apropiat chiar stratul de stocare al lui Graylog. Daca esti deja investit in unelte Elastic sau ai nevoie de ecosistemul de vizualizare al Kibana, a rula stack-ul direct e o alegere rezonabila, desi pierzi interfata mai prietenoasa a Graylog pentru streams si pipeline rules si preiei direct licentierea proprie a Elastic.

Loki cu Grafana (grafana.com/oss/loki ) indexeaza doar etichetele de metadata in loc de continutul complet al logului, tratand corpurile logurilor ca blob-uri comprimate, neindexate, dramatic mai ieftin de rulat la scara. Compromisul e flexibilitatea de cautare: full-text extins nu e punctul forte al lui Loki asa cum e la Graylog. Daca esti deja pe deplin investit in Grafana, Loki se integreaza natural fara sa adauge o paradigma noua.

SigNoz e o platforma de observabilitate open source mai noua care combina loguri, metrici si trace-uri peste ClickHouse, atragatoare daca vrei o singura platforma pentru toate trei semnalele din prima zi, desi e un proiect mai tanar, cu o comunitate mai mica si mai putin istoric operational decat Graylog sau stack-ul Elastic.

Deci, sa-l rulezi?

Daca ai mai mult de doua servere si te-ai saturat sa umbli prin SSH la 3 dimineata incercand sa reconstruiesti ce s-a intamplat, logging-ul centralizat isi merita costul repede, iar Graylog e o cale matura, capabila sa o faci: optiuni solide de ingestie, un pipeline real de procesare, cautare care ramane utilizabila la volum. Intra cu ochii deschisi asupra amprentei de trei servicii, dimensioneaza OpenSearch corect pentru volumul tau de loguri, si decide-ti strategia de retentie inainte ca folosirea spatiului de disc sa ia decizia in locul tau.

Daca te gandesti unde sa il rulezi de fapt, un VPS DreamServer iti da resursele dedicate pe care le vrea acest tip de workload fara sa supra-dimensionezi pentru o implementare mica, iar daca preferi sa nu detii tu partea operationala de a mentine sanatoase Docker-ul, dimensiunile heap-ului OpenSearch si retentia indecsilor pe termen lung, serviciile noastre de administrare servere acopera exact acest tip de ingrijire continua.