[ZBXNEXT-6109] LLD Max Returned value through a Proxy limit 65536 characters ? Created: 2020 Aug 05  Updated: 2020 Sep 08  Resolved: 2020 Sep 08

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Documentation (D)
Affects Version/s: 5.0.2
Fix Version/s: None

Type: Change Request Priority: Critical
Reporter: Dimitri Bellini Assignee: Andris Zeila
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Centos 7.x


Attachments: PNG File Screenshot from 2020-08-05 10-37-14-1.png     PNG File Screenshot from 2020-08-05 10-37-14.png     PNG File Screenshot from 2020-08-05 15-19-49.png     PNG File zbx_proxy_limit_64k.png     PNG File zbx_proxy_limit_64k_returned_lld_json.png    
Issue Links:
Duplicate

 Description   

Hi DevTeam,

we have discovery a very confusing situation/limit of LLD disocvery.

From the Doc (https://www.zabbix.com/documentation/current/manual/discovery/low_level_discovery

There is no limit for low-level discovery rule JSON data if it is received directly by Zabbix server, because return values are processed without being stored in a database. There's also no limit for custom low-level discovery rules, however, if it is intended to acquire custom LLD data using a user parameter, then user parameter return value limit applies (512 KB).

If data has to go through Zabbix proxy it has to store this data in database so database limits apply.

So the Proxy have a huge limit to only 64k returned value! I think this a problem for Big installation that use Zabbix Proxy to monitoring Windows Services or applications/RestAPI.

What do you think to find a solution and align the limits of Zabbix Server and Zabbix Proxy to the same level?

Thanks so much

 



 Comments   
Comment by Oleksii Zagorskyi [ 2020 Aug 05 ]

On mysql "proxy_history.value" has "longtext" type, which is limited for 4GB.
So it's not a limit.

Comment by Dimitri Bellini [ 2020 Aug 05 ]

HI Oleksii,

Fantastic but why do you have so huge type  from the doc i saw this (https://www.zabbix.com/documentation/current/manual/config/items/item#text_data_limits): 

Strange?

 

 

Comment by Oleksii Zagorskyi [ 2020 Aug 05 ]

I am agree that makes sense to add one more column to the table - "Longtext".
We don't state on the page where each column is user, right? But at least it may indicate that "Text" is not maximal one.

Comment by Dimitri Bellini [ 2020 Aug 05 ]

Hi Oleksii, 

Maybe i missed something but how we can decide what table the LLD have to use on the Proxy? 

At the moment with a fresh Zabbix 5.0 installation we still have this kind of limits, do you mention some sort of workaround?

Thanks so much

Comment by Oleksii Zagorskyi [ 2020 Aug 05 ]

The limit comes from user parameter, not from the fact that you use proxy.

Maybe the 2nd sentence, you initially quoted, sounds more scary than it is actually, and it may mislead.
The "proxy_history.value"for:
mysql - Longtext = 4G https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html
postgres - Text = unlimited length https://www.postgresql.org/docs/9.1/datatype-character.html
sqlite3 - Text = practical default limit is 1 billion https://www.sqlite.org/limits.html
oracle - did not check.

I'd rewrite the sentence or would remove it at all.

Comment by Andris Zeila [ 2020 Aug 05 ]

The table lists data limits for item value types (character, log text). LLD rules (while technically stored into items table) is different matter.

Comment by Dimitri Bellini [ 2020 Aug 05 ]

I think if the returned value is related to DB type i would suggest to mention on the docs.

In our case we have installed the Zabbix Proxy DB on a Centos 7.7 with the default MariaDB 5.5.64, at the moment the table of "proxy_history" is defined like this:

so is defined as "longtext", maybe is a problem related to the MariaDB version 5.5 ?

Comment by Dimitri Bellini [ 2020 Sep 08 ]

The problem was not reproducible, so we can close the issue.

Generated at Sun Mar 16 02:33:32 EET 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.