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
Looking closer, both interfaces are indeed asynchronous. For traces, the interface returns a Future, making it naturally async, while for metrics, it’s defined using async fn. Although the difference isn’t major, the async fn approach in metrics does look cleaner, more straightforward interface.
The text was updated successfully, but these errors were encountered:
The logs specification requires that the exporter implements force_flush as described here: - https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/sdk.md#forceflush-2. This function can be asynchronous, but if so, the exporter should offer a way to inform the provider of its status.
Apart from that, the force_flush() interface are different for traces and metrics:
Traces:
opentelemetry-rust/opentelemetry-sdk/src/export/trace.rs
Line 63 in a5e2061
Metrics:
opentelemetry-rust/opentelemetry-sdk/src/metrics/exporter.rs
Line 24 in a5e2061
Looking closer, both interfaces are indeed asynchronous. For traces, the interface returns a
Future
, making it naturallyasync
, while for metrics, it’s defined usingasync fn
. Although the difference isn’t major, theasync fn
approach in metrics does look cleaner, more straightforward interface.The text was updated successfully, but these errors were encountered: