Skip to content

Conversation

schmikei
Copy link
Contributor

@schmikei schmikei commented Aug 14, 2025

This PR modernizes the Apache ActiveMQ mixin to utilize an updated common-lib, logs-lib and best match the kafka-observ-lib.

Apache ActiveMQ cluster Overview
image

Apache ActiveMQ instance Overview
image
image

Apache ActiveMQ queue Overview
image

Apache ActiveMQ Overview
image

Apache ActiveMQ logs
image

image

@schmikei schmikei marked this pull request as ready for review August 18, 2025 13:42
@schmikei schmikei requested a review from a team as a code owner August 18, 2025 13:42
@schmikei schmikei marked this pull request as draft August 18, 2025 15:48
@schmikei schmikei marked this pull request as ready for review August 19, 2025 17:34
Copy link
Member

@Dasomeone Dasomeone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @schmikei, sorry for the delay in reviewing these jsonnet-libs PRs!
Overall this is looking good, but I have a couple stylistic comments throughout that I think we need to have a look at.

First though, mixtool linting (with latest update) passes!

But yeah, I think we need to have a look at the groupLabels as there's a bunch of hardcoded label usage, especially in the legends throughout where it'd make sense to combine into one. Speficically with how often job and activemq_cluster are used together.

unit: 'none',
sources: {
prometheus: {
expr: 'sum by (activemq_cluster, job) (increase(activemq_queue_enqueue_count{%(queriesSelector)s}[$__interval:])) + sum by (activemq_cluster, job) (increase(activemq_topic_enqueue_count{%(queriesSelector)s, destination!~"ActiveMQ.Advisory.*"}[$__interval:]))',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a thought, what do you think of adding a specific selector variable for job + activemq_cluster? Seems to me they're used together frequently

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm correct me if I'm wrong but my at least initial understanding was that we were trying to use the queriesSelector for anything related to groupLabels? Or is this comment pertaining to the sum by expression? Apologies if I'm misunderstanding the suggestion!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent question, I should've been more clear! My comment was specifically with regards to the sum and group by used throughout, where it appears we might want another selector. I may be wrong, but that's just my gut feeling here to avoid hardcoding too many things (and combining hard-coded with selectors)

sources: {
prometheus: {
expr: 'avg(activemq_memory_usage_ratio{%(queriesSelector)s})',
legendCustomTemplate: '{{activemq_cluster}} - {{instance}}',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking out loud here, would poke vitaly but he's out on PTO currently.

Thoughts on using instanceLabels and activemqLabels in the legend here? I know there's a slight risk if there's multiple labels defined, but I think it might make sense for most uses?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yep I can explore some options for templating the legends a tad bit better 👍

unit: 'none',
sources: {
prometheus: {
expr: 'sum by (instance, activemq_cluster, job) (increase(activemq_topic_enqueue_count{%(queriesSelector)s})[$__interval:])',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we use the basic cluster anywhere?

I'm commenting as I go here, so I'm just wondering because I've not seen groupLabels used yet

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

groupLabels gets mostly propogated via the commonlib.variables.new() but I am curious if you are expecting another usage outside of the queriesSelector?

Copy link
Member

@Dasomeone Dasomeone Sep 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I think for this comment I meant in the sum and group by as well, given that we specifically call out activemq_cluster, and users may want to optionally have sum by k8s cluster as well

Comment on lines +2 to +5
filteringSelector: this.filteringSelector,
groupLabels: this.groupLabels,
instanceLabels: this.instanceLabels,
enableLokiLogs: this.enableLokiLogs,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems we don't use these at all outside the queriesSelector abstraction?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh good catch 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just realized that these change the behavior of the signals API if not present on the signal... i.e. we change datasource specifically if enableLokiLogs is set

with enableLokiLogs

"uid": "${prometheus_datasource}"

=>

without enableLokiLogs

"uid": "${datasource}"

I'm not sure if this is an intentional but does break my local setup by doing this. Do you have any insight into the reasoning for this? My local setup does get broken without these fields set on the signals...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is done for legacy linting reasons, as the linter expects ${datasource}, but this truly is something we're moving away from. Fine to leave it as-is for now then, we'll revisit in another clean-up pass later on though I'm curious what errors you get?

sources: {
prometheus: {
expr: 'sum (activemq_queue_queue_size{%(queriesSelector)s})',
legendCustomTemplate: '__auto',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where at all possible, I'd like to avoid using auto. Are there no good consistent labels we could use here? Even a hardcoded name might be better than the formatting auto provides?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah this was mostly to match parity with the current mixin... this is rendered as a single statistical sum so I'd imagine its a single latestValue that gets rendered. I suppose with this being a signal it might make sense to remove the legendCustomTemplate = __auto but the legend is a static string like queues?

image => image

I'll go ahead and make that change but let me know if you want a revert or anything :)

Copy link
Member

@Dasomeone Dasomeone Sep 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah that's a great point, I was fully thinking of it from a point of view of a timeseries panel and not wanting {instance=xyz, cluster=123}=value as the legend. For stat panels auto is just fine.

E.g. could you update any use of __auto for anything but stat panels to be more descriptive, and leave it as __auto for stat panels?

@schmikei
Copy link
Contributor Author

Okay I believe that pieces of feedback have been addressed. Looking forward to hear your thoughts on this one #1471 (comment)

@schmikei schmikei force-pushed the schmikei/activemq-modernization branch from 9ea3c61 to 11cbd40 Compare August 28, 2025 13:54
@schmikei schmikei force-pushed the schmikei/activemq-modernization branch from 11cbd40 to 64bd26c Compare August 28, 2025 13:55
@Dasomeone
Copy link
Member

@schmikei looks like I had in fact missed this PR, adding to my list to clean up and go over in the morning!

Copy link
Member

@Dasomeone Dasomeone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One teensy comment left, otherwise everything else has been addressed and looks great!!

I just want to say apologies again for letting this one stay in review and continually forgetting about it 😓

@Dasomeone Dasomeone enabled auto-merge (squash) September 25, 2025 13:48
@Dasomeone Dasomeone merged commit 874d8f2 into grafana:master Sep 25, 2025
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants