[ZBX-24717] Setting of items that use Change per second differs from manual. Created: 2024 Jun 25  Updated: 2024 Nov 25  Resolved: 2024 Nov 25

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Templates (T)
Affects Version/s: 6.0.30
Fix Version/s: None

Type: Problem report Priority: Major
Reporter: Osamu Uehara Assignee: Aleksejs Abrosimovs
Resolution: Declined Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Preprocessing.png     PNG File itemprototype.png    

 Description   

This ZBX ticket is a request to fix the some default template.
The manual for the Change per second includes the following statement.

Note: As this calculation may produce floating-point numbers, it is recommended to set the 'Type of information' to Numeric (float), even if the incoming raw values are integers.

However, several templates have different settings.
Example

  • Template:Network Generic Device SNMP
    • Item prototypes:Interface {#IFDESCR}: Bits received
      • Type of information:Numeric (unsigned)
  • Template:Cisco Catalyst 3750V2-24FS SNMP
    • Item prototypes:Interface {#IFNAME}({#IFALIAS}): Bits sent
      • Type of information:Numeric (unsigned)
  • Template:Cisco IOS SNMP
    • Item prototypes:Interface {#IFNAME}({#IFALIAS}): Inbound packets discarded
      • Type of information:Numeric (unsigned)

Wouldn't it be necessary to change to Numeric (float)?

 Comments   
Comment by Aleksejs Abrosimovs [ 2024 Nov 25 ]

As mentioned, the manual states:

Note: As this calculation may produce floating-point numbers, it is recommended to set the 'Type of information' to Numeric (float), even if the incoming raw values are integers.

But, it also states:

This is especially relevant for small numbers where the decimal part matters.

and:

If the floating-point values are large and may exceed the 'float' field length in which case the entire value may be lost, it is actually suggested to use Numeric (unsigned) and thus trim only the decimal part.

Taking into account that the metrics of the matter are bits and packets - smallest unsplittable entities and that the amount of them is usually huge, we can assume that the possible decimal part of the calculated result is not significant for troubleshooting and analysis and can be safely ignored in most cases.
Although, using float type is logically right, benefits of using integer to save space in the database outweighs possible rare cases where decimal part could matter.

And for these rare cases, any template can be altered by user to meet one's needs.

Generated at Tue Mar 18 11:08:31 EET 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.