On Jul 24, 2014, at 11:22 AM, Liz Clayton <lclayton(a)redhat.com&gt; wrote: Thanks for forwarding this proposal Liz! While I chew on this, I have posted this on the user forums and twitter as well: https://community.jboss.org/message/882227#882227 https://twitter.com/jtgreene/status/492347878254182401 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

+100 on Jason's comment thanking you for posting this. On 7/24/14, 12:05 PM, Jason Greene wrote: That seemed intuitive to me. I don't get though why some boxes are different sizes from others on "Second Iteration: Stacked heatmap". On "First draft heatmap – Server Group view for 'availability'" I could somewhat get that, as different server groups can vary in size based on # of servers. My instinct is something like alphabetical is better. The color already lets me easily find and identify things where availability/status is relevant to what I want to do. But when it's not relevant to what I want (say I want to work with server-X for reasons completely unrelated to availability) then I need to rely on location to find what I want quickly. Note that multiple servers in a domain can have the same name; it's the host (as in Host Controller) + server name combination that must be unique. If the colors are green and grey, maybe not. But in a number of examples you use green<->red, with grey too, and I think that's pretty intuitive. Red = bad, green = good, yellowish = in between, grey = the good/bad aspect is out-of-scope. I think we need a better understanding of what alerts are. In general, I like the idea of the occurrence of some kind of negative event tends to shift the color away from green and toward red. But what constitutes a negative event? How much control does the user have over that definition? How much control does the user have over how much different events shift the color? Please be cautious about the Alerts notion in your design. WildFly doesn't actually have the kind of altering system that many might be thinking of when they imagine this kind of thing. So it would have to be developed. That's something we want to do, and Jeff Mesnil is doing some of the foundational work, but it's not there yet and it's a big job competing with lots of other big tasks. So, we want it, but the more a UI design depends on a complex alerting system, the riskier it is that a needed feature won't be there. Re: some of the questions, on the "Questions" page: "What are the states for server availability?" On "Not available" and "Failed" we have no notion of why a server was taken down; i.e. the admin takes it down, but whether they did so due to issues or for some other reason, we have no idea. We can distinguish a crash from an administrative shutdown. Also, there are other aspect of a server's running state that complicate things. We are adding the ability to put a server in "suspending" and "suspended" states where it moves to not accepting normal end user requests but is still running. This isn't an "error" state; the admin has chosen to put the server in that state. There's also a similar notion regarding how consistent the server's running state is with its persistent configuration. Admins can make configuration changes that will not take effect until the server is reloaded or restarted. I'm not sure if those things are well represented on a green-yellow-red color continuum because they are somewhat different from server health. But they are important pieces of data to visualize. "How does the Alerts tab fit in with the *current* Notification message queue?" Heiko Braun knows better, but I don't see a close fit. The current queue isn't really based on any sort of server-push of events. The console makes administrative requests and gets responses; if relevant that request/response results in stuff in the queue. But anything that happens outside of those requests/responses is unknown to the console. Cheers, -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat

On 7/25/14, 3:16 AM, Heiko W.Rupp wrote: Good to know. I figured that would happen, a la the rhq-metrics work; I'm glad to hear that's the plan. Yes, absolutely. We've done very little in this area, and have very little in the way of resources, so anything we do we'd very much want to do as part of a broader effort. The work I mentioned that Jeff is doing truly is foundational; it's not an alerts management system, it's the fundamental support for receiving notifications from the management API. Anything not based on polling would need that. See http://lists.jboss.org/pipermail/wildfly-dev/2014-July/002533.html -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat

Hi, ----- Original Message ----- Thanks for looking it over, and for the great feedback! I have some follow-up questions inline. So it sounds like the uniformly sized boxes (pg 5) are working better for you? Followed by the standard heatmap (pg15), and then not so much for the irregular ones on pg 16? The boxes are irregular on 16 because they were intended to display mini heatmaps, stacked. And unlike the domain-view version (pg15) where the size of the box would be driven by # of servers - the mini ones could be scaled by some other metric (throughput or etc.). But I didn't really have that information, so I made the boxes uniformly sized. That makes sense. For the everything is OK scenario - maybe there could be some kind of search to help locate/highlight a specific server in the display. Good to know. Is there info to help figure out those bands - when something changes from yellow to red...? Yes exactly. I was hoping that there could be some type of relationship (events=shifting), and that the user could drill-down to learn more about the event(s). But lots of hand-waving in the design, because I'm not sure how do-able that is? Great to know, thanks! I'm principally trying to find a way for users to drill-down to get more information about an availability issue. Perhaps there are other ways that steer clear of alerts. So it sounds like there is shutdown ("N/A") and "failed." So it sounds like there is: shutdown ("N/A"), "suspended", and "failed." Would that directly affect its availability status? yes, great to know about. So there are events happening on the system, that could affect availability, which will not show up in the message queue? Thanks! Liz

Hi, Thanks for answering my questions! ----- Original Message ----- ... I hadn't thought about it being a user selection, but that's an interesting idea. ... So there's server health (availability), & server "state", and they are both useful bits of high-level info. OK, thanks! -Liz

Hi, ----- Original Message ----- Thanks for sending this pointer! I read through the thread and have a few more questions: - Sounds like there are some terminology issues to reconcile as part of this? - Should these shutdown states be represented in the visualization? If so, do you think they should be represented as: * A graduated scale of availability (shades of yellow/orange), to reflect the various states of suspension or “out of sync” ness? - or - * A single “out of sync” (suspended?) state? If that were the case, perhaps “out of sync” could be represented as an intermediate (yellow/orange) state between green and red. Details about the state could be presented in a hover overlay, with a link to perform the action needed ("restart" for example). Thanks, -Liz

Hi, ----- Original Message ----- Thanks for checking it out, and for getting it out there! -Liz