-
Notifications
You must be signed in to change notification settings - Fork 176
feat: Update Apache ActiveMQ mixin to use modern libraries #1471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Update Apache ActiveMQ mixin to use modern libraries #1471
Conversation
There was a problem hiding this 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:]))', |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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}}', |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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:])', |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
filteringSelector: this.filteringSelector, | ||
groupLabels: this.groupLabels, | ||
instanceLabels: this.instanceLabels, | ||
enableLokiLogs: this.enableLokiLogs, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh good catch 👍
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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', |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
?


I'll go ahead and make that change but let me know if you want a revert or anything :)
There was a problem hiding this comment.
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?
Okay I believe that pieces of feedback have been addressed. Looking forward to hear your thoughts on this one #1471 (comment) |
9ea3c61
to
11cbd40
Compare
11cbd40
to
64bd26c
Compare
…/jsonnet-libs into schmikei/activemq-modernization
…i/activemq-modernization
@schmikei looks like I had in fact missed this PR, adding to my list to clean up and go over in the morning! |
There was a problem hiding this 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 😓
…i/activemq-modernization
…/jsonnet-libs into schmikei/activemq-modernization
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

Apache ActiveMQ instance Overview


Apache ActiveMQ queue Overview

Apache ActiveMQ Overview

Apache ActiveMQ logs
