Tip na monitoring kontejnerových služeb

[czechsys]

Ahoj,

nema nekdo tip na jednoduchy kontejnerovy monitoring? Pouzivam netdata,zabbix, vyvojari by chteli do netdata nastavit monitorovani kontejnerovych ssl redisu, ale tenhle pristup by vyzadoval k urcitym operacim roota, nemluve o tom, ze netdata neumi reload, a jine problematicke body. Prometheus zatim neprovozuji. Tak kdyby nekdo znal nejaky na zprovozneni velice jednoduchy monitoring, o kterem by se dalo uvazovat.

Diky.

[Reklama]

[by_cx]

Prometheus je vcelku jednoduchý na zprovoznění a jeho formát metrik podporuje kde co.

[LivingLegend]

tohle https://github.com/oliver006/redis_exporter by ti nepomohlo?

Navic zaba pak kdyztak umi cist data ze Promethea, takze bs mohl mit stale vse usebe.

[czechsys]

Ja jsem prometheus kdysi zkusmo rozjizdel, vazne je to dnes tak lehky? Prece jen, netdata na real-time monitoring bez notifikaci s nastavenym diskovym limitem je instalacne temer nulova narocnost.

[by_cx]

Je to pořád stejně lehký. Nahodit Prometheus je jeden kontejner či binárka s jedním konfigurákem, kde je seznam adres s metrikami, třeba s tím redis_exporterem zmíněným výše.

[Reklama]

[_Tomáš_]

netdata jako label do prometheus posílá container id, což při každém restartu containeru udělá celý nový shard s metrikami (roste to i na malém prostředí do desítek GB místa na disku), je potřeba ty labely vyloučit, to je trocha práce, tj. není to zrovna tak snadné.

Každopádně těch cest moc nemáš, dnes vše jede na prometheusu, zvedne se ti proti netdatě cpu, disk, metriky budou horší. S ELK si také nepomůžeš.

Je to vždy u projektů velká věc, jak to vlastně udělat. ELK není špatný když máš peníze/hw, prometheus (raději victoriametrics) znamená poměrně dost ruční práce a ladění, ale pak funguje dobře, problém ze mě jsou dlouhé intervaly sběru a nemožnost zajistit integritu (nevíš, jestli ti něco nechybí). Občas funguje dobře i cAdvisor nebo sysdig, ale blbě se to rozšiřuje. Stejně tak někdy je možné použít i coroot.com.

Pak tady je celá řada placených nástrojů jako splunk, dynatrace, datadog, ale tam s pracností jsi dost nahoře.

[LivingLegend]

Jeste pokud mas zabu, tak by se s vyvoejm slo domluvit aby ty data pushovali do ni. (misto do Promethea)
Ma to prijit ted v sedmickove verzi. Vyhoda by mohla bejt v tom, ze push data history funguje proti trapu, takze i kdyz se protoci kontejner pod nohama, mohl by ti to hazet do porad jednoho a toho sameho trap itemu.

[czechsys]

Tak ja predpokladam, ze to nakonec budeme mit monitorovany bud zabbixem, nebo necim, co bude notifikacne schopne. U netdata notifikace nepouzivam, asi bych to nedokazal rozumne nakonfigurovat a jeste per agent.

Cilem je momentalne (resp. hledam, zda to jde) real-time kratkodoby monitoring. Asi zatim zkusim netdata jako kontejner v rootless, umi to, jen to bude omezene.

Nebo je tu nekdo, kdo by rekl, ze je normalni a rozumny, dat vyvojarum omezeny sudo pristup na systemd/netdata pro rekonfiguraci/restarty? Nemluve o tom, kdyz pak bude vice kontejneru (casem by tam melo byt vic automatizace).

[_Tomáš_]

tak netdata rootless znamená stejně, že jí dáš přístup na systemd dbus a docker socket (já jí řeším zpravidla omezením přes systemd service).

Udělej na změnu konfigurace interface nebo jí dělej ty manuálně, netuším, co by chtěli na netdatě měnit často, alerty jsou ve vlastním souboru, tam můžeš vytvořit nějaké cli+vi na změnu.

Netdata používá pluginy, pluginy jsou aplikace nebo scripty, které běží pod netdata uživatelem (či rootem) a tam si pak vývojáři mohou dát jakýkoliv backdoor, tj. určitě bych jim do konfigurace nedával přímý přístup. Netdata skenuje systém a monitoruje automaticky vše, co najde.

U zabbixu to připravují, jak to bude vypadat kdoví, dnes už zabbix spíše dáváme pryč.

[czechsys]

tak netdata rootless znamená stejně, že jí dáš přístup na systemd dbus a docker socket (já jí řeším zpravidla omezením přes systemd service).

Kdyz bezi pod someuser, to je problem ohledne pristupu na systemd dbus? Pouzivame stejny pristup i pro someuser unity/timery. To, ze se dostanou na rootless docker.socket, mi az tak nevadi, kdyz to bezi cele pod someuser.

Udělej na změnu konfigurace interface nebo jí dělej ty manuálně, netuším, co by chtěli na netdatě měnit často, alerty jsou ve vlastním souboru, tam můžeš vytvořit nějaké cli+vi na změnu.

No nastesti u nas nevznikaji projekty tak rychle a casto, takze se to da zatim obslouzit z me strany manualne. Ale idealni ani cilovy stav to neni. Jak myslis pak ten "interface"?

[_Tomáš_]

Co je rootless docker.socket? Podman? Jinak docker vyžaduje kvůli tomu jak funguje root práva.

Netdata potřebuje SYS_ADMIN a /{proc,sys}, aby mohla vidět procesy a zobrazit využití podle uživatelů, /etc/{passwd,group} pro získání jmen uživatelů, SYS_PTRACE, aby viděla síťová spojení, musí mít přístupný /run/dbus aby monitorovala systemd služby atd. Mají to popsané ve své dokumentaci. Tj. i bez root účtu má ty práva dost vysoká.

Připrav konfigurační soubor (v jakémkoliv formátu), který budou moci uživatelé zapisovat, ten budeš sledovat (či pravidelně zpracovávat) a z něho vytvoříš výslednou konfiguraci pro netdatatu, pokud se něco změní, uděláš restart. Nebo můžeš udělat sudo script, který po spuštění otevře v EDITOR tmp kopii části konfigurace, počkáš na ukončení editoru, zkontrluješ jestli se něco změnilo a případně aktualizuješ netdatu a uděláš její restart (ala jak funguje visudo nebo crontab -e). Zásadně uživatelé nepouštím na vyšší práva.

[czechsys]

Co je rootless docker.socket? Podman? Jinak docker vyžaduje kvůli tomu jak funguje root práva.

No to je docker nainstalovany pod obycejnym uzivatelem, ve stylu "dockerd-rootless-setuptool.sh" + "systemctl --user start docker".

Připrav konfigurační soubor (v jakémkoliv formátu), který budou moci uživatelé zapisovat, ten budeš sledovat (či pravidelně zpracovávat) a z něho vytvoříš výslednou konfiguraci pro netdatatu, pokud se něco změní, uděláš restart. Nebo můžeš udělat sudo script, který po spuštění otevře v EDITOR tmp kopii části konfigurace, počkáš na ukončení editoru, zkontrluješ jestli se něco změnilo a případně aktualizuješ netdatu a uděláš její restart (ala jak funguje visudo nebo crontab -e). Zásadně uživatelé nepouštím na vyšší práva.

Takhle nejak jsem uvazoval v prvni fazi. Jen mi tam nevonel pristup ke konfiguraci neceho, co se konfiguruje pres ansible (a k nemu vyvojari pristup nemaji, navic bez Toweru), takze trochu kolizni stav plus nutnost restartovat. To mi ciste neprijde uz vubec :-)

No nic, prinejhorsim skoncime bez real-time.

[_Tomáš_]

jo aha, tohle, ok, to můžeš netdatou monitorovat ze stejného procesu, ale řada metrik bude chybět.

Pokud máš ansible a repositář, nemůžeš tu konfiguraci strčit do repa a přes CI nasazovat ansiblem? O jakou vlastně konfigurace jde? Netdata se normálně běžně vůbec nekonfiguruje, sama si čte, vše na co má přístup a nerozumím tomu, proč by vývojáři měli její konfiguraci měnit.

Každopádně my máme běžně všechny konfigurace v repositáři a vývojáři je normálně vidí, mohou dělat PR, navrhovat vylepšení, diskutovat, mohou si to i na vlastním virtuálu vytočit a vyzkoušet. Vyšší oprávnění ale na serverech prostě nemají a mít nemohou.

[czechsys]

Pokud máš ansible a repositář, nemůžeš tu konfiguraci strčit do repa a přes CI nasazovat ansiblem? O jakou vlastně konfigurace jde? Netdata se normálně běžně vůbec nekonfiguruje, sama si čte, vše na co má přístup a nerozumím tomu, proč by vývojáři měli její konfiguraci měnit.

CI jsem ja  nemame Tower, takze se vse spousti manualne. No jde o to, ze chteji videt metriky z redisu, vzhledem k tomu, ze kazdy kontejnerovy redis bude mit jiny port/login/pass, tak se to do konfigurace musi zadat.

[_Tomáš_]

tak ansible script můžeš spouště s jakéhokoliv CI (gitlab, github atd.) či jakýmkoliv procesem, na to nepotřebuješ Tower/AWX.

Chápu, co tím myslíš. Tak si drž někde seznam redisů a jejich hesel (vault či jiná databáze s hesly), to iteruj při nasazení ansiblem a zanes do konfigurace. Nebo redis nech povinně poslouchat také na socketu v nějaké mountnuté složce a tomu dej práva pro netdatu, při nasazení můžeš najít všechny redis sockety a zanést do konfigurace. Cest je strašně moc.

Připadá mi, že v tom z nějakého důvodu hledáš přílišné složitosti a nevidím k nim důvod.