[#3520] specific metrics for unknown messages #3519
Conversation
Sonatype Lift is retiringSonatype Lift will be retiring on Sep 12, 2023, with its analysis stopping on Aug 12, 2023. We understand that this news may come as a disappointment, and Sonatype is committed to helping you transition off it seamlessly. If you’d like to retain your data, please export your issues from the web console. |
adapters/lora/src/main/java/org/eclipse/hono/adapter/lora/LoraProtocolAdapter.java
Outdated
Show resolved
Hide resolved
|
@BobClaerhout would you mind creating an issue for this feature request which we could use to discuss? It is not obvious to me what the motivation for this change is so providing a little context in the issue would be very helpful (to me :-)). |
BobClaerhout
changed the title
BobClaerhout
force-pushed
the
specificMetricsForUnknownMessages
branch
from
1bb6c34
to
00f5993
Compare
Created a ticket: #3520 |
BobClaerhout
force-pushed
the
specificMetricsForUnknownMessages
branch
from
00f5993
to
51251a6
Compare
BobClaerhout
force-pushed
the
specificMetricsForUnknownMessages
branch
2 times, most recently
from
18bf45a
to
6ac3f87
Compare
![sonatype-lift[bot]](https://avatars.githubusercontent.com/in/9843?s=60&v=4){kind=small}
...-base/src/main/java/org/eclipse/hono/adapter/http/AbstractVertxBasedHttpProtocolAdapter.java
Outdated
Show resolved
Hide resolved
🛠 Lift Auto-fixSome of the Lift findings in this PR can be automatically fixed. You can download and apply these changes in your local project directory of your branch to review the suggestions before committing.1 # Download the patch
curl https://lift.sonatype.com/api/patch/github.com/eclipse-hono/hono/3519.diff -o lift-autofixes.diff
# Apply the patch with git
git apply lift-autofixes.diff
# Review the changes
git diffWant it all in a single command? Open a terminal in your project's directory and copy and paste the following command: curl https://lift.sonatype.com/api/patch/github.com/eclipse-hono/hono/3519.diff | git applyOnce you're satisfied, commit and push your changes in your project. Footnotes |
BobClaerhout
force-pushed
the
specificMetricsForUnknownMessages
branch
3 times, most recently
from
ff18da6
to
84c0094
Compare
BobClaerhout
force-pushed
the
specificMetricsForUnknownMessages
branch
4 times, most recently
from
8bab1a5
to
39e59a0
Compare
| /** | ||
| * The message received has a bad syntax and could not be parsed. | ||
| */ | ||
| BAD_SYNTAX("bad-syntax"), | ||
| /** | ||
| * The type of the message could not be deducted from the message. | ||
| */ | ||
| UNKNOWN_TYPE("unknown-type"), | ||
| /** | ||
| * The type of the message is not supported for this action. | ||
| */ | ||
| UNSUPPORTED_TYPE("unsupported-type"), |
There was a problem hiding this comment.
do these reasons have any meaning outside the scope of the Lora adapter?
There was a problem hiding this comment.
no, the first 3 do not.
There was a problem hiding this comment.
Do you see any particular value in reporting the generic reasons as well? We do have the reason for failed message processing in the traces and so far, nobody needed to have them reported in metrics.
If we do not need them then I would suggest to only define and use the Lora specific reasons in the context of the Lora adpter in order not to mix up generic and adapter specific error handling.
There was a problem hiding this comment.
I believe the others are useful as well. It provides a lot more insight into missed messages. Lot's of our devices are out in the field an unreachable. Having some reporting from the cloud services makes sense imo.
There was a problem hiding this comment.
The only concern I have is that these kinds of issues (currently) only occur with the Lora adapter because none of the other adapters actually care about the message payload. In fact, being payload agnostic is actually one of Hono's core features/assertions ...
There was a problem hiding this comment.
Agreed, but it is very useful information. If a message is unprocessable because it was wrongly formatted, it's completely different from a unknown type. From an operational standpoint, we need to act differently
There was a problem hiding this comment.
It doesn't hurt, right? It only adds information in the metrics. You are free to use it or not.
adapters/lora/src/main/java/org/eclipse/hono/adapter/lora/LoraProtocolAdapter.java
Outdated
Show resolved
Hide resolved
service-base/src/main/java/org/eclipse/hono/service/metric/Metrics.java
Outdated
Show resolved
Hide resolved
service-base/src/main/java/org/eclipse/hono/service/metric/MetricsTags.java
Outdated
Show resolved
Hide resolved
service-base/src/main/java/org/eclipse/hono/service/metric/MetricsTags.java
Outdated
Show resolved
Hide resolved
service-base/src/main/java/org/eclipse/hono/service/metric/MetricsTags.java
Outdated
Show resolved
Hide resolved
service-base/src/main/java/org/eclipse/hono/service/metric/MetricsTags.java
Outdated
Show resolved
Hide resolved
service-base/src/main/java/org/eclipse/hono/service/metric/MetricsTags.java
Outdated
Show resolved
Hide resolved
|
@BobClaerhout any update on this or can we defer this to after the 2.4.0 release? |
BobClaerhout
force-pushed
the
specificMetricsForUnknownMessages
branch
2 times, most recently
from
5852676
to
859f41d
Compare
Sorry for the delay. I've applied all remarks from @calohmn. Release 2.4.0 is just fine for me |
|
@calohmn , @sophokles73 , any other remarks? |
adapters/lora/src/main/java/org/eclipse/hono/adapter/lora/LoraProtocolAdapter.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Bob Claerhout <[email protected]>
BobClaerhout
force-pushed
the
specificMetricsForUnknownMessages
branch
from
859f41d
to
e94a14c
Compare
We would like to have a different metrics for unknown messages compared to messages which are processable (for some reason). This PR adds this metric for the unknown messages