How to get AppInsights working in .NET 8 Functions v4

[LockTar]

Hi,

Sorry for the new issue but I think this will bring a lot of open issues together to a final solution in a sample repository.
Hopefully we can make something default/officially/easier for new people because it took me a long time to figure everything out.

• This setup is ugly but solves AppInsights logging in Azure Functions v4 in combination with .NET 7. It uses the new (still in preview) Microsoft.Azure.Functions.Worker.ApplicationInsights package explained in PR 944
• It fixes the hardcoded Warning filter explained in 1123 comment. See auto added Warning filter details here.
• It highlights that the default Warning filter is automatically added explained here.
• It adds an appsettings.json configuration file for default configuration as suggested in Update samples and docs to add Host.CreateDefaultBuilder() #1025
• It loads the appsettings.json configuration file.
• It configures the logging from out of the appsettings.json configuration file
• It is a more realistic sample application other than "Hello world" because of multiple classes, loggers and injected loggers.

I want to thank @brettsam, @jviau and @kshyju for posting helpful comments that let me finally see some logging in Azure Application Insights lower than Warning (so Trace, Debug, Information).

See the sample repository for more details to get it running. See the details of the Func.Isolated.Net7.With.AI project.

Screenshots from Azure:

[SeanFeldman]

@LockTar, is that repo public?

[LockTar]

@LockTar, is that repo public?

Oeps! Forgot to change that. It's public now

[LockTar]

@SeanFeldman
Basically it results in the following:

1. Add the 2 new lines of the preview package
2. Remove the warning and above logger
3. Use appsettings.json as configuration file
4. Configure logging from appsettings.json
5. Optional setup DI for testing injected classes with ILogger<T>

Program.cs

using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Func.Isolated.Net7.With.AI;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(builder =>
    {
        // Is added by package "Microsoft.Azure.Functions.Worker.ApplicationInsights".
        // Documented here because it is still preview: https://github.com/Azure/azure-functions-dotnet-worker/pull/944#issue-1282987627
        builder
            .AddApplicationInsights()
            .AddApplicationInsightsLogger();        
    })
    .ConfigureServices((ctx, serviceProvider) =>
    {
        // You will need extra configuration because above will only log per default Warning (default AI configuration) and above because of following line:
        // https://github.com/microsoft/ApplicationInsights-dotnet/blob/main/NETCORE/src/Shared/Extensions/ApplicationInsightsExtensions.cs#L427
        // This is documented here:
        // https://github.com/microsoft/ApplicationInsights-dotnet/issues/2610#issuecomment-1316672650
        // So remove the default logger rule (warning and above). This will result that the default will be Information.
        serviceProvider.Configure<LoggerFilterOptions>(options =>
        {
            var toRemove = options.Rules.FirstOrDefault(rule => rule.ProviderName
                == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");

            if (toRemove is not null)
            {
                options.Rules.Remove(toRemove);
            }
        });


        // Setup DI
        serviceProvider.AddTransient<IUserDataService, UserDataService>();
    })
    .ConfigureAppConfiguration((hostContext, config) =>
    {
        // Add appsettings.json configuration so we can set logging in configuration.
        // Add in example a file called appsettings.json to the root and set the properties to:
        // Build Action: Content
        // Copy to Output Directory: Copy if newer
        //
        // Content:
        // {
        //   "Logging": {
        //     "LogLevel": {
        //       "Default": "Error" // Change this to ie Trace for more logging
        //     }
        //   }
        // }
        config.AddJsonFile("appsettings.json", optional: true);
    })
    .ConfigureLogging((hostingContext, logging) =>
    {
        // Make sure the configuration of the appsettings.json file is picked up.
        logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
    })
    .Build();

host.Run();

Add appsettings.json file with settings Build Action: Content and Copy to Output Directory: Copy if newer:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Func.Isolated.Net7.With.AI.MyOtherFunctions": "Error",
      "Func.Isolated.Net7.With.AI.MyUserFunctions": "Debug",
      "Func.Isolated.Net7.With.AI.UserDataService": "Trace"
    }
  }
}

[jviau]

@LockTar thank you for summarizing all of this for others to reference. Glad you were able to get it working. Was the logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging")); call what we were ultimately missing in the previous discussions? If so, I wonder if the Logging:ApplicationInsights:LogLevel:Default = Information would actually work with that? This would replace the need for the Configure<LoggerFilterOptions> hack.

Anyways - is there any action items you want from our side as an outcome of this issue? Keep in mind we do already have intentions to address telemetry in Functions (ideally go with OpenTelemetry).

[LockTar]

Was the logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging")); call what we were ultimately missing in the previous discussions? If so, I wonder if the Logging:ApplicationInsights:LogLevel:Default = Information would actually work with that? This would replace the need for the Configure<LoggerFilterOptions> hack.

Just tested it for you.
If I don't set the delete logger filter rule from you and change appsettings.json to:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Func.Isolated.Net7.With.AI.MyOtherFunctions": "Error",
      "Func.Isolated.Net7.With.AI.MyUserFunctions": "Debug",
      "Func.Isolated.Net7.With.AI.UserDataService": "Trace"
    },
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Debug"
      }
    }
  }
}

Then I would see Debug messages as well. So, this would change the default warning rule.

BUT
If I change it to Logging:ApplicationInsights:LogLevel:Default = Error, then I of course only see Error messages but I'm losing in example the Logging:LogLevel:Func.Isolated.Net7.With.AI.UserDataService = Trace messages.

That's not what you want... Maybe you have fix for that as well but that is exactly the thing that everyone is saying. It is to unclear how everything is working for Azure (Isolated) Functions.

[LockTar]

Anyways - is there any action items you want from our side as an outcome of this issue? Keep in mind we do already have intentions to address telemetry in Functions (ideally go with OpenTelemetry).

Yes.

1. My console logging (localhost debugging) is missing completely. How can this be fixed... Is this related with Logging calls does not appear in console when running locally in 1.9.0 using ApplicationInsights preview packages #1090?
2. I/We want an official sample application or new VS2022 default project template with clear documentation on how to set logging. Now we have 3 places to set logging and it's unclear how everything is working. We have host.json, appsettings:Logging:LogLevel and appsettings:Logging:ApplicationInsights:LogLevel.
   Everything is based on assumptions.

I don't know if OpenTelemetry is going to fix everything but I guess this will not be finished tomorrow. We create new Azure Functions on almost daily level. We need to have clear logging (documentation) from the start.

[jviau]

For the log filters: Logging:ApplicationInsights:LogLevel:Default = Error and Logging:LogLevel:Func.Isolated.Net7.With.AI.UserDataService = Trace only showing Error in App Insights is behaving as expected. The first one is a provider specific filter, which takes precedence over the second filter you have. This reminds me why I have that filter removal 'hack' in my code and not the config approach. It is the same situation as you: I wanted to control log filters through the non-provider configuration (Logging:LogLevel:*). App insights package always adding that Warning filter gets in the way, so I removed it. The hack isn't the best, but also not the worst. We will not be porting that into our app insights package as we do not want to conflict with what the AppInsights package has decided to do. We will leave the decision to include that filter customization to the end user.

For the console logging missing completely in local debugging, something I was missing this entire time was that stdout for the worker is piped to the host, which is not always forwarding them to the terminal you are running in. @fabiocav / @brettsam what is the recommended way to get console logs from worker in local debugging?

And we do intend for the OpenTelemetry work to address all of these concerns. You will have much more control over the logs. However, something that won't change is the multiple places to configure logging. Ultimately, you have two processes running - the host and the worker and they have their own respective logging configuration. We will always have to expose the ability to configure them separately (host.json for the host config, then you are ultimately in control of the setting file(s) for the worker). As for the multiple "LogLevel" sections to configure, that is also out of our control. This is how Microsoft.Extensions.Logging works - we do not own that API or its configuration.

To summarize, sounds like we just need to help you with the worker --> host stdout pipe causing issues with console logging.

[LockTar]

App insights package always adding that Warning filter gets in the way, so I removed it. The hack isn't the best, but also not the worst. We will not be porting that into our app insights package as we do not want to conflict with what the AppInsights package has decided to do. We will leave the decision to include that filter customization to the end user.

I understand that you don't want to make conflicts with the AppInsights packages. Otherwise, you will get mixed results in MS Azure services. But removing the Warning filter could be added to the project template in VS20xx. Maybe not enabled but in comment. Maybe with a link to the docs (that I can't find anywhere for Azure Functions...). (See below bullet 2)

And we do intend for the OpenTelemetry work to address all of these concerns. You will have much more control over the logs. However, something that won't change is the multiple places to configure logging. Ultimately, you have two processes running - the host and the worker and they have their own respective logging configuration. We will always have to expose the ability to configure them separately (host.json for the host config, then you are ultimately in control of the setting file(s) for the worker). As for the multiple "LogLevel" sections to configure, that is also out of our control. This is how Microsoft.Extensions.Logging works - we do not own that API or its configuration.

Thank you for the explanation. I understand that there are 2 types of places to configure.

To summarize, sounds like we just need to help you with the worker --> host stdout pipe causing issues with console logging.

1. Well, yes. Console logging would be nice for local debugging.
2. How can we make things clearer for people that create a new project. The appsettings.json and Program.cs as stated above aren't default. There is no clear documentation from an Azure Function Isolated perspective how to set this all up... It took me hours and I'm not the only one. It would be nice to have documentation about this and a changed project template.

Don't get me wrong (not attacking you or colleagues at all) but my employers want me to write (small) business solutions. Azure Functions are ideal for this. That's why I'm using Functions from the beginning. Logging should be more an addition for troubleshooting. It now takes me longer to figure out how logging works (it changes a lot) than I'm writing a complete API...

[drew-fc]

hi @LockTar ,

Thank you so much for putting this together.
I have integrated your changes into my project, but the result I am getting is that nothing is printed at all to the terminal during debugging sessions.
Previously, I was only getting Information and above to print.
I have downloaded your entire repo and tried to get your project to work, but it fails on host.Run() when it starts. The error I get is

`Exception has occurred: CLR/System.InvalidOperationException
An unhandled exception of type 'System.InvalidOperationException' occurred in System.Private.CoreLib.dll: 'The gRPC channel URI 'http://:7283' could not be parsed.'

Any ideas how to move forward?
I am using Visual Studio Code if that matters, not Visual Studio, although I have VS if you think that's absolutely needed to move forward.
thanks again