WIP: AMQ-9552: Add metric lastMessageTimestamp to StatisticsBroker based o… #1285
Conversation
|
Some examples per threshold of this metric from real life implementation:
|
ggkochanski
force-pushed
the
AMQ-9552
branch
4 times, most recently
from
cc8ba95
to
e0bf09d
Compare
| @@ -80,6 +80,9 @@ public synchronized long getLastSampleTime() { | |||
| return this.lastSampleTime; | |||
| } | |||
|
|
|||
| public synchronized long getLastSampleTimeOrStartTime(){ | |||
| return lastSampleTime == 0 ? startTime : lastSampleTime; | |||
There was a problem hiding this comment.
An alternative approach to setting the lastSampleTime to 0, we can keep the this.lastSampleTime = this.startTime; as originally implemented. But then we add an additional field in StatisticImpl class like "hasUpdated" to indicate if the lastSampleTime has been updated. In that way, it's up to the caller to decide what to make use of this "hasUpdated" field. I.E write 0, or not set at all ... etc.
The advantage of avoiding giving special meaning to 0 is:
- Not explicit in semantic and make the code a bit harder to follow (why 0?)
- What if 0 means some other things in downstream code
- More flexible and clear on the caller, it calls the object to see if the lastSampleTime has been updated since restart, rather than just set the value to whatever
stats.getEnqueues().getLastSampleTime()returns
There was a problem hiding this comment.
wow, that's clever 😊
it's much better,
we may even skip generation of
statsMessage.setLong("lastMessageTimestamp", stats.getEnqueues().getLastSampleTime())
when it's not "hasUpdated" 😋
…n lastSampleTime of metric enqueues (if hasUpdated)
mattrpav
changed the title
|
I have started a capability to put additional statistics behind a config flag, so adding new metrics such as lastMessageTimestamp, lastMessageId, etc.. do not add computation overhead to all queues by default to all users. The statistics broker update should wait to follow the work done for the core capability. The field names should be consistent across all APIs and functions. There are other requests to add deeper observability fields -- firstEnqueue, lastEnqueue, firstDequeue, etc.. so 'lastMessageTimestamp' as a field name is not specific enough to meet all the requests. ref: [AMQ-9426] The initial work for the feature is here: #1156 |
| if ( stats.getEnqueues().hasUpdated() ) { | ||
| // NOTICE: Client-side, you may get the broker "now" Timestamp by msg.getJMSTimestamp() | ||
| // This allows for calculating inactivity. | ||
| statsMessage.setLong("lastMessageTimestamp", stats.getEnqueues().getLastSampleTime()); |
There was a problem hiding this comment.
@mattrpav I can see your change is merged, so I'm refreshing the pull request.
I understand the name unification motivation. Should I change name lastMessageTimestamp into lastEnqueTimestamp here?
There was a problem hiding this comment.
@ggkochanski The field naming is a broader conversation. The full scope is not one field as you have in this PR. We currently have a number of metrics (and config params) that are not fully aligned in naming convention, so I would press for an organized approach for these new metrics.
Related JIRAs:
ref: https://issues.apache.org/jira/browse/AMQ-4358
ref: https://issues.apache.org/jira/browse/AMQ-5497
Add metric lastMessageTimestamp to StatisticsBroker based on modification time of metric enqueues: