ASP.NET Core integration only reads settings from env vars

Describe the bug I hoped that the v1.12 will fix that issue but it doesnt

i dont know, maybe we are doing something wrong but i dont think so because the integration for http (out)/database calls still works

Runtime environment (please complete the following information):

• Instrumentation mode: automatic
• Tracer version: 1.12
• OS: mcr.microsoft.com/dotnet/core/runtime-deps:3.1
• CLR: .NET Core 3.1

Additional context Partial parts from Docker image:

FROM                    mcr.microsoft.com/dotnet/core/runtime-deps:3.1
....
#Install Datadog APM packages
ARG DD_VERSION=1.12.0
RUN mkdir -p /tmp
RUN curl -L https://github.com/DataDog/dd-trace-dotnet/releases/download/v${DD_VERSION}/datadog-dotnet-apm_${DD_VERSION}_amd64.deb --output /tmp/datadog_apm.deb
RUN sudo dpkg -i /tmp/datadog_apm.deb


#Setup Datadog APM
ENV CORECLR_ENABLE_PROFILING=1
ENV CORECLR_PROFILER={846F5F1C-F9AE-4B07-969E-05C26BC060D8}
ENV CORECLR_PROFILER_PATH=/opt/datadog/Datadog.Trace.ClrProfiler.Native.so
ENV DD_INTEGRATIONS=/opt/datadog/integrations.json
ENV DD_DOTNET_TRACER_HOME=/opt/datadog

note: installs without any problems

Trace initialization

Tracer.Instance = Tracer.Create(
    new Uri($"http://{AWSEnvironment.DockerHost}:8126"),
    <serviceName>,
    true
);

note: isDebugEnabled: true, there is no debug file in the directory ( in the container )

Partial parts from Startup.cs

        public virtual void ConfigureServices(IServiceCollection services)
        {
            // ....
            services.AddControllers()
                .AddNewtonsoftJson(options =>
                {
                    options.SerializerSettings.ContractResolver = new Newtonsoft.Json.Serialization.CamelCasePropertyNamesContractResolver();
                    options.SerializerSettings.NullValueHandling = NullValueHandling.Ignore;
                    options.SerializerSettings.Formatting = Formatting.None;
                })
                .AddListTypeConverter()
                .AddMvcOptions(options =>
                {
                    options.InputFormatters.Add(new TextPlainInputFormatter());
                    options.OutputFormatters.Add(new HtmlOutputFormatter());
                    options.Conventions.Add(new AcceptHeaderToProducesMapper());
                    options.Conventions.Add(new LowerControllerModelConvention());
                });
                // ....
        }

        public virtual void Configure(IApplicationBuilder app)
        {
            // ....
            app.UseRouting();
            app.UseEndpoints(endpoints => { endpoints.MapControllers(); });
            // ....
        }

[lucaspimentel]

Thanks, @ffandreassoroko. I tried setting the Agent hostname in code the way you did, and had the same result as you. The tracer tries to send traces to localhost!

After some debugging, I realized we call Tracer.Instance.StartDiagnosticObservers() in our startup hook, before users have a chance to replace the default Tracer.Instance. The result is that any instrumentation that uses DiagnosticSource keeps using that original Tracer instance even if the user replaces Tracer.Instance with a new instance.

The workaround for now is to not configure settings in code and not replacing the default Tracer.Instance. Instead use one of the other configuration methods, like environment variables.

(edit: typo)

[andreas-soroko]

Hey, thanks for the answer.

based on your example (and infos how i can enable logs), i was able to get it work.

its seems that settings.AgentUri has no effect

var settings = TracerSettings.FromDefaultSources();
settings.AgentUri = new Uri($"http://{AWSEnvironment.DockerHost}:8126");

i found the endpoint http://localhost:8126 in the logs, but localhost is wrong, so i modified our bootstrapper script a bit that “DD_AGENT_HOST” get filled

export DOCKER_HOST=$(wget -qO- http://169.254.169.254/latest/meta-data/local-ipv4)
export DD_AGENT_HOST=$(wget -qO- http://169.254.169.254/latest/meta-data/local-ipv4)

/tmp/dotnet/<backend>

tada… works 👍

additional, it seems that your createLogPath scripts does not work, after executing nothings happens, folder was not created - had to do it like you