You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is no way to organize the watcher list into a folder or tree structure. As the list of watches grows it would be nice to have a way to organize the watches so that they're easier to find.
We currently use watches to alert on events from the following scenarios:
Using metricbeat for monitoring our servers, processes, and Windows services
Using heartbeat for monitoring server / service / URL up time
Using filebeat to gather logs and alert on the absence of the logs altogether as well as error level events and keyword events
Using winlogbeat to gather security and application logs and alert on server / database login events and other application error events
For our team this would allow us to break out the watches into a structure like the following:
Server Health
Application Health
Elasticsearch Cluster Health
User Specific watches
The text was updated successfully, but these errors were encountered:
@rukas sounds like a valid feature request to me, but I believe it is better to place it in the https://github.com/elastic/kibana repo where all things UI live. If it ends up requiring something from ES it will bubble up. Can you please open an issue there? Thanks.
Currently there is no way to organize the watcher list into a folder or tree structure. As the list of watches grows it would be nice to have a way to organize the watches so that they're easier to find.
We currently use watches to alert on events from the following scenarios:
Using metricbeat for monitoring our servers, processes, and Windows services
Using heartbeat for monitoring server / service / URL up time
Using filebeat to gather logs and alert on the absence of the logs altogether as well as error level events and keyword events
Using winlogbeat to gather security and application logs and alert on server / database login events and other application error events
For our team this would allow us to break out the watches into a structure like the following:
Server Health
Application Health
Elasticsearch Cluster Health
User Specific watches
The text was updated successfully, but these errors were encountered: