Add support for metrics and tracing #8
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
satabin
force-pushed
the
metrics
branch
3 times, most recently
from
3ea0674 to
d13e3a8
Compare
JPisCoding
reviewed
Mar 27, 2024
otel4s/src/main/scala/com/commercetools/queue/otel4s/MeasuringQueuePusher.scala
Outdated
Show resolved
Hide resolved
JPisCoding
approved these changes
Mar 27, 2024
Components having metrics now take an instance of the `QueueMetrics` class, which allows for instantiating the outcome handling closure only once when the `QueueSubscriber` or `QueuePublisher` is created.
AL333Z
approved these changes
Mar 29, 2024
Sadly not all systems provide it. We can add a generic stats method, I need to check which ones are available to all queue systems. |
JPisCoding
approved these changes
Apr 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows to wrap any queue client into a client that tracks metrics and/or traces.
Regarding the metrics, we can discuss if and what other metrics we want to have built-in. I only defined a metrics that counts accesses to the queue system and the action and outcome. These metrics need to be built into the concrete client implementations.
I think that metrics like number of messages pushed or number of messages received do not need to be built in, as they are easily implemented on the resulting streams if needed. This gives freedom to user to define their message level metrics as they wish. This is debatable and I'd like to gather your thought here and what kind of metrics we would like to have on top of the one I defined here.