The Datadog sidecar uses file tailing to collect logs. Datadog recommends writing application logs to /home/LogFiles/ because this directory is persisted across restarts.
You can also create a subdirectory, such as /home/LogFiles/myapp, if you want more control over what is sent to Datadog. However, if you do not tail all log files in /home/LogFiles, then Azure App Service application logs related to startups and errors are not collected.
The Datadog sidecar uses file tailing to collect logs. Datadog recommends writing application logs to /home/LogFiles/ because this directory is persisted across restarts.
You can also create a subdirectory, such as /home/LogFiles/myapp, if you want more control over what is sent to Datadog. However, if you do not tail all log files in /home/LogFiles, then Azure App Service application logs related to startups and errors are not collected.
The Datadog sidecar uses file tailing to collect logs. Datadog recommends writing application logs to /home/LogFiles/ because this directory is persisted across restarts.
You can also create a subdirectory, such as /home/LogFiles/myapp, if you want more control over what is sent to Datadog. However, if you do not tail all log files in /home/LogFiles, then Azure App Service application logs related to startups and errors are not collected.
Instrument your main application with the dd-trace-dotnet library.
Add the following lines to the Dockerfile for your main application. This installs and configures the Datadog tracer within your application container.
RUN mkdir -p /datadog/tracer RUN mkdir -p /home/LogFiles/dotnet ADD https://github.com/DataDog/dd-trace-dotnet/releases/download/v2.51.0/datadog-dotnet-apm-2.51.0.tar.gz /datadog/tracer RUN cd /datadog/tracer && tar -zxf datadog-dotnet-apm-2.51.0.tar.gz
Build the image and push it to your preferred container registry.
Full example Dockerfile
# Stage 1: Build the applicationFROM mcr.microsoft.com/dotnet/sdk:8.0 AS buildWORKDIR /app# Copy the project file and restore dependenciesCOPY *.csproj ./RUN dotnet restore# Copy the remaining source codeCOPY . .# Build the applicationRUN dotnet publish -c Release -o out# Stage 2: Create a runtime imageFROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtimeWORKDIR /app# Copy the build output from stage 1COPY --from=build /app/out ./# Datadog specificRUN mkdir -p /datadog/tracerRUN mkdir -p /home/LogFiles/dotnetADD https://github.com/DataDog/dd-trace-dotnet/releases/download/v2.51.0/datadog-dotnet-apm-2.51.0.tar.gz /datadog/tracerRUNcd /datadog/tracer && tar -zxf datadog-dotnet-apm-2.51.0.tar.gz# Set the entry point for the applicationENTRYPOINT["dotnet","<your dotnet app>.dll"]
The Datadog sidecar uses file tailing to collect logs. Datadog recommends writing application logs to /home/LogFiles/ because this directory is persisted across restarts.
You can also create a subdirectory, such as /home/LogFiles/myapp, if you want more control over what is sent to Datadog. However, if you do not tail all log files in /home/LogFiles, then Azure App Service application logs related to startups and errors are not collected.
The Datadog sidecar uses file tailing to collect logs. Datadog recommends writing application logs to /home/LogFiles/ because this directory is persisted across restarts.
You can also create a subdirectory, such as /home/LogFiles/myapp, if you want more control over what is sent to Datadog. However, if you do not tail all log files in /home/LogFiles, then Azure App Service application logs related to startups and errors are not collected.
The Datadog sidecar uses file tailing to collect logs. Datadog recommends writing application logs to /home/LogFiles/ because this directory is persisted across restarts.
You can also create a subdirectory, such as /home/LogFiles/myapp, if you want more control over what is sent to Datadog. However, if you do not tail all log files in /home/LogFiles, then Azure App Service application logs related to startups and errors are not collected.
In your App settings in Azure, set the following environment variables on both your main container and the sidecar container. Alternatively, set these variables on your main container and enable the Allow access to all app settings option.
DD_SERVICE: How you want to tag your service. For example, sidecar-azure
DD_ENV: How you want to tag your env. For example, prod
DD_SERVERLESS_LOG_PATH: Where you write your logs. For example, /home/LogFiles/*.log or /home/LogFiles/myapp/*.log
DD_AAS_INSTANCE_LOGGING_ENABLED: When true, log collection is automatically configured for an additional file path: /home/LogFiles/*$COMPUTERNAME*.log
If your application has multiple instances, make sure that your application's log filename includes the $COMPUTERNAME variable. This ensures that log tailing does not create duplicated logs from multiple instances reading the same file.
For .NET applications: Additional required environment variables
If you are setting up monitoring for a .NET application, configure the following required environment variables.
consttracer=require('dd-trace').init({logInjection:true,});constexpress=require("express");constapp=express();const{createLogger,format,transports}=require('winston');constlogger=createLogger({level:'info',exitOnError:false,format:format.json(),transports:[newtransports.File({filename:`/home/LogFiles/app-${process.env.COMPUTERNAME}.log`}),],});app.get("/",(_,res)=>{logger.info("Welcome!");res.sendStatus(200);});app.get("/hello",(_,res)=>{logger.info("Hello!");metricPrefix="nodejs-azure-sidecar";// Send three unique metrics, just so we're testing more than one single metric
metricsToSend=["sample_metric_1","sample_metric_2","sample_metric_3"];metricsToSend.forEach((metric)=>{for(leti=0;i<20;i++){tracer.dogstatsd.distribution(`${metricPrefix}.${metric}`,1);}});res.status(200).json({msg:"Sending metrics to Datadog"});});constport=process.env.PORT||8080;app.listen(port);