Looks like the limit for system.run[] also increased in 2.0.5 version:
# zabbix_get -s localhost -p 10060 -k agent.version
2.0.4
# zabbix_get -s localhost -p 10060 -k system.run["cat /tmp/512K-1B.log"]
ZBX_NOTSUPPORTED

But would be good to get a C dev confirmation.

Probably it also (the increasing) worth to mention on the page https://www.zabbix.com/documentation/2.0/manual/config/items/itemtypes/zabbix_agent

(1) Interesting note, at least for mysql backend - http://dev.mysql.com/doc/refman/5.5/en/storage-requirements.html
BLOB, TEXT L + 2 bytes, where L < 2^16

In DB schema we use TEXT type for "value" column, so we cannot store more than 64K in history_text, history_log tables.
I guess this already discussed in other issue(s).

Are values truncating before store in to DB ?
Where it's documented ?

asaveljevs See also ZBX-11117.

martins-v Text data limits depending on DB type are documented for 3.0, 3.4, 4.0. RESOLVED

zalex_ua CLOSED

"system.run[]" executes the specified command and intercepts its standard output. The output is processed as a text. The output size limit is 64 kB (up to version 2.0.4) and 512 KB (starting from version 2.0.5 and in trunk) and includes trailing whitespace. Trailing whitespace is truncated. If the command output is not text but binary data containing NULL bytes the results are unpredictable.

martins-v Details about the output size limit and required text format added to system.run[] description:

https://www.zabbix.com/documentation/2.0/manual/config/items/itemtypes/zabbix_agent
https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/zabbix_agent

Please review.

andris If "system.run[]" command output exceeds 512 KB (actually, 524288 - 1 byte)(v.2.0.5 and in trunk) ZBX_NOTSUPPORTED is returned.

zalex_ua Looks good. Probably CLOSED.

Thanks Oleksiy & Martins, I guess we would then need to upgrade to 2.0.5.

We currently have for Zabbix server:
Zabbix server v2.0.3 (revision 30485) (03 October 2012)

As for clients/agents we have some that appear to be running:

On Solaris: Zabbix Agent (daemon) v2.0.0 (revision 27675) (21 May 2012)
Compilation time: Jun 4 2012 15:22:31

On Linux some have servers have:

Examples:

• On CentOS release 5.9 (Final):
  Zabbix Agent (daemon) v1.8.5 (revision 19050) (15 April 2011)
  Compilation time: Jun 22 2011 10:15:11

• On Red Hat Enterprise Linux Server release 6.3 (Santiago):
  Zabbix Agent (daemon) v1.8.8 (revision 21965) (28 September 2011)
  Compilation time: Oct 5 2011 10:20:47

Any words of wisdom on downloading/upgrading to the most current stable version of Zabbix? We'll start reading the documentation.

Thanks again.

Rick M.

Issue resolved, except (1) and (2)
zalex_ua CLOSED

(2) details from ZBX-5863 could be mentioned on https://www.zabbix.com/documentation/2.0/manual/discovery/low_level_discovery#creating_custom_lld_rules as a note.
Looks like there is also a limit - 512 KB.

Similar discussion (odbc related) is ZBX-8489.

martins-v Data limits for low-level discovery documented for 3.0, 3.4, 4.0. RESOLVED

zalex_ua CLOSED

SPECIAL CASE
UserParameter, used in LLD

Seems to be actual for any agent's userparameter, including LLD:

# /usr/local/bin/my-lld-script | wc -c
3218151

# zabbix_get -s localhost -k my-lld-key
ZBX_NOTSUPPORTED

#tail /var/log/zabbix/zabbix_agentd.log
Traceback (most recent call last):
File "/usr/local/bin/scu-lld-triggers", line 89, in <module>
print dumps(out_data, ensure_ascii=False).encode('utf8')
IOError: [Errno 32] Broken pipe
53710:20141205:162332.827 command output exceeded limit of 512 KB

# zabbix_agent --version
Zabbix agent v2.2.6 (revision 48483) (27 August 2014)
Compilation time: Aug 28 2014 10:11:26

But, if agent's userparameter implements LLD - not all of returned data will be stored in one cell of backend db, isn't it?
Withal, LLD should be able to return a lot of data in the single request. It is rather justly, if we have only one expression to use in external system request - we can not separate requests to decrease data.

Dear viktorkho and all those who is interested!

LLD rule result is not stored in DB, but is processed by the server "on the fly", so there is no limitation for the full size of LLD data if it comes to server directly. If it comes through proxy, it must be stored in proxy's DB and it will be truncated in the process (mildly to 64 Kchars or vigorously to 2048 bytes depending on proxy's backend). But it seems there is a limitation on LLD data line which should not be longer than 64 KB.