Prometheus queue metrics not available when using separate acceptor

[maloneybob]

Greetings,

Starting this as a discussion, as we're not yet sure it's a bug.

We followed the recommendation in springboot with cluster of brokers to use another acceptor port other than 61616, as it's also used internally. Created it on 61618, and also as recommended, a new headless ClusterIP service. After switching all clients to the new service and port, message production and consumption successfully operates as before. However, we no longer have updated Prometheus queue metrics, which are solely enabled via "enableMetricsPlugin: true". They still exist, but values are always 0 for

• artemis_connection_count
• artemis_consumer_count
• artemis_message_count

Related, the admin console also doesn't show expected consumer counts or yet-to-be consumed messages.

Is there an existing setting in the ArtemisCloud CRDs or broker params to be changed that will correct this issue?

We are currently running

• operator: 1.1.0
• broker-init: 1.0.25
• broker-kubernetes: 1.0.24

We reviewed the release notes for 1.2.0 and 1.2.1, but none look related.

Thanks!
Bob

[brusdev]

I can not reproduce this issue with the following ActiveMQArtemis CR:

apiVersion: broker.amq.io/v1beta1
kind: ActiveMQArtemis
metadata:
  name: artemis-broker
spec:
  deploymentPlan:
    size: 2
    enableMetricsPlugin: true
  acceptors:
    - name: "core-acceptor"
      port: 61617
      protocols: "CORE"

$ kubectl exec artemis-broker-ss-0 -c artemis-broker-container -- ./amq-broker/bin/artemis consumer --verbose --destination my-test --protocol core --message-count 1 --url tcp://artemis-broker-ss-0:61617

$ kubectl exec artemis-broker-ss-0 -c artemis-broker-container -- curl --silent http://artemis-broker-ss-0:8161/metrics/ | grep 'artemis_consumer_count{address="my-test"'
artemis_consumer_count{address="my-test",broker="amq-broker",queue="my-test",} 1.0

[maloneybob]

Thanks @brusdev, we've made a number of changes since opening this discussion, none of which appeared to be related. However, as of today, we can no longer replicate the issue, so closing.

Bob