Skip to content
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

[exporter/<logs>] Update timestamp processing logic #9369

Merged
merged 3 commits into from
Apr 22, 2022

Conversation

mar4uk
Copy link
Contributor

@mar4uk mar4uk commented Apr 20, 2022

Description: Resolves #9130
Testing: Added unit tests

@@ -43,7 +43,11 @@ type logPacker struct {
func (packer *logPacker) LogRecordToEnvelope(logRecord plog.LogRecord) *contracts.Envelope {
envelope := contracts.NewEnvelope()
envelope.Tags = make(map[string]string)
envelope.Time = toTime(logRecord.Timestamp()).Format(time.RFC3339Nano)
timestamp := logRecord.Timestamp()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember a conversation about adding an IsZero() function. Was it for pdata?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No consensus was reached to add IsZero, but it was clarified that the pdata representation of time is uint64, so checking with == 0 is correct.

@@ -126,7 +126,7 @@ func resourceAndInstrumentationLogToEntry(resMap map[string]interface{}, log plo

func timestampFromRecord(log plog.LogRecord) string {
if log.Timestamp() == 0 {
return timeNow().UTC().Format(timestampFieldOutputLayout)
return log.ObservedTimestamp().AsTime().UTC().Format(timestampFieldOutputLayout)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is ObservedTimestamp guaranteed to be non-zero?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the specification, yes. But it's probably wise to check here in case there's a mistake upstream.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's right. I added check for zero observed timestamp to not break things

Copy link
Member

@djaglowski djaglowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @mar4uk. The code looks great, although I think Juraci has pointed out an instance where a zero-check would be warranted just in case.

@djaglowski djaglowski merged commit 49edf30 into open-telemetry:main Apr 22, 2022
@mar4uk mar4uk deleted the issue-9130 branch April 22, 2022 12:50
djaglowski added a commit to djaglowski/opentelemetry-collector-contrib that referenced this pull request May 10, 2022
)

* [exporter/<logs>] Update timestamp processing logic

* [exporter/<logs>] Update timestamp processing logic. Handle zero observed timestamp case

Co-authored-by: Daniel Jaglowski <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[exporter/<logs>] Update timestamp processing logic
4 participants