We have Nagios XI 5.2.2 and use dashboards quite a bit. I'd like to find out more information on dashboards since we have 50 now and will be adding much more.
Is there a way to delete shared dashboards. I can delete dashboards that I can see, but can I remove dashboards on other users' dashboards that were shared?
Is there a way to make a collapsible tiered list of dashboards? As mentioned, there are currently 50 dashboards now, but it gets difficult to read and reorganized. What can we do to manage the list in an easier way than just by alphabetical order?
There is a dashboard called "[ screen ]" that got shared. Is there a way to delete that dashboard? I can't delete it in my own dashboards but it can be see in the "Deploy Dashboards" list. I've got two because someone deployed it to me, but I can't removed mine or the shared one.
The reason we use so many dashboards is because we get to have a history of all the CPUs, ping response times, memory usage, application specific metrics, etc. used for a certain product/application and want to compare them with related servers.
1.) I believe you will need to be an admin to remove (technicaly un-deply) other users' dashboards that have been shared, otherwise you can masquerade as that user and remove them that way as well.
2.) Not currently, no. There is not currently a way to collapse/expand lists. I can get this added as a feature request, but what criteria would you suggest for organizing them?
3.) As with 1.) above, I believe you will need to be an admin to un-share this one, though this might be a but since SCREEN is a special dashboard Double-check and if this is a bug I'll get it filed.
tmcdonald wrote:1.) I believe you will need to be an admin to remove (technicaly un-deply) other users' dashboards that have been shared, otherwise you can masquerade as that user and remove them that way as well.
2.) Not currently, no. There is not currently a way to collapse/expand lists. I can get this added as a feature request, but what criteria would you suggest for organizing them?
3.) As with 1.) above, I believe you will need to be an admin to un-share this one, though this might be a but since SCREEN is a special dashboard Double-check and if this is a bug I'll get it filed.
Thank you for checking the above items.
That's pretty cool to be able to masquerade as another user to remove their dashboards, but it will get tedious for multiple users and dashboards. However, I'm not seeing an option anywhere on the dashboards page to remove (un-deploy) other users' dashboards.
The criteria would just be a simple collapsible list so for example:
_______ Product/Header
|____ Subcategory
| |_ Metric
| |_ Another Metric
|____ 2nd Subcategory
| |_ Different Metric
|____ 3rd Subcat...
etc., etc.
Yea, there's no remove button or anything for the "[ screen ]" dashboard anywhere that I can see...
I'm logged in with an admin account and with the default nagiosadmin account without seeing options mentioned.
IN 5.2.8 I was able to deploy SCREEN to another user, then delete it as them just fine - can you upgrade to the latest version of XI and see if this works for you? I'll still have to file the collapsing and un-deploy as feature requests, but let me know if an upgrade fixes the other point.
tmcdonald wrote:IN 5.2.8 I was able to deploy SCREEN to another user, then delete it as them just fine - can you upgrade to the latest version of XI and see if this works for you? I'll still have to file the collapsing and un-deploy as feature requests, but let me know if an upgrade fixes the other point.
We can upgrade, but will have to time a maintenance period for it. It does seem quite a big change for 1 minor usage feature that still requires masquerading as each user, then deleting the dashboards (there are a lot of users). Thank you for filing the collapsing list and un-deploying as feature requests. It will help us administer the dashboards faster and in a more organized form.
Speaking of speed, is there a recommended max for each dashboard? For example, we have a certain metric that we track on a group of 20 hosts. The 20 hosts are exactly the same and we track its memory on one dashboard, but the page takes a long time to load and because it updates every minute or so, it slows down (can't move page or do anything for a duration of about 15-20 seconds) as the updates get applied to all the memory usage graphs. This is also a reason why having a collapsible list would make grouping easier.
I went ahead and filed the undeploy and collapsing functions as feature requests (internal IDs 8758 and 8759 respectively in case you need to reference them).
In regards to speed, that's going to be highly dependent on your individual server and there are a lot of variables in play. For starters though, are you adding 20 individual dashlets, or adding them as a service group and adding a single dashlet for that group? The latter option should be much faster.
tmcdonald wrote:I went ahead and filed the undeploy and collapsing functions as feature requests (internal IDs 8758 and 8759 respectively in case you need to reference them).
In regards to speed, that's going to be highly dependent on your individual server and there are a lot of variables in play. For starters though, are you adding 20 individual dashlets, or adding them as a service group and adding a single dashlet for that group? The latter option should be much faster.
Thank you again for filing the feature requests!
I'm adding 20 individual memory usage graphs from the "Performance Graphs" tab of the service check. I'm not seeing an option to add the performance graphs from the service group in a single dashlet. We want to see the 24 hour history of each performance graph so if there are any spikes or dramatic drops, we can see if it's a trend among all servers or just on one server.
Bah, sorry missed the "graphs" part. How many total hosts and services are you monitoring? What's your CPU/memory allocation, and usage? We might consider implementing a ramdisk if you are over a certain threshold:
Bah, sorry missed the "graphs" part. How many total hosts and services are you monitoring? What's your CPU/memory allocation, and usage? We might consider implementing a ramdisk if you are over a certain threshold: