-
-
Notifications
You must be signed in to change notification settings - Fork 1
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
Conversation
import "sentry_protos/snuba/v1/trace_item_filter.proto"; | ||
|
||
message TraceColumn { | ||
enum Name { |
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.
just a few things:
- rename some of these, I would move
enum Name
to top-level scope and call it something likeenum TraceMetadataType
orTraceKey
orTraceAttributeKey
- (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
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.
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?
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'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
- Add a comment to the request object that describes the endpoint
- add comments to each of the inputs in the request object to describe what it is (if non obvious)
- add comments to each field of the response object to describe what it is (if non obvious)
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; |
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 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).
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 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?
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.
with your current API, how would you find all traces where span.op = http
and error.project_id=1
?
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.
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.
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.
we map the prefixes to each dataset and we query.
Can you elaborate?
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.
or event better, show me an example with python
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 the latest commits should fix your concerns.
The latest Buf updates on your PR. Results from workflow ci / buf-checks (pull_request).
|
// List of attributes we want to query. | ||
repeated TraceAttribute attributes = 6; |
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.
Does this mean we need to specify the type of every attribute when querying? A little inconvenient but not a deal breaker.
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.
Fair enough, I'll remove it if you don't want it and document the type of each attribute in the docstring.
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.
We'll likely want it in the response? So I'm okay with keeping it for now
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 added it back.
// List of attributes we want to query. | ||
repeated TraceAttribute attributes = 6; |
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.
We'll likely want it in the response? So I'm okay with keeping it for now
This will add Protobuf files describing a new endpoint to find traces. It will return a list of traces with fields requested.
Features:
enum
TraceItemTable
endpointenum
Limitations:
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.