Add Prometheus instance to monitor applications about cluster-monitoring-operator HOT 9 CLOSED

How do you handle NetworkPolicy objects, so that Prometheus is actually able to scrape data from the other namespaces?

It's a similar situation as the RoleBindings Prometheus requires in order to perform target discovery. We haven't made a final decision on this yet, either the cluster-monitoring-operator will create the NetworkPolicies or the operators of the respective component namespaces will.

from cluster-monitoring-operator.

At least I discovered in 6742ea6 (and other commits) that the Prometheus Operator is configured to only manage Prometheus instances in the openshift-monitoring namespace, whereas the README states:

The deployed Prometheus Operator is meant to be leveraged by users to easily deploy new Prometheus setup for their application monitoring

Why is the Prometheus Operator configured to only manage Prometheus instances in the openshift-monitoring namespace? Maybe @brancz can answer this question? (Committer of the change)

from cluster-monitoring-operator.

@nabbdl not yet. We are just now adding new functionality to enable create Prometheus servers in additional namespaces for your particular needs: #138

from cluster-monitoring-operator.

Thanks for answering @squat, that PR looks promising and I'm looking forward to test this when it got merged. Currently trying to figure out how to do our future cluster and app monitoring and I'm keen to test the monitoring operator (incld. feedback!)

from cluster-monitoring-operator.

Sorry, we actually need to update that readme. This code base is what used to be the Tectonic Prometheus Operator, where that statement held true, however, now the way to provision additional Prometheus servers in addition to cluster-monitoring, is using the operator-lifecycle-manager.

from cluster-monitoring-operator.

The clarified README sheds some light, thank you. But also causes some confusion: Why was a multi-namespace support implemented in #138? Is this meant for monitoring different cluster components running in several namespaces?

And when deploying another Prometheus Operator using OLM: How do I make sure that multiple Prometheus Operators don't get in the way of each other? So that each Operator knows which namespaces to manage the various CRD objects?

from cluster-monitoring-operator.

Is this meant for monitoring different cluster components running in several namespaces?

Precisely, in OpenShift we have the openshift-monitoring, openshift-console, openshift-x namespaces that all contain components that we are very much in control over which is why this multi-namespace approach is ok and even wanted in that case.

And when deploying another Prometheus Operator using OLM: How do I make sure that multiple Prometheus Operators don't get in the way of each other? So that each Operator knows which namespaces to manage the various CRD objects?

The Prometheus Operators are configured with the set of namespaces to watch, and OLM ensures through its own namspacing scheme that underlying objects are not reconciled by multiple operators.

from cluster-monitoring-operator.

Precisely, in OpenShift we have the openshift-monitoring, openshift-console, openshift-x namespaces that all contain components that we are very much in control over which is why this multi-namespace approach is ok and even wanted in that case.

Understood! Makes completely sense. One last question: How do you handle NetworkPolicy objects, so that Prometheus is actually able to scrape data from the other namespaces? Do you handle them with the Cluster Monitoring Operator? And I guess ovs-multitenant SDN is not supported anymore with this monitoring approach? Or do you join projects so that network access is possible?

The Prometheus Operators are configured with the set of namespaces to watch, and OLM ensures through its own namspacing scheme that underlying objects are not reconciled by multiple operators.

Thanks! Time to learn more details about how OLM exactly works 👍

from cluster-monitoring-operator.

Thanks @brancz for answering all my questions, highly appreciated!

With the discussion above: @nabbdl do you agree to close this issue? I think the initial question of this issue is answered now.

from cluster-monitoring-operator.