[ZBX-11508] Handling of boolean type not correct Created: 2016 Nov 21  Updated: 2019 Mar 30  Resolved: 2019 Mar 30

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Proxy (P), Server (S)
Affects Version/s: 3.0.4
Fix Version/s: None

Type: Incident report Priority: Minor
Reporter: Raymond Kuiper Assignee: Zabbix Development Team
Resolution: Won't fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File screenshot-1.png     PNG File screenshot-2.png     PNG File screenshot-3.png    
Issue Links:
Duplicate
duplicates ZBXNEXT-3563 Allow the use of boolean data type in... Closed

 Description   

The manual states that using a data type of boolean should have the following behaviour:

"Data type is used for integer items in order to specify the expected data type:
Boolean - textual representation translated into either 0 or 1. Thus, 'TRUE' is stored as 1 and 'FALSE' is stored as 0. All values are matched in a case-insensitive way. Currently recognized values are, for:
TRUE - true, t, yes, y, on, up, running, enabled, available
FALSE - false, f, no, n, off, down, unused, disabled, unavailable
Additionally, any non-zero numeric value is considered to be TRUE and zero is considered to be FALSE."

As stated, any non-zero numeric values should be considered a boolean True and thus should be translated as "1" in the history. This is currently not the case in Zabbix 3.0.4. A value of '2' is stored without translation.



 Comments   
Comment by Raymond Kuiper [ 2016 Nov 21 ]

Tested with both trapper and internal items.

Comment by Raymond Kuiper [ 2016 Nov 21 ]

Curiously enough, sending 10000 as a value does translate to 1. From that moment on, translation seems to be working correctly.

See screenshot-1

Comment by Aleksandrs Saveljevs [ 2016 Nov 21 ]

Could it be that you had a "Decimal" item initially, then switched to "Boolean" and started sending values, but the server's configuration cache still used the old "Decimal" setting for some time?

Comment by Raymond Kuiper [ 2016 Nov 21 ]

It was a newly created item which was set to boolean from the start.

Comment by Aleksandrs Saveljevs [ 2016 Nov 21 ]

I could not reproduce it with trapper items (where the value is obtained externally), but internal items (where the value is obtained from inside the server) do not seem to take "Boolean" setting into account indeed.

Comment by Raymond Kuiper [ 2016 Nov 21 ]

Hmm, wait. For the trapper you might be right, issue might be due to config cache there.
The internal item is however definitely set to boolean from the start.

See new screenshot-2 and screenshot-3.

Comment by Raymond Kuiper [ 2016 Nov 21 ]

@asaveljevs: Thanks for confirming!

Comment by Aleksandrs Saveljevs [ 2016 Nov 23 ]

As Raymond already mentioned in ZBXNEXT-3563, there is no possibility to select boolean for calculated and aggregate items. The fact that there is a possibility to select boolean for internal items is probably a frontend bug, so we could theoretically limit it on the frontend side. In other words, the choice of boolean/octal/decimal/hexadecimal is currently meant for values obtained from the outside using strings, rather than in-memory.

However, there are other item types like simple checks where the value can be obtained both internally (e.g., ICMP pings) and externally (VMware items?), so the choice of whether to limit the data type cannot be made based on item type alone. Therefore, this issue looks more like a feature request, so it is proposed to close this as a duplicate of ZBXNEXT-3563. In any case, it should probably be done after ZBXNEXT-1443 and ZBXNEXT-3508, because a lot of related code is likely to change.

Comment by Raymond Kuiper [ 2016 Nov 23 ]

If this is considered a frontend bug, can this be resolved under this ZBX or do we need to add a new one referencing this one?

Comment by Aleksandrs Saveljevs [ 2016 Nov 23 ]

We decided not to fix the frontend right now, because the problem is minor and would not solve the problem fully anyway (e.g., simple checks).

Comment by Aleksandrs Saveljevs [ 2016 Nov 28 ]

Raymond, would you like to keep this issue open or we can close it as a duplicate of ZBXNEXT-3563?

Comment by Alexander Vladishev [ 2019 Mar 30 ]

Seems it was fixed in version 3.4.1 with ZBXNEXT-3006. Now all values, regardless of their source, go through the preprocessing, where the preprocessor step "Boolean to decimal" is applied to them.

Generated at Fri Mar 29 08:43:15 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.