Azure-docs: Expand Logging Services section

Created on 23 May 2019  Â·  14Comments  Â·  Source: MicrosoftDocs/azure-docs

Please give some expanded guidance in the Logging Services section.


Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

Pri1 assigned-to-author azure-functionsvc doc-enhancement triaged

Most helpful comment

Couple of comments:

  1. You do need to use ILogger<T> for DI. The base interface is not registered by .NET. This isn't really a Functions thing; it's .NET Core DI in general (I commented here about it -- https://github.com/Azure/azure-functions-host/issues/4425#issuecomment-492338472). We do pass you a base ILogger in your function, which I think has created this confusion. But that's not DI -- that's us creating one with a specific category and passing it explicitly.
  2. The T in ILogger<T> can be any type. It simply uses that type to construct the logger's category by using the type name. This is the reason that DI requires the generic interface -- without it, it has no way to know what category you want to use. You can also request the ILoggerFactory itself and create a logger that way, with whatever category you like.
  3. There's currently a bug where we're aggressive with our filtering -- which removes any custom logging. Issue and workaround here: https://github.com/Azure/azure-functions-host/issues/4345

Numbers 1 and 2 are just general .NET Logging... you can read up more here: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-2.2

All 14 comments

@danhamlin Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

It would be really helpful if it showed how to wire it up to send to AI, like the default ILogger passed to the function does automatically when you have AI instrumentation on. It appears that ILogger isn't injected when I take a dependency on it in any of my other injected dependencies. 😞

Same here. Need to inject the default ILogger into service classes.

Services registered in DI can get a logger like so (notice the generic that differs from what function methods get injected):

public SomeDependency(ILogger<SomeDependency> logger)
{
    logger.LogInformation("important information");
}

I'm using this in my function apps.

@danhamlin that doesn't show how to register it or how it gets injected. I think you left something out of your example.

Appologies, I goofed with the markdown, but I fixed it now. There is logging registered out of the box. If you want to add additional logging providers you can use something like the following in your startup class:
builder.Services.AddLogging(loggingBuilder => loggingBuilder.AddNLog());
You may or may not run into issues depending on the complexity of the logging you're adding. For example there are issues logged around customizing application insights logging: https://github.com/Azure/azure-functions-host/issues/3741

So it appears the generic interface is what I was missing. Does it need to match the class being injected into? (I am planning to use it within a MediatR pipeline component--effectively middleware--and I'm not sure what the generic argument should be.)

Services registered in DI can get a logger like so (notice the generic that differs from what function methods get injected):

public SomeDependency(ILogger<SomeDependency> logger)
{
    logger.LogInformation("important information");
}

I'm using this in my function apps.

It compiles and runs without exception, though I don't see any log output in the console window (running the azure function in the local test environment).

+ @brettsam and @jeffhollan for awareness of this discussion.

cc. @craigshoemaker

Couple of comments:

  1. You do need to use ILogger<T> for DI. The base interface is not registered by .NET. This isn't really a Functions thing; it's .NET Core DI in general (I commented here about it -- https://github.com/Azure/azure-functions-host/issues/4425#issuecomment-492338472). We do pass you a base ILogger in your function, which I think has created this confusion. But that's not DI -- that's us creating one with a specific category and passing it explicitly.
  2. The T in ILogger<T> can be any type. It simply uses that type to construct the logger's category by using the type name. This is the reason that DI requires the generic interface -- without it, it has no way to know what category you want to use. You can also request the ILoggerFactory itself and create a logger that way, with whatever category you like.
  3. There's currently a bug where we're aggressive with our filtering -- which removes any custom logging. Issue and workaround here: https://github.com/Azure/azure-functions-host/issues/4345

Numbers 1 and 2 are just general .NET Logging... you can read up more here: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-2.2

Thanks, @brettsam. I should have read up more but was confused because of ILogger just working when added as a function parameter.

3. There's currently a bug where we're aggressive with our filtering -- which removes any custom logging. Issue and workaround here: Azure/azure-functions-host#4345

Thank you. That fixed it for me.

Just to make matters clear for future readers -

The injected ILogger or ILoggerFactory will get injected properly but NOT actually write to any Logging Providers - in my case I was expecting to see it write to Application Insights and the Console. Due to the bug https://github.com/Azure/azure-functions-host/issues/4345

Workaround is to add this to your host.json file

{
    "version": "2.0",
    "logging": {
        "logLevel": {
            "Default": "Information"
        }
    }
}

Moving to #please-close this issue as it's not a doc-related issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mrdfuse picture mrdfuse  Â·  3Comments

Agazoth picture Agazoth  Â·  3Comments

DeepPuddles picture DeepPuddles  Â·  3Comments

jamesgallagher-ie picture jamesgallagher-ie  Â·  3Comments

monteledwards picture monteledwards  Â·  3Comments