open-telemetry / open-telemetry/opentelemetry-python-contrib
[boto3sqs] When used together with botocore instrumentation two spans for the same SQS operation are created
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.1k
- Forks
- 1.1k
- Avg merge
- 4d 15h
- Merged PRs (30d)
- 16
Description
When using the boto3sqs and botocore instrumentations together two similar spans for the same SQS operation are created.
Steps to reproduce
Have boto3sqs and botocore instrumentation active at the same timle, like in the snippet below:
import boto3
from opentelemetry.instrumentation.botocore import BotocoreInstrumentor
from opentelemetry.instrumentation.boto3sqs import Boto3SQSInstrumentor
# ... setup span processor, exporter, ...
BotocoreInstrumentor().instrument()
Boto3SQSInstrumentor().instrument()
client = boto3.client("sqs")
client.send_message(QueueUrl="<queue>", MessageBody="msg")
, or simply add the botocore instrumentor (BotocoreInstrumentor().instrument()) to one of the boto3sqs tests.
What is the expected behavior?
Only one span is produced for SQS operations like send_message, receive_message, ...
What is the actual behavior?
Separate but similar span are created for the SQS operations that are instrumented commonly by both instrumentations.
E.g. when calling the boto3 sqs.send_message API there will be one span produced by theBoto3SQSInstrumentor and another one by the BotocoreInstrumentor.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by adding BotocoreInstrumentor().instrument() to one of the boto3sqs tests and reproduce the duplicate spans for send_message or another shared SQS operation. Trace the boto3sqs and botocore instrumentation entry points, then verify that each operation produces only one span.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, python
- Domain
- observability
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100