Server returned empty content treatment

[markfree]

I'm monitoring an HTTP endpoint that returns a text list, and use a Javascript preprocessing step to count the number of lines.

Sometimes the returned value is empty, so Zabbix makes the item unsupported.


I could use a "Check for not supported value" preprocessing step, but I think that would bypass any error the item might have.
How do you guys handle the "Server returned empty content" error?

[cyber]

That should be the correct step to take. As docs say,

This step is always executed as the first preprocessing step and is placed above all others after saving changes to the item. It can be used only once.

so it cannot have any influence on other steps you may have there...

[markfree]

I see.
I was looking for alternative ways for handling this kind of error.
For instance, in cases where the content is empty, the "Check for not supported value" preprocessing step could resolve it by assigning a value of 0, preventing it from being marked as unsupported.
However, when the HTTP code is other than 200, the current preprocessing step wouldn't appropriately handle it, leading to the item not being flagged as unsupported.

I wish there was a more granular error handling.

[cyber]

Empty content is error 204 IIRC, so it will not pass your initial code check for 200... thus, it becomes "not supported", but then preprocessing kicks in and "check for unsupported" sets value to whatever you want. After that your JS preprocessing can probably handle this, if you consider it.. Isn't this what you need? Item not becoming unsupported... You can have a special trigger for this value, what you set to get notified about such cases...
I think if you get empty answer with code 200, your item does not become unsupported, just your JS cannot handle the emptiness...

[markfree]

I think I understand what you mean, but I'm not sure it is this case.

You see... If I test the HTTP item and switch the "Retrieve mode" to "Headers", we can see the return code.
If Zabbix successfully retrieves the data, the HTTP item will receive the code 200.


If the HTTP item receives an empty response, the HTTP code will also be 200 and the item will still be unsupported.


Now, imagine if the return code was 404 or something else, the preprocessing step would also bypass the error.

[cyber]

I don't really see, how in your second example it manages to become unsupported before all the preprocessing, even if your accepted code is OK.. Any other checks there? SSL checks or something?
If your item setting has that ok code is only 200, then it will not become unsupported with empty answer which has 200 in header. That code is checked before any preprocessing.

[markfree]

It's just a simple HTTP Get with no other checks.


I don't think the server is actually sending an empty content message. It sends an empty string.


Still, the item gets unsupported by "empty content".


Well... it is empty after all.
My point is that I didn't want to use the "Check for not supported value" preprocessing step. But, I guess that it is not possible in this scenario.