You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
opentelemetry-rust uses a logging-bridge to connect to log/trace macros and also discusses currently dropping the own tracing SDK in favor of Tokios trace macros for tracing (#1689). Similar to e.g. .NET OTel leveraging System.Diagnostics & Microsoft.Extension.ILogger instead additional libs.
The log & trace macros have the really nice effect, that one doesn't need to pass around optional objects around a lot, the macros are "just there", even if no logging/tracing is turned on. And they are a nice abstraction from the actual logging library. My libs don't need to care about specifics.
With this background:
Would it be possible to make such an abstraction macro for metrics as well? Creating the concrete Meter instance via meter!(name) and later derive instruments from that meter. And at startup I either connect an OTel metrics provider to the meter-backend. Or I don't.
But while writing the library I don't need to care about the meter potentially being None. It will work anyway code-wise, but just don't do much (like log!/trace!).
Then (over time) rust developers only need 3 abstraction libs for observability, all similar in how they are used: log, trace & meter.
I would be willing to help out, but I don't (yet) have much experience with rust macro development.
Considered Alternatives
Passing along Option, which I currently do in my code. And it's cumbersome, compared to log!/trace!
Additional Context
No response
The text was updated successfully, but these errors were encountered:
option 3 from #1642 calls for macros approach. This is not yet pursued actively, but I can totally imagine that coming in the future. Leveraging macros for performance and easier-to-use APIs is a good addition.
Related Problems?
No response
Describe the solution you'd like:
opentelemetry-rust uses a logging-bridge to connect to log/trace macros and also discusses currently dropping the own tracing SDK in favor of Tokios trace macros for tracing (#1689). Similar to e.g. .NET OTel leveraging System.Diagnostics & Microsoft.Extension.ILogger instead additional libs.
The log & trace macros have the really nice effect, that one doesn't need to pass around optional objects around a lot, the macros are "just there", even if no logging/tracing is turned on. And they are a nice abstraction from the actual logging library. My libs don't need to care about specifics.
With this background:
Would it be possible to make such an abstraction macro for metrics as well? Creating the concrete Meter instance via
meter!(name)
and later derive instruments from that meter. And at startup I either connect an OTel metrics provider to the meter-backend. Or I don't.But while writing the library I don't need to care about the meter potentially being None. It will work anyway code-wise, but just don't do much (like log!/trace!).
Then (over time) rust developers only need 3 abstraction libs for observability, all similar in how they are used: log, trace & meter.
I would be willing to help out, but I don't (yet) have much experience with rust macro development.
Considered Alternatives
Passing along Option, which I currently do in my code. And it's cumbersome, compared to log!/trace!
Additional Context
No response
The text was updated successfully, but these errors were encountered: