Open bidetofevil opened 6 months ago
It's worth adding a min. level configuration since not all levels are critical. Also, worth adding a deboucer since this can be super noisy. https://developer.android.com/topic/performance/memory
I think this is a great idea. Contributions for this are very much welcome!
I think this is a great idea as well! We can monitor when the app is running on low memory and identify the exact time when it happens.
However, I'm still not sure where to put this event in the context of OpenTelemetry Signals. We can put the low memory event as:
I'm leaning towards using a Span Event, since we can get the full picture of the app's events by looking at Spans in the Trace.
What do you guys think?
What signal is appropriate depends entirely on how sessions or being modelled in the app/library that is capturing the telemetry. For instance, in the Embrace SDK, this will be SpanEvent attached to the specific span we use to model a session, but this may not be appropriate for everyone.
The new Events
signal seems to make the most sense to me in the long term - certainly a semconv that is attached to an Event makes sense.
In the context of this project, @breedx-splk probably has the best insight as to how best to model it, either now or in the future.
Yeah, I agree with @bidetofevil that Events
will be the way to model this. One way to tell is that the title of this issue even has the word "event" in it, and we think about these low memory points as events. 😄
I believe the latest core java sdk release has the updated API that matches changes to the spec and semconv, and will allow rich objects in event payload bodies. Would be great to see what an implementation of these would look like, with respect to low memory.
Cool! I just found out that Events
support is already on development (Event API Interface, Semantic Convention for Events), thanks 🙌
One way to tell is that the title of this issue even has the word "event" in it, and we think about these low memory points as events. 😄
The new Events signal seems to make the most sense to me in the long term - certainly a semconv that is attached to an Event makes sense.
Agree that Events
is the most suitable signal for this kind of use case 👍
Android's ComponentCallback2 interface allows for the app to listen for OS-level memory events that tell the app the process is trying to recover memory. Surfacing these warnings/alerts (as Events?) could be useful as it could be an indication the app is running low on resources so performance could be hampered.