- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
See compatibility requirements for information about what ASM features are available for serverless functions.
Configuring ASM for AWS Lambda involves:
The Datadog Serverless Framework plugin can be used to automatically configure and deploy your lambda with ASM.
To install and configure the Datadog Serverless Framework plugin:
Install the Datadog Serverless Framework plugin:
serverless plugin install --name serverless-plugin-datadog
Enable ASM by updating your serverless.yml
with the enableASM
configuration parameter:
custom:
datadog:
enableASM: true
Overall, your new serverless.yml
file should contain at least:
custom:
datadog:
apiKeySecretArn: "{Datadog_API_Key_Secret_ARN}" # or apiKey
enableDDTracing: true
enableASM: true
See also the complete list of plugin parameters to further configure your lambda settings.
Redeploy the function and invoke it. After a few minutes, it appears in ASM views.
The Datadog CLI modifies existing Lambda function configurations to enable instrumentation without requiring a new deployment. It is the quickest way to get started with Datadog’s serverless monitoring.
If you are configuring initial tracing for your functions, perform the following steps:
Install the Datadog CLI client:
npm install -g @datadog/datadog-ci
If you are new to Datadog serverless monitoring, launch the Datadog CLI in interactive mode to guide your first installation for a quick start, and you can ignore the remaining steps. To permanently install Datadog for your production applications, skip this step and follow the remaining ones to run the Datadog CLI command in your CI/CD pipelines after your normal deployment.
datadog-ci lambda instrument -i --appsec
Configure the AWS credentials:
Datadog CLI requires access to the AWS Lambda service, and depends on the AWS JavaScript SDK to resolve the credentials. Ensure your AWS credentials are configured using the same method you would use when invoking the AWS CLI.
Configure the Datadog site:
export DATADOG_SITE="<DATADOG_SITE>"
Replace <DATADOG_SITE>
with (ensure the correct Datadog site is selected on the right-hand side of this page).
Configure the Datadog API key:
Datadog recommends saving the Datadog API key in AWS Secrets Manager for security. The key needs to be stored as a plaintext string (not a JSON blob). Ensure your Lambda functions have the required secretsmanager:GetSecretValue
IAM permission.
export DATADOG_API_KEY_SECRET_ARN="<DATADOG_API_KEY_SECRET_ARN>"
For testing purposes, you can also set the Datadog API key in plaintext:
export DATADOG_API_KEY="<DATADOG_API_KEY>"
Instrument your Lambda functions:
To instrument your Lambda functions, run the following command.
datadog-ci lambda instrument --appsec -f <functionname> -f <another_functionname> -r <aws_region> -v 101 -e 65
To fill in the placeholders:
<functionname>
and <another_functionname>
with your Lambda function names.--functions-regex
to automatically instrument multiple functions whose names match the given regular expression.<aws_region>
with the AWS region name.Note: Instrument your Lambda functions in a development or staging environment first. If the instrumentation result is unsatisfactory, run uninstrument
with the same arguments to revert the changes.
Additional parameters can be found in the CLI documentation.
The Datadog CDK Construct automatically installs Datadog on your functions using Lambda Layers, and configures your functions to send metrics, traces, and logs to Datadog through the Datadog Lambda Extension.
Install the Datadog CDK constructs library:
# For AWS CDK v1
pip install datadog-cdk-constructs
# For AWS CDK v2
pip install datadog-cdk-constructs-v2
Instrument your Lambda functions
# For AWS CDK v1
from datadog_cdk_constructs import Datadog
# NOT SUPPORTED IN V1
# For AWS CDK v2
from datadog_cdk_constructs_v2 import Datadog
datadog = Datadog(self, "Datadog",
python_layer_version=101,
extension_layer_version=65,
site="<DATADOG_SITE>",
api_key_secret_arn="<DATADOG_API_KEY_SECRET_ARN>", // or api_key
enable_asm=True,
)
datadog.add_lambda_functions([<LAMBDA_FUNCTIONS>])
To fill in the placeholders:
<DATADOG_SITE>
with
(ensure the correct SITE is selected on the right).<DATADOG_API_KEY_SECRET_ARN>
with the ARN of the AWS secret where your Datadog API key is securely stored. The key needs to be stored as a plaintext string (not a JSON blob). The secretsmanager:GetSecretValue
permission is required. For quick testing, you can use apiKey
instead and set the Datadog API key in plaintext.More information and additional parameters can be found on the Datadog CDK documentation.
Python
# Use this format for x86-based Lambda deployed in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>:101
# Use this format for arm64-based Lambda deployed in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>-ARM:101
# Use this format for x86-based Lambda deployed in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>:101
# Use this format for arm64-based Lambda deployed in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>-ARM:72
```
Replace `<AWS_REGION>` with a valid AWS region, such as `us-east-1`. The available `RUNTIME` options are `Python37`, `Python38` and `Python39`.
Node
# Use this format for AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>:115
# Use this format for AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>:115
```
Replace `<AWS_REGION>` with a valid AWS region such as `us-east-1`. The available RUNTIME options are `Node16-x`, `Node18-x`, `Node20-x`.
Java: Configure the layers for your Lambda function using the ARN in one of the following formats, depending on where your Lambda is deployed. Replace <AWS_REGION>
with a valid AWS region such as us-east-1
:
# In AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:dd-trace-java:15
# In AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-java:15
Go: The Go tracer doesn’t rely on a layer and is a regular Go module. You can upgrade to its latest version with:
go get -u github.com/DataDog/datadog-lambda-go
.NET: Configure the layers for your Lambda function using the ARN in one of the following formats, depending on where your Lambda is deployed. Replace <AWS_REGION>
with a valid AWS region such as us-east-1
:
# x86-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:dd-trace-dotnet:16
# arm64-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:dd-trace-dotnet-ARM:16
# x86-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-dotnet:16
# arm64-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-dotnet-ARM:16
<AWS_REGION>
with a valid AWS region such as us-east-1
:# x86-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-Extension:65
# arm64-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-Extension-ARM:65
# x86-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension:65
# arm64-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension-ARM:65
# Use this format for x86-based Lambda deployed in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>:101
# Use this format for arm64-based Lambda deployed in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>-ARM:101
# Use this format for x86-based Lambda deployed in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>:101
# Use this format for arm64-based Lambda deployed in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>-ARM:101
```
Replace `<AWS_REGION>` with a valid AWS region, such as `us-east-1`. The available `RUNTIME` options are `Python38`, `Python39`, `Python310`, `Python311`, `Python312`
.
Node
# Use this format for AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>:115
# Use this format for AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>:115
```
Replace `<AWS_REGION>` with a valid AWS region such as `us-east-1`. The available RUNTIME options are `Node16-x`, `Node18-x`, `Node20-x`.
Java: Configure the layers for your Lambda function using the ARN in one of the following formats, depending on where your Lambda is deployed. Replace <AWS_REGION>
with a valid AWS region such as us-east-1
:
# In AWS commercial regions
arn:aws:lambda:<AWS_REGION>:417141415827:layer:dd-trace-java:15
# In AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-java:15
Go: The Go tracer doesn’t rely on a layer and is a regular Go module. You can upgrade to its latest version with:
go get -u github.com/DataDog/datadog-lambda-go
.NET: Configure the layers for your Lambda function using the ARN in one of the following formats, depending on where your Lambda is deployed. Replace <AWS_REGION>
with a valid AWS region such as us-east-1
:
# x86-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:417141415827:layer:dd-trace-dotnet:16
# arm64-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:417141415827:layer:dd-trace-dotnet-ARM:16
# x86-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-dotnet:16
# arm64-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-dotnet-ARM:16
Install the Datadog Lambda Extension by configuring the layers for your Lambda function using the ARN in one of the following formats. Replace <AWS_REGION>
with a valid AWS region such as us-east-1
:
# x86-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:417141415827:layer:Datadog-Extension:65
# arm64-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:417141415827:layer:Datadog-Extension-ARM:65
# x86-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension:65
# arm64-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension-ARM:65
Enable ASM by adding the following environment variables on your function deployment:
environment:
AWS_LAMBDA_EXEC_WRAPPER: /opt/datadog_wrapper
DD_SERVERLESS_APPSEC_ENABLED: true
For Node and Python functions only, double-check that the function’s handler is set correctly:
/opt/nodejs/node_modules/datadog-lambda-js/handler.handler
.DD_LAMBDA_HANDLER
to your original handler, for example, myfunc.handler
.datadog_lambda.handler.handler
.DD_LAMBDA_HANDLER
to your original handler, for example, myfunc.handler
.Redeploy the function and invoke it. After a few minutes, it appears in ASM views.
serverless-init
worksThe serverless-init
application wraps your process and executes it as a subprocess. It starts a DogStatsD listener for metrics and a Trace Agent listener for traces. It collects logs by wrapping the stdout/stderr streams of your application. After bootstrapping, serverless-init
then launches your command as a subprocess.
To get full instrumentation, ensure you are calling datadog-init
as the first command that runs inside your Docker container. You can do this by setting it as the entrypoint, or by setting it as the first argument in CMD.
Add the following instructions and arguments to your Dockerfile.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
RUN npm install --prefix /dd_tracer/node dd-trace --save
ENV DD_SERVICE=datadog-demo-run-nodejs
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["/nodejs/bin/node", "/path/to/your/app.js"]
Copy the Datadog serverless-init
into your Docker image.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
Copy the Datadog Node.JS tracer into your Docker image.
RUN npm install --prefix /dd_tracer/node dd-trace --save
If you install the Datadog tracer library directly in your application, as outlined in the manual tracer instrumentation instructions, omit this step.
(Optional) Add Datadog tags.
ENV DD_SERVICE=datadog-demo-run-nodejs
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
Change the entrypoint to wrap your application in the Datadog serverless-init
process.
Note: If you already have an entrypoint defined inside your Dockerfile, see the alternative configuration.
ENTRYPOINT ["/app/datadog-init"]
Execute your binary application wrapped in the entrypoint. Adapt this line to your needs.
CMD ["/nodejs/bin/node", "/path/to/your/app.js"]
If you already have an entrypoint defined inside your Dockerfile, you can instead modify the CMD argument.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
RUN npm install --prefix /dd_tracer/node dd-trace --save
ENV DD_SERVICE=datadog-demo-run-nodejs
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
CMD ["/app/datadog-init", "/nodejs/bin/node", "/path/to/your/app.js"]
If you require your entrypoint to be instrumented as well, you can swap your entrypoint and CMD arguments instead. For more information, see How serverless-init
works.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
RUN npm install --prefix /dd_tracer/node dd-trace --save
ENV DD_SERVICE=datadog-demo-run-nodejs
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["/your_entrypoint.sh", "/nodejs/bin/node", "/path/to/your/app.js"]
As long as your command to run is passed as an argument to datadog-init
, you will receive full instrumentation.
Add the following instructions and arguments to your Dockerfile.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
RUN pip install --target /dd_tracer/python/ ddtrace
ENV DD_SERVICE=datadog-demo-run-python
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["/dd_tracer/python/bin/ddtrace-run", "python", "app.py"]
Copy the Datadog serverless-init
into your Docker image.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
Install the Datadog Python tracer.
RUN pip install --target /dd_tracer/python/ ddtrace
If you install the Datadog tracer library directly in your application, as outlined in the manual tracer instrumentation instructions, omit this step.
(Optional) Add Datadog tags.
ENV DD_SERVICE=datadog-demo-run-python
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
Change the entrypoint to wrap your application in the Datadog serverless-init
process.
Note: If you already have an entrypoint defined inside your Dockerfile, see the alternative configuration.
ENTRYPOINT ["/app/datadog-init"]
Execute your binary application wrapped in the entrypoint, launched by the Datadog trace library. Adapt this line to your needs.
CMD ["/dd_tracer/python/bin/ddtrace-run", "python", "app.py"]
If you already have an entrypoint defined inside your Dockerfile, you can instead modify the CMD argument.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
RUN pip install --target /dd_tracer/python/ ddtrace
ENV DD_SERVICE=datadog-demo-run-python
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
CMD ["/app/datadog-init", "/dd_tracer/python/bin/ddtrace-run", "python", "app.py"]
If you require your entrypoint to be instrumented as well, you can swap your entrypoint and CMD arguments instead. For more information, see How serverless-init
works.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
RUN pip install --target /dd_tracer/python/ ddtrace
ENV DD_SERVICE=datadog-demo-run-python
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["your_entrypoint.sh", "/dd_tracer/python/bin/ddtrace-run", "python", "app.py"]
As long as your command to run is passed as an argument to datadog-init
, you will receive full instrumentation.
Add the following instructions and arguments to your Dockerfile.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD 'https://dtdg.co/latest-java-tracer' /dd_tracer/java/dd-java-agent.jar
ENV DD_SERVICE=datadog-demo-run-java
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["./mvnw", "spring-boot:run"]
Copy the Datadog serverless-init
into your Docker image.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
Add the Datadog Java tracer to your Docker image.
ADD 'https://dtdg.co/latest-java-tracer' /dd_tracer/java/dd-java-agent.jar
If you install the Datadog tracer library directly in your application, as outlined in the manual tracer instrumentation instructions, omit this step.
(Optional) Add Datadog tags.
ENV DD_SERVICE=datadog-demo-run-java
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
Change the entrypoint to wrap your application in the Datadog serverless-init
process.
Note: If you already have an entrypoint defined inside your Dockerfile, see the alternative configuration.
ENTRYPOINT ["/app/datadog-init"]
Execute your binary application wrapped in the entrypoint. Adapt this line to your needs.
CMD ["./mvnw", "spring-boot:run"]
If you already have an entrypoint defined inside your Dockerfile, you can instead modify the CMD argument.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD 'https://dtdg.co/latest-java-tracer' /dd_tracer/java/dd-java-agent.jar
ENV DD_SERVICE=datadog-demo-run-java
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
CMD ["/app/datadog-init", "./mvnw", "spring-boot:run"]
If you require your entrypoint to be instrumented as well, you can swap your entrypoint and CMD arguments instead. For more information, see How serverless-init
works.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD 'https://dtdg.co/latest-java-tracer' /dd_tracer/java/dd-java-agent.jar
ENV DD_SERVICE=datadog-demo-run-java
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["your_entrypoint.sh", "./mvnw", "spring-boot:run"]
As long as your command to run is passed as an argument to datadog-init
, you will receive full instrumentation.
Manually install the Go tracer before you deploy your application. Compile your go binary with the “appsec” tag enabled (go build --tags "appsec" ...
). Add the following instructions and arguments to your Dockerfile:
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENTRYPOINT ["/app/datadog-init"]
ENV DD_SERVICE=datadog-demo-run-go
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
Copy the Datadog serverless-init
into your Docker image.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
Change the entrypoint to wrap your application in the Datadog serverless-init
process.
Note: If you already have an entrypoint defined inside your Dockerfile, see the alternative configuration.
ENTRYPOINT ["/app/datadog-init"]
(Optional) Add Datadog tags.
ENV DD_SERVICE=datadog-demo-run-go
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
Execute your binary application wrapped in the entrypoint. Adapt this line to your needs.
CMD ["/path/to/your-go-binary"]
If you already have an entrypoint defined inside your Dockerfile, you can instead modify the CMD argument.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENV DD_SERVICE=datadog-demo-run-go
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
CMD ["/app/datadog-init", "/path/to/your-go-binary"]
If you require your entrypoint to be instrumented as well, you can swap your entrypoint and CMD arguments instead. For more information, see How serverless-init
works.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENV DD_SERVICE=datadog-demo-run-go
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["your_entrypoint.sh", "/path/to/your-go-binary"]
As long as your command to run is passed as an argument to datadog-init
, you will receive full instrumentation.
Add the following instructions and arguments to your Dockerfile.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
# For arm64 use datadog-dotnet-apm-2.57.0.arm64.tar.gz
# For alpine use datadog-dotnet-apm-2.57.0-musl.tar.gz
ARG TRACER_VERSION
ADD https://github.com/DataDog/dd-trace-dotnet/releases/download/v${TRACER_VERSION}/datadog-dotnet-apm-${TRACER_VERSION}.tar.gz /tmp/datadog-dotnet-apm.tar.gz
RUN mkdir -p /dd_tracer/dotnet/ && tar -xzvf /tmp/datadog-dotnet-apm.tar.gz -C /dd_tracer/dotnet/ && rm /tmp/datadog-dotnet-apm.tar.gz
ENV DD_SERVICE=datadog-demo-run-dotnet
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["dotnet", "helloworld.dll"]
Copy the Datadog serverless-init
into your Docker image.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
Copy the Datadog .NET tracer into your Docker image.
# For arm64 use datadog-dotnet-apm-2.57.0.arm64.tar.gz
# For alpine use datadog-dotnet-apm-2.57.0-musl.tar.gz
ARG TRACER_VERSION
ADD https://github.com/DataDog/dd-trace-dotnet/releases/download/v${TRACER_VERSION}/datadog-dotnet-apm-${TRACER_VERSION}.tar.gz /tmp/datadog-dotnet-apm.tar.gz
RUN mkdir -p /dd_tracer/dotnet/ && tar -xzvf /tmp/datadog-dotnet-apm.tar.gz -C /dd_tracer/dotnet/ && rm /tmp/datadog-dotnet-apm.tar.gz
If you install the Datadog tracer library directly in your application, as outlined in the manual tracer instrumentation instructions, omit this step.
(Optional) Add Datadog tags.
ENV DD_SERVICE=datadog-demo-run-dotnet
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
Change the entrypoint to wrap your application in the Datadog serverless-init
process.
Note: If you already have an entrypoint defined inside your Dockerfile, see the alternative configuration.
ENTRYPOINT ["/app/datadog-init"]
Execute your binary application wrapped in the entrypoint. Adapt this line to your needs.
CMD ["dotnet", "helloworld.dll"]
If you already have an entrypoint defined inside your Dockerfile, you can instead modify the CMD argument.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
# For arm64 use datadog-dotnet-apm-2.57.0.arm64.tar.gz
# For alpine use datadog-dotnet-apm-2.57.0-musl.tar.gz
ARG TRACER_VERSION
ADD https://github.com/DataDog/dd-trace-dotnet/releases/download/v${TRACER_VERSION}/datadog-dotnet-apm-${TRACER_VERSION}.tar.gz /tmp/datadog-dotnet-apm.tar.gz
RUN mkdir -p /dd_tracer/dotnet/ && tar -xzvf /tmp/datadog-dotnet-apm.tar.gz -C /dd_tracer/dotnet/ && rm /tmp/datadog-dotnet-apm.tar.gz
ENV DD_SERVICE=datadog-demo-run-dotnet
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
CMD ["/app/datadog-init", "dotnet", "helloworld.dll"]
If you require your entrypoint to be instrumented as well, you can swap your entrypoint and CMD arguments instead. For more information, see How serverless-init
works.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
# For arm64 use datadog-dotnet-apm-2.57.0.arm64.tar.gz
# For alpine use datadog-dotnet-apm-2.57.0-musl.tar.gz
ARG TRACER_VERSION
ADD https://github.com/DataDog/dd-trace-dotnet/releases/download/v${TRACER_VERSION}/datadog-dotnet-apm-${TRACER_VERSION}.tar.gz /tmp/datadog-dotnet-apm.tar.gz
RUN mkdir -p /dd_tracer/dotnet/ && tar -xzvf /tmp/datadog-dotnet-apm.tar.gz -C /dd_tracer/dotnet/ && rm /tmp/datadog-dotnet-apm.tar.gz
ENV DD_SERVICE=datadog-demo-run-dotnet
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["your_entrypoint.sh", "dotnet", "helloworld.dll"]
As long as your command to run is passed as an argument to datadog-init
, you will receive full instrumentation.
Manually install the Ruby tracer before you deploy your application. See the example application.
Add the following instructions and arguments to your Dockerfile.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENV DD_SERVICE=datadog-demo-run-ruby
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENV DD_TRACE_PROPAGATION_STYLE=datadog
ENTRYPOINT ["/app/datadog-init"]
CMD ["rails", "server", "-b", "0.0.0.0"]
Copy the Datadog serverless-init
into your Docker image.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
(Optional) add Datadog tags
ENV DD_SERVICE=datadog-demo-run-ruby
ENV DD_ENV=datadog-demo
ENV DD_APPSEC_ENABLED=1
ENV DD_VERSION=1
This environment variable is needed for trace propagation to work properly in Cloud Run. Ensure that you set this variable for all Datadog-instrumented downstream services.
ENV DD_TRACE_PROPAGATION_STYLE=datadog
Change the entrypoint to wrap your application in the Datadog serverless-init
process.
Note: If you already have an entrypoint defined inside your Dockerfile, see the alternative configuration.
ENTRYPOINT ["/app/datadog-init"]
Execute your binary application wrapped in the entrypoint. Adapt this line to your needs.
CMD ["rails", "server", "-b", "0.0.0.0"]
If you already have an entrypoint defined inside your Dockerfile, you can instead modify the CMD argument.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENV DD_SERVICE=datadog-demo-run-ruby
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENV DD_TRACE_PROPAGATION_STYLE=datadog
CMD ["/app/datadog-init", "rails", "server", "-b", "0.0.0.0"]
If you require your entrypoint to be instrumented as well, you can swap your entrypoint and CMD arguments instead. For more information, see How serverless-init
works.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENV DD_SERVICE=datadog-demo-run-ruby
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENV DD_TRACE_PROPAGATION_STYLE=datadog
ENTRYPOINT ["/app/datadog-init"]
CMD ["your_entrypoint.sh", "rails", "server", "-b", "0.0.0.0"]
As long as your command to run is passed as an argument to datadog-init
, you will receive full instrumentation.
Add the following instructions and arguments to your Dockerfile.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php /datadog-setup.php
RUN php /datadog-setup.php --php-bin=all
ENV DD_SERVICE=datadog-demo-run-php
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENTRYPOINT ["/app/datadog-init"]
# use the following for an Apache and mod_php based image
RUN sed -i "s/Listen 80/Listen 8080/" /etc/apache2/ports.conf
EXPOSE 8080
CMD ["apache2-foreground"]
# use the following for an Nginx and php-fpm based image
RUN ln -sf /dev/stdout /var/log/nginx/access.log && ln -sf /dev/stderr /var/log/nginx/error.log
EXPOSE 8080
CMD php-fpm; nginx -g daemon off;
Note: The datadog-init
entrypoint wraps your process and collects logs from it. To get logs working properly, ensure that your Apache, Nginx, or PHP processes are writing output to stdout
.
Copy the Datadog serverless-init
into your Docker image.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
Copy and install the Datadog PHP tracer.
ADD https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php /datadog-setup.php
RUN php /datadog-setup.php --php-bin=all
If you install the Datadog tracer library directly in your application, as outlined in the manual tracer instrumentation instructions, omit this step.
(Optional) Add Datadog tags.
ENV DD_SERVICE=datadog-demo-run-php
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
Change the entrypoint to wrap your application in the Datadog serverless-init
process.
Note: If you already have an entrypoint defined inside your Dockerfile, see the alternative configuration.
ENTRYPOINT ["/app/datadog-init"]
Execute your application.
Use the following for an Apache and mod_php based image:
RUN sed -i "s/Listen 80/Listen 8080/" /etc/apache2/ports.conf
EXPOSE 8080
CMD ["apache2-foreground"]
Use the following for an Nginx and php-fpm based image:
RUN ln -sf /dev/stdout /var/log/nginx/access.log && ln -sf /dev/stderr /var/log/nginx/error.log
EXPOSE 8080
CMD php-fpm; nginx -g daemon off;
If you already have an entrypoint defined inside your Dockerfile, and you are using an Apache and mod_php based image, you can instead modify the CMD argument.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php /datadog-setup.php
RUN php /datadog-setup.php --php-bin=all
ENV DD_SERVICE=datadog-demo-run-php
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
RUN sed -i "s/Listen 80/Listen 8080/" /etc/apache2/ports.conf
EXPOSE 8080
CMD ["/app/datadog-init", "apache2-foreground"]
If you require your entrypoint to be instrumented as well, you can swap your entrypoint and CMD arguments instead. For more information, see How serverless-init
works.
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php /datadog-setup.php
RUN php /datadog-setup.php --php-bin=all
ENV DD_SERVICE=datadog-demo-run-php
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENTRYPOINT ["/app/datadog-init"]
# use the following for an Apache and mod_php based image
RUN sed -i "s/Listen 80/Listen 8080/" /etc/apache2/ports.conf
EXPOSE 8080
CMD ["your_entrypoint.sh", "apache2-foreground"]
# use the following for an Nginx and php-fpm based image
RUN ln -sf /dev/stdout /var/log/nginx/access.log && ln -sf /dev/stderr /var/log/nginx/error.log
EXPOSE 8080
CMD your_entrypoint.sh php-fpm; your_entrypoint.sh nginx -g daemon off;
As long as your command to run is passed as an argument to datadog-init
, you will receive full instrumentation.
To enable ASM on your application, begin by adding the following key-value pairs under Application Settings in your Azure configuration settings.
DD_API_KEY
is your Datadog API key.DD_CUSTOM_METRICS_ENABLED
(optional) enables custom metrics.DD_SITE
is the Datadog site parameter. Your site is
. This value defaults to datadoghq.com
.DD_SERVICE
is the service name used for this program. Defaults to the name field value in package.json
.DD_START_APP
is the command used to start your application. For example, node ./bin/www
(unnecessary for applications running in Tomcat).DD_APPSEC_ENABLED
value should be 1 in order to enable Application SecurityLinux Azure App Service Web Apps built using the code deployment option on built-in runtimes depend on a startup command that varies by language. The default values are outlined in Azure’s documentation. Examples are included below.
Set these values in the DD_START_APP
environment variable. Examples below are for an application named datadog-demo
, where relevant.
Runtime | DD_START_APP Example Value | Description |
---|---|---|
Node.js | node ./bin/www | Runs the Node PM2 configuration file, or your script file. |
.NET Core | dotnet datadog-demo.dll | Runs a .dll file that uses your Web App name by default.Note: The .dll file name in the command should match the file name of your .dll file. In certain cases, this might not match your Web App. |
PHP | cp /home/site/wwwroot/default /etc/nginx/sites-available/default && service nginx reload | Copies script to correct location and starts application. |
Python | gunicorn --bind=0.0.0.0 --timeout 600 quickstartproject.wsgi | Custom startup script. This example shows a Gunicorn command for starting a Django app. |
Java | java -jar /home/site/wwwroot/datadog-demo.jar | The command to start your app. This is not required for applications running in Tomcat. |
Note: The application restarts when new settings are saved.
Go to General settings and add the following to the Startup Command field:
curl -s https://raw.githubusercontent.com/DataDog/datadog-aas-linux/v1.4.0/datadog_wrapper | bash
Download the datadog_wrapper
file from the releases and upload it to your application with the Azure CLI command:
az webapp deploy --resource-group <group-name> --name <app-name> --src-path <path-to-datadog-wrapper> --type=startup
To see Application Security Management threat detection in action, send known attack patterns to your application. For example, send a request with the user agent header set to dd-test-scanner-log
to trigger a security scanner attack attempt:
curl -A 'dd-test-scanner-log' https://your-function-url/existing-route
A few minutes after you enable your application and exercise it, threat information appears in the Application Signals Explorer.
추가 유용한 문서, 링크 및 기사: