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

feat(eap): Add a GetTraces endpoint #71

Merged
merged 10 commits into from
Dec 23, 2024
Merged

feat(eap): Add a GetTraces endpoint #71

merged 10 commits into from
Dec 23, 2024

Conversation

phacops
Copy link
Contributor

@phacops phacops commented Dec 13, 2024

This will add Protobuf files describing a new endpoint to find traces. It will return a list of traces with fields requested.

Features:

  • You can pick which fields from the enum
  • You can specify the type you want from a field
  • You can use the same filter conditions as for the TraceItemTable endpoint
  • You can order by any field from the enum

Limitations:

  • No aggregation possible
  • No support for alias
  • A fixed list of fields to query

Since traces are not a defined object but a specific view on an aggregated list of spans, I don't think we should plan to support any field possible. Maybe at some point, we'll make the trace a real object and we'll add trace attributes and by then, we can design a new version of the endpoint.

Closes https://github.com/getsentry/eap-planning/issues/121.

@phacops phacops requested review from a team as code owners December 13, 2024 15:49
@phacops phacops changed the title Pierre/eap find traces feat(eap): Add a FindTraces endpoint Dec 13, 2024
@phacops phacops changed the title feat(eap): Add a FindTraces endpoint feat(eap): Add a GetTraces endpoint Dec 13, 2024
@phacops phacops requested a review from colin-sentry December 16, 2024 20:02
import "sentry_protos/snuba/v1/trace_item_filter.proto";

message TraceColumn {
enum Name {
Copy link
Member

@colin-sentry colin-sentry Dec 16, 2024

Choose a reason for hiding this comment

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

just a few things:

  • rename some of these, I would move enum Name to top-level scope and call it something like enum TraceMetadataType or TraceKey or TraceAttributeKey
  • (subjective) rename Trace in response to just be Row
  • (subjective) the whole request might be better called 'TraceTableRequest' or something like that
  • add docstrings to at least the top-level messages, and each enum member

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why move the enum to top-level? It's really meant to be used only in this endpoint for a request, why not keep it embedded?

Copy link
Member

@kylemumma kylemumma left a comment

Choose a reason for hiding this comment

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

I've been going back through our proto definitions and adding better documentation on each of the Request and Response protos, so users can understand what the endpoints are and how to use them. I would appreciate if you could add these comments for documentation

  1. Add a comment to the request object that describes the endpoint
  2. add comments to each of the inputs in the request object to describe what it is (if non obvious)
  3. add comments to each field of the response object to describe what it is (if non obvious)

@volokluev
Copy link
Member

Can you add some example python files like we have for the other endpoints so we can see the API in action?

}

RequestMeta meta = 1;
TraceItemFilter filter = 2;
Copy link
Member

Choose a reason for hiding this comment

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

this won't work for searching across event types. At least not by itself. The filter currently does not support a name. That's why in the other file there's extra filter definitions for traces (because they are different).

Copy link
Contributor Author

@phacops phacops Dec 17, 2024

Choose a reason for hiding this comment

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

I didn't want to enable filtering on traces, I want to only allow filtering on trace items, that's why I removed it.

Traces don't have a name, they don't have attributes, I don't think we should enable filtering on things that are defined by trace item fields.

As for searching across event types, wouldn't it let me add a filter for a different even type than spans? Why is it preventing me from cross-event searches specifically? Maybe we'd need to allow a list of TraceItemFilter with an event type for each?

Copy link
Member

Choose a reason for hiding this comment

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

with your current API, how would you find all traces where span.op = http and error.project_id=1?

Copy link
Contributor Author

@phacops phacops Dec 17, 2024

Choose a reason for hiding this comment

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

Pass a TraceItemFilter with your conditions, we map the prefixes to each dataset and we query.

I think we could do better by adding groups of filtered with a specific event type though.

Copy link
Member

Choose a reason for hiding this comment

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

we map the prefixes to each dataset and we query.

Can you elaborate?

Copy link
Member

Choose a reason for hiding this comment

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

or event better, show me an example with python

Copy link
Contributor Author

@phacops phacops Dec 18, 2024

Choose a reason for hiding this comment

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

I think the latest commits should fix your concerns.

@phacops phacops requested a review from volokluev December 17, 2024 20:48
Copy link

github-actions bot commented Dec 18, 2024

The latest Buf updates on your PR. Results from workflow ci / buf-checks (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed⏩ skipped✅ passed✅ passedDec 18, 2024, 10:33 PM

Comment on lines +60 to +61
// List of attributes we want to query.
repeated TraceAttribute attributes = 6;
Copy link
Member

Choose a reason for hiding this comment

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

Does this mean we need to specify the type of every attribute when querying? A little inconvenient but not a deal breaker.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fair enough, I'll remove it if you don't want it and document the type of each attribute in the docstring.

Copy link
Member

Choose a reason for hiding this comment

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

We'll likely want it in the response? So I'm okay with keeping it for now

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added it back.

@phacops phacops requested a review from Zylphrex December 18, 2024 19:31
Comment on lines +60 to +61
// List of attributes we want to query.
repeated TraceAttribute attributes = 6;
Copy link
Member

Choose a reason for hiding this comment

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

We'll likely want it in the response? So I'm okay with keeping it for now

@phacops phacops merged commit ff28c24 into main Dec 23, 2024
6 checks passed
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.

6 participants