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

Providing Activity/Fragment name in the span name #211

Open
LikeTheSalad opened this issue Jan 8, 2024 · 6 comments
Open

Providing Activity/Fragment name in the span name #211

LikeTheSalad opened this issue Jan 8, 2024 · 6 comments

Comments

@LikeTheSalad
Copy link
Contributor

Currently, the ActivityTracer and FragmentTracer tools create spans with only the verb as name, which causes too low cardinality when analyzing the data later on. For example, the screenshot below shows how a span of an Activity creation, followed by 2 fragment creations as children, looks like right now:

Screenshot 2024-01-08 at 10 26 01

Analyzing this data might become more straightforward to do if the name of the Activity/Fragment would appear in the span name, for example:

Created - MyActivity
Created - Fragment1
Created - Fragment2
@breedx-splk
Copy link
Contributor

The fragment/activity name should be an attribute on the span though. This is a good candidate for us to solidify as semantic convention, IMO: Span naming for activity/fragment creation.

@LikeTheSalad
Copy link
Contributor Author

The fragment/activity name should be an attribute on the span though.

That's ok for me, though it would still be helpful to mention something about it in the span name as well.

This is a good candidate for us to solidify as semantic convention, IMO: Span naming for activity/fragment creation.

Sounds good, I think it might be worth mentioning it in the Client SIG as well.

@marandaneto
Copy link
Member

Something to consider is that the Fragments are obfuscated IIRC (Activities are not), so inferring the name from the class name is suboptimal.
So there should be an approach where the user should be able to overwrite the fragment's name, like a callback that passes the fragment instance as a parameter and returns a string, by default returns the class name, but if the user sets this callback, they can return what they want, they can probably do a when/switch and compare types and return a human-readable name that makes sense.

The other option is to symbolicate the fragment's name on the server, far from ideal for a vendor-agnostic lib.

@LikeTheSalad
Copy link
Contributor Author

That's a great point, we definitely need to find alternatives to just getting the class name at runtime.

@aldoKelvianto
Copy link

So there should be an approach where the user should be able to overwrite the fragment's name, like a callback that passes the fragment instance as a parameter and returns a string

Agree, I think we can use Datadog RUM's approach where the user defines Activity/Fragment during initialization.

For example:

val rumConfig = RuntimeConfig.rumConfigBuilder()
    .useViewTrackingStrategy(FragmentViewTrackingStrategy(
      predicate =  object : ComponentPredicate<Fragment> {
          override fun accept(component: Fragment): Boolean {
              return allowedFragments.contains(component)
          }

          override fun getViewName(component: Fragment): String? {
              when (component) {
                  is LoginFragment -> "Login Fragment"
                  is HomeFragment -> "Home Fragment"
                  else -> "Default Fragment"
              }
          }
      }
    ))
    .build()

@marandaneto
Copy link
Member

Yep, that's exactly what I'd suggest

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

No branches or pull requests

4 participants