Steps to reproduce:
Install a Zookeeper cluster with 3 instances.
Get all Zookeeper instances monitored by Zabbix via the Zookeeper by HTTP template.
Check which Zookeeper instance is the leader of the cluster (e.g. curl -s http://<ip_of_zookeeper>:8080/commands/leader).
Stop that Zookeeper instance which is the leader.

Result:
An alert is generated for the two remaining Zookeeper instances saying that Zookeeper was restarted there. But a check of the Zookeeper service does not report a restart.

Expected:
No alert.

The check of the template is getting the uptime of the Zookeeper instance via the REST API by curl -s http://<ip_of_zookeeper>:8080/commands/monitor.
When the uptime value is less than 60 seconds, it assumes that Zookeeper has restarted.

This check may be useful in a stand-alone configuration.

In a Zookeeper cluster, every time a new leader is elected, this internal uptime value is reset to 0.
That re-election does not affect the operation, it only gives any application which is using the Zookeeper cluster the info to which instance the requests shall be sent to.
So in a Zookeeper cluster, checking that uptime value is not the right way to decide if Zookeeper was restarted or not.