[ZBX-13523] confusing messages during network discovery Created: 2018 Feb 21 Updated: 2021 Aug 17 Resolved: 2018 Mar 02 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Proxy (P), Server (S) |
Affects Version/s: | 4.0.0alpha3 |
Fix Version/s: | 4.0.0alpha5, 4.0 (plan) |
Type: | Problem report | Priority: | Trivial |
Reporter: | richlv | Assignee: | Vladislavs Sokurenko |
Resolution: | Fixed | Votes: | 0 |
Labels: | logging | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
||||||||||||
Team: | Team A | ||||||||||||
Sprint: | Sprint 28 | ||||||||||||
Story Points: | 0.5 |
Description |
Steps to reproduce: Result: Message from <IP> is missing header. Message ignored. Expected: |
Comments |
Comment by Vladislavs Sokurenko [ 2018 Feb 22 ] |
Thank you for your report, reproduced also for passive check without discovery. Here is how it worked previously: Received empty response from Zabbix Agent at [127.0.0.1]. Assuming that agent dropped connection because of access permissions. Server log with warning level: 31294:20180222:095319.526 Zabbix agent item "agent.ping" on host "Zabbix server" failed: first network error, wait for 15 seconds 31296:20180222:095334.562 Zabbix agent item "agent.ping" on host "Zabbix server" failed: another network error, wait for 15 seconds 31296:20180222:095349.670 Zabbix agent item "agent.ping" on host "Zabbix server" failed: another network error, wait for 15 seconds 31296:20180222:095404.720 temporarily disabling Zabbix agent checks on host "Zabbix server": host unavailable For discovery 31860:20180222:095920.818 discovery: item [system.uname] error: Received empty response from Zabbix Agent at [127.0.0.1]. Assuming that agent dropped connection because of access permissions. Old behavior must be restored. |
Comment by Vladislavs Sokurenko [ 2018 Feb 22 ] |
Fixed in development branch: |
Comment by richlv [ 2018 Feb 23 ] |
thank you for doing a more throughout testing. could you please clarify on the changes - to what extent was the old behaviour restored ? what will happen if a passive agent version 1.0 is queried by the server ? vso yes, it will stop logging the messages, behavior will be same as before, I am not sure about 1.0 do you have one to try ? <richlv> not right now, but if there was a specification, what would it say about such a scenario ?
vso I think in that case agent would think that only ZBXD\1\6 was received but I am not sure if Zabbix server 4.0 works with agent 1.0 at all. |
Comment by Andris Zeila [ 2018 Feb 27 ] |
Successfully tested |
Comment by Vladislavs Sokurenko [ 2018 Feb 28 ] |
Fixed in:
|
Comment by asdfg [ 2018 Jun 06 ] |
I have installed zabbix agent in version 4.0.0alpha7 and server is 3.0.18. After configuration passive monitoring I see this error message in zabbix agent log Message from $ZABBIX_SERVER_IP is missing header. Message ignored. There is no compatibility between 4.0 and 3.0? |
Comment by asdfg [ 2018 Sep 26 ] |
Any update? Server: Zabbix 3.0.22 Client: 4.0.0beta2 Result: Message from XXX is missing header. Message ignored. |
Comment by Vladislavs Sokurenko [ 2018 Sep 26 ] |
This is documented in upgrade notes: Plain text protocol dropped Support for the plain text protocol has been dropped and a header is now mandatory. A header has been added to Zabbix get requests, Zabbix server/proxy passive check requests and frontend requests to Zabbix server. As a consequence, Zabbix agents that are older than version 1.4 are no longer supported. Also, messages from self-written senders will be rejected if the header is absent. Whereas previously Zabbix trappers would accept messages without headers as well as messages with headers, now they will only accept messages with protocol header. |
Comment by Enrico Tröger [ 2018 Oct 14 ] |
I'm affected by this as well (Zabbix Server: 3.0, one of the agents in 4.0). IMO this scenario might affect more users where the server is still 3.x while some of the monitored agents get updated before the server and then monitoring will break. Wouldn't it be possible to add some compatibility layer for exactly this case? |