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

5.10.2022 20:18 | Přečteno: 2334× | linux | | poslední úprava: 6.10.2022 08:36

A jdeme do dalšího kola. Tentokrát se podíváme na Nagios a Nrpe.

Nagios a nrpe plugin a AlmaLinux 8.5

Né každý to může znát. Nagios je řešení monitoringu serverů, služeb apod. Nrpe server je pak jakoby agent. Nrpe server je tedy nainstalován v systému, který chceme monitorovat. Firewall je nastaven tak, aby se na agenta dostal jen Nagios server. Nrpe server má povolenou komunikaci jen z Nagios serveru, povoleno šifrovanou komunikaci, povoleno posílání argumentů a dalších věcí. Tj. komunikace není nijak omezena a příkazy jsou posílány dle libovůle Nagios serveru.

check_systemd

Protože chceme nějak rozumněji monitorovat služby na koncovém serveru, tak použijeme check_systemd. Je to jen pythoní script. Vyžaduje python3.7 a vyšší (kvůli podpoře/závislosti scriptu na annotations). Instalace tohoto checkovacího scriptu je jednoduchá.

# instalace pythonu 3.8
dnf install python38

# stažení scriptu
cd /usr/lib64/nagios/plugins/
wget https://raw.githubusercontent.com/Josef-Friedrich/check_systemd/main/check_systemd.py

# nainstalování závislostí (script vyžaduje nagiosplugin)
pip3.8 install nagiosplugin

Script pak začne fungovat, lokálně vyzkoušíme (zkontrolujeme, že běží dvě služby: postifx + elasticsearch):

./check_systemd.py -w 80 -c 120 -I postfix -I elasticsearch --required active
SYSTEMD OK - all | count_units=292 data_source=cli startup_time=76.845;80;120 units_activating=0 units_active=209 units_failed=0 units_inactive=83

Voláme z Nagios serveru

Připravíme si nastavení Nrpe serveru :

# povolíme volání přes sudo, protože volání systemd vyžaduje roota
sudoedit /etc/sudoers.d/nrpe
Defaults:nrpe !requiretty
nrpe    ALL=NOPASSWD: /usr/lib64/nagios/plugins/check_systemd.py

# přidáme si volání do nrpe serveru
nano /etc/nagios/nrpe.cfg
...
command[check_systemd]=sudo /usr/lib64/nagios/plugins/check_systemd.py -P -w $ARG1$ -c $ARG2$ -W $ARG3$ -C $ARG4$ $ARG5$ --required $ARG6$
...

# restart
systemctl restart nrpe

Následně už můžeme z Nagios serveru zavolat:

# switchnu se na uživatele, pod kterým běží nagios
su - centreon-engine
/usr/lib/centreon/plugins/check_centreon_nrpe3 -H 192.168.1.1 -c check_systemd -a 80 120 518400 604800 "-I postfix -I elasticsearch" active
NRPE: Unable to read output

Co to? Zapneme debug na nrpe serveru a podíváme se do logů:

nrpe[1459913]: Host 192.168.1.2 is asking for command 'check_systemd' to be run...
nrpe[1459913]: Running command: sudo /usr/lib64/nagios/plugins/check_systemd.py -P -w 80 -c 120 -W 518400 -C 604800 -I
nrpe[1459914]: WARNING: my_system() seteuid(0): Operation not permitted
sudo[1459915]:     nrpe : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/lib64/nagios/plugins/check_systemd.py -P -w 80 -c 120 -W 518400 -C 604800 -I
nrpe[1459913]: Command completed with return code 2 and output:
nrpe[1459913]: Return Code: 3, Output: NRPE: Unable to read output
nrpe[1459913]: Connection from 192.168.1.2 closed

Nemáme přístup (Operation not permitted)? Jak to? Ok, zkusíme na cílovém serveru, zda je sudo a vše ok nastaveno správně:

su - nrpe
sudo /usr/lib64/nagios/plugins/check_systemd.py -P -w 80 -c 120 -W 518400 -C 604800 -I postfix -I elasticsearch
SYSTEMD OK - all | count_units=292 data_source=cli startup_time=76.845;80;120 units_activating=0 units_active=209 units_failed=0 units_inactive=83

Kde je problém?

Tak si to shrneme:

• nrpe server je nastaven správně
• parametry nrpe server akceptuje a u jiných "check_" modulů není problém (a to se jiným modulům posílají ještě divočejší parametry)
• sudo je nastaveno správně
• ruční kontrola přes nrpe uživatele funguje také ok
• nefunguje tedy jen spuštění ze sítě / z Nagios serveru

Kde si myslíte, že je problém a jaké je jeho řešení?
Nápověda: Není to bug, není to chyba v konfiguraci Nagiosu, ani Nrpe serveru, ani chyba v posílání argumentů nebo syntaxe. Dalo by se říci, že je to obecný problém, který se může objevit i jinde (tj. nemusí se týkat nagiosu ani nrpe). Problém je na AlmaLinux 8.5 + epel repo, jinak vše default instalace.

Zdar Max

PS: Znovu připomínám, že problém je dávno vyřešen, ale přišlo mi to celkem zajímavé jako kvízek.

Předchozí kvízy
Střípky z IT - (1). : Uhádnete, kde byl problém?
Střípky z IT - (2) : DHCP : Uhádnete, kde byl problém?
Střípky z IT - (3) : NFS : Uhádnete, kde byl problém?
Střípky z IT - (4) : MX-ONE : Uhádnete, kde byl problém?
Střípky z IT - (5) : CentOS7 : Uhádnete, kde byl problém?
Střípky z IT - (6) : ext4 : Uhádnete, kde byl problém?
Střípky z IT - (7) : IP na L3 : Uhádnete, kde byl problém?
Střípky z IT - (8) : Systemd : Uhádnete, kde byl problém?
       

Komentáře

[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...