+1 for a UI for Apex.

-0 for making it part of the STRAM.

- Regarding same port, I was wondering if there will be usage patterns
based on firewall rules just based on ports ? This leads us to a situation
where we have to trust all users at the same level as the application
communication patterns.
- Deepak N mentioned of building metrics components. Assuming he is working
on this feature and is providing a REST API as well, there might be
overlaps in the functionality being implemented. Some part of the UI
features mentioned in the list seem to be definitely metrics related. Most
of the metrics UI views can be aggregated at external web applications like
Grafana of course with the help of other tooling like REST server from
atrato or Prometheus components.
- Are we considering serving metrics beyond application restarts? If yes,
visualising metrics is a better fit for tooling carved out for those
purposes given the amount of information will be huge and we will also need
potentially time series stores ?
- The highest value is from the points mentioned in the second phase and
DAG views implementation in the first phase.( assuming Deepak N proposal
for metrics is implementing a REST API).

There is definitely a huge value add in providing a UI and the need of the
hour for Apex. My concern is that we might be diluting the value add
provided to build such a functionality inside the STRAM and hence feel it
is better served as an external application as opposed to something
embedded in the STRAM.

Regards,
Ananth
On Sun, Jun 10, 2018 at 3:10 AM, Thomas Weise <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB