-
Notifications
You must be signed in to change notification settings - Fork 452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial implementation of the logging SDK spec #788
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great step thanks for starting this, the duplication between runtimes is indeed unfortunate, we could look at unifying those in subsequent PRs. Also note the changes discussed in #781.
opentelemetry-sdk/src/log/record.rs
Outdated
/// span. | ||
#[derive(Debug, Clone)] | ||
#[non_exhaustive] | ||
pub struct TraceContext { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe LogTraceContext
to disambiguate from other trace context concepts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it refers to W3C trace context standard. Maybe we can merge it with the definition in trace
mod?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, just confusing as the concept is used multiple places, like the TraceContextPropagator doesn't use this and the TraceContextExt doesn't involve it either (maybe the ext should be renamed as well to disambiguate?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe easier to divide the trace context field into trace id, span id, and trace flag and use the basic types. Or alternatively, those fields should only be present when trace
is enabled. so that we can just refer the types from trace
mod
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is SpanContext
, which stores the span ID, trace ID, and trace flags. However, it also stores an additional TraceState
field, which is not in a Log Record. That's why I had to create this field.
opentelemetry-sdk/src/log/record.rs
Outdated
|
||
/// Value types for representing arbitrary values in a log record. | ||
#[derive(Debug, Clone)] | ||
pub enum Any { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spec calls this typeAny
but this may be confusing as people may read it as std::any::Any
, possibly LogBody
, AnyBody
, or something slightly more specific? also would be nice to have these be as consistent with the Value
type as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about LogAny
or AnyValue
? I initially wanted to reuse Value
, but both the spec and the Rust implementation mandate that an Array
be homogenous in its member types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about
LogAny
orAnyValue
? I initially wanted to reuseValue
, but both the spec and the Rust implementation mandate that anArray
be homogenous in its member types.
Those seem reasonable 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed this to AnyValue
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this I think it's a good start!
.0, | ||
dropped_attributes_count: 0, | ||
}), | ||
schema_url: "".to_string(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe leave a TODO here to implement the schema url in the furture
opentelemetry-sdk/src/log/record.rs
Outdated
/// span. | ||
#[derive(Debug, Clone)] | ||
#[non_exhaustive] | ||
pub struct TraceContext { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it refers to W3C trace context standard. Maybe we can merge it with the definition in trace
mod?
Hey there! What's the status of this PR? Maybe some help needed? |
👋🏼 @vibhavp thank you again for making the PR, do you mind if we rebase this on main? |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #788 +/- ##
=======================================
- Coverage 55.1% 50.9% -4.3%
=======================================
Files 149 165 +16
Lines 18143 19686 +1543
=======================================
+ Hits 10006 10025 +19
- Misses 8137 9661 +1524
☔ View full report in Codecov by Sentry. |
opentelemetry-api/src/logs/logger.rs
Outdated
|
||
fn versioned_logger( | ||
&self, | ||
name: Cow<'static, str>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be: name: impl Into<Cow<'static, str>>,
this will allow us to directly pass string literal as name
argument.
opentelemetry-api/src/logs/logger.rs
Outdated
attributes: Option<Vec<KeyValue>>, | ||
) -> Self::Logger; | ||
|
||
fn logger(&self, name: Cow<'static, str>) -> Self::Logger { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name
argument can be: name: impl Into<Cow<'static, str>>
this will allow us to directly pass string literal as argument.
Thanks @TommyCpp for fixing lint. As discussed in the community meeting, do you think we can merge this PR, as that will allows others to incrementally contribute the improvements over this. I did some trivial testing using ostream-exporter, and the logs are printed successfully to standard output. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
@jtescher Could you also take another look? There is a request-changes from your earlier review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still needs some cleanup and I'd like to see the Any
type renamed as it conflicts with the type in the standard library, but we can do it follow up changes as well.
use std::{borrow::Cow, fmt::Debug}; | ||
|
||
/// `LogExporter` defines the interface that log exporters should implement. | ||
#[async_trait] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think traits that every 3rd-party exporter is expected to implement should be forcing non-standard things like the async-trait crate. It's hacky and unnecessary, and will probably turn into an issue in the future when/if built-in support for async functions in traits shows up.
While the SpanExporter's BoxedFuture is unpleasant, it feels like a more future-proof design and one that is less burdensome on developers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, exporter trait needn't be async, and let the processor decide how export would be invoked. We can keep this consistent with SpanExporter -
pub trait SpanExporter: Send + Debug { |
fn drop(&mut self) { | ||
match self.try_shutdown() { | ||
None => handle_error(Error::Other( | ||
"canont shutdown LoggerProvider when child Loggers are still active".into(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cannot
pub type LogResult<T> = Result<T, LogError>; | ||
|
||
#[derive(Error, Debug)] | ||
#[non_exhaustive] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More a comment for when we look to stabilize, but non-exhaustive is a double edged sword because while adding a new enum value is considered breaking without it because code will fail to compile. It might be worse to have people think they covered all errors and then find out at runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, better to fail early at compile time. Probably we can remove non-exhaustive attribute before releasing stable version of logs.
} | ||
|
||
/// OTLP exporter that sends log data | ||
pub enum LogExporter { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For another review: the builder is non_exhausive but the Exporter isn't?
Sounds good! Thank you for working on this @vibhavp and appriciate everyone that reviewed it |
This PR is a first stab at implementing the logging SDK specification. Owing to the similar nature of traces and logging data, it's mostly a
s/span/log/g
on the trace SDK, but without corresponding additions to theapi
package, as the specification's intent is for the SDK to be used by logging libraries, not developers.There is a bit of duplication, especially with respect to how the batching is implemented, and I'm curious in seeing whether that could be resolved by unifying
TraceRuntime
andLogRuntime
into a signal-agnostic trait.