Zabbix and Wazuh operations

The problem

Monitoring has to remain useful during failures. That means understanding not only dashboards but the database, agents, alert encoding, backups, memory use and service dependencies behind them.

What I did

The current environment uses Zabbix 6.0.42 LTS in an LXC and Wazuh 4.14.3-1 in a dedicated VM.

• Investigated Zabbix LXC backup failure caused by a missing local MySQL socket
• Identified database character-set limitations that rejected emoji alert content
• Used plain-text alert templates as a safe workaround pending utf8mb4 migration
• Tuned Wazuh heap allocation to stabilise the indexer/dashboard workload
• Kept monitoring and security roles distinct: health and trends in Zabbix, endpoint and event analysis in Wazuh

Implementation notes

Representative commands from the way I diagnose and maintain this project. Public examples use placeholders instead of credentials or sensitive addresses.

# Zabbix server and agent checks
systemctl status zabbix-server zabbix-agent2 --no-pager
journalctl -u zabbix-server -n 100 --no-pager
zabbix_get -s <AGENT_IP> -k agent.ping

# Wazuh manager, indexer and dashboard checks
systemctl status wazuh-manager wazuh-indexer wazuh-dashboard --no-pager
journalctl -u wazuh-manager -n 100 --no-pager
filebeat test output

# Confirm listening services and resource pressure
ss -lntup
free -h
df -hT

Result

The result is a monitoring setup I understand below the dashboard layer, including how to recover it and how to recognise when the monitoring platform itself is unhealthy.