Grafana self-hosted pentru monitoring infrastructura
Monitoring

Grafana: panoul unic de sticla prin care iti vezi toata infrastructura

Un server se misca greu la 3 dimineata. Care dintre ele, si de ce? Fara un loc in care sa te uiti, raspunsul e un ssh disperat pe cinci masini, un top care iti arata o singura secunda din viata sistemului, si o senzatie generala ca “parca era mai bine ieri”. Cu un panou de dashboard-uri in fata, raspunsul e la o privire: nodul 3 a urcat pe I/O acum patruzeci de minute, exact cand a pornit un backup, iar CPU-ul e de fapt normal. Aia e diferenta pe care o face Grafana.

Grafana , stratul de vizualizare open-source de la Grafana Labs , e practic standardul de facto pentru “panoul unic de sticla” prin care se uita echipele de infrastructura. La versiunea 13.0 (lansata in aprilie 2026) e licentiat sub AGPLv3, aduna zeci de mii de stele pe GitHub si ruleaza in orice, de la un Raspberry Pi de acasa pana la flote de mii de servere. Il rulam de ani de zile in fata propriei infrastructuri, in datacenterul nostru din Bucuresti. Acest articol e raportul de teren.

Ce este, mai exact, Grafana

Prima confuzie de risipit: Grafana nu e un sistem de monitoring complet, e stratul de vizualizare si alerting din varful lui. Nu colecteaza singur metrici, nu stocheaza serii temporale, nu are un agent care sa umble pe serverele tale. Grafana se conecteaza la o sursa de date care deja tine cifrele, le interogheaza si le deseneaza in dashboard-uri.

Asta e cel mai important lucru de inteles inainte de orice: Grafana are nevoie de un backend de date in spate. Cel mai comun cuplu e Grafana plus Prometheus sau, cum folosim noi, VictoriaMetrics (drop-in compatibil cu Prometheus, dar de cateva ori mai eficient pe disc). Prometheus/VictoriaMetrics scrape-uiesc metricile de la exportere (node_exporter pentru host-uri, cadvisor pentru containere, exportere SNMP pentru switch-uri), le stocheaza, iar Grafana le citeste prin PromQL si le transforma in grafice.

Arhitectural, Grafana e un serviciu scris in Go, cu un frontend in TypeScript/React, si isi tine propria configurare (dashboard-uri, useri, surse de date, reguli de alerta) intr-o baza de date (SQLite implicit, sau PostgreSQL/MySQL pentru setup-uri mari). Nu confunda baza asta cu datele de monitoring: baza Grafana tine doar meta-informatia, seriile temporale traiesc in sursa de date.

De ce contorizeaza modelul asta cu surse de date

Puterea reala a Grafanei e ca decupleaza vizualizarea de stocare. Acelasi dashboard poate combina, pe acelasi ecran, panouri care trag din trei surse diferite: metrici din VictoriaMetrics, log-uri din Loki , si o interogare directa intr-un PostgreSQL de aplicatie. Nu esti legat de un singur furnizor de date. Cand cineva iti spune “aplicatia a fost lenta la 14:32”, pui un panou de latenta langa unul de erori din log si langa unul de CPU, toate aliniate pe aceeasi axa de timp, si vezi corelatia dintr-o privire.

Grafana suporta zeci de surse de date native: Prometheus, VictoriaMetrics, Loki, Tempo (trace-uri), InfluxDB, Graphite, Elasticsearch, PostgreSQL, MySQL, CloudWatch si multe altele prin plugin-uri. In practica, alegi backend-ul de metrici in functie de scara, iar Grafana ramane constanta din varf.

Ce primesti din cutie

Editia open-source (Grafana OSS, cea despre care vorbim; exista si o editie Enterprise comerciala, mai jos despre ea) vine cu tot ce iti trebuie pentru observabilitate serioasa:

  • Dashboard-uri si panouri de toate felurile: time-series, gauge, stat, tabel, heatmap, bar chart, state timeline. Fiecare panou e o interogare plus o reprezentare vizuala.
  • Alerting unificat: reguli de alerta care evalueaza o interogare la interval si declanseaza cand un prag e depasit, cu contact points (email, Slack, Telegram, webhook, PagerDuty) si notification policies care ruteaza alertele.
  • Explore, un mod de interogare ad-hoc pentru cand vrei sa sapi in PromQL sau LogQL fara sa construiesti un dashboard, exact ce iti trebuie in mijlocul unui incident.
  • Provisioning as-code: surse de date, dashboard-uri si reguli de alerta pot fi definite in fisiere YAML/JSON versionate in Git, nu doar click-uite in UI (mai jos despre asta, e cel mai bun lucru de facut).
  • Variabile si templating: un singur dashboard cu un dropdown $host care iti arata oricare server din flota, in loc de un dashboard per masina.
  • Transformari: join-uri, calcule si filtre pe rezultatele interogarilor, direct in panou, fara sa modifici sursa de date.
  • Autentificare flexibila: login nativ, OAuth (Google, GitHub, OIDC generic), LDAP, sau auth prin reverse proxy (cum facem noi, cu header injectat de un layer de SSO in fata).
  • Anotari: marcaje pe axa de timp pentru deploy-uri, incidente sau ferestre de mentenanta, ca sa vezi imediat “aha, graficul a sarit exact cand am dat release”.

Ce nu face: Grafana nu colecteaza metrici (aia e treaba exporterelor + Prometheus/VictoriaMetrics), nu agrega log-uri singur (aia e Loki sau Elasticsearch), si nu inlocuieste un sistem de ITIL cu ticketing si acknowledgement. E stratul de vizualizare si alerting, si e cel mai bun la asta.

Instalare Grafana pe un VPS

Grafana e un singur binar Go, deci instalarea e simpla. Cel mai curat mod pe un server modern e prin Docker, alaturi de un backend de metrici. Un exemplu minim cu docker compose, Grafana plus VictoriaMetrics:

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:latest
    command: ["--retentionPeriod=12", "--storageDataPath=/vmdata"]
    volumes:
      - ./vmdata:/vmdata

  grafana:
    image: grafana/grafana-oss:13.0.0
    ports:
      - "3000:3000"
    volumes:
      - ./grafana:/var/lib/grafana
      - ./provisioning:/etc/grafana/provisioning
    environment:
      GF_SECURITY_ADMIN_PASSWORD: "schimba-ma"

Ridici stack-ul cu docker compose up -d, apoi UI-ul e la http://<ip-server>:3000/ cu userul admin si parola pe care ai pus-o. Primul lucru pe care il faci: leaga sursa de date. Nu prin click, ci prin provisioning (vezi mai jos), ca sa fie reproductibil.

Ca la orice interfata de management, portul 3000 nu trebuie expus lumii intregi fara un layer de protectie. Fie il pui in spatele unui reverse proxy cu TLS si autentificare, fie il restrictionezi la IP-urile tale prin firewall:

ufw allow from IP_BIROU_TAU to any port 3000 proto tcp
ufw deny 3000

Daca rulezi asta pe un VPS DreamServer , pune aceeasi regula si in firewall-ul de retea al providerului, nu te baza doar pe regulile la nivel de host pentru interfetele de administrare.

Dashboards-as-code: cel mai bun lucru pe care il poti face

Tentatia, la inceput, e sa construiesti totul din UI: adaugi sursa de date cu click-uri, faci dashboard-uri manual, setezi alertele din interfata. Merge, dar ai construit o cutie neagra pe care nu o poti recrea daca serverul moare. Solutia curata e provisioning-ul, tot ce tine de configurare traieste in fisiere versionate in Git.

Sursa de date, un fisier YAML:

# /etc/grafana/provisioning/datasources/vm.yaml
apiVersion: 1
datasources:
  - name: VictoriaMetrics
    type: prometheus
    access: proxy
    url: http://victoriametrics:8428
    isDefault: true

Un provider de dashboard-uri, care incarca automat orice JSON dintr-un folder:

# /etc/grafana/provisioning/dashboards/default.yaml
apiVersion: 1
providers:
  - name: DreamServer
    folder: DreamServer
    type: file
    options:
      path: /var/lib/grafana/dashboards

Iar dashboard-urile in sine sunt fisiere JSON in acel folder. Nu trebuie sa le scrii de la zero: comunitatea Grafana are mii de dashboard-uri gata facute la grafana.com/dashboards . Cateva pe care le folosim si le recomandam:

  • Node Exporter Full (ID 1860): tot ce iti trebuie despre un host Linux, CPU/RAM/disc/retea, la nivel de detaliu absurd.
  • Ceph Cluster: sanatatea unui cluster de storage Ceph.
  • Un dashboard de containere prin cAdvisor, ca sa vezi care container mananca CPU-ul, nu doar ca hostul e incarcat.

Le imporČ›i o data, le salvezi ca JSON in folderul provisioned, si de acolo sunt in Git. La urmatorul deploy, un Grafana proaspat vine sus cu toate dashboard-urile deja acolo. Asta e diferenta dintre “am un Grafana” si “am o platforma de observabilitate pe care o pot reconstrui intr-un minut”.

Tipare de configurare care merita stiute

Cateva lucruri pe care le-am gasit chiar utile dincolo de default-uri.

Autentificare prin reverse proxy

Login-ul nativ Grafana e ok pentru o singura persoana, dar daca ai deja un SSO in companie, dezactiveaza-l si lasa un reverse proxy sa faca autentificarea, injectand userul intr-un header:

[auth.proxy]
enabled = true
header_name = X-WEBAUTH-USER
auto_sign_up = true

Asa oamenii se logheaza o data, prin identitatea companiei, si Grafana ii creeaza automat la primul acces. Cand pleaca cineva, il dezactivezi in SSO si accesul la dashboard-uri dispare.

Un dashboard cu variabile, nu cincizeci de dashboard-uri

Nu face un dashboard per server. Fa unul singur cu o variabila $host populata dintr-o interogare (label_values(node_uname_info, instance)) si un dropdown care iti schimba toata pagina intre masini. Adaugi un server nou in flota, apare singur in dropdown. Mai putin de intretinut, mai usor de comparat doua noduri.

Alerteaza pe simptome, nu pe cauze

Tentatia e sa pui o alerta pe fiecare metrica. Rezultatul e zgomot si alerte pe care le ignori. Alerteaza pe ce doare userul: disc aproape plin, un serviciu care nu mai raspunde, latenta care a sarit, o rata de erori care creste. CPU la 90% nu e o problema daca aplicatia raspunde bine. Pastreaza numarul de alerte suficient de mic cat sa te trezesti la fiecare.

Trimite alertele undeva unde le vezi

Un contact point de email e minimul; un canal de Slack/Telegram dedicat e mai bun, pentru ca alertele nu se ineaca in inbox. Configureaza failure cu un prag de cateva evaluari consecutive, ca sa nu tipe la primul spike tranzitoriu, si activeaza notificarea de rezolvare, ca sa stii cand s-a linistit singur.

Citeste modul Explore inainte sa construiesti panouri

Cand investighezi ceva nou, nu construi un dashboard. Deschide Explore, scrie interogari PromQL ad-hoc, vezi ce metrici exista si cum arata. Abia dupa ce ai gasit interogarea care spune ceva, o pui intr-un panou. Explore e locul unde intelegi datele; dashboard-ul e locul unde le prezinti.

Unde Grafana nu e raspunsul potrivit

Merita sa fim onesti despre limite.

  • Nu e o baza de date. Fara un backend de metrici (Prometheus, VictoriaMetrics, InfluxDB) nu ai ce vizualiza. Grafana singur nu monitorizeaza nimic; e jumatatea din varf a stivei.
  • Nu colecteaza log-uri singur. Pentru log-uri ai nevoie de Loki sau Elasticsearch in spate. Grafana le deseneaza, dar altcineva le aduna.
  • Nu inlocuieste un sistem clasic de monitoring cu auto-discovery. Tool-uri ca Checkmk sau Zabbix descopera singure servicii, tin inventar hardware/software si au workflow de acknowledgement ITIL. Grafana e complementar: grafice si corelare, nu ticketing. La noi ruleaza in paralel cu Checkmk fara sa se calce.
  • AGPLv3 conteaza daca modifici si oferi ca serviciu. Pentru uz intern, licenta nu te atinge. Dar daca modifici Grafana si o oferi ca serviciu prin retea, esti obligat sa publici modificarile. Pentru majoritatea covarsitoare a cazurilor, irelevant.
  • Feature-urile Enterprise sunt inchise. Rapoartele PDF programate, RBAC granular, sincronizarea de echipe prin LDAP si cateva plugin-uri de surse de date enterprise (Splunk, Oracle, ServiceNow) sunt in editia comerciala. Editia OSS e generoasa, dar daca ai nevoie de rapoarte trimise automat catre management, planuieste in consecinta.

Alternative pe care le-am luat in calcul

Pentru completitudine: ne-am uitat si la Kibana (excelent daca traiesti in ecosistemul Elasticsearch, mai slab in afara lui), Netdata (senzational pentru vizibilitate instant per-nod cu zero configurare, dar mai putin potrivit ca panou centralizat pe o flota), Zabbix si Checkmk (sisteme de monitoring complete cu auto-discovery si alerting, dar cu grafice mai rigide), si Perses (un proiect mai nou, complet open-source, dashboard-as-code din prima, de urmarit).

Grafana s-a dovedit cea mai curata potrivire pentru “vreau un singur panou peste care sa pun orice sursa de date si sa corelez tot, fara sa ma leg de un furnizor”. Ponderile tale pot fi diferite.

Deci, sa-l rulezi?

Daca administrezi mai mult de cateva servere si te-ai saturat sa dai ssh pe fiecare cand ceva merge prost, Grafana plus un backend de metrici (VictoriaMetrics e alegerea noastra) merita o duminica dupa-amiaza. Instalarea e rapida, dashboard-urile din comunitate iti dau valoare in cinci minute, iar prima data cand un grafic iti arata cauza unui incident inainte sa apuci sa te panichezi, vei sti ca ti-a intrat in stack pentru totdeauna.

Daca il rulezi in productie, tine configurarea in Git prin provisioning, pune-l in spatele unui SSO, si trateaza baza lui (SQLite sau Postgres) ca infrastructura cu backup. Dashboard-urile se reconstruiesc din JSON intr-un minut; ce ai pierde cu adevarat sunt userii, alertele si istoricul de anotari.

Noi rulam Grafana peste VictoriaMetrics pentru toata flota noastra, cu dashboard-uri provisionate din Git si alerte pe email, si il recomandam oricarui client care ne intreaba cum sa-si vada infrastructura. Daca vrei sa-l incerci pe infrastructura pe care nu trebuie sa o construiesti tu intai, planurile noastre VPS incep la dimensiuni suficient de mici cat sa faca experimentul ieftin, iar serviciul de administrare server acopera instalarea, backend-ul de metrici si tuning-ul daca preferi sa sari peste curba de invatare.

Oricum ai alege, sa-ti pui un dashboard in fata e o seara mai bine petrecuta decat inca un top pe inca un server. Codul e pe GitHub, un stack de docker compose te pune pe picioare in cinci minute, si vei sti intr-o ora daca isi castiga un loc in fata infrastructurii tale.

Avem Incredere & Suntem Membri

Suntem membri ai principalelor organizatii de infrastructura internet.

RIPE NCC MANRS PeeringDB RoTLD DSIX SBIX 4IXP LOCIX Euro-IX RIPE NCC MANRS PeeringDB RoTLD DSIX SBIX 4IXP LOCIX Euro-IX