[ZBX-16886] ZBX 4.4.1 snmp agent items network errors Created: 2019 Nov 08  Updated: 2019 Nov 22  Resolved: 2019 Nov 22

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 4.4.1
Fix Version/s: None

Type: Incident report Priority: Critical
Reporter: Anatoliy Grachev Assignee: Aigars Kadikis
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File image-2019-11-12-16-36-07-550.png     PNG File image-2019-11-12-18-13-44-384.png     PNG File image-2019-11-13-08-52-56-755.png    

 Description   

Hi there.

We have few network nodes monitored via snmp (only 6).
However, after upgrading to version 4.4.1, the newly added nodes show a timeout.
The logs show the following errors:
123092: 20191108: 143138.697 SNMP agent item "system.uptime [sysUpTime]" on host "XXXXXXXXXXXXXXXXXXXX" failed: first network error, wait for 15 seconds
123093: 20191108: 143219.001 SNMP agent item "system.uptime [sysUpTime]" on host "XXXXXXXXXXXXXX" failed: another network error, wait for 15 seconds
123089: 20191108: 143246.525 temporarily disabling SNMP agent checks on host "XXXXXXXXXXXXXXXXXX": host unavailable
In the configuration file, the timeout has already been increased to 30, snmpwalk receives data instantly from the zabbix machine:
zabbix-1 zabbix] $ time snmpwalk -v2c -c XXXXXXXXXXXXXXXX 1.2.3.4 .1.3.6.1.2.1.1.5.0
SNMPv2-MIB :: sysName.0 = STRING: XXXXXXXXXXXXXXXXX

real 0m0.029s
user 0m0.020s
sys 0m0.006s

Queues in administration - queues, no. There is a lot of free random access memory. An elastic is used as the database. The snmp trapper is running, but the file to which it should write the log is empty.
Can you help with something?

 

 Comments   
Comment by Aigars Kadikis [ 2019 Nov 11 ]

Kindly share the graph:

Monitoring -> Graphs -> Host group: Zabbix server -> Host: Zabbix server -> "Zabbix data gathering process busy"

Show it for the interval of the last 3h.

Comment by Anatoliy Grachev [ 2019 Nov 12 ]

Here

Comment by Anatoliy Grachev [ 2019 Nov 12 ]

The problems on the chart, but snmp still timeout

Comment by Anatoliy Grachev [ 2019 Nov 13 ]

Here is actual

Comment by Aigars Kadikis [ 2019 Nov 22 ]

Pollers which are responsible for SNMP data collection are very OK.

It's not a solution, but can you try restart backend daemon. Is the problem comes in the very next minutes?

Please include a bigger portion of the log file. Any other suspicious lines?

Do you monitor devices via a wired connection?

Is the "Use bulk requests" checkbox ON in the host configuration page? Please try to uncheck it for all hosts and see if there are some improvements regarding data collection.

 

We have few network nodes monitored via snmp (only 6).
However, after upgrading to version 4.4.1, the newly added nodes show a timeout.

Did you upgrade and then registered new nodes. or registred new nodes and hit the upgrade?

Comment by Anatoliy Grachev [ 2019 Nov 22 ]

Hi, restart zabbix-server does not help.
Debug level -4 does not shows any problems.
Of course we monitor devices via a wired connection.
Checkbox "Use bulk request" uncheck - watching.
The problem began to be observed after updating the server zabbiks. We use snmp discovery, which finds and adds new devices. After which the host becomes unavailable (beats by timeout). Although some of the data from these hosts comes. When we deleted the host that was added before the update and let the discovery add it again, there will be no problems with this host.

Comment by Aigars Kadikis [ 2019 Nov 22 ]

And then after awhile even newly discovered hosts will generate problems in the log file?

Are you linking some non-stock templates for the hosts which are having problems? please, upload template xml?

Comment by Anatoliy Grachev [ 2019 Nov 22 ]

Sorry this turned out to be my mistake.
In our network we use different community for different type device. I think that it's inherited from discobvery.

Thank you for help.

Generated at Fri Apr 17 05:45:32 EEST 2026 using Jira 10.3.18#10030018-sha1:5642e4ad348b6c2a83ebdba689d04763a2393cab.