Advertising:
Troubleshooting High Usage Zabbix LLD worker processes y Zabbix configuration syncer processes
Jump to navigation
Jump to search
Antes que nada, me gustaría dar las gracias a Gustavo Guido (CUSTOS) y Carlos Ortega (Imagunet) ambos integrantes del grupo de Telegram ZabbixEspañol que gracias a su ayuda pude llegar a la resolución en un tiempo récord!!! :)
Problema
Zabbix se degrada y comienza a funcionar mal, tenemos alarmas de "Zabbix LLD worker processes more than 75% busy" aunque en la realidad los procesos tanto de LLD Worker como de Configuration Syncer están casi todo el tiempo al 100%
Detección
Se activa el LogSlowQueries en el zabbix_server.conf lo que permite ver en el log las querys mas lentas.
# vi /etc/zabbix/zabbix_server.conf LogSlowQueries=3000
- Donde aparecian muchas del tipo: 10952:20220303:131404.882 slow query: 19.891447 sec, "update item_discovery set lastcheck=1646309621 where itemid in (483123,483124,...);" 10956:20220303:131404.882 slow query: 21.557915 sec, "update item_discovery set lastcheck=1646309617 where itemid in (482189,482190,...);" 10958:20220303:131429.337 slow query: 9.698309 sec, "update trigger_discovery set lastcheck=1646309634 where triggerid in (205974,205975,...);" 10954:20220303:131435.607 slow query: 5.215942 sec, "select id.itemid,...,i.allow_traps from item_discovery id join items i on id.itemid=i.itemid where id.parent_itemid in (...)"
Con esta información podemos intuir que las tablas item_discovery y trigger_discovery no están funcionando correctamente.
Resolución
Realizamos un VACUUM FULL
- Vamos a proceder a realizar una optimización de esta tablas con el comando VACUUM, recordar que la BD es un PostgreSQL y tener cuidado que el VACUUM que vamos a ejecutar bloquea las tablas en exclusiva, por este motivo es mejor ejecutarlo con Zabbix detenido.
zabbix=> VACUUM FULL item_discovery; zabbix=> REINDEX TABLE public.item_discovery; zabbix=> VACUUM FULL trigger_discovery; zabbix=> REINDEX TABLE public.trigger_discovery;
- Luego de ejecutar el comando podemos ver la siguiente mejoría:
Analizamos las filas muertas (N_DEAD_TUP)
Las filas murtas se generaban por un replicación slot de una replica anterior a la migración que quedo parada cuando inicie el proceso de migración. Zabbix tiene una muy alta transaccionalidad, al cortar la replica esta genero muchas filas muertas que degradaban la performance de la base de datos. Para solventar el problema eliminamos el slot de replicación y hacemos un VACUUM ANALYZE de la tabla.
- Ver los replication slots $ psql -U postgres -c "select * FROM pg_replication_slots ;" slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn ------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+---------------+--------------------- pgstandby2 | | physical | | | f | t | 100108 | | | C518/41000000 | (1 row)
- Borrar un replication slot
$ psql -U postgres -c "select pg_drop_replication_slot('pgstandby2');"
- Analizamos las tablas con mas n_dead_tup y vemos que las de item discovery es una de las que mas tienen
zabbix=> SELECT relname, n_dead_tup FROM pg_stat_user_tables where n_dead_tup > 0;
relname | n_dead_tup
----------------------+------------
problem | 5
alerts | 6
triggers | 1
hosts | 38
application_discovery | 29
globalvars | 2
graphs | 5
events | 164
item_discovery | 78189072 <----
_hyper_2_9569_chunk | 6635
housekeeper | 47
auditlog | 721
sessions | 703
items | 111
items_applications | 25
acknowledges | 3
escalations | 5
task | 5
host_discovery | 9
event_recovery | 65
_hyper_3_9568_chunk | 88
graph_discovery | 97
trigger_discovery | 13345530 <----
problem_tag | 58
httptest | 28
event_tag | 472
host_inventory | 37
graphs_items | 10
28 rows)
- Ejecutamos un VACUUM ANALYZE y esperamos a ver si las limpia, se puede hacer con zabbix funcionando. zabbix=> VACUUM ANALYZE public.item_discovery; LOG: process 122527 still waiting for ShareUpdateExclusiveLock on relation 304242 of database 16402 after 1000.124 ms LOG: process 122527 acquired ShareUpdateExclusiveLock on relation 304242 of database 16402 after 1000.292 ms VACUUM
- Post ejecucion, vemos que ya no hay n_dead_tup y vemos que la performance en la BD mejora muchisimo.
zabbix=> SELECT relname, n_dead_tup FROM pg_stat_user_tables where n_dead_tup > 0;
relname | n_dead_tup
-----------------------+------------
problem | 5
alerts | 6
triggers | 3
hosts | 15
application_discovery | 28
globalvars | 1
graphs | 5
events | 164
item_discovery | 6886
_hyper_2_9569_chunk | 6635
housekeeper | 47
auditlog | 721
sessions | 995
items | 111
items_applications | 25
acknowledges | 3
escalations | 16
task | 5
host_discovery | 9
event_recovery | 65
_hyper_3_9568_chunk | 88
graph_discovery | 290
trigger_discovery | 5935
problem_tag | 58
httptest | 15
event_tag | 472
host_inventory | 49
graphs_items | 10
(28 rows)
Otras consultas que ayudaron a determinar que Items cargaban mas la utilización del LLD Process
zabbix=> select hostid,count(*) contador from items group by hostid order by contador desc; hostid | contador --------+---------- 15131 | 2544 host A 15082 | 2222 host B 15079 | 1892 host C 14949 | 1884 host D 15337 | 609 host E
zabbix=> select substring(key_,1,20),count(*) from items group by substring(key_,1,20) order by count(*) desc limit 10;
substring | count
----------------------+-------
emc_vnx5800.py["--co | 4146
vfs.fs.size[{#FSNAME | 3837
system.cpu.load[perc | 2877
vbr[VMResultBackup," | 1961
vfs.fs.size[/var/www | 1928
stk6780.py["--stdvol | 1613
vfs.file.cksum[/etc/ | 1366
icmppingsec | 1111
icmpping | 1111
icmppingloss | 1111
(10 rows)
Conclusión
- Es muy importante tener la herramienta de monitorización y la BD bien monitorizada, para poder detectar estos cambios de comportamiento rápidamente y poder solventarlos.
PD: Queda mas que claro que en cuanto tenga una ventana, tendré que realizar un VACUUM FULL a toda la BD de Zabbix, pero por el momento, con esto pude salir del paso!!!