Memory Info allocated bytes name is unclear

[KnapSac]

Problem Statement

Events contain an additional MemoryInfo context. This is useful, but especially the Allocated bytes name is a bit unclear. It's actually the total allocated bytes over the lifetime of the process, not the currently allocated bytes (which is represented by Heap Size Bytes).

sentry-dotnet/src/Sentry/Internal/MainSentryEventProcessor.cs

Line 166 in 0e11682

var allocatedBytes = GC.GetTotalAllocatedBytes();

If the process has been running for some time this becomes obvious, because we don't have machines with that much memory. But after startup this is not immediately obvious.

Solution Brainstorm

I'd suggest renaming Allocated Bytes to Total Allocated Bytes and maybe Heap Size Bytes to Currently Allocated Bytes.

Additionally, it would be nice if there was a way to provide some additional information about what these values represent. E.g. linking to the documentation. However, I don't know if the UI supports that.

[Flash0ver]

Thank you @KnapSac for your suggested improvement.

I like the rename from/to

-Allocated Bytes
+Total Allocated Bytes

as it mirrors the name from the .NET BCL.

re: Docs
Perhaps we can clarify the values in our Sentry .NET SDK documentation, with a link to the Microsoft documentation.

Questions to the team:

• Is "Memory Info" a general concept across the Sentry SDKs?
• Or is this something "local" to some Sentry SDKs?

"Contexts", such as "Memory Info", are not search-able / filter-able / indexed, right?
So changing the Key of a Value should not be a breaking change ... or am I mixing something up?

[bruno-garcia]

Is "Memory Info" a general concept across the Sentry SDKs?

Some SDKs have some memory info but this is done for .NET using the .NET's API data so not something "unified across SDKs"

"Contexts", such as "Memory Info", are not search-able / filter-able / indexed, right?

By default its not. But some context are treated differently at ingestion time and indexed. Such as os.name for example.

So changing the Key of a Value should not be a breaking change ... or am I mixing something up?

Yes. it's safe to change

[bruno-garcia]

Literally came u internally last week:

[KnapSac]

Perhaps we can clarify the values in our Sentry .NET SDK documentation, with a link to the Microsoft documentation.

That would be helpful, and save others from having to look through the source code to find out what these values mean.

It would probably make sense to add documentation for the Thread Pool Info context as well, which is .NET specific.