-
Notifications
You must be signed in to change notification settings - Fork 558
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
Add more metrics for processing latency #5974
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -136,6 +136,8 @@ public final class ProcessingStateMachine { | |
private long errorRecordPosition = StreamProcessor.UNSET_POSITION; | ||
private volatile boolean onErrorHandlingLoop; | ||
private int onErrorRetries; | ||
// Used for processing duration metrics | ||
private long processingStartTime; | ||
|
||
public ProcessingStateMachine( | ||
final ProcessingContext context, final BooleanSupplier shouldProcessNext) { | ||
|
@@ -217,8 +219,8 @@ private void processEvent(final LoggedEvent event) { | |
return; | ||
} | ||
|
||
metrics.processingLatency( | ||
metadata.getRecordType(), event.getTimestamp(), ActorClock.currentTimeMillis()); | ||
processingStartTime = ActorClock.currentTimeMillis(); | ||
metrics.processingLatency(metadata.getRecordType(), event.getTimestamp(), processingStartTime); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you explain the choice to include deserialization as part of the processing time? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As a first step I did not want to narrow the scope of a metrics. If processing duration is higher than what we expect, then we can narrow down the metrics to smaller blocks. Would you like to take deserialization out of the processing time? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I mostly wanted to know if it was a conscious choice, and if so, why. Do you think it might be confusing/unexpected that deserializing is part of the processing time? I think it might be a little unexpected, but once you know it doesn't sound out of place imho, you can make a case that it is part of the processing. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, I wanted to include the complete processing - from this event is ready to process until the next event is ready. This would give us an idea how much time we spent in StreamProcessor. So that should include the steps There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That makes more sense - we can make it more granular by adding a metric per step later on (i.e. updateState, writeFollowUpEvents, etc.). If we add one here, can we also add one in reprocessing? Both will be very useful when refactoring how we do stream processing next quarter 👍 |
||
|
||
try { | ||
final UnifiedRecordValue value = recordValues.readRecordValue(event, metadata.getValueType()); | ||
|
@@ -426,6 +428,8 @@ private void executeSideEffects() { | |
|
||
notifyListener(); | ||
|
||
metrics.processingDuration( | ||
metadata.getRecordType(), processingStartTime, ActorClock.currentTimeMillis()); | ||
// continue with next event | ||
currentProcessor = null; | ||
actor.submit(this::readNextEvent); | ||
|
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.
I think it would be interesting to find hotspots by adding value type/intent as labels - however I'm not sure if that creates too much dimensions/data explosion. We can definitely do that as a second iteration though.
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.
Yes. We can improve it when we need it.