Closed johgoe closed 6 days ago
@brusdev fyi, I saw you are currently writing an example how to use it.
A workaround which works:
apiVersion: broker.amq.io/v1beta1
kind: ActiveMQArtemis
metadata:
name: active-mq-artemis-test
deploymentPlan:
enableMetricsPlugin: true
size: 2
resourceTemplates:
- selector:
kind: "Service"
name: "active-mq-artemis-test-hdls-svc"
labels:
app.kubernetes.io/component: headless
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: artemis-with-metrics-monitor
spec:
selector:
matchLabels:
application: active-mq-artemis-test
app.kubernetes.io/component: headless
endpoints:
- targetPort: 8161
@johgoe thanks for the heads-up and sharing your workaround. The operator could add a specific label to the headless by default.
@johgoe I'm not able to repduce this issue with my example because that example use the port name wconsj
that is only exposed by the console service while you are using the port number 8161.
I have just updated my example to use the port console-jolokia that exists even if the console is not exposed, see #977
I didn't expose the console that's why wconsj didn't exists. I will try port console-jokokia instead of 8161
My cluster contains configuration like this
which causes an additional service per broker node.
Because these services and hdls and the ping service contains the application label the following servicemonitor will cause duplicate scraper
My cluster with 2 nodes are watched by 6 scrapers because of these. These are the labels shown in prometheus:
I guess currently there is no better way, but maybe an additional label like
app.kubernetes.io/component: headless
can be added and used within the serviceMonitor