Centos 7, Ubutnu Xenial

Hello Gustavo,

It is even possible to use pure filter function like:

z.history.get(filter={"itemid":"46525"}, history=0, time_from=1538132400.0, time_till=1538136000.0, sortfield='clock', sortorder='ASC')

When using itemids as a parameter it does not create any impact on a result.

Either it is a bug or documentation task.

Reference:
https://www.zabbix.com/documentation/current/manual/api/reference/history/get

I am using show-latest-values.py code to get 'Free swap space' values on 'Zabbix server' in lastet 5 minutes.

Both approaches are executed:

# Execute only filter and use 'itemid':
zapi.history.get(filter={"itemid":"23309"},history=3, time_from = ctime-300, time_till = ctime)

# Use parameters: 'hostids' and 'itemids':
zapi.history.get(hostids=10084,itemids=23309,history=3, time_from = ctime-300, time_till = ctime)

The result is: result.log

Hello Aigars

That's right, we agree in the work arround, but the problem still there.

We try it in the 4.0, and the same thing ocurs

If we take away de hostid filter, it works properly, retriving just the specified item.

May be now its an "or" between the conditions where it use to be an "and" ? In my opinion, it should be an "and"

Regards

This behavior can be explained as follows:
Suppose there is a host 99032 with items 99136, 99144 and a host 99033 with item 99146.
Let's execute the query to history by specifying only the list of items and we will not specify the hosts ('itemids' => [99136, 99146]):

 We observe that the list of items is used as a filter directly to the history and the request is executed correctly.

Now we will only request a list of hosts ( 'hostids' => [99032, 99033]):

Observe that when the hosids parameter is present in the request, before performing the history query, another request is made to the hosts and all items of the selected hosts are retrieved.

Next, we indicate a specific host and specific item:

All items of the specified host have been selected, but the specified item 99144 seems to have been ignored.

Finally, let's execute another query. Request a list of hosts and a specific item:

Now we observe that only the specified item was selected and it seems that the entire list of hosts was ignored.
In fact, if the request contains the hostids parameter explicitly present, then the hosts specified in the request are selected first and then all their items are selected from the history. If, in addition, items are also specified, they are used as a filter (as INNER JOIN) to the hosts, and not to the history.

This might be another case of API validation (ZBX-3783) - it seems like hostid and itemid should be mutually exclusive in this case.

Hi everyone

I think richlv has a point here, and is logical, if there is an itemid specified, you can discard the hostid, since the item will determine to which host it belongs to.

Never the less, if they are both specified, the result should not change.

Greetings

I'd prefer the API rejecting requests with both hostid and itemid. Less ambiguity than ignoring some parameters in some cases.

API response should contain only entities, that match all provided filters.

So, in this case, if you are using both "hostids" and "itemids" filters, in response you should get history for items that match both conditions:

1. itemid is provided in itemids array
2. item belongs to one of hosts, provided in hostids array

As it currently is not working like this for history.get API method, it should be fixed.

Validation-wise, I cannot come up with a case where it would make sense to specify both hostid and itemid, it seems like a bad request - but that's hardly a critical issue.

richlv, is not working like used to, this is enaugh, I think, to fix it, and is this the reason why is critical, the scripts you have already develop and deploy are not working like they did

A case wich you must specify both, if a user is using a script, he can specify both.

Sorry, I didn't follow that - while I agree that the current behaviour is not correct, I don't see a benefit from accepting redundant parameters. Is there a usecase I'm missing?

That's what matters, we agree that the current behaviour is not correct.

Fixed in:

• 4.0.4rc1 r88201
• 4.2.0alpha3 (trunk) r88202