feat: Update Logger#on_emit to create LogRecords #1611
Conversation
Co-authored-by: James Bunch <fallwith@gmail.com>
kaylareopelle
requested review from
fbogsany,
mwear,
robertlaurin,
dazuma,
ericmustin,
arielvalentin,
ahayworth,
plantfansam and
robbkidd
as code owners
|
👋 This pull request has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the |
Previously, trace_id, span_id, and trace_flags were assigned based on the OpenTelemetry::Trace.current_span's SpanContext. The specification requires a context be accepted as an argument on emit. If no context is provided, OpenTelemetry::Context.current will be used. If there isn't a current span on OpenTelemetry::Context.current trace_id, span_id, and trace_flags will be nil unless they are passed as arguments. Also, remaining #emit methods are renamed to #on_emit.
| # | ||
| # @api public | ||
| def emit( | ||
| def on_emit( |
There was a problem hiding this comment.
When we renamed the method in #1517, I forgot to go back and change the references in the API.
This code was leftover and should have been removed. Now, the specfic `trace_id`, `span_id`, and `trace_flags` attributes are used instead.
…lemetry-ruby into logs-sdk-log-record
| @trace_id = trace_id | ||
| @span_id = span_id | ||
| @trace_flags = trace_flags | ||
| @resource = logger&.resource |
There was a problem hiding this comment.
I know there's a method added to the sdk logger here to support this but it still reads like logger.logger_provider.resource to me.
I wonder if there's any merit in following the same pattern we did with the tracer https://github.com/open-telemetry/opentelemetry-ruby/blob/main/sdk/lib/opentelemetry/sdk/trace/tracer.rb#L35
There was a problem hiding this comment.
That's a great point, following that approach cleans up the code nicely. Fixed in ab57071
| LogRecordData = Struct.new(:timestamp, # optional Integer nanoseconds since Epoch | ||
| :observed_timestamp, # Integer nanoseconds since Epoch |
There was a problem hiding this comment.
The timestamp and observed_timestamp are documented here to be "Integer nanoseconds since Epoch", so there should be no need for the unix_nano_timestamp and unix_nano_observed_timestamp methods below.
There was a problem hiding this comment.
Great point. Fixed in 0fb4606
| # @param [optional Float, Time] timestamp Time when the event occurred. | ||
| # @param [optional Float, Time] observed_timestamp Time when the event | ||
| # was observed by the collection system. If nil, will first attempt | ||
| # to set to `timestamp`. If `timestamp` is nil, will set to | ||
| # `Process.clock_gettime(Process::CLOCK_REALTIME, :nanosecond)`. |
There was a problem hiding this comment.
Why do these accept Float? They should only accept Time, like corresponding methods in the tracing API. This makes it easier to ensure the correctness of conversion to "Integer nanoseconds since Epoch" internally, and reduces confusion about the units.
There was a problem hiding this comment.
I got a little too overzealous when trying to adhere to the spec. The datatype in the Logs Data Model was listed as "Type: Timestamp, uint64 nanoseconds since Unix epoch." Since the timestamp could be efficiently accessed using Process.clock_gettime(Process::CLOCK_REALTIME, :nanosecond), I decided to add it and make it the default.
Based on these questions, I decided to remove the Float option, go all in on the Time object and transform it into a nanosecond Integer in LogRecord#to_log_record_data.
Fixes across two commits:
| # @param [optional Float, Time] timestamp Time in nanoseconds since Unix | ||
| # epoch when the event occurred measured by the origin clock, i.e. the | ||
| # time at the source. | ||
| # @param observed_timestamp [optional Float, Time] Time in nanoseconds | ||
| # @param [optional Float, Time] observed_timestamp Time in nanoseconds | ||
| # since Unix epoch when the event was observed by the collection system. | ||
| # Intended default: Process.clock_gettime(Process::CLOCK_REALTIME) |
There was a problem hiding this comment.
The units are unclear here. If we accept nanoseconds, I'd expect that to be Integer rather than Float, and if we accept Time, then the units are not relevant. IMO we should only accept Time, and we should convert that to "Integer nanoseconds since Epoch" internally.
Related: documenting the Process.clock_gettime(Process::CLOCK_REALTIME) as the default increases confusion about the units (and precision).
There was a problem hiding this comment.
Great points, I agree. Addressed here: #1611 (comment)
|
👋 This pull request has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the |
Convert Time to the appropriate nanosecond format in LogRecordData. Remove Float option from argument declaration.
The LogRecordData definition says the time is already Integer nanoseconds since epoch, so move the logic to convert the timestamp to LogRecord#to_log_record_data
* Follow the pattern in TracerProvider#internal_start_span * Update spacing in LogRecordData * Remove resource references outside LoggerProvider * Remove Logger attr_readers for logger_provider and instrumentation_scope
|
@robertlaurin, @fbogsany - Thanks for your feedback! I've been able to return to this project and addressed your comments. This PR is ready for another review. |
This PR creates a
LogRecordclass that is read/writeable to start with, and becomes read-only when it transitions toLogRecordData.Additionally, it provides the SDK implementation of the Logs Bridge API
Logger#on_emitmethod to emitLogRecords to the processing pipeline.Relates to the following specs:
Resolves: #1484