Zabbix: fixing “Invalid parameter “/1/request_method”: value must be 0”

If you are importing older templates in a recent version of Zabbix, it might fail with an error message:

Import failed

Invalid parameter “/1/request_method”: value must be 0.

This is likely caused by older versions of Zabbix setting some incorrect flags in the database, and more recent versions adding input validation.

The intent behind the validation changes is good. But it ends up with a situation where completely valid templates exported by an older version of Zabbix cannot be imported anymore. One might expect that after receiving user reports about this the import would be fixed to handle the previously exported versions — otherwise it's a pretty bad user experience. Unfortunately, Zabbix support could only offer shipping all affected templates to them for manual fixing, or fixing the original problem for an extra fee. With almost 200 potentially affected templates the first carried a risk of some secret being accidentally embedded in a template, and the latter did not seem like a good customer experience.

But the problem is already well known, right? After all, even the error message says that for the request_method field “value must be 0”. Looking closer at the problem we can figure out that the request_method is only used for the HTTP agent items anyway, so we could just drop it for all other item types. Is this really so complex that it needs to deliver all templates somewhere? Let's take a look…

Luckily, Zabbix massively improved the export format by dropping (most) unneeded fields and changing magic numbers to text strings. As we store our templates in a version control system in JSON format, it can be attacked with jq:

jq '(.zabbix_export.templates[].items.[] | select(.type!="HTTP_AGENT")) |= del(.request_method)' 

This will remove the request_method field only for the items of type HTTP_AGENT. What if we have 200 templates? Loops FTW.

while read f; do
  echo "$f"
  cat "$f" | jq '(.zabbix_export.templates[].items.[] | select(.type!="HTTP_AGENT")) |= del(.request_method)' > "$f"2 && mv "$f"2 "$f"
done < <(ls "*.json")

If you use Zabbix low level discovery (LLD), there might be affected item prototypes, too. In that case just adjust the XPath expression.

jq '(.zabbix_export.templates[].discovery_rules[].item_prototypes.[] | select(.type!="HTTP_AGENT")) |= del(.request_method)'

This has been validated for templates, exported from Zabbix 5.0. Don't do this for older versions like 4.0 — with the export format being different it will break HTTP agent items.