Egyszer mindenki életében eljön az a pillanat, amikor valami nem működik, pedig működnie kellene.
Nálam ez sokkal sűrűbben fordul elő, mint szeretném 🙂 Hiába üzemeltetek zabbix szervereket ~15 éve, hiába írok belőlük cikkeket, rendszeresen megesik, hogy a zabbix szerver nem lát egy vagy több zabbix agentet.
Talán valamelyik cikkemben említettem, hogy a sikerhez három dolog kell:
- jól beállított zabbix szerver
- jól beállított zabbix agent(ek)
- az agent és a szerver között szabad kommunikáció a megfelelő portokon
A kommunikáció iránya attól függ, hogy az agent aktív vagy passzív módban van-e. Én alapból passzív agentekkel dolgozom, azaz a szerver fordul az agenthez. Fix IP címes környezetben ez tökéletes.
Ha nem változtatjuk meg a gyári portokat, és passzív agenteket használunk, akkor az agentet futtató gépen nyissuk ki a 10050-es tcp portot, a szerveren pedig a 10051-es tcp portot.
A szemléltetéshez előveszem a korábban létrehozott labor környezetem, elindítom a vm1 és a zbxsrv nevű gépeket:
[msandor@msandorhp ~]$ cd ~/git/ansible_vagrant
[msandor@msandorhp ansible_vagrant]$ vagrant up vm1 zbxsrvMiután bebootoltak a gépek, ellenőrizzük, hogy a vm1 agentet látja-e a zabbix szerver, azaz „zöld-e” az ikonja. Nyissuk meg a megfelelő oldalt, beraktam a vm1-et a szűrőbe, most a többire nem vagyunk kíváncsiak, azok amúgy is pirosak lesznek (hiszen nem futnak).
Ezt kell látnunk:
Magyarul a fentebb emlegetett három feltétel mindegyike teljesül. Vegyük elő a szerszámos ládánkat, és néhány parancs segítségével gyűjtsünk információkat a működő állapotról.
Lépjünk be a zbxsrv szerverre:
[msandor@msandorhp ansible_vagrant]$ vagrant ssh zbxsrvEllenőrizzük a vm1 10050-es tcp portját:
[vagrant@zbxsrv ~]$ sudo docker exec zabbix-server nmap -p 10050 192.168.56.2
Starting Nmap 7.93 ( https://nmap.org ) at 2023-12-18 15:51 CET
Nmap scan report for 192.168.56.2
Host is up (0.00067s latency).
PORT STATE SERVICE
10050/tcp open zabbix-agent
Nmap done: 1 IP address (1 host up) scanned in 0.40 secondsKérdezzünk valami egyszerűt az agenttól, mondjuk az uptime-ot:
[vagrant@zbxsrv ~]$ sudo docker exec zabbix-server zabbix_get -s 192.168.56.2 -p 10050 -k system.uptime
zabbix_get [236]: Check access restrictions in Zabbix agent configurationHoppácska! Tudja valaki, hogy miért kaptunk hibaüzenetet?
Elsőre én sem értettem, aztán beugrott, hogy a labort úgy állítottam össze pár hónapja, hogy minden kommunikáció TLS titkosítást kapott. Szükségünk lesz a vm1 psk kulcsára, szerencsére van egy mappa, ami a zabbix szerver konténerbe fel van csatolva. Tegyük bele a vm1.psk fájlt a /home/vagrant/docker/zabbix-server mappába az alábbi tartalommal:
00fcb3f04e646dd9186717bb43f96aa829d01d497ea31254ca72a1ebe568aa96A helyes parancsunk:
[vagrant@zbxsrv ssh_keys]$ sudo docker exec zabbix-server zabbix_get -s 192.168.56.2 -p 10050 -k system.uptime --tls-connect=psk --tls-psk-identity="vm1" --tls-psk-file=/var/lib/zabbix/ssh_keys/vm1.psk
3494Teljesen mindegy, hogy milyen eredményt kaptunk, az a lényeg, hogy kapjunk egy számot válaszul!
Megjegyzés: aki nem konténerben futtatja a zabbix szervert, annak így fog kinézni a megfelelő parancs:
[vagrant@zbxsrv ~]$ zabbix_get -s 192.168.56.2 -p 10050 -k system.uptime --tls-connect=psk --tls-psk-identity="vm1" --tls-psk-file=vm1.psk
4153Természetesen előbb fel kell telepíteni a zabbix-get nevű csomagot, és ugyanúgy létre kell hozni a vm1.psk fájlt.
Ebben a laborban azért működik mindkét módszer, mert ugyanarról a szerverről adtam ki a parancsot, azaz a vm1 gép zabbix agentje nem tud különbséget tenni a két kérés között, mert mindkettő ugyanarról az IP címről érkezett. Ezért fontos, hogy a zabbix szerverről teszteljünk.
Most direkt lekérdezem egy másik gépről:
[msandor@msandorhp ~]$ zabbix_get -s 192.168.56.2 -p 10050 -k system.uptime --tls-connect=psk --tls-psk-identity="vm1" --tls-psk-file=vm1.psk
zabbix_get [3155555]: Get value error: SSL_read() TLS connection has been closed during read
zabbix_get [3155555]: Check access restrictions in Zabbix agent configurationPedig a port innen nézve is nyitva van:
[msandor@msandorhp ~]$ nmap -p 10050 192.168.56.2
Starting Nmap 7.93 ( https://nmap.org ) at 2023-12-18 18:27 CET
Nmap scan report for 192.168.56.2
Host is up (0.00037s latency).
PORT STATE SERVICE
10050/tcp open zabbix-agent
Nmap done: 1 IP address (1 host up) scanned in 0.37 secondsBemutattam a jó válaszokat („open” és „egy szám”), most bemutatom azt az esetet, ha elgépelem a zabbix szerver IP címét a vm1 gép zabbix agent konfigjában (/etc/zabbix/zabbix_agentd.conf).
[root@vm1 ~]# sed s,"192.168.56.6","192.168.56.111",g -i /etc/zabbix/zabbix_agentd.conf
[root@vm1 ~]# systemctl restart zabbix-agentÚjra mehet a teszt a konténerből:
[vagrant@zbxsrv ~]$ sudo docker exec zabbix-server zabbix_get -s 192.168.56.2 -p 10050 -k system.uptime --tls-connect=psk --tls-psk-identity="vm1" --tls-psk-file=/var/lib/zabbix/ssh_keys/vm1.psk
zabbix_get [836]: Get value error: SSL_read() TLS connection has been closed during read
zabbix_get [836]: Check access restrictions in Zabbix agent configurationA hibaüzenet ugyanaz lett, mint ha máshonnan kérdeztem volna le. Állítsuk vissza az IP címet:
[root@vm1 ~]# sed s,"192.168.56.111","192.168.56.6",g -i /etc/zabbix/zabbix_agentd.conf
[root@vm1 ~]# systemctl restart zabbix-agentMost elrontom a hálózati kapcsolatát, a példa kedvéért feltelepítek egy tűzfalat (firewalld), és nem nyitom ki a 10050-es tcp portot (persze el is indítom, és lekérdezem a státuszát):
[root@vm1 ~]# yum install firewalld
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.nextlayer.at
* epel: mirror.nextlayer.at
* extras: mirror.nextlayer.at
* updates: mirror.nextlayer.at
Resolving Dependencies
--> Running transaction check
---> Package firewalld.noarch 0:0.6.3-13.el7_9 will be installed
--> Processing Dependency: python-firewall = 0.6.3-13.el7_9 for package: firewalld-0.6.3-13.el7_9.noarch
--> Processing Dependency: firewalld-filesystem = 0.6.3-13.el7_9 for package: firewalld-0.6.3-13.el7_9.noarch
--> Processing Dependency: ipset for package: firewalld-0.6.3-13.el7_9.noarch
--> Processing Dependency: ebtables for package: firewalld-0.6.3-13.el7_9.noarch
--> Running transaction check
---> Package ebtables.x86_64 0:2.0.10-16.el7 will be installed
---> Package firewalld-filesystem.noarch 0:0.6.3-13.el7_9 will be installed
---> Package ipset.x86_64 0:7.1-1.el7 will be installed
--> Processing Dependency: ipset-libs(x86-64) = 7.1-1.el7 for package: ipset-7.1-1.el7.x86_64
--> Processing Dependency: libipset.so.13(LIBIPSET_4.8)(64bit) for package: ipset-7.1-1.el7.x86_64
--> Processing Dependency: libipset.so.13(LIBIPSET_2.0)(64bit) for package: ipset-7.1-1.el7.x86_64
--> Processing Dependency: libipset.so.13()(64bit) for package: ipset-7.1-1.el7.x86_64
---> Package python-firewall.noarch 0:0.6.3-13.el7_9 will be installed
--> Processing Dependency: python-slip-dbus for package: python-firewall-0.6.3-13.el7_9.noarch
--> Running transaction check
---> Package ipset-libs.x86_64 0:7.1-1.el7 will be installed
---> Package python-slip-dbus.noarch 0:0.4.0-4.el7 will be installed
--> Processing Dependency: python-slip = 0.4.0-4.el7 for package: python-slip-dbus-0.4.0-4.el7.noarch
--> Running transaction check
---> Package python-slip.noarch 0:0.4.0-4.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
=============================================================================================================================================================================================
Package Arch Version Repository Size
=============================================================================================================================================================================================
Installing:
firewalld noarch 0.6.3-13.el7_9 updates 449 k
Installing for dependencies:
ebtables x86_64 2.0.10-16.el7 base 123 k
firewalld-filesystem noarch 0.6.3-13.el7_9 updates 51 k
ipset x86_64 7.1-1.el7 base 39 k
ipset-libs x86_64 7.1-1.el7 base 64 k
python-firewall noarch 0.6.3-13.el7_9 updates 355 k
python-slip noarch 0.4.0-4.el7 base 31 k
python-slip-dbus noarch 0.4.0-4.el7 base 32 k
Transaction Summary
=============================================================================================================================================================================================
Install 1 Package (+7 Dependent packages)
Total download size: 1.1 M
Installed size: 4.5 M
Is this ok [y/d/N]: y
Downloading packages:
(1/8): ipset-7.1-1.el7.x86_64.rpm | 39 kB 00:00:00
(2/8): ebtables-2.0.10-16.el7.x86_64.rpm | 123 kB 00:00:00
(3/8): firewalld-0.6.3-13.el7_9.noarch.rpm | 449 kB 00:00:00
(4/8): ipset-libs-7.1-1.el7.x86_64.rpm | 64 kB 00:00:00
(5/8): firewalld-filesystem-0.6.3-13.el7_9.noarch.rpm | 51 kB 00:00:00
(6/8): python-slip-dbus-0.4.0-4.el7.noarch.rpm | 32 kB 00:00:00
(7/8): python-firewall-0.6.3-13.el7_9.noarch.rpm | 355 kB 00:00:00
(8/8): python-slip-0.4.0-4.el7.noarch.rpm | 31 kB 00:00:00
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 1.8 MB/s | 1.1 MB 00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : ebtables-2.0.10-16.el7.x86_64 1/8
Installing : ipset-libs-7.1-1.el7.x86_64 2/8
Installing : ipset-7.1-1.el7.x86_64 3/8
Installing : python-slip-0.4.0-4.el7.noarch 4/8
Installing : python-slip-dbus-0.4.0-4.el7.noarch 5/8
Installing : python-firewall-0.6.3-13.el7_9.noarch 6/8
Installing : firewalld-filesystem-0.6.3-13.el7_9.noarch 7/8
Installing : firewalld-0.6.3-13.el7_9.noarch 8/8
Verifying : ipset-7.1-1.el7.x86_64 1/8
Verifying : python-slip-dbus-0.4.0-4.el7.noarch 2/8
Verifying : firewalld-filesystem-0.6.3-13.el7_9.noarch 3/8
Verifying : firewalld-0.6.3-13.el7_9.noarch 4/8
Verifying : python-slip-0.4.0-4.el7.noarch 5/8
Verifying : python-firewall-0.6.3-13.el7_9.noarch 6/8
Verifying : ipset-libs-7.1-1.el7.x86_64 7/8
Verifying : ebtables-2.0.10-16.el7.x86_64 8/8
Installed:
firewalld.noarch 0:0.6.3-13.el7_9
Dependency Installed:
ebtables.x86_64 0:2.0.10-16.el7 firewalld-filesystem.noarch 0:0.6.3-13.el7_9 ipset.x86_64 0:7.1-1.el7 ipset-libs.x86_64 0:7.1-1.el7 python-firewall.noarch 0:0.6.3-13.el7_9
python-slip.noarch 0:0.4.0-4.el7 python-slip-dbus.noarch 0:0.4.0-4.el7
Complete!
[root@vm1 ~]# systemctl start firewalld
[root@vm1 ~]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0 eth1
sources:
services: dhcpv6-client ssh
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:Ismét lefuttatom a port szkennert, és a zabbix_get parancsot:
[vagrant@zbxsrv ~]$ sudo docker exec zabbix-server nmap -p 10050 192.168.56.2 -Pn
Starting Nmap 7.93 ( https://nmap.org ) at 2023-12-18 17:28 CET
Nmap scan report for 192.168.56.2
Host is up (0.0014s latency).
PORT STATE SERVICE
10050/tcp filtered zabbix-agent
Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds
[vagrant@zbxsrv ~]$ sudo docker exec zabbix-server zabbix_get -s 192.168.56.2 -p 10050 -k system.uptime --tls-connect=psk --tls-psk-identity="vm1" --tls-psk-file=/var/lib/zabbix/ssh_keys/vm1.psk
zabbix_get [917]: Get value error: cannot connect to [[192.168.56.2]:10050]: [113] Host is unreachableMegváltozott az eredmény, a port „filtered” lett, a lekérdezés pedig „Host is unreachable” választ adott, azaz nem elérhető.
Leállítottam a tűzfalat, újra működik minden. Most bemutatom a 4. variációt, amikor nem fut a zabbix agent:
[root@vm1 ~]# systemctl stop zabbix-agentJöhet a szken és a lekérdezés:
[vagrant@zbxsrv ~]$ sudo docker exec zabbix-server nmap -p 10050 192.168.56.2 -Pn
Starting Nmap 7.93 ( https://nmap.org ) at 2023-12-18 17:37 CET
Nmap scan report for 192.168.56.2
Host is up (0.00051s latency).
PORT STATE SERVICE
10050/tcp closed zabbix-agent
Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds
[vagrant@zbxsrv ~]$ sudo docker exec zabbix-server zabbix_get -s 192.168.56.2 -p 10050 -k system.uptime --tls-connect=psk --tls-psk-identity="vm1" --tls-psk-file=/var/lib/zabbix/ssh_keys/vm1.psk
zabbix_get [1037]: Get value error: cannot connect to [[192.168.56.2]:10050]: [111] Connection refusedAz eredmény: zárva a port (closed), és a zabbix_get nem tud csatlakozni az agenthez (cannot connect to…).
Összefoglalás
Két egyszerű paranccsal (nmap és zabbix_get) rengeteg hasznos információt meg lehet tudni a zabbix agentekről, a válaszok alapján nagy eséllyel rá fogunk jönni a hibára.