feat(collector/receiver): expose service.instance.id

[adamantal]

Description

The service.instance.id identifier is unique to a component (a Lambda execution), and it may have several advantages exposing this information:

• due to its manageable cardinality, it is a better candidate for indexing (as opposed to Lambda execution ids, that can be of much bigger magnitude)
• debugging caching issues across consecutive Lambda invocation on the same instance, as the opentelemetry-lambda's collector is persisted across executions

Testing

Tested live on a Lambda function, on top of #2011:

[wpessers]

I'm not entirely sure this change is really adding something new. There is already a faas.instance resource attribute which I believe should be handled by the aws resource detector (in language specific layers like node.js). This refers to the cloudwatch log stream id, so it has the same cardinality as your proposed service_instance_id.

[wpessers]

Upon closer inspection, it looks like this may only be supported in node.js and java

[wpessers]

So in my opinion, this feature is already solved in a different way. I believe otel already supports aws lambda resource detection for most languages, which should include the faas.instance. This uniquely identifies a lambda "container" through the log stream id. Some examples below:

• JS: https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/packages/resource-detector-aws/src/detectors/AwsLambdaDetector.ts#L72
• Python: https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/sdk-extension/opentelemetry-sdk-extension-aws/src/opentelemetry/sdk/extension/aws/resource/_lambda.py
• Java: https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/aws-resources/README.md
• Go: https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/detectors/aws/lambda

@tylerbenson @serkan-ozal any opinion on this?

[adamantal]

In our use case the (Python) Lambda code itself is not instrumented with opentelemetry, but the opentelemetry-collector-lambda is running alongside the execution (as a Lambda extension). The logs that we receive lack the attribute you referenced above.

This PR adds this ability to enrich the logs implemented at collector-side (so we don't have to instrument the Python code just to collect the logs that would otherwise be available through the Telemetry API anyways).

[adamantal]

I'll take a deeper look to the attributes using the debug exporter to see all metadata, I might have missed something

[serkan-ozal]

What I am unable to see here is that who puts AWS CloudWatch log stream id into the receiver.Settings as service instance it? cc @adamantal

[adamantal]

Sorry for the delay, I caught up with other issues.

To give you more information I managed to test this internally on a staging environment using a debug exporter. An extract of a sampled log record:

ResourceLog #0
Resource SchemaURL: 
Resource attributes:
     -> faas.invoked_provider: Str(aws)
     -> service.name: Str([REDACTED])
     -> faas.name: Str([REDACTED])
     -> service.instance.id: Str(4879ee99-4c85-4aee-a0f1-9c89989439df)
     -> faas.max_memory: Str(2048)
     -> faas.version: Str($LATEST)
     -> faas.invoked_region: Str(us-east-2)
ScopeLogs #0
ScopeLogs SchemaURL: 
InstrumentationScope github.com/open-telemetry/opentelemetry-lambda/collector/receiver/telemetryapi 
LogRecord #0
ObservedTimestamp: 2025-12-09 15:04:07.609211443 +0000 UTC
Timestamp: 2025-12-09 15:04:07.141 +0000 UTC
SeverityText: 
SeverityNumber: Unspecified(0)
Body: Str(REPORT RequestId: d1acf096-5d04-4a32-99b7-58a059aa69dc Duration: 163.18 ms Billed Duration: 164 ms Memory Size: 2048 MB Max Memory Used: 224 MB)
Attributes:
     -> faas.invocation_id: Str(d1acf096-5d04-4a32-99b7-58a059aa69dc)
     -> type: Str(platform.report)
Trace ID: 
Span ID: 
Flags: 0

As you can see above, there's a faas.invocation_id that connects logs belonging to the same invocation, but there's no id to connect invocations that belongs to the same execution environment. Hence the service.instance.id introduced by this PR.

Answering your question, the service.instance.id itself is generally not the same as the cloudwatch log stream id. The cloudwatch log stream is exposed to the Lambda execution through an environment variable which is not available for the collector, I don't see an easy way to match those two ids. My point is that we don't even need to do that, just link the consecutive Lambda executions within the same execution environment with any (arbitrary) unique id, where service.instance.id is sufficient for this purpose.