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

fix: fix span logging based on changes to request types timestamps #12393

Merged
merged 4 commits into from
Apr 1, 2024

Conversation

cstyan
Copy link
Contributor

@cstyan cstyan commented Mar 28, 2024

In #11018 we modified various loki request types so that their GetStart/GetEnd functions return time.Time rather than int64. The underlying motivation was to allow the protobuf definition for request types to use actual time types instead of int64 types.

However, in that PR we broke the span logging for some request types. In the first commit here, the tests for TestLokiRequestSpanLogging, TestLokiSeriesRequestSpanLogging, and TestLabelRequestSpanLogging will fail. The second commit fixes the logging of the timestamps to the span.

Signed-off-by: Callum Styan <callumstyan@gmail.com>
@cstyan cstyan requested a review from a team as a code owner March 28, 2024 20:34
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
@cstyan cstyan changed the title fix span logging based on changes to request types timestamps fix: fix span logging based on changes to request types timestamps Mar 28, 2024
Copy link
Member

@owen-d owen-d left a comment

Choose a reason for hiding this comment

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

I understand the want for tests, but 800 lines of imports + mocks feels overkill to just solve timestamp.Time(r.GetStart()). I went and looked and this is exactly what it was prior to the pr which broke it

@@ -249,8 +249,8 @@ func (r *LabelRequest) WithQuery(query string) queryrangebase.Request {

func (r *LabelRequest) LogToSpan(sp opentracing.Span) {
sp.LogFields(
otlog.String("start", timestamp.Time(r.GetStart().UnixNano()).String()),
otlog.String("end", timestamp.Time(r.GetEnd().UnixNano()).String()),
otlog.String("start", timestamp.Time(r.Start.UnixNano()/(int64(time.Millisecond)/int64(time.Nanosecond))).String()),
Copy link
Member

Choose a reason for hiding this comment

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

What is going on here? This can just be timestamp.Time(r.GetStart()).

This is doing millis (r.GetStart) -> nanos (.UnixNano) -> divide by milli_duration -> divide by nano_duration (which is just "divide by 1")

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can definitely simplify this, it just depends on what we want the time string in the span to look like.

otlog.String("start", timestamp.Time(r.GetStart().UnixMilli()).String()), would give us the exact format we had in the past, something like "2024-03-29 22:27:27.141 +0000 UTC", where as otlog.String("start", r.GetStart().String()), would give us something like "2024-03-29 22:27:27.141919586 +0000 UTC m=+1000.015209489".

For now I'll go with the former as it matches what we had before and is shorter.

Signed-off-by: Callum Styan <callumstyan@gmail.com>
@slim-bean slim-bean merged commit 018856c into main Apr 1, 2024
10 checks passed
@slim-bean slim-bean deleted the callum-fix-request-span-logging branch April 1, 2024 13:40
trevorwhitney added a commit that referenced this pull request Apr 1, 2024
commit 018856c
Author: Callum Styan <callumstyan@gmail.com>
Date:   Mon Apr 1 06:40:16 2024 -0700

    fix: fix span logging based on changes to request types timestamps (#12393)

    Signed-off-by: Callum Styan <callumstyan@gmail.com>

commit 5190dda
Author: Shantanu Alshi <shantanu.alshi@grafana.com>
Date:   Mon Apr 1 18:30:21 2024 +0530

    feat(detected_labels): Initial skeleton for the API (#12390)

    Co-authored-by: Cyril Tovena <cyril.tovena@gmail.com>

commit 0b7ff48
Author: Sandeep Sukhani <sandeep.d.sukhani@gmail.com>
Date:   Mon Apr 1 14:21:50 2024 +0530

    chore: delete request processing improvements (#12259)

commit a509871
Author: Ed Welch <edward.welch@grafana.com>
Date:   Sun Mar 31 22:14:21 2024 -0400

    chore: remove experimental flags for l2 cache and memcached "addresses" config (#12410)

commit 7480468
Author: Kaviraj Kanagaraj <kavirajkanagaraj@gmail.com>
Date:   Sun Mar 31 18:00:53 2024 +0200

    fix: (Bug) correct resultType when storing instant query results in cache (#12312)

    Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>

commit 246623f
Author: Trevor Whitney <trevorjwhitney@gmail.com>
Date:   Fri Mar 29 17:05:36 2024 -0600

    fix(detected_fields): fix issues with frontend integration (#12406)

    This PRs fixes issues we found when integrating with the frontend
    * the `/experimental` api made it difficult to interact with using the existing datasource, so move to `v1/detected_fields`
    * the config flag was considered cumbersome as the only potential negative impact of the endpoint is when it is used, and nothing is currently using it
    * the use of an enum in the protobuf produced unexpected results in the json, so type was converted to string
rhnasc pushed a commit to inloco/loki that referenced this pull request Apr 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants