-
Notifications
You must be signed in to change notification settings - Fork 116
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
updated session.id and telemetry.sdk.elastic_export_timestamp #844
Conversation
specs/agents/mobile/README.md
Outdated
| [`device.manufacturer`](https://opentelemetry.io/docs/reference/specification/resource/semantic_conventions/device/) | `device.manufacturer` | `Apple`, `Samsung` | :x: no | This information is potentially not directly available on the device and needs to be derived / mapped from `device.model.identifier`. In this case, the APM server should do the mapping. | | ||
| [`process.runtime.name`](https://opentelemetry.io/docs/reference/specification/resource/semantic_conventions/process/#process-runtimes) | `service.runtime.name` | `Android Runtime` | :x: no | Use `Android Runtime` for Android. For iOS use `iOS`. | | ||
| [`process.runtime.version`](https://opentelemetry.io/docs/reference/specification/resource/semantic_conventions/process/#process-runtimes) | `service.runtime.version` | `2.0.1` | :x: no | Use the Dalvik version for Android (`System.getProperty("java.vm.version")`). For iOS use the version of iOS. | | ||
| `session.id` | `session.id` | `A73DC41E-DF18-4BB4-ABC0-F0000FD95653` | :x: no | | |
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.
Is the iOS agent setting session.id
in the OTel resources? Because at the moment the Android one is just adding it as a regular, dynamic attr.
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.
No, I'm not, but for lack of a better place for this attribute, I threw it in this table. It's probably more appropriate from a categorization perspective to put it in it's own table, but I'm not sure if there's a term in open-telemetry for a non-resource attribute that applies to all signals.
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.
Oh! Got it, makes sense. I just wanted to double-check because it was a bit confusing to see it under the resource attrs, though I see what you mean, it's not clear what table it should go to.
CODEOWNERS
)To auto-merge the PR, add
/
schedule YYYY-MM-DD
to the PR description./schedule 2023-12-15