Moved this to feature requests.

So you think this is a cool feature instead of a performance bug?

Well... I think it works "as designed". If we think, that the design can be better, that's a feature request... in my opinion.

Then is it a good design to return in the background lots of data which is not even displayed by the web interface in any way?

Not to get into discussion about good or bad design, but as most designs - it can be improved.

I'm not sure I'm right, maybe there where reasons I'm not aware of, why it was created as is. So I see it as a design that works, but can/should be improved.

A bug in my opinion is something that doesn't work as designed.

From such perspective we can treat any bug reports as feature requests because regardless of the problem Zabbix as such is working, isn't it? 

I can clearly imagine that no one ever thought about this particular problem for a second before it was designed and implemented. 

On one hand Zabbix is putting serious efforts to improve the performance on large scale. Take ZBXNEXT-4108 as example. Off the topic but even ZBXNEXT-4820 requesting for better sounds gets turned down because of the increase in the file size. Then how is this my request considered as a feature when useless data is returned by a page request causing considerable load on all components of Zabbix?

Were you actually able to reproduce it?

Hello Ingus, thanks for the valuable opinion, you might be right. But I'm not the person to make the decision, but I will forward this ticket, so that appropriate decision can be made. Maybe it will be moved back to ZBX.

Yes, I was able to reproduce the error, it's easy on a host with one trigger.

Thank you very much!

With one trigger it is not a big problem, I agree there, but when there are thousands of triggers in mixed order on multiple hosts then the slowdown is significant. 

Thanks to aleksejs.petrovs, who pointed out that api output should match that what you see in frontend, so moving this back to bugs and marking as confirmed.

Sorry for the confusion.

While I can understand the confusion, that problem.get is returning more problems, than displayed, in Problem list it was done on purpose.
Currently the steps are:

1. select number of problems, with any matching filters applied.
2. get triggerids, that matches them.
3. select triggers, with any matching filters applied (including 'monitored' => true)
4. remove from list the problems without related triggers
5. repeat from step 1, if not enough problems are selected
   (Note: data for any trigger is requested only once)

What is requested by this task, is to add "monitored" filter for event.get and problem.get.
'monitored' filter implies adding NOT EXISTS check, which will look for data in tables functions, items, hosts and triggers, to the SQL.
This is quiet heavy check. In current implementation it is done only for triggers request, and is checked only once for any trigger. Adding it in problem.get and event.get, will require to do this check for every problem or event, which is way more times, than it is currently done.

With this, I have strong grounds to doubt that this change will be beneficial to the performance of Problem list page.

Also I will insist, that this is Feature request and not a bug, because

1. currently the pages are displaying correct data
2. problem.get and event.get was made without 'monitored' on purpose as very heavy operations. (same as history.get)
   And implementing such option should be considered as feature request.

I am not closing the task, as proper performance comparison still can be done.

vmurzins EDIT: It can be considered as feature request to add API parameter, that will be used only by users. (Zabbix frontend has no need for such parameter).

Looks like moving to bugs was not successful, still a ZBXNEXT.

Hello colleagues. This is NOT just "Preaty to have" feature. This is real fail of design.

One of Zabbix development direction - service based monitoring. Am I correct? A lot of changes was made for this and we are using this structure for more than 300 service trees. 

Problem described here is one of the most critical issue:

You have service tree with more than 50 services, 300 hosts and 5000 triggers.

You need add one more host - you can't predict that triggers will not generate problems.

Problem generated by template trigger -> Service status changed.

You have no way to change service status back!

You can't change template because a lot of hosts use this template. You can not delete trigger or item because problem will not disapper. You can not delete host - problem will not desappear also plus this will be impossible to resolve this problem at all. Only via database request. 

Only one option - allow manual close from  template -> manual close -> fast disable trigger before item will data. Is this really "Target design"?

This problem exist in 7.0.0 unfortunatelly.

If you are using "service oriented" monitoring and accidentally deleted host (operator mistake for example) - nightmare for big and 24/7 environments.

only delete FROM events where eventid = '';

Same request here

https://support.zabbix.com/browse/ZBX-21994?jql=reporter%20%3D%20%22Egor%20T.%22

ZBXNEXT-7106 is related

Can you please solve this? If the problem is not visible in the frontend, it should not be visible in the API either. With every problem.get I get “dead” problems that I can only delete by manually deleting them from the database in the event table. If someone deletes an old hosts with open problems i get new "dead" problems. I don't understand this design decision and why this should be a good idea.