Introduce resource attribute faas.max_memory
#1296
Conversation
arminru
added
area:semantic-conventions
| - id: max_memory | ||
| type: number | ||
| brief: > | ||
| The amount of memory available to the serverless function in MB. |
There was a problem hiding this comment.
I think we should use bytes here. AWS probably uses MiB (1024 based) instead of MB (1000 based), but using bytes would avoid such confusion and may be more exact for other FaaS environments.
I think we also use bytes instead of a derived unit for all other byte-related attributes (like message size, HTTP body size).
Even if we decide to keep using Mega- then I would prefer writing MiB as it is more clear that it is 1024-based (even though that is expected anyway for everything but filesystem/storage related stuff).
There was a problem hiding this comment.
Bytes is the wrong granularity here.
The suggestion to use MiB is legit though. I changed that in b3669dc
There was a problem hiding this comment.
Probably bytes is unusual as something shown/configured in the UI. But MiB is also somewhat arbitrary. Maybe some other FaaS provider will let you configure the memory in KiB? Or it only let's you configure MiB but the API to query the max memory returns bytes.
I would be happy if we just used the unit B (bytes) for all memory-related stuff, instead of mixing GiB, MiB, KiB, B, MB, KB, GB. IMHO these derived units are better used only for display purposes.
There was a problem hiding this comment.
It's not arbitrary but the most reasonable unit here. It's the lowest resolution needed regarding this metric.
The other example listed (request/response size, ...) actually have byte granularity, this does not.
There was a problem hiding this comment.
It's the lowest resolution needed regarding this metric.
If we call it aws_lambda.max_memory, then yes. And I agree that it is unlikely we will come across another FaaS provider that provides finer granularity (it would not make sense).
Still, this will the first attribute we introduce with MB/MiB as unit.
There was a problem hiding this comment.
Still no good reason not to use it in this case IMHO. Having different units based on the use case is quite common.
There was a problem hiding this comment.
FYI: #1307 (comment) suggests to always use the smallest practical unit.
|
Just a general question mostly for other spec approvers - I think container can also have |
|
@anuraaga I was thinking about this too. But I could e.g. imagine that faas.max_memory for a container-based AWS lambda might be different from what we would detect as container.max_memory. E.g. a FaaS implementation might allow short memory surges if the host has enough memory free. Or it might use a process limit instead of a container limit. I think there is merit in having an attribute that is (more or less) defined to show what was configured as "Max Memory" for the Lambda. |
|
Merging as a) It seems an non-polemical addition and b) The PR has enough reviews and it has been waiting the whole break to get merged already. |
Fixes #
Changes
This PR introduces the new attribute
max_memoryto thefaasresource attributes. Maximum memory allocated to a serverless function is a useful metric since e.g. too little memory can easily stop a Java AWS Lambda function from working correctly.