Open traviswdev opened 9 years ago
The problem I see here is that it would require some kind of backend storage in order to have persistency and the ability to share these groups.
I feel like the grouping should be done at the Sensu level with subscriptions and these could be displayed on a new view which shows the status of each subscription based on their clients status.
I've long wanted sensu to have a services
group feature, which would enable both this front-end feature and a couple of other things: subscription groups and cleaner aggregates in particular.
But it seems to me that the notion of a service is strictly different to subscriptions: for example our database servers are all subscribed to both "systems" and "database", but almost everything is subscribed to "systems" so that's not a particularly useful group to surface.
Additionally, having a service notion would allow you to aggregate checks from multiple sources -- including jit sources -- into a nice view.
The idea that palourde presented would be sufficient in solving this problem, I think. All we'd have to do is have a separate view where the clients are folded into groups based on subscriptions. If the subscription name was the title of the group, then my managers would probably be happy.
Honestly... now that think about it, why not just do this with the current clients view? Instead of seeing a list of (~1000 for me) clients that I have to filter through, why not just have clients folded into groups based on what subscriptions they fall under?
Yes, some clients would fall under multiple subscription groups and sometimes those groups would not be very useful to us (like quodlibetor's "systems" example), but we could simply use the "client.json" of each client to put them into groups that are useful to us. It removes the need for backend storage, as palourde suggested. Even if no checks point at a group, we could still use made-up subscriptions to make uchiwa more user friendly at large scale.
Finally, if we want to solve the "systems" problem quodlibetor mentioned instead of ignoring it, we could put an optional field in the "uchiwa.json" called "invisible_subscriptions" (or something similar) that causes uchiwa to not present the listed groups on the clients page. This would mean that any machines that fell only under an invisible group show up not grouped at all. No code change would be needed on the sensu side for this.
I can think of another solution, but it would require a small change in the way sensu parses the client.json "subscriptions" field. Just add a "-" like so:
Sensu would have to parse "-dog" and "dog" the same (so checks with subscribers: dog will get run on them) , but "-dog" would force uchiwa to not put that client into that group when displaying it on the clients page. This would probably be a neater solution in terms of how things turn out, but might require more work to accomplish.
Solving that problem isn't really mandatory, though, it just cleans up things a bit further. Even in Zabbix we currently have groups that are divided into subgroups, and we rarely care about seeing the entire large groups as a whole. If the default state of these groups was "folded" on the uchiwa clients screen and the little green "OK!" bar shows in front of them all, management is generally happy.
Yeah, long post, summary:
Honestly... now that think about it, why not just do this with the current clients view? Instead of seeing a list of (~1000 for me) clients that I have to filter through, why not just have clients folded into groups based on what subscriptions they fall under?
It doesn't currently do the fancy collapsing that you recommend, but there is a subscriptions
filter in Uchiwa on the clients page. At least in 0.9+, I'm not sure when it was introduced. It's pretty helpful.
Yeah, I mentioned the filter to my management, and they said it wasn't sufficient.
For me, the way that sensu/uchiwa does this now is perfectly fine. I rather prefer seeing the empty "Events" screen with no events if there are no problems.
For them, they want a dashboard to go look at that has product names (groups) that combines all of that status of it's child machines with it's own status marker next to it. That way, when they get a customer calling about the status of a product we offer, they can just see the product and answer the question. They don't want to have to do any filtering or ...thinking... to get the UI the way "it is supposed to be" (which I realize is just an aftereffect of having used Zabbix for a long time). Plus, if a product ends up being hosted on more machines than the current screen holds they either have to increase the quantity per screen or filter further... etc.
I know there are ways around it, but doing something like this would quite drastically clean/organize the uchiwa UI clients page, and that should be reason enough.
The way one of my managers put it: "I'd like for it to be able to be brought up on a TV on my wall and just be able to look at it to know the status of the products." In order to do this, no UI interaction can happen.
Just to update, I have made significant headway on this in a testing environment.
Having no web development experience before this is causing the project to move slower than I'd wish.
How I did it: I basically just used the bootstrap ui accordion that was already included in the code to make the accordion, and added a single function in controllers.js that updates the overall subscription status based on children statuses.
I'm going to clean up the CSS and behavior of the page a bit and try to figure out how to make this a toggle-able option (in the options menu, maybe). Any thoughts or recommendations?
Edit: Now that I think about it, maybe I should just do it the way palourde originally recommended... create a new view titled "Subscription Groups"... and leave the old clients view alone.
@traviswdev Thanks for your PR. Unfortunately I won't be able to look at it before the end of August since I'm on vacation for the next weeks.
I feel like it should be enabled/disabled with a toggle or moved to a dedicated view since it might not easily scale with hundred and hundred of clients but again I only saw the screenshots and didn't actually played with it.
@amdprophet, if you have some free time and you are interested, feel free to go ahead with this PR!
I would also love something like this. Since some of us don't use subscriptions and Sensu supports arbitrary metadata it'd be nice to be able to pre-define keys to use as groups in the Uchiwa config.
I updated my pull request to reflect the requested changes. The "Groups" view now exists in my fork and is directly below the clients view in the sidebar. My pull request (with pictures and more detailed info) is at https://github.com/sensu/uchiwa-web/pull/60
Hey, are there any plans to progress this forward?
I think it'd be great to be able to provide Uchiwa with a configuration option to specify an attribute to group clients by; with the default being no grouping.
We use an arbitrary attribute that'd we'd love to group clients by.
I'm :+1: to add the ability to do this, I am :-1: on requiring a new external persistent store as a dependency. Can this be some new metadata field we provide alongside subscriptions in the config?
+1
On the "clients" screen of the uchiwa frontend, having an option in the "Actions" menu to "Group clients" is highly desired. My organization wants to switch to Sensu (from Zabbix), but won't do it if every single client machine and name clutters the screen. We have almost 1000 client machines we are monitoring. They'd rather group all machines of one product or domain to make things cleaner to look at.
The way I would see this working, on the "clients" page:
I have been hacking away at this, attempting to accomplish it, but I have close to zero web development experience so decided to post here. If you don't like the idea of this feature maybe you could respond with some hints/ideas on how I could accomplish it.