Mobile metric spec

[bryce-b]

trafficstars

• [x] Create PR as draft
• [x] Approval by at least one other agent
• [x] Mark as Ready for Review (automatically requests reviews from all agents and PM via CODEOWNERS)
  • Remove PM from reviewers if impact on product is negligible
  • Remove agents from reviewers if the change is not relevant for them
• [ ] Merge after 2 business days passed without objections
  To auto-merge the PR, add /schedule 2022-09-10 to the PR description.

/schedule 2022-09-10

[apmmachine]

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-11-04T04:35:00.098+0000

• Duration: 3 min 1 sec

[bryce-b]

I did some testing on charting and refactored the application launch time metrics so they are more friendly to charting.

[bryce-b]

I decided to continue using the terminology provided by the Apple sdk, we can add additional ones that make sense for android.

[LikeTheSalad]

I decided to continue using the terminology provided by the Apple sdk, we can add additional ones that make sense for android.

That's ok, probably there's a way we can fit things as Apple does but might have different names in Android, so maybe we could map stuff or come up with generic names that could work for both, it's just that I'm still in an early stage with the Android agent compared to iOS so I haven't gotten here yet 😅 - I think that, if there's no problem with changing the terminology later on iOS (should it ever need to happen), then it's fine to leave it as is for now and we should continue to define it once I can fully dive into the Android metrics.

[bryce-b]

I don't think it's a good idea to replace concrete terms used on a specific platform with generic cross platform terms. There are subtleties in the terminology, and if we use platform terms e.g.: optimized time to first draw people familiar with the platform know exactly what that is, vs warm which means they will have to look up our documentation to know what that means, which will be different on android vs iOS.

[LikeTheSalad]

I don't think it's a good idea to replace concrete terms used on a specific platform with generic cross platform terms. There are subtleties in the terminology, and if we use platform terms e.g.: optimized time to first draw people familiar with the platform know exactly what that is, vs warm which means they will have to look up our documentation to know what that means, which will be different on android vs iOS.

That's fair enough, so I guess then we should mention somewhere on this doc that said terms are iOS specific, and then I would add the Android specific ones separately later on

[AlexanderWert]

I don't think it's a good idea to replace concrete terms used on a specific platform with generic cross platform terms. There are subtleties in the terminology, and if we use platform terms e.g.: optimized time to first draw people familiar with the platform know exactly what that is, vs warm which means they will have to look up our documentation to know what that means, which will be different on android vs iOS.

If we decide to keep device-type-specific terms (iOS vs. Android) , we should do one of the following (otherwise it will be very difficult to handle the metrics later in the UI):

• in case it is a technology-specific metric, we should denote it with an explicit namespace (e.g. ios.mymetric or android.anothermetric). OpenTelemetry is doing the same for technologies (see example for Cassandra DB)
• if there is a common metric between iOS and Android (e.g. launchTime) BUT some of the categorization labels / fields are different (e.g. values for type on application.launch.time is different between iOS and Android) then we need
  • EITHER: an additional field / label on the metric that denotes the device-type (i.e. ios or android). This would allow to handle the label values more explicit
  • OR: prefix the values with the device-type (e.g. ios/foreground, android/warm)

Thoughts on this?

[LikeTheSalad]

I like the idea to use android.* and ios.* for device specific metrics, and in regards to common metrics with different types of values I think it'd be better to define an additional field/label for the device type because I believe it'd be more practical for making queries later on, e.g. if our users want to create a dashboard for iOS only for example, I guess it'd be easier to filter those by a field rather than by a value pattern

[AlexanderWert]

and in regards to common metrics with different types of values I think it'd be better to define an additional field/label for the device type (ios vs android)

OK, depending on how the APM Server is / will handle those metrics, this information might be added already by the APM server from the agent metadata (i.e. agent-name). @axw correct me if I'm wrong!

[axw]

OK, depending on how the APM Server is / will handle those metrics, this information might be added already by the APM server from the agent metadata (i.e. agent-name). @axw correct me if I'm wrong!

Yep, it should already be possible to filter by agent.name or os.type.