Dashboard for state of the fault tolerance implementations

[Michael Hofmann]

Hi,

is it planned, to have a central Dashboard to show the state of all fault tolerance implementations of my services, if I would like to (like Hystrix)?
How about integrate this with metrics and health check? I think, one central point to get all informations would be a great benefit for admins.

Regards,
Michael

[Kevin Sutter]

Michael,
At this point, we are not considering a dashboard.  We are leaving that up to other efforts.  The results of fault tolerance, metrics, and health check could feed into existing dashboard implementations.  I believe some of the MP implementations are planning for that type of integration.

-- Kevin

[Emily Jiang]

In this week's FT hangout, John, Antoine and I discussed the dashboard idea. The conclusion is that we would like to integrate with Metrics as part of app mentrics and then the FT info being displayed. We discussed some other features for the next FT releases. We want to wait for Wildfly and Hammock to fully implement the FT 1.0 as they are quite close now and then move on. Please join the FT gitter room for further discussion.

Emily

[Emily Jiang]

Michael,
You are welcome to join FT gitter https://gitter.im/eclipse/microprofile-fault-tolerance. You can also find the link from the FT repo.

Emily

[John D. Ament]

Based on our discussion this week + what I already see working well, I put together this rough diagram of how I suspect this should work.  Feel free to poke holes in it though.

One of the problems with having a server based dashboard, there's no good way to secure it.  Its not really part of that service, instead if you're looking at it from a microservice standpoint, you should have tools available to you from the application that can feed the metric data to a common location.  From that common location, you can create dashboards and alerting capabilities with this information.  By relying on that single server, you're creating the same type of tight coupling that exists with your traditional monolith.  You're very closely tied to that one server and if that server goes away, there's potential data loss.

The key takeaways that I have are we need to have a robust enough solution for all other specs in MP to produce metric data into MP Metrics, and ensure that MP Metrics can publish that data into the appropriate place.  I don't know if that's a message queue, a rest api or what, but it's somewhere outside the application so that it can be stored long term.

John

[Heiko Rupp]

MP-Metrics will in one of the future versions add support for other specs to add data in their respective namespace.

[donbo...@gmail.com]

+1 for central monitoring of the data rather than having a dashboard built in.  An in-built dashboard would only show the info from one service, which isn't all that interesting.

I'd also like to add the thought that we need to avoid causing our own specs to become overly entangled.  I absolutely think it's the right thing to do to have metrics for fault tolerance, but I think we need to do it in a way that doesn't require metrics code to be in the FT API.  For example the implementer could decide if they want to directly add metrics code directly into their FT implementation, or if they want to use bytecode injection or some other means to get metrics added when metrics are wanted by whomever is configuring the server.

Regards,

Don