DSM Queue tab CloudWatch metrics empty: eventSourceARN used as queue identifier instead of short name

未關閉 適合新手
#755 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
2/5
預估耗時
1-3 小時
新手友好度
76/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
冷清
技術堆疊
aws, python

研究方向

從 datadog_lambda/tracing.py 的 _dsm_set_checkpoint() 開始,接著比較 ddtrace/internal/datastreams/botocore.py 中的佇列名稱處理方式,尤其是 get_queue_name() 和 SQS checkpoint 的呼叫端。完成標準是 Lambda DSM checkpoint 使用 CloudWatch 整合所預期的佇列識別碼格式,讓 Queue 分頁查詢與 SQS 指標標籤相符。

由索引模型根據 Issue 內容生成。

描述

Description

The DSM (Data Streams Monitoring) Queue tab shows empty CloudWatch metric graphs for SQS queues consumed by Lambda functions. The root cause is a mismatch between how datadog-lambda-python identifies queues in DSM checkpoints vs how the AWS CloudWatch integration tags SQS metrics.

Root Cause

In datadog_lambda/tracing.py, _dsm_set_checkpoint() passes the full eventSourceARN to set_consume_checkpoint():

# tracing.py line ~262
source_arn = first_record.get("eventSourceARN", "")
# ...
_dsm_set_checkpoint(context_json, event_type, source_arn)  # full ARN

This results in a DSM checkpoint with:

topic:arn:aws:sqs:eu-west-2:123456789012:my-queue.fifo

The DSM Queue tab then uses this full ARN value to construct CloudWatch metric queries:

sum:aws.sqs.number_of_messages_received{queuename:arn:aws:sqs:eu-west-2:123456789012:my-queue.fifo}

But the AWS CloudWatch integration tags SQS metrics with just the short queue name (from the CloudWatch QueueName dimension):

queuename:my-queue.fifo

Result: the query returns no data, and all Queue tab graphs are empty.

Comparison with botocore SDK path

The botocore instrumentation in dd-trace-py correctly extracts the short name:

# ddtrace/internal/datastreams/botocore.py
def get_queue_name(params):
    queue_url = params["QueueUrl"]
    url = parse.urlparse(queue_url)
    return url.path.rsplit("/", 1)[-1]  # returns "my-queue.fifo"

Both handle_sqs_sns_produce() and handle_sqs_receive() use this short name as the DSM topic: tag. When SQS messages are consumed by a long-running process polling with sqs.receive_message(), the botocore instrumentation handles the DSM checkpoint and the Queue tab works correctly. The bug is specific to Lambda functions triggered by SQS event source mappings, where datadog-lambda-python handles the checkpoint instead.

Expected Behavior

_dsm_set_checkpoint() should extract the short queue name from the ARN before passing it to set_consume_checkpoint(), e.g.:

queue_name = source_arn.rsplit(":", 1)[-1]  # "my-queue.fifo"
set_consume_checkpoint(event_type, queue_name, carrier_get, manual_checkpoint=False)

This would align the Lambda consumption path with the botocore SDK path, and the DSM Queue tab CloudWatch queries would match the actual queuename tag values.

Workaround

Users can manually change the metric filter from queuename to dd_resource_key (which contains the full ARN) to see data. But this must be done for each graph individually and doesn't persist.

Environment

  • datadog-lambda v8.123.0
  • dd-trace-py v4.6.0
  • Lambda Extension v92-next
  • Python 3.14
  • SQS FIFO queue consumed via Lambda event source mapping
  • AWS region: eu-west-2
主要語言
Python
星號
102
分支
52
平均合併
5 天 19 小時
30 天內合併 PR
2

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

DataDog/datadog-lambda-python 的其他 Issue

查看 DataDog/datadog-lambda-python 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。