Střípky z IT - (9) : Nagios : Uhádnete, kde byl problém? (diskuse)

[Miriam]

Jaktože tohle ještě nemá tučňáka? Jako autorka nejčtenějšího blogu na abclinuxu žádám o nápravu

[alkoholik]

SELinux?

[Max]

:D. A jak to zjistit, zda je to skutečně SELinux a případně jak řešit?
Zdar Max

[lajdak]

audit2why a audit2allow?

[Max]

Jop, jop :).
Zdar Max

[alkoholik]

Step 3.

[Max]

Čekal jsem, že se sem nejdříve podívají nějací méně znalí uživatelé :-/. Ale ok, takže hned tedy uvolním pokračování:
Nagios + Nrpe + SELinux
Zdar Max
PS: musím ty kvízy dělat těžší

[X]

Je to otevrene jako bug. ;) https://github.com/NagiosEnterprises/nrpe/issues/237

[Max]

O tomto vím, ale nejsem si jistý, zda jde o konfigurační mistake, nebo opravdu o nějaký bug.
Zdar Max

[Bystroushaak]

Problém byl v tom že používáte nagios.

[Max]

Ale já nepoužívám nagios :). Používám Centreon :).
Ale jo, je to forknutý Nagios. Chápu, že letí věci jako realtime Netdata, nebo Prometheus, ze kterého si cucá data Grafana apod.
Prometheus už nasazujeme, Grafanu také. Zatím jen pro konkrétní projekty a né jako náhradu za Centreon.
Osobně pořád i v dnešní době vidím v Nagiosovém pojetí monitoringu jisté výhody. Je to velmi nenáročné, hodně robustní, jde to škálovat do aleluja a pro spousty nasazení je to maximálně dostačující.
Netoužím ani po automatizaci z onoho řešení (něco jako najdi všechno na síti a začni to monitorovat, nebo tady šup agenta na server a monitoruj vše, co tam na něm najdeš). Monitoruji jen důležité věci a pokud chci automatizaci, tak jednotně přes Ansible. Centreon nějaké řešení má, které je podobné třeba tomu z checkmk, ale jak říkám, nijak po tom netoužím.
Centreon mám vyladěn snad do maximální úrovně, přidat k monitoringu další server, nebo další síťový prvek, jsou tři kliky myší, které zvládne kdkoli atd. A false positive hlášení mám pomalu na úrovni nuly.
Zdar Max

[Bystroushaak]

U nás používáme DataDog, na který vesměs můžu říct jen chválu (až na ty ceny teda). Vždycky když se potkám s nagiosem, tak trpím, především protože je to nějaká legacy verze (resp. asi deset nagiosů, kterých se nikdo roky nedotknul ani koštětem) a zatím nikdo neměl sílu vykopat je do pryč. Zrovna včera jsem se bavil se šéfem našeho oddělení, že to prý zkusí projít a převést všechno co půjde na DD, a optimisticky to odhadoval jako práci na pár měsíců.

Osobně mě na tom nejvíc sralo jak těžké tam je upravit třeba text u alertu. U toho bizáru co tu máme jsem to nakonec vzdal, protože tam byl někdo hrozně kreativní a není k tomu dokumentace co tam vlastně nakonec vymyslel, ale to co bys tam čekal nikde nenajdeš. Ty false positives jsou taky otravné, nehledě na to že je těžké z toho dostat smysluplnnou informaci.

Netoužím ani po automatizaci z onoho řešení (něco jako najdi všechno na síti a začni to monitorovat, nebo tady šup agenta na server a monitoruj vše, co tam na něm najdeš). Monitoruji jen důležité věci a pokud chci automatizaci, tak jednotně přes Ansible.

Tohle řešíme jednak tím že se automaticky berou metriky z clusterů (ať už EC2 v AWS, nebo k8s), ale taky tím že se instaluje DD agent do base image (AMI nebo docker).

To automatické řešení se tu pomalu zavádí (APM tracing), to jsem zatím jednou viděl v rámci nějakého incidentu a připadalo mi to jako vidět v praxi fungovat nějaký sci-fi vynález. Řešil jsem tenkrát že něco vypadlo a protože na to bylo navázáno asi 20 dalších services, tak jsi viděl 20 alertů (z nagiosu byly nejlepší, tam nikdy nevím ani kde je vypnout), viděl že 20 věcí nefunguje, ale zjistit co z těch 20 věcí to způsobilo bylo docela peklo, dokud jsem se nepodíval do APM trace, kde mi to nakreslilo schéma, analýzu toho jak se ten výpadek zpropagoval v čase a nakonec to pomocí nějaké heuristiky ukázalo na jednu věc, že ta byla příčina. Tak jsem se tam lognul, a fakt jo.

BTW, pokud tě sere ansible, tak doporučuji mrknout na pyinfra (psal jsem o tom před pár lety blog).

[Max]

Ten znám, ale to je čistě jen cloudová služba. My jedeme skoro všechno on-prem.
Ansible mi vyhovuje. Kromě toho, že mi nijak nevadí, tak je velmi rozšířený a lze hned dohledat všechno možný a člověk nemusí vymýšlet kolo.
Pokud jde o Nagios, tak jak říkám, já ho mám vyladěn, všechno vyšablonováno, nulové false positive atd.
Pokud jde o monitorování aplikací, tak pořádně jedině s APM. To používáme také, v rámci ELK (jedeme v TiB, SaaS by byl asi docela mastný), kde je pak vše vidět na jednom místě včetně logů aplikací.
Zatím tedy vše v on-prem, čistě OSS.
Tebou popsaný příklad s problémem mi přijde, jako když někdo spravuje nějaké prostředí, které nezná (nemyslím nijak zle, myslím to jako třeba neohlídání si předávky apod.).
Zdar Max

[Bystroushaak]

Tebou popsaný příklad s problémem mi přijde, jako když někdo spravuje nějaké prostředí, které nezná (nemyslím nijak zle, myslím to jako třeba neohlídání si předávky apod.).

Tak když máš firmu kde je několik tisíc programátorů, tam ani není možné že bys mohl všechno znát. Myslím že kdybych sledoval co všechno dělají týmy tady v Praze, tak bych už nestíhal nic jiného.

[Max]

Pravdou je, že nemám zkušenosti s tak velkým teamem, ale tak nějak jsem očekával, že všichni nedělají všechno, ale každý jen něco, každý je zodpovědný za nějakou část a tu má pod kontrolou / rozumí jí a řetězec funguje (vše vyjasněno v rámci dohled, admin, devík).
Ale třeba mám jen obrovsky mylné dojmy a postupně k tomu taktéž dojdeme. On k8s a všechno kolem toho k tomu tak nějak směřuje (že nikdo nebude vědět nic a každý problém se bude dlouho trasovat jak u idiotů).
Zdar Max

[Bystroushaak]

Pravdou je, že nemám zkušenosti s tak velkým teamem, ale tak nějak jsem očekával, že všichni nedělají všechno, ale každý jen něco, každý je zodpovědný za nějakou část a tu má pod kontrolou / rozumí jí a řetězec funguje (vše vyjasněno v rámci dohled, admin, devík).

To není úplně možné už jen protože všechno se neustále mění. Výhoda microservices.. Jinak jo, ale to se týče spíš vývoje, pak se dělají rotace na L1/L2, kde člověk na L1 řeší tak nějak všechno ten den, L2 je většinou někdo kdo rozumí tomu konkrétnímu projektu, ale to má tu nevýhodu že mezi těma věcma musíš prvně vůbec zjistit co je příčina, abys to na něj potom mohl hodit.

On k8s a všechno kolem toho k tomu tak nějak směřuje (že nikdo nebude vědět nic a každý problém se bude dlouho trasovat jak u idiotů).

Tak tak :)

[Max]

My jsme totiž ve firmě rozjeli vývoj nového informačního systému. Takže máme rozjetý Gitlab, k8s, redis clustery, rabbitmq clustery, S3 storage, ELK s APM, Prometheus, Grafanu a dalších milion věcí okolo toho. V rámci Gitlabu pak CI/CD pipeline atd. Osobně řeším jen backend (neřeším psaní CI/CD ani konfiguraci k8s, no time, ale občas se do něčeho snažím proniknout). Každopádně pozoruji, že se postupně vyvíjí blackbox. Je to vtipný a smutný zároveň.
Zdar Max

[Ruža Becelin]

To bych rekl, ze je (bylo) cilem.

Ind-as-a-Service.

Nastesti uz se firmy zacinaji z toho vlhkeho snu probouzet... Aspon na Zapade...