Checkmk: monitorizare de infrastructura care se auto-configureaza

Un sysadmin care intretine manual configul de monitorizare pentru 150 de servere ajunge, mai devreme sau mai tarziu, in una din doua stari: fie ignora jumatate din alerte pentru ca sunt zgomot, fie afla despre o problema de la un client inainte s-o vada in dashboard. Amandoua sunt simptome ale aceleiasi boli: cineva a trebuit sa scrie de mana fiecare check, pentru fiecare host, si nimeni n-a mai tinut pasul cand infrastructura a crescut.

Checkmk ataca exact problema asta. In loc sa incepi de la zero si sa declari manual “monitorizeaza filesystem-ul /var pe host-ul X”, ii dai un host si el iti spune ce a gasit: filesystem-uri, interfete de retea, procese, servicii systemd, containere Docker, ce mai are pe acolo. Codul e pe github.com/Checkmk/checkmk , editia Raw e open-source sub GPLv2, iar noi il rulam in productie, alaturi de Grafana si VictoriaMetrics, pentru auto-discovery de servicii si monitorizare clasica de host-uri in centrul nostru de date din Bucuresti.

Ce este, mai exact, Checkmk

Checkmk a inceput prin 2008 ca un plugin numit check_mk pentru Nagios, menit sa rezolve durerea de cap a configurarii manuale a check-urilor. In timp, proiectul a crescut intr-o platforma completa de monitorizare, cu propriul motor de colectare si propria interfata web, dar a pastrat filozofia initiala: discovery intai, configurare dupa.

Practic, functioneaza asa: instalezi agentul Checkmk pe un host (un binar mic, fara dependinte grele) sau il configurezi sa vorbeasca SNMP/IPMI/HTTP cu un device care nu poate rula agent. Apoi rulezi discovery, iar Checkmk iti propune o lista de servicii de monitorizat, bazata pe ce a gasit efectiv acolo. Accepti lista (sau o ajustezi), si de-acum incolo host-ul e monitorizat.

Exista doua fluxuri majore de editii: Raw, complet open-source, cu un motor de check bazat istoric pe Nagios-core, si editiile comerciale Enterprise/Cloud, care aduc un motor propriu (CMC), scalabilitate mai mare, raportare si cateva integrari suplimentare (agent bakery, de exemplu). Pentru majoritatea infrastructurilor self-hosted, Raw e suficient.

De ce conteaza asta

Diferenta fata de Nagios clasic sau Zabbix nu e filozofica, e practica: timpul. Cand ai 5 servere, scrii configul de mana si nu bagi de seama diferenta. Cand ai 50 sau 500, fiecare host nou, fiecare disk nou adaugat, fiecare interfata de retea reconfigurata inseamna o editare manuala pe care cineva o uita. Checkmk elimina cea mai mare parte din aceasta munca repetitiva: rulezi discovery periodic, iar diferentele (servicii noi aparute, servicii disparute) sunt semnalate explicit, nu ignorate silentios.

Ce primesti din cutie

• Auto-discovery de host-uri si servicii, cu peste 2000 de plugin-uri de check bundle-uite pentru sisteme de operare, echipamente de retea de la zeci de producatori, baze de date, hypervisoare si aplicatii comune.
• Colectare hibrida: agent-based acolo unde poti instala un binar, agentless prin SNMP, HTTP/API sau IPMI acolo unde nu poti (switch-uri, UPS-uri, BMC-uri).
• Notificari pe reguli, cu rutare flexibila catre email, Slack, SMS-gateway sau orice script custom, in functie de host, severitate sau ora din zi.
• Downtimes si acknowledgements, plus un flux de tip ITIL pentru stari de problema (deschisa, confirmata, inchisa) si o consola de evenimente pentru corelarea de syslog/SNMP traps.
• Inventar hardware/software, cu istoric de schimbari - util cand vrei sa stii ce s-a schimbat pe un server intre doua incidente.
• Grafice si dashboard-uri built-in, bazate pe RRD, plus o functie de agregare de business (BI) care ruleaza starile mai multor servicii intr-o vedere unica de nivel “serviciu de business e OK/nu e OK”.

Instalare Checkmk pe un VPS

Cel mai simplu mod de a incerca Checkmk e prin imaginea oficiala Docker, care contine un “site” complet (agent, core, UI, baza RRD) intr-un singur container:

docker volume create checkmk_data

docker run -d --name checkmk \
  --restart unless-stopped \
  -p 8080:5000 \
  -v checkmk_data:/omd/sites \
  --tmpfs /opt/omd/sites/cmk/tmp:exec \
  checkmk/check-mk-raw:2.3.0-latest

La primul start, containerul genereaza o parola de admin pentru site-ul cmk si o afiseaza in log (docker logs checkmk). UI-ul e disponibil la http://<ip-vps>:8080/cmk/check_mk/, dar in productie il pui in spatele unui reverse proxy cu TLS (Traefik, nginx, Caddy), nu-l expui direct.

Pentru firewall, cu ufw:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw deny 8080/tcp
ufw enable

Ideea e ca portul 8080 (sau orice port intern de aplicatie) sa fie accesibil doar de pe localhost/reverse proxy, nu direct din internet. Pentru un fleet mic-mediu, un VPS cu 2-4 GB RAM e suficient pentru discovery si monitorizare pana la cateva zeci de host-uri; peste asta, aloca mai multa memorie sau ia in calcul mai multe site-uri Checkmk distribuite.

Tipare de configurare care merita stiute

Discovery per-folder, nu per-host

Checkmk organizeaza host-urile in foldere, iar regulile (ce sa monitorizezi, cum sa notifici, ce praguri sa folosesti) se pot atasa la nivel de folder, mostenite de toate host-urile din el. In loc sa configurezi fiecare server individual, grupezi host-urile similare (toate serverele web, toate switch-urile Cisco) intr-un folder si aplici regulile o singura data. Discovery-ul ruleaza periodic per folder, iar diferentele fata de starea cunoscuta apar ca “servicii noi/disparute de revizuit”, nu se aplica automat silentios.

Piggyback data pentru arhitecturi indirecte

O tehnica utila cand ai o masina (un hypervisor, un load balancer) care “stie” mai multe despre alte host-uri decat pot afla ele singure: Checkmk permite ca un host sa impinga date de monitorizare in numele altui host (“piggyback”). Un hypervisor poate raporta starea VM-urilor lui fara ca fiecare VM sa aiba propriul agent instalat. Pattern-ul e similar cu ce facem noi cand derivam automat tintele de scrape Prometheus/VictoriaMetrics din inventarul Ansible: sursa de adevar ramane un singur loc, iar restul se deriva de acolo.

Event console pentru corelare de syslog si SNMP traps

Daca deja primesti syslog sau SNMP traps de la echipamente de retea, event console-ul Checkmk le poate ingera si corela cu host-urile existente, transformand un flux brut de log-uri intr-un semnal de monitorizare structurat, cu reguli de matching si escaladare.

Notification rules pe mai multe niveluri

Regulile de notificare se pot inlantui: o regula generala pentru toata infrastructura, suprascrisa de reguli specifice pentru un grup de host-uri critice (baze de date de productie, de exemplu), care merg pe alt canal si cu alt prag de severitate. Evita sa ai un singur canal Slack care primeste tot, de la un disk la 80% pana la un server cazut.

Unde Checkmk nu e raspunsul potrivit

Daca ceea ce vrei e o vedere corelata, ad-hoc, peste metrici cu cardinalitate mare (per-request, per-container, per-endpoint API), Checkmk nu e instrumentul potrivit; acolo Prometheus sau VictoriaMetrics, interogate prin PromQL si vizualizate in Grafana, sunt mult mai flexibile - am scris despre Grafana ca strat de vizualizare intr-un articol anterior.

Nici nu e un agregator de log-uri: monitorizarea de log-uri din Checkmk e utila pentru pattern matching simplu (cauta un string, numara aparitii), nu pentru cautare full-text peste terabytes de log-uri, unde ai nevoie de Loki sau ELK.

In fine, editia Raw are limite reale fata de Enterprise: agent bakery (impachetare custom de agent per grup de host-uri) si scalabilitatea peste cateva mii de host-uri sunt motive pentru care echipele mari platesc pentru editia comerciala. Pentru un fleet mic-mediu self-hosted, insa, Raw acopera confortabil nevoia.

Alternative pe care le-am luat in calcul

Zabbix e cea mai directa alternativa: la fel de matur, la fel de open-source, dar cu un model diferit de organizare (items/triggers/actions in loc de discovery automat de servicii) si un accent mai mare pe scalabilitate prin proxy-uri distribuite.

Prometheus/VictoriaMetrics + Grafana raman alegerea noastra pentru metrici de tip timeserie si dashboard-uri custom - am detaliat de ce am ales acest combo separat. Checkmk si acest combo nu se exclud: multe echipe le ruleaza in paralel, Checkmk pentru discovery + alerting + flux ITIL, Grafana pentru corelare vizuala si explorare.

Nagios, stramosul direct, ramane o optiune valida daca vrei control total de jos in sus, dar costul de intretinere manuala e exact ce Checkmk incearca sa elimine.

Deci, sa-l rulezi?

Daca administrezi o infrastructura cu zeci sau sute de host-uri si echipamente de retea eterogene, si vrei sa scapi de scrisul manual de configuratii de monitorizare pentru fiecare, Checkmk merita instalat macar ca proof-of-concept intr-un weekend. Discovery-ul singur, care iti arata in cateva minute ce servicii ruleaza pe un host nou, justifica timpul investit.

Daca vrei sa-l incerci fara sa te complici cu instalarea si mentenanta, ia un VPS la noi si porneste containerul de mai sus in cateva minute, sau lasa-ne pe noi sa ne ocupam de tot prin serviciul de administrare de servere , de la instalare la tuning-ul regulilor de notificare.