The essential UI problem is that it uses API.
The problem is in efficiency, especially on downtime times. Especially when DB is slooow under 100k+ problems, events, triggers updates. (Remember the crash?). Most important widgets looks like this most of the time:
Solution:
Have a list of active problems on the Zabbix server side, refresh it according to problems happening or closing on the "go".
Fetch it via trapper interface.
Build "current status" widgets out of them, avoid API as much as possible.
Side effect:
Have a list of "internal problems" for monitoring system administrator to see what's working wrong in terms of monitoring, use the same idea to build such an interface.
The progress
server->trapper->php->browser "hello world" prototype seems to be working:
Lets see how it works all together completed a bit later.
The problem is in efficiency, especially on downtime times. Especially when DB is slooow under 100k+ problems, events, triggers updates. (Remember the crash?). Most important widgets looks like this most of the time:
Solution:
Have a list of active problems on the Zabbix server side, refresh it according to problems happening or closing on the "go".
Fetch it via trapper interface.
Build "current status" widgets out of them, avoid API as much as possible.
Side effect:
Have a list of "internal problems" for monitoring system administrator to see what's working wrong in terms of monitoring, use the same idea to build such an interface.
The progress
server->trapper->php->browser "hello world" prototype seems to be working:
Lets see how it works all together completed a bit later.
No comments:
Post a Comment