AWS Lambda spec #470
AWS Lambda spec #470
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
|
Co-authored-by: Colton Myers <colton.myers@gmail.com>
Co-authored-by: Colton Myers <colton.myers@gmail.com>
|
Should the lambda/FaaS spec mention things that agents should not do by default that they typically would do:
|
There was a problem hiding this comment.
Just a few comments so far, and I haven't read it all in depth. I'm wondering if we can generalise some of these things and limit the faas.* fields to truly faas-specific things like "coldstart". Lambda isn't the only thing you can have behind API Gateway, so it seems wrong to record information about API Gateway under faas.*. Similarly for triggering account ID -- are these just "user IDs"?
AlexanderWert
force-pushed
the
lambda-spec
branch
from
929ca42
to
38fd169
Compare
Co-authored-by: Emily S <emily.s@elastic.co>
Co-authored-by: Emily S <emily.s@elastic.co>
| ### Overwriting Metadata | ||
| Automatically capturing cloud metadata doesn't work reliably from a Lambda environment. Moreover, retrieving cloud metadata through an additional HTTP request may slowdown the lambda function / increase cold start behaviour. Therefore, the generic cloud metadata fetching should be disabled when the agent is running in a lambda context (for instance through checking for the existance of the `AWS_LAMBDA_FUNCTION_NAME` environment variable). | ||
| Where possible, metadata should be overwritten at Lambda runtime startup corresponding to the field specifications in this spec. | ||
| Some metadata fields are not available at startup (e.g. `invokedFunctionArn`). In this case corresponding fields need to be set either as metadata with the first invocation of the lambda function or set for every lambda invocation as transaction fields. |
There was a problem hiding this comment.
I'm a little unclear on whether some of these fields need to be set on the metadata only, the transaction only, if the intention is that all these fields will eventually be added to both the metadata and transaction objects, or if we're meant to pick where a field goes from context that up from context.
Using the current APM Server schemas as a guide, we have
Fields that don't exist on either the metadata or the transaction
| Prop | Current Metadata | Current Transaction |
|---|---|---|
| cloud.origin.account.id | NO | NO |
| cloud.origin.provider | NO | NO |
| cloud.origin.region | NO | NO |
| cloud.origin.service.name | NO | NO |
| faas.coldstart | NO | NO |
| faas.execution | NO | NO |
| faas.trigger.reuqest_id | NO | NO |
| faas.trigger.type | NO | NO |
| service.node.name | NO | NO |
| service.id | NO | NO |
| service.origin | NO | NO |
| service.origin.id | NO | NO |
| service.origin.name | NO | NO |
| service.origin.version | NO | NO |
Fields that are metadata only
| Prop | Current Metadata | Current Transaction |
|---|---|---|
| cloud.provider | YES | NO |
| cloud.region | YES | NO |
| cloud.service.name | YES | NO |
Fields that are transaction only
| Prop | Current Metadata | Current Transaction |
|---|---|---|
| transaction.name | NO | YES |
| transaction.type | NO | YES |
| message.age | NO | YES |
| message.body | NO | YES |
| message.headers | NO | YES |
| message.queue | NO | YES |
and fields that exist on both the metadata and the transaction
| Prop | Current Metadata | Current Transaction |
|---|---|---|
| service.framework.name | YES | YES |
| service.name | YES | YES |
| service.runtime.name | YES | YES |
| service.version | YES | YES |
There was a problem hiding this comment.
Fields that don't exist on either the metadata or the transaction
Fields that are not operation-specific belong in metadata.
service.node.name
This is called service.node.configured_name in the intake API; it is recorded as service.node.name in Elasticsearch docs.
service.id
This should be added to metadata.
I think everything else you listed should be transaction-only.
No description provided.