Gatus: monitorizare de sanatate cu configurare ca in Git

Un serviciu pica la ora 3 dimineata. Nu conteaza cat de bine e scris codul sau cat de scump e serverul, la un moment dat ceva se opreste: un certificat expira, o baza de date refuza conexiuni, un container intra in crash loop. Singura intrebare care chiar conteaza e cat de repede afli tu, inainte sa afle clientul printr-un tichet nervos trimis la 9 dimineata.

Raspunsul nostru la intrebarea asta e Gatus , un dashboard de health-check si status page, open source, licenta permisiva (stil MIT), scris in Go si livrat ca un singur binar/imagine de container usor de rulat oriunde. Nu e doar ceva ce recomandam altora: il rulam efectiv in propriul nostru datacenter din Bucuresti, ca instrument intern, ca sa stim instant cand pica ceva din infrastructura noastra sau dintr-un serviciu expus catre clienti, inainte sa ne spuna cineva din afara.

Ce este, mai exact, Gatus

Gatus nu e un agent care se instaleaza pe fiecare masina si raporteaza metrici de sistem. Nu concureaza cu un node exporter sau cu un agent de monitorizare full-stack. Gatus face un singur lucru, dar il face bine: verifica periodic un set de endpoint-uri (HTTP, TCP, ICMP, DNS, TLS) si evalueaza raspunsul fata de niste conditii pe care le scrii tu, in YAML.

O conditie arata asa: [STATUS]==200, [RESPONSE_TIME]<300, [CERTIFICATE_EXPIRATION]>168h. Simplu de citit, simplu de scris, si suficient de flexibil ca sa acoperi majoritatea scenariilor reale: “raspunde cu 200 in mai putin de 300ms”, “certificatul TLS mai are cel putin o saptamana valabilitate”, “portul e deschis”, “inregistrarea DNS se rezolva corect”.

Rezultatele se pastreaza in SQLite (deci nu ai nevoie de o baza de date externa doar ca sa tii istoricul), iar Gatus expune si un endpoint /metrics compatibil Prometheus, asa ca poti sa il conectezi la un stack de monitorizare existent daca vrei sa corelezi datele cu alte metrici.

De ce conteaza asta in productie

Diferenta reala fata de “am pus un ping in cron” e in doua lucruri: pragurile de failure/success configurabile si integrarile de alertare. Nu vrei sa primesti alerta la primul timeout (retelele au blip-uri), dar nici nu vrei sa afli despre o cadere reala dupa 20 de minute. Gatus iti lasa sa definesti exact cate esecuri consecutive inseamna “chiar a picat” si cate succese consecutive inseamna “chiar s-a recuperat”, per endpoint. Iar cand pragul e atins, alerta pleaca prin email, Slack, Telegram, PagerDuty sau alte canale suportate, fara sa mai scrii tu logica de debounce.

Ce primesti din cutie

• Un status page web, gata de folosit, care arata starea curenta si istoricul recent al fiecarui endpoint monitorizat.
• Verificari multi-protocol: HTTP/HTTPS, TCP, ICMP (ping), DNS, si validare TLS/certificat, toate din aceeasi definitie de configurare.
• Conditii scriptabile pe status code, timp de raspuns, continut de body, expirare de certificat si alte campuri expuse de raspuns.
• Praguri configurabile de failure-threshold si success-threshold, ca sa controlezi zgomotul de alertare.
• Integrari de notificare gata facute pentru cele mai folosite canale (email, Slack, Telegram, PagerDuty, si altele).
• Un endpoint /metrics in format Prometheus, pentru cine vrea sa bage datele intr-un stack existent.
• Zero baza de date externa: istoricul traieste in SQLite, langa binar.
• Configurare 100% declarativa: tot ce monitorizezi e definit in fisiere YAML, ceea ce inseamna ca poti pune configul in Git, sa faci code review pe un pull request care adauga un endpoint nou, si sa ai istoric complet al schimbarilor de monitorizare, exact ca la orice alta bucata de infrastructura-ca-cod.

Instalare Gatus pe un VPS

Cel mai simplu mod de a incerca Gatus e cu Docker, direct pe un VPS. Ai nevoie doar de un fisier de configurare montat ca volum si de un port expus.

mkdir -p ~/gatus/config
cat > ~/gatus/config/config.yaml <<'EOF'
endpoints:
  - name: website
    url: "https://example.com"
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 500"
      - "[CERTIFICATE_EXPIRATION] > 168h"

  - name: api-backend
    url: "tcp://example.com:5432"
    interval: 60s
    conditions:
      - "[CONNECTED] == true"
EOF

docker run -d \
  --name gatus \
  --restart unless-stopped \
  -p 8080:8080 \
  -v ~/gatus/config:/config \
  twinproduction/gatus

Sau, daca preferi docker-compose, echivalentul e:

services:
  gatus:
    image: twinproduction/gatus
    container_name: gatus
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./config:/config

Un lucru pe care merita sa il ai in vedere de la inceput: daca VPS-ul are ufw activ (cum ar trebui sa aiba orice server expus pe internet), portul 8080 nu e deschis automat doar pentru ca ai pornit containerul. Fie deschizi explicit portul cu ufw allow 8080/tcp (si il restrangi la IP-urile tale, daca poti), fie, si mai bine, pui Gatus in spatele unui reverse proxy cu TLS si lasi deschise doar 80/443, iar 8080 ramane accesibil doar din reteaua interna a serverului. Pentru un status page pe care il verifici tu si echipa, a doua varianta e aproape intotdeauna alegerea corecta.

Daca nu ai inca un server pe care sa il rulezi, pornesti rapid pe un VPS cu resurse suficiente pentru un container de dimensiuni mici, Gatus nu are cerinte de hardware serioase.

Tipare de configurare care merita stiute

Praguri de failure si success rezonabile

Nu seta failure-threshold: 1 decat daca chiar vrei alerta la primul blip de retea. In practica, un prag de 2-3 esecuri consecutive, la un interval de verificare de 30-60 de secunde, iti da un semnal onest fara sa te trezeasca la fiecare glitch tranzitoriu. Simetric, success-threshold de 2 iti confirma ca recuperarea e reala, nu doar un raspuns izolat intre doua caderi.

Certificate care expira in liniste

Conditia [CERTIFICATE_EXPIRATION] > 168h (o saptamana) pe fiecare endpoint HTTPS pe care il monitorizezi e probabil cea mai ieftina asigurare pe care o poti configura. Un certificat expirat descoperit de un client inainte de tine e o conversatie neplacuta care se evita complet cu o singura linie de YAML.

Verificari dincolo de HTTP

Nu tot ce conteaza raspunde pe port 80/443. O baza de date pe TCP, o inregistrare DNS care trebuie sa se rezolve la IP-ul corect, un ping ICMP catre un echipament de retea, un certificat TLS pe un port non-web, toate intra in aceeasi lista de endpoint-uri, cu acelasi tip de conditii. Practic, un singur instrument iti acopera si aplicatia web, si infrastructura din spatele ei.

Alertare pe grupuri, nu pe fiecare endpoint separat

Cand ai zeci de endpoint-uri, alertarea individuala per serviciu poate deveni ea insasi zgomot. Grupeaza logic endpoint-urile (public-facing, intern, baza de date, retea) si gandeste-te la canalul de notificare potrivit pentru fiecare grup: un Slack pentru alertele “de urmarit”, un PagerDuty sau email direct pentru cele care chiar cer o interventie imediata.

Unde Gatus nu e raspunsul potrivit

Gatus e excelent la un singur lucru: “e endpoint-ul asta disponibil si raspunde asa cum ma astept?”. Nu incerca sa il folosesti in locul unui stack de observabilitate complet. Nu face tracing distribuit, nu iti arata de ce a crescut latenta la un anumit query din baza de date, nu profileaza aplicatia, si nu inlocuieste un sistem de logging centralizat. Daca ai nevoie sa intelegi comportamentul intern al unei aplicatii, nu doar daca raspunde din exterior, ai nevoie de metrici de aplicatie, log-uri structurate si, probabil, tracing, alaturi de Gatus, nu in loc de el.

De asemenea, daca echipa ta are deja un stack Prometheus/Grafana matur cu blackbox checks configurate, s-ar putea sa nu castigi mult adaugand Gatus separat, in afara de un status page dedicat, mai usor de aratat catre oameni care nu citesc dashboard-uri PromQL.

Alternative pe care le-am luat in calcul

• Uptime Kuma : probabil cea mai cunoscuta alternativa, cu o interfata web mult mai orientata pe click-and-configure. Daca preferi sa adaugi monitoare dintr-un UI, nu din fisiere YAML versionate, Uptime Kuma e o alegere solida. Compromisul e ca istoricul de configurare traieste in baza de date a aplicatiei, nu in Git, ceea ce face code review-ul si urmarirea schimbarilor mai greu de facut.
• Prometheus Blackbox Exporter : daca ai deja Prometheus si vrei doar verificari de tip probe (HTTP, TCP, ICMP, DNS) integrate direct in acel ecosistem, fara un status page separat, blackbox exporter face exact asta, dar ramane o piesa in plus intr-un stack Prometheus, nu un produs de sine statator cu UI propriu.
• Healthchecks.io : un unghi diferit, orientat pe monitorizarea cron job-urilor si a task-urilor programate (“dead man’s switch”: daca job-ul nu raporteaza la timp, primesti alerta), mai putin pe verificari active de tip endpoint. Se poate self-hosta, si merge bine in completare cu Gatus, nu neaparat ca inlocuitor.

Motivul pentru care am ales Gatus a fost simplu: configurarea ca fisier YAML in Git se potriveste exact cu felul in care tratam restul infrastructurii, ca infrastructura-ca-cod, revizuita in pull request-uri, nu editata pe furis dintr-un UI care nu tine minte cine a schimbat ce.

Deci, sa-l rulezi?

Daca esti o echipa mica sau un dezvoltator solo care vrea sa stie primul, nu ultimul, cand pica ceva, Gatus e o alegere solida: usor de instalat, usor de inteles, si configurarea traieste langa restul codului, nu intr-o baza de date separata. Nu e un inlocuitor pentru observabilitate completa, dar pentru intrebarea de baza, “merge sau nu merge serviciul asta chiar acum”, face treaba fara complicatii inutile.

Daca vrei un loc unde sa il rulezi fara batai de cap, un VPS e suficient pentru un dashboard ca acesta, iar daca preferi sa nu te ocupi tu de partea de administrare a serverului, configurare firewall, actualizari, hardening, echipa noastra de administrare servere poate prelua toata partea operationala, cat tu te concentrezi pe ce arata dashboard-ul.