chore: updated mapping

[abhilash-sivan]

grpc
aws s3
azure storage
aws lambda
aws lambda invoke

revisitted messaging libs for gap filling

[aryamohanan]

I miss messaging.operation in v1.23 and messaging.operation.name in v1.41

[aryamohanan]

qs: Are we collecting rabbitmq.queue from our instrumentation?

[abhilash-sivan]

No, we are not. The purpose of adding some of these fields is that I thought even if we do not collect the data now, we can add this later because some of this was marked as mandatory in the RFD, so even if we keep this mapping here right now, the functionality won't be affected because we will clean up the undefined data.

from rfd:

rabbitmq.exchange + rabbitmq.key + rabbitmq.queue	messaging.destination.name

That said, with the more recent changes in mapping, we went with stricter checking of what our instrumentation produces and retained only the relevant mappings. Given that, this can be removed. Thanks!

[aryamohanan]

The purpose of adding some of these fields is that I thought even if we do not collect the data now, we can add this later because some of this was marked as mandatory in the RFD,

Please don't rely solely on the RFD. As you know, it isn't thoroughly reviewed or guaranteed to match every tracer, at least for us. It's better to validate the requirements against our instrumentation rather than assuming everything in the RFD is accurate.

[aryamohanan]

Where did you get this mapping key messaging.rabbitmq.message.routing_key

[abhilash-sivan]

This is a manual error; the actual key is messaging.rabbitmq.destination.routing_key

[aryamohanan]

Note: Type seems mandatory field but we only collect that in exit spans? I checked v3/sqs instrumentation. Please research and confirm.

The values we collected are "single.sync" or "batch.sync".

[abhilash-sivan]

In v2, also, we collect type

return cls.ns.runAndReturn(() => {
const span = cls.startSpan({
spanName: 'sqs',
kind: EXIT
});
span.ts = Date.now();
span.stack = tracingUtil.getStackTrace(instrumentedSendMessage);
span.data.sqs = {
sort: sortTypes.EXIT,
type: messageData.Entries ? callTypes.SEND_MESSAGE_BATCH : callTypes.SEND_MESSAGE,
group: messageData.MessageGroupId,
queue: originalArgs[0].QueueUrl || ''
};

here also we only collect "type" for exit spans.

But I don't think that impacts this mapping. We map everything here—if the field is present, we convert it; otherwise, we clean it up. Also, there is no type field in the resulting OpenTelemetry span. correct ?

[aryamohanan]

I'm bit confused: now https://opentelemetry.io/docs/specs/semconv/faas/aws-lambda/#sqs-message

• faas.trigger MUST be set to pubsub.
• messaging.operation.type MUST be set to process.
• messaging.system MUST be set to aws_sqs.

[aryamohanan]

I agree, may be we can remove the comment

[aryamohanan]

The purpose of adding some of these fields is that I thought even if we do not collect the data now, we can add this later because some of this was marked as mandatory in the RFD,

Please don't rely solely on the RFD. As you know, it isn't thoroughly reviewed or guaranteed to match every tracer, at least for us. It's better to validate the requirements against our instrumentation rather than assuming everything in the RFD is accurate.

[aryamohanan]

I'm bit confused: now https://opentelemetry.io/docs/specs/semconv/faas/aws-lambda/#sqs-message

• faas.trigger MUST be set to pubsub.
• messaging.operation.type MUST be set to process.
• messaging.system MUST be set to aws_sqs.

[aryamohanan]

server address and port is missing, we can get the value from connection

[aryamohanan]

We can also find server address and port from url

[aryamohanan]

'rpc.call'?

[aryamohanan]

complex logic move to util.js