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): Trace Item resolvers #6732

Merged
merged 12 commits into from
Jan 10, 2025
Merged

feat(EAP): Trace Item resolvers #6732

merged 12 commits into from
Jan 10, 2025

Conversation

volokluev
Copy link
Member

@volokluev volokluev commented Jan 8, 2025

Context

In order to make room for new kinds of TraceItems (e.g. uptime monitors, errors, logs, etc),add a layer of indirection to the RPC layer

Before:

RPC Flask Endpoint -> RPCEndpoint.execute() -> Snuba query pipeline

After:


                                           /-> EAP resolver -> Snuba query pipeline (or whatever else)
RPC Flask Endpoint -> RPCEndpoint.execute() -> Uptime resolver -> Snuba query pipeline (or whatever else)
                                           \-> Errors resolver -> Snuba query pipeline (or whatever else)

For rationale, please read this doc

How it works:

Every EAP endpoint has a get_resolver method based on the TraceItemName passed in the request meta. A resolver has the same inputs and outputs as the RPCEndpoint.

For each endpoint in EAP, there is a resolver class:
https://github.com/getsentry/snuba/pull/6732/files#diff-c018ef30d919d555c5e69908ce74e5f9144d613de3588a48d849f8c757b58628R22-R53

For each TraceItem we have, we implement the appropriate resolvers, this PR moves EndpointTraceItemTable and EndpointTimeSeries implementations for EAP spans into resolver implementations.

Resolvers are picked up automatically if they follow the directory structure:

snuba/web/rpc/v1/resolvers
  |->R_eap_spans
  |->R_uptime
  |->R_logs
  |->R_etc

Implementing resolver classes in these directories will ❇️ just work ❇️ without needing to change endpoint code.

Outstanding things

It's not clear yet what is really "common" and what is not. We will figure this out through the course of doing this work

@volokluev volokluev force-pushed the volo/eap/event_resolvers branch from 3d283d7 to 07f5413 Compare January 8, 2025 23:23
Copy link

codecov bot commented Jan 8, 2025

❌ 1 Tests Failed:

Tests completed Failed Passed Skipped
700 1 699 1
View the top 1 failed tests by shortest run time
tests.clickhouse.optimize.test_optimize_scheduler::test_get_next_schedule_raises_exception
Stack Traces | 0.002s run time
Traceback (most recent call last):
  File ".../clickhouse/optimize/test_optimize_scheduler.py", line 242, in test_get_next_schedule_raises_exception
    with pytest.raises(OptimizedSchedulerTimeout):
  File ".../local/lib/python3.11.../site-packages/_pytest/python_api.py", line 970, in __exit__
    fail(self.message)
  File ".../local/lib/python3.11.../site-packages/_pytest/outcomes.py", line 196, in fail
    raise Failed(msg=reason, pytrace=pytrace)
Failed: DID NOT RAISE <class 'snuba.clickhouse.optimize.optimize_scheduler.OptimizedSchedulerTimeout'>

To view more test analytics, go to the Test Analytics Dashboard
📢 Thoughts on this report? Let us know!

Comment on lines +36 to +53
class ResolverAttributeNames(
TraceItemDataResolver[
TraceItemAttributeNamesRequest, TraceItemAttributeNamesResponse
]
):
@classmethod
def endpoint_name(cls) -> str:
return "AttributeNames"


class ResolverAttributeValues(
TraceItemDataResolver[
TraceItemAttributeValuesRequest, TraceItemAttributeValuesResponse
]
):
@classmethod
def endpoint_name(cls) -> str:
return "AttributeValues"
Copy link
Member

@xurui-c xurui-c Jan 9, 2025

Choose a reason for hiding this comment

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

Should we also implement resolvers for these in the future (subsequent PR)?

Copy link
Member Author

Choose a reason for hiding this comment

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

Absolutely

Copy link
Contributor

@davidtsuk davidtsuk left a comment

Choose a reason for hiding this comment

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

Added a few questions, but overall this looks good. Nice work!

) -> "Type[TraceItemDataResolver[Tin, Tout]]":
return cast(
Type["TraceItemDataResolver[Tin, Tout]"],
getattr(cls, "_registry").get_class_from_name(
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe I'm missing something, but where is this _registry attribute being set?

Copy link
Member Author

Choose a reason for hiding this comment

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

in the RegisteredClass metaclass

return cast(
Type["TraceItemDataResolver[Tin, Tout]"],
getattr(cls, "_registry").get_class_from_name(
f"{cls.endpoint_name()}__{trace_item_name}"
Copy link
Contributor

Choose a reason for hiding this comment

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

From my understanding trace_item_name is an enum, so won't this evaluate to something like "TraceItemTable__0"?

Copy link
Member Author

Choose a reason for hiding this comment

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

correct

@volokluev volokluev marked this pull request as ready for review January 9, 2025 23:45
@volokluev volokluev requested review from a team as code owners January 9, 2025 23:45
@volokluev volokluev force-pushed the volo/eap/event_resolvers branch from 65806d1 to d962e4e Compare January 9, 2025 23:45
@volokluev volokluev merged commit de96862 into master Jan 10, 2025
31 checks passed
@volokluev volokluev deleted the volo/eap/event_resolvers branch January 10, 2025 00:29
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.

3 participants