jmx-monitoring-stacks

jmx-monitoring-stacks copied to clipboard

Following the improvements to use gitpod to run cp-demo remotely: https://github.com/confluentinc/cp-demo/pull/390

These changes enable additional configuration for monitoring stack repo to work on gitpod.

Fix #53

cc @vdesabou

Now that I'm thinking of it, there's a lot of repetition with what already exists in CP Demo. What if instead of adding a new .gitpod.yml file here, we add a new conditional on CP demo repo's .gitpod.yml file to enable the jmx monitoring stacks?

For example, there is currently this conditional to disable auto start:

if [ -z "$DISABLE_AUTOSTART" ] ...

We could add something like

if [ -n "$ENABLE_JMX_STACKS" ] ...

and then start the JMX monitoring stacks.

What do you think?

@chuck-confluent sounds interesting. If I understand correctly, would this require to start the jmx monitoring stack from cp-demo project? then these changes would need to be done there? or is it something to change on this repo?

Yes, exactly. I think it makes sense to centralize there because JMX is already part of CP demo instructions:

• https://docs.confluent.io/platform/current/tutorials/cp-demo/docs/on-prem.html#jmx

It makes sense to me to have cp demo be the central point of entry for this. You'd essentially do the same thing you did here, but in reverse. If the user indicates via environment variable that they want to see the JMX stacks, then gitpod clones the jmx-monitoring-stacks repo and instruments CP demo with monitoring.

I could be wrong though. Maybe it makes more sense to have it here. My opinion on this isn't very strong because I don't have a good sense of how this repo is / should be used.

I agree with the new approach. Instead of using a new env variable, why not using existing one as it is required anyway ?

STACK=jmxexporter-prometheus-grafana STACK=metricbeat-elastic-kibana STACK=jolokia-elastic-kibana

I like the idea of centralizing the configurations on cp-demo. We can start as @chuck-confluent says:

You'd essentially do the same thing you did here, but in reverse.

The purpose of this repo is to be used as a baseline for customers to monitor Confluent from different monitoring stacks, so it's not only usable from cp-demo e.g. I've been using it from cp-ansible as well.

Eventually we could move some of the scripting here into cp-demo to make it even more decoupled. CC @waliaabhishek

https://github.com/confluentinc/cp-demo/pull/401

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

It seems like the idea was to move this feature to cp-demo, but it was closed because gitpod didn't have enough resources. We can try to setup gitpod for dev-toolkit now, I'm going to open a new issue for this.