Replies: 2 comments · 6 replies
-
|
Hi, see my answers below...
No
No
There will be some extension libraries in the future which will provide adapters between MQTTnet logging and others like Serilog or the logging components from Microsoft
No |
Beta Was this translation helpful? Give feedback.
-
|
"There will be some extension libraries in the future which will provide adapters between MQTTnet logging and others like Serilog or the logging components from Microsoft Is there something I can reference for these extension libraries? |
Beta Was this translation helpful? Give feedback.
-
|
@chkr1011 following up on this. However, I believe more modern tracing and structured logging are blocked specifically by the goal of maintaining compatibility with .NET Standard, as the System.Diagnostics.Activity API that implements Otel-compatible tracing and structured logging is not part of .NET Standard. I think the compatibility between the IMqttNetLogger interface and Otel is a less significant issue. Looking for guidance on how we can relax backward-compatibility with .NET Standard in the MQTTnet project to enable use of System.Diagnostics.Activity, while being good open-source contributors. Some possible options:
Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
@kallayj I believe |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @CZEMacLeod for the tip about the System.Diagnostics.DiagnosticSource package. I believe this project also has a goal of having zero external dependencies (which led to the internal IMqttNetLogger interface replacing ILogger), so guidance is still needed from this repo's maintainer. Tracing appears to me to be, like logging and exception handling, too close to the code to do from an external library. As a point of comparison, the calls to IMqttNetLogger still need to be made in MqttNet code. So I need some help seeing how you think this could be done. |
Beta Was this translation helpful? Give feedback.
-
|
I too am interested in exploring progress on the OTEL front. If you would like to maintain the zero dependency path then we would need to restrict metrics to net 8. I do think we should move to the standardised logging abstraction as it would open up alot of flexibility. |
Beta Was this translation helpful? Give feedback.
-
|
It seems with the new 5.x branch on net8 only, that OTEL should again be viable for shipping in the box? @chkr1011 @kallayj |
Beta Was this translation helpful? Give feedback.
-
|
It looks like implementing some form of https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/ would be the way to go. We would also want to pay attention to how asynchronous request/reply and pubsub is handled via "long running operation" conventions, by way of using Span Links to correlate tracing a pub/sub (i.e. one-to-many) operation, or for replies to asynchronous requests. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello! Posting to ask some questions from a consumer perspective!
As an engineer, I desire to have an end-to-end view of edge, broker, core services. By implementing OpenTelemetry in each layer of my solutions, I can more easily achieve deeper observability and profile my solutions.
As a MQTTnet user, I desire to know the roadmap for the observability plane within MQTTnet to better understand trace, metric. and logging capacities within MQTTnet and how I can create a more unified approach to observability driven design within my solutions.
Beta Was this translation helpful? Give feedback.
All reactions