RockyLinux 8.x

Ok I have tested also on Zabbix 6.0.x and it work in the same way of 6.2.2, text value are not managed by the step "Check of Not supported value".

I'd agree with issue reporter that from zabbix user point of view, the error is just about not supported, disregarding that it's classified on server side when processing real received value.

CONFIRMED.

Hi Oleksii,
this use case is very common from my experience.
For instance if you are monitoring temperature/power supplies/etc on some SNMP devices, sometimes they will change to report "numbers" to "text message" if something is not working as expected (ie. PSU not present).

Thanks so much

This is a very interesting one and let me try to clear up things here.

How does Zabbix server processes the collected value

1. Zabbix process (poller, trapper, does not matter) receives the result of an attempt to collect the metric value, it could be
   1. a valid result
   2. what seems to be a valid result (e. g. we have the result but it's value type is not what we expected, this will become NOTSUPPORTED later)
   3. ZBX_NOTSUPPORTED (an attempt to retrieve the value failed)
2. This process passes whatever the result of an attempt is to preprocessing and the steps are executed one by one:
   1. if Check for not supported value step exists it's executed first (note, it catches 1.3 but not 1.2)
   2. other preprocessing steps are executed
   3. the result is passed back
3. Now the result is validated and if the resulting value type does not match item value type, item becomes NOTSUPPORTED

As you can see, 1.2 will never be caught by 2.1 and the item will become NOTSUPPORTED (the case of this issue).

Some facts

The name of the Preprocessing step Check for not supported value is really confusing here and the biggest problem, as I see it. The idea of the name was "There was an issue while trying to retrieve the metric value". In your case, there was no issue when trying to collect it. In fact, with Trapper item this makes even less sense. There can never be an issue collecting a metric if it'a a Trapper item. If I could not collect it I have nothing to send. If it's not sent, we have nothing to do, if it is sent - we have the value, we had no issues retrieving it. If there is a network issue, it's a network issue, it's not related to the item.

So, fact #1, the Check for not supported value preprocessing step does not make sense in Trapper item. I'd expect this choice not even available in the drop-down of the preprocessing steps if item type is Trapper. But then the issue would be when item type is changed, I mean, do we want to remember this step or not. I think at least for Trapper item there could be a red warning saying something like You have configured a preprocessing step that will be ignored so we won't have issues like this anymore and everyone would be happier.

Fact #2, the preprocessing step name Check for not supported value is misleading as this step is not covering all the cases when item becomes NOTSUPPORTED (e. g. this issue). I'd suggest changing the name to something like Check if no item value could be retrieved. Then, when during troubleshooting a user would check preprocessing steps of a Trapper item it'd be easier to understand what's going on and why his step did not handle it.

Fact #3, this should be documented, at least, as currently there is no word on the exceptions when this preprocessing step will not work.

"Check for not supported value" VS item type

What about other item types? This is what I came up with after doing some investigation:

Item type	"Check for not supported value" makes sense	Example
Zabbix agent		unknown item key
Zabbix agent (active)		unknown item key
Simple check		unknown item key
SNMP agent		unknown oid
SNMP trap		cannot read trap file
Zabbix internal		unknown item key
Zabbix trapper		The only way for this preprocessing step to work is to send string "ZBX_NOTSUPPORTED" as the value of the trapper item. Can't think of a scenario when this could be useful though.
External check		script not found
Database monitor		invalid SQL
HTTP agent		no such URL
IPMI agent		unknown sensor
SSH agent		login failed
TELNET agent		login failed
JMX agent		no such JMX metric
Calculated		invalid formula syntax
Dependent item		This will work only if the master item becomes "notsupported".
Script		JavaScript syntax error

But! Remember that incorrect item value type received is not the case, it is never the case, because we have preprocessing steps that can be used to fix that.

Dear Dimir,
very good and detailed explanation of the problem but how we can solve the problem of "Item Type Mismatch"? We can not use both Preproc for "Check for not supported value" and RegExp or Replace?
Can you suggest a work around?

PS: I think we need this detailed explanation on Official Zabbix Documentation. Thanks

I'd add Custom multiplier with parameter 1, checked the Custom on fail checkbox and either discard it or set the value to what's needed:

Nice trick but I can not check if we have problem on "result of an attempt".
It's correct? Thanks

You cannot have failed "attempt to collect" with Trapper item. Value mismatch is not the issue of collecting, it's an issue of applying. This is why I believe changing that step name is so important.

Sorry Dimir, my example is not related to Zabbix Trapper but for instance to SNMP Check.
The best way to monitoring this kind of Items id to have a good collection validation, for instance some preproc like:

• Check for not supported value - To detect some possible failure on SNMP collection of wrong OID
• Validation step - Some times there are some specific situation that we receive a different value type than the standard values

Have you never seen such behavior?

Best regards

I understand but I'd still recommend to use Custom multiplier with 1. Let me try to explain.

Besides other things Preprocessing is used to change the collected value type. And this is a valid use case. For example, we receive the temperature value as "15 ℃", which is, obviously, a string. We have the following item configuration:

• item value type: Numeric (unsigned)
• Preprocessing, only 1 step: Remove non-digits (using e. g. Replace)

After the value is preprocessed we will get an integer and there will be no value type error.

Thus, since Preprocessing was introduced, no matter what item type, we cannot check the value type at the moment we receive it, because it might get fixed in Preprocessing steps.

So, to conclude, if the reason of NOTSUPPORTED is incorrect value type (item type does not matter) it will always happen after Preprocessing, which means, this can never be caught with Check for not supported value.

Ok, understood.
In my specific case of a Network device that return for the Power Supply temperature metrics something like that:

• "numbers" equal to temperature
• "no sensor" (a string) in case of no power supply presence
  We can"validate" it using a preproc step like "Dos not match RegExp" with the option "Custom on fail" to discard or what we prefer.

Thanks so much

So, to conclude, here is what I suggest to do here:

1. Rename preprocessing step name Check for not supported value to Check if no value could be retrieved.
2. When configuring Check if no value could be retrieved preprocessing step show warning
   This check is performed before preprocessing, it will not work for catching the errors of other steps
3. Document this whole thing.

Reopening as there was no changes in the code so the resolution "Fixed" is incorrect.

I propose to document how the "Check for not supported value" preprocessing step works.

More victims of this confusion: ZBX-25416 ZBX-21126 

Hi Dimir,

Rather than document it (which can be a good starting point), it might be more beneficial to enhance the feature to directly support these kinds of dynamic scenarios

Thank you very much for your time and consideration.

For catching the "in-between steps" errors of this kind I believe there is "Custom on fail". I understand that there could be changes for good here but I can't decide on that. At this point we were allowed to document current behaviour.

Hi Dimir,

Thank you, it's the first step. Maybe ZabbixDevs can consider the suggestion for the next releases.

Thank you!

adancis Do you think we could have an appendix with a more detailed description for those that would like to dive deeper into this? An entry with the whole this comment:

https://support.zabbix.com/browse/ZBX-21543?focusedId=748530&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-748530

and a link to that from "Check for not supported value" step documentation with "learn more about"? While I agree this might be interesting for less than 1 % of our users I believe it might be crucial for those and isn't appendix exactly for things like this?

Documentation updated:

• Item value preprocessing (6.0, 6.4, 7.0, 7.2, 7.4; updated "Check for not supported value" description)
• Usage examples/Preprocessing examples (6.0, 6.4, 7.0, 7.2, 7.4; added new example)

For now, the documentation has been updated to include a clarification about the limit of the "Check for not supported value" preprocessing step. dimir, I'm uncertain whether adding a page to Appendixes is the best solution here; perhaps updating the Preprocessing details page would be more appropriate. I'll see what I can do.

Thanks, adancis! That was some decent amount of work spent on this and I heard a couple of positive feedbacks about that very detailed description this is why I would hate loosing this information. And I mean, including that table with different item types.

Documentation updated:

• Usage examples/Preprocessing examples (6.0, 6.4, 7.0, 7.2, 7.4; added "Checking for not supported value" example)