Kubernetes monitorozása Zabbixszal

Mondanom se kell, hogy mennyire hasznos a monitoring, nélküle vakon repülünk. Nem ördögtől való, hogy telepítsünk minden kubernetes szerverünkre 1-1 zabbix agentet, de így csak olyan adatokat fogunk kapni, amit a Linux by Zabbix agent nevű templét tartalmaz. Természetesen ez is több, mint a semmi.

Ám fogalmunk sem lesz a kubernetes állapotáról, se a benne futó podokról. Ezt felismerte a zabbix csapata, és készítettek olyan templéteket, amik magával a kubernetes apival kommunikálnak. Így mindent is tudni fogunk a rendszerünkről. Ráadásul azzal se kell törődnünk, ha új node-okkal bővül a klaszter, vagy régieket töröltünk, teljesen automatikusan le fogja követni a zabbix.

Mire lesz szükségünk?

egy működő zabbix szerverre, én a 7.0-t használom
6 db templétre, amiket innen tudsz letölteni
egy kubernetes klaszterre (a példában egy egy node-os lesz)
git kliensre
kubectl-re
helm-re

Letöltés előtt ellenőrizd a zabbixodat, elképzelhető, hogy már benne vannak a templétek:

Ha nálad egy sincs, vagy régebbi változatot látsz, akkor válaszd ki a neked való verziót, töltsd le az összes templétet, majd importáld be a zabbixodba (Data collection -> templates -> import):

Telepítsük a szükséges zabbix komponenseket a kubernetesbe

Vegyük elő a kedvenc terminálunkat, majd adjuk ki az alábbi parancsokat:

git clone https://git.zabbix.com/scm/zt/kubernetes-helm.git
cd kubernetes-helm
kubectl create namespace monitoring

Szükségünk lesz egy konfig fájlra:

helm show values . > zabbix_values.yaml

Nyissuk meg a kedvenc szövegszerkesztőnkkel a zabbix_values.yaml nevű fájlt.

A következő sorokat fogjuk testre szabni:

35. sor: tag: alpine-7.0-latest
48. sor: value: "kind-lab-cluster"
59. sor: value: "zabbix.sajátdomain.hu"
71. sor: value: 60
226. sor: tag: alpine-7.0-latest

Az első és az utolsó kötelező, ugyanis a zabbix szerver nem beszélget eltérő verziójú proxyval, a többi opcionális. Természetesen ha a belső hálózaton van a zabbixod, akkor IP címet is használhatsz. A proxy neve mindegy, de ugyanazt kell megadnod a proxy hozzáadásánál is.

Végül telepítsük a zabbix komponenseit a kubernetesbe:

helm install zabbix . --dependency-update -f zabbix_values.yaml -n monitoring

Kérdezzük le a tokent:

kubectl get secret zabbix-service-account -n monitoring -o jsonpath={.data.token} | base64 -d

Nálam ez lett (csak a példa kedvéért, a sajátodat használd 🙂 ):

eyJhbGciOiJSUzI1NiIsImtpZCI6IjZRVC1Xdm00QjE1QjIwS2hMbTk3aGxuRF90XzVtWUJib25iZDlxTFBjSVkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2
UiOiJtb25pdG9yaW5nIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InphYmJpeC1zZXJ2aWNlLWFjY291bnQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiemFiYml
4LXNlcnZpY2UtYWNjb3VudCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjAwZjk1MTJhLTc1NmYtNDQ1Ny04NmFiLWI2NjllYjZmMzE2YyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptb25p
dG9yaW5nOnphYmJpeC1zZXJ2aWNlLWFjY291bnQifQ.sXPYYD4aYk3hku9XaOmQNdH0_30Ynow7vEdURQLg5iv3NGno9acYQLzKYtNB4L_sbO05sB-O0wrXru4iMmkFz3VJyvmqlbkYElwwFKXl5zCPKh0Q0mD-4qGNwmQ0zlmKu0z8nqlEj6U3TVDpuU
oPdIN9jWTa0OkZSSQ5p0X2byZDW5l80VGiKTUlO2AHgukl_EKo_r0DF3ujHAndNtPuuxQUIiW0y5RrDycSp_Nim_5JnNCX99T7Ipikxs2LMcv9J6W_UGr9_8SbVaE5q-towvFrDb-UN53RGyZThg_CMjU_1fNAUSyzkViv5CEIZFlkg6OiCRsDfej55kY
0dVURyw

Hozzunk létre egy új proxyt (Administration -> Proxies -> Create proxy):

Itt ugyanazt a nevet használjuk, amit korábban a zabbix_values.yaml nevű fájlban megadtunk.

Hozzunk létre egy új hosztot a zabbixban (Data collections -> Hosts -> Create host):

a hoszt neve tetszőleges
a templét a képen látható legyen
a hoszt csoport is tetszőleges
a proxy a korábban létrehozott legyen
majd kattintsunk a Macros linkre:

a neve: {$KUBE.API.TOKEN}
az értéke a korábban lekérdezett token legyen
végül mentsük el

Adjunk hozzá még egy hosztot, amit úgy a legegyszerűbb megtenni, hogy megnyitjuk az imént létrehozottat, majd leklónozzuk:

adjunk egy új nevet
tallózzuk ki az új templétet
töröljük le a másik templétet
végül nyomjuk meg a Clone gombot:

Már csak el kell menteni. Ez a módszer gyorsabb, mintha mindent a nulláról állítottunk volna be.

Milyen adatokat fogunk kapni?

Kezdjük az elején, semmilyen adatunk nem lesz, ha a proxy nem tud a szerverrel kommunikálni:

A lényeg, hogy Online legyen!

Ha nálad Offline, akkor hálózati gubancod lehet, mert a kubernetesben futó zabbix proxy nem látja a zabbix szerver 10051-es tcp portját, ellenőrizd a tűzfalad a zabbix szerveren (ha van).

Most már mehetünk a hoszt oldalra, az egyszerűség kedvéért szűrjünk a proxyra:

válasszuk ki a proxy lehetőséget
tallózzuk ki azt a proxyt, amit a kubernetesben futtatunk
majd Apply

Ha egy szerveres a kubernetes-ed, akkor nálad is 7 hosztot fog mutatni. Kettőt mi hoztunk létre, a többit a zabbix hozta létre a kapott adatok alapján. Mind a 6 kubernetes templét megjelent a listában, a 7. pedig egy mezei Linux by Zabbix agent lett. Ha több node-os klaszterre tettem volna, akkor minden hoszt kapott volna 1-1 bejegyzést. Azaz 2 node esetén 8, 3 node esetén 9 hoszt jött volna létre.

Nézzük meg, milyen adatokat kapunk a kubernetesből

Menjünk a zabbix Monitoring -> Latest data menüre, egyesével adjuk hozzá az összes hosztunkat (nálam 7 db), majd Apply:

Hiába van 7 hosztom, a listában már csak 6 db látszik, valaki nem küld adatokat… A bűnös a kind-lab-control-plane, az egyetlen, amelyiknek zabbix templétje van! Ha csak a hiányzó kind-lab-control-plane hosztot választom ki, akkor mégis 88 rekordot mutat, szóval ez bugnak tűnik. Mindenesetre a másik 6 több, mint 1000 rekordot szolgáltat nekünk, pedig mindössze 3 podunk fut a K8s-ben:

Összefoglalva

A szükséges szoftverek telepítése pár perc, a zabbix komponensek telepítése pár másodperc, a két zabbix hoszt felvétele is pár perc, tovább tart a cikket elolvasni 🙂

Cserébe, amíg le nem törlöd (helm uninstall zabbix -n monitoring), teljesen automatikusan fogod kapni az adatokat, akkor is, ha idő közben kicserélsz a klaszterben minden node-ot.