[#3520] specific metrics for unknown messages

[BobClaerhout]

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

[sonatype-lift]

Sonatype Lift is retiring

Sonatype 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.
We are extremely grateful and thank you for your support over the years.

📖 Read about the impacts and timeline

[sophokles73]

@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]

@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 :-)).

Created a ticket: #3520

[sonatype-lift]

🛠 Lift Auto-fix

Some 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.¹

# 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 diff

Want 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 apply

Once you're satisfied, commit and push your changes in your project.

Footnotes

1. You can preview the patch by opening the patch URL in the browser. ↩

[sophokles73]

do these reasons have any meaning outside the scope of the Lora adapter?

[BobClaerhout]

no, the first 3 do not.

[sophokles73]

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.

[BobClaerhout]

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.

[sophokles73]

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 ...

[BobClaerhout]

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

[BobClaerhout]

It doesn't hurt, right? It only adds information in the metrics. You are free to use it or not.

[sophokles73]

@BobClaerhout any update on this or can we defer this to after the 2.4.0 release?

[BobClaerhout]

@BobClaerhout any update on this or can we defer this to after the 2.4.0 release?

Sorry for the delay. I've applied all remarks from @calohmn. Release 2.4.0 is just fine for me

[BobClaerhout]

@calohmn , @sophokles73 , any other remarks?