- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- Administrator's Guide
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
",t};e.buildCustomizationMenuUi=t;function n(e){let t='
",t}function s(e){let n=e.filter.currentValue||e.filter.defaultValue,t='${e.filter.label}
`,e.filter.options.forEach(s=>{let o=s.id===n;t+=``}),t+="${e.filter.label}
`,t+=`Datadog Database Monitoring (DBM) correlates backend traces from your OpenTelemetry-instrumented application with detailed database performance data. This allows you to link spans from your application to related query metrics and execution plans, helping you identify the exact queries that are slowing down your services.
Before you begin, ensure you have configured unified service tagging. This is required for all data correlation in Datadog.
To correlate traces and metrics, you must:
Instrument database spans: Add specific OpenTelemetry attributes to your database spans to enable correlation with DBM.
Configure trace ingestion path: Enable the correct feature gate on your Collector or Agent to ensure database spans are properly processed for DBM.
For DBM correlation to work, your database spans must include the following attributes.
Attribute | Required? | Description | Example |
---|---|---|---|
db.system | Yes | The database technology. | postgres , mysql , sqlserver |
db.statement | Yes | The raw SQL query text. Datadog uses this to set the span’s resource name after obfuscation and normalization. | SELECT * FROM users WHERE id = ? |
span.type | Yes | (Datadog-specific) Identifies and processes database spans. Usually derived automatically by the OpenTelemetry SDK or Datadog Agent. Only set manually when spans are created directly with the SDK. | sql , postgres , mysql , sql.query |
db.name | No | The logical database or schema name being queried. | user_accounts |
span.type
attribute is a Datadog-specific convention for identifying and processing database spans.
When using OpenTelemetry auto-instrumentation or the Datadog Agent, this attribute is set automatically.
Only add it manually if you are instrumenting spans directly with the SDK.To get started, instrument your application using the appropriate OpenTelemetry auto-instrumentation library for your language. For setup instructions, see the official OpenTelemetry instrumentation documentation.
These libraries automatically add the required db.system
and db.statement
attributes. The Datadog Agent or SDK then derives span.type
automatically, so no manual attribute configuration is needed.
If your environment involves a custom database client or spans not recognized by the library, you can enrich them using the OpenTelemetry Collector’s attributes
processor.
For example, you can add span.type: sql
to any span that has the db.system
attribute:
processors:
attributes/add_span_type:
actions:
- key: span.type
value: "sql"
action: insert
# Apply this action only to spans that have the db.system attribute
from_context: span
when:
- span.attributes["db.system"] != nil
service:
pipelines:
traces:
# Add the processor to your traces pipeline
processors: [..., attributes/add_span_type, ...]
If you are manually creating spans with the OpenTelemetry SDK, you can set the attributes directly in your code. For more information, see the OpenTelemetry documentation.
The following is a conceptual example of manual instrumentation using Python’s OpenTelemetry SDK:
from opentelemetry import trace
tracer = trace.get_tracer("my-app.instrumentation")
# When making a database call, create a span and set attributes
with tracer.start_as_current_span("postgres.query") as span:
# Set attributes required for DBM correlation
span.set_attribute("span.type", "sql")
span.set_attribute("db.system", "postgres")
span.set_attribute("db.statement", "SELECT * FROM users WHERE id = ?")
span.set_attribute("db.name", "user_accounts")
# Your actual database call would go here
# db_cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
Depending on how you send traces to Datadog, you may need to enable specific feature gates to ensure database spans are processed correctly.
If you are using the Datadog Helm chart (v3.107.0 or later), set the feature gate in your values.yaml
:
datadog:
otelCollector:
featureGates: "datadog.EnableReceiveResourceSpansV2,datadog.EnableOperationAndResourceNameV2"
When starting the Collector, you must enable the correct feature gate for your version.
For recent versions of the Collector, enable the datadog.EnableOperationAndResourceNameV2
feature gate:
otelcontribcol --config=config.yaml \
--feature-gates=datadog.EnableOperationAndResourceNameV2
For older versions of the Collector, both of the following feature gates are required:
otelcontribcol --config=config.yaml \
--feature-gates=datadog.EnableReceiveResourceSpansV2,datadog.EnableOperationAndResourceNameV2
In your Datadog Agent configuration, ensure the DD_APM_FEATURES
environment variable includes enable_operation_and_resource_name_logic_v2
.
After your application is sending traces, you can see the correlation in the APM Trace View:
span.type: sql
)If you don’t see the expected correlation between your APM traces and DBM, it’s typically due to a missing or incorrect configuration. Check the following common causes:
db.system
and db.statement
. The span.type
attribute is also required but is typically derived automatically by Datadog.service
tag on your traces must match the service
tag on your database host metrics. Verify that unified service tagging is configured correctly.db.statement
attribute. If the query uses non-standard or complex syntax, parsing may fail. If you suspect this is the case, contact Datadog support for assistance.추가 유용한 문서, 링크 및 기사: