When a TCP connection is successfully accepted but the remote peer does not complete the transmission of a Zabbix message, a trapper may remain occupied until the configured timeout on TrapperTimeout= is reached.

Currently, the logs can show that the process spent a significant amount of time processing the connection:

435:20260416:180509.233 zbx_setproctitle() title:'trapper #1 [processed data in 300.733235 sec, waiting for connection]' 

but they do not always provide enough information to determine whether the process was waiting for the remainder of an incomplete message.

Zabbix server and proxy currently provide extensive diagnostic information when DebugLevel=5 is enabled. However, troubleshooting incoming TCP connections can still require external packet captures to determine what happened to a connection before a request was completely received and processed.

It would be useful to extend the LOG_LEVEL_TRACE output with additional connection-level information for TCP connections handled by Zabbix server and proxy processes, especially trappers.

The goal is not to provide packet-level tracing or replace tools such as tcpdump/Wireshark, but to expose information that is already available at the application/socket level and that can help correlate connection problems with Zabbix processes.

For incoming connections, DebugLevel 5 could optionally log information such as:

• Remote IP address and source port;
• Local IP address and listening port;
• Connection acceptance timestamp;
• Connection security type (unencrypted/TLS, where applicable);
• Zabbix protocol flags after the header has been received;
• Expected payload size declared in the Zabbix protocol header;
• Expected uncompressed size when compression is enabled;
• Number of payload bytes actually received;
• Receive errors or timeout reason;
• Amount of data still expected when a timeout occurs;
• Connection close timestamp and reason.

For example, a timeout could provide diagnostic information similar to:

TCP receive timeout:
peer=192.0.2.10:54321
local=192.0.2.20:10051
protocol_flags=0x03
expected=1478752
received=4027
remaining=1474725
reason="read timeout"

Having this information available at DebugLevel 5 would significantly improve troubleshooting, particularly in environments involving load balancers, NAT, container networking, overlay networks, firewalls or other intermediate network components.

Benefits

This would make it easier to distinguish between:

• a Zabbix processing issue;
• an incomplete message received from a peer;
• a connection timeout;
• a network-related interruption.

It would also reduce the need for packet captures in production environments where network captures may be difficult or restricted.