Create the ability to disable Graphs
Feature Request
Is your feature request related to a problem? Please describe
We have a very large environment that changes rapidly. So, Graphs stop updating and become less relevant to ongoing operation. However, management want's to keep a record of those Graphs and Data Sources for posterity (upto 3 years).
Instead of cluttering the user interface with a bunch of empty graphs from a device that still exists, and is enabled, it would be nice to be able to:
- Remove these graphs from view by disabling them.
- Stop the Data Collector's for polling for data.
Describe the solution you'd like
Simple, a setting in Graph Local called 'disabled', an API to disable/enable both Graphs and Data Sources, and for the API's that call Graphs, to hide them from view.
Would this cover a scenario like a port that was used and is now turned down So there was data at one point but data is no longer available for the port?
Yup, it's the same thing for us. We have a Host Group. It was there for a few months, we removed it, but people want to 'selectively' view those graphs in the future, though they will never again get data.
I'm thinking of some simple API's
api_graphs_disable(string|array $graphs);
api_graphs_enable(string|array $graphs);
Then, a Dropdown on the Graphs Management page and possibly a Glyph on the Graph View page.
Block it of course for Aggregate Graphs.
This would knock out a major issue I have right now.
This is very nice implementation, if we can have also the possibility to identify quickly and simply these graphs be fantastic. thanks a lot.
Whilst this would be useful, you will also likely need to have a timespan for the last time the graph was polled from otherwise the default view will just have a blank graph.
IMHO, this is incorrect approach, If I understand it right. This leads to implementation of a new feature new to application logic, which should be avoided.
Instead, Autom8 should be extended to perform such action. I have similar issue (wanted to delete graphs, devices, thresholds).
We need the API in either case. This feature request was focused on a GUi first approach. If you could articulate you requirements for Autom8 in a separate feature request, I would appreciate it.