Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand Logging Services section #32004

Closed
danhamlin opened this issue May 23, 2019 — with docs.microsoft.com · 14 comments
Closed

Expand Logging Services section #32004

danhamlin opened this issue May 23, 2019 — with docs.microsoft.com · 14 comments

Comments

Copy link

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.

@AshokPeddakotla-MSFT
Copy link
Contributor

AshokPeddakotla-MSFT commented May 23, 2019

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

@bennor
Copy link

bennor commented Jun 1, 2019

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. 😞

Copy link

mutzl commented Jun 3, 2019

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

Copy link
Author

danhamlin commented Jun 4, 2019

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.

@bennor
Copy link

bennor commented Jun 4, 2019

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

Copy link
Author

danhamlin commented Jun 4, 2019

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: Azure/azure-functions-host#3741

@bennor
Copy link

bennor commented Jun 5, 2019

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.)

@mutzl
Copy link

mutzl commented Jun 6, 2019

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).

@ggailey777
Copy link
Contributor

ggailey777 commented Jun 6, 2019

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

cc. @craigshoemaker

@brettsam
Copy link
Contributor

brettsam commented Jun 6, 2019

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 -- ILogger is not injected when using new DI functionality Azure/azure-functions-host#4425 (comment)). 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: Remove filters for ILoggers created by customer DI Azure/azure-functions-host#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

@bennor
Copy link

bennor commented Jun 6, 2019

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

@mutzl
Copy link

mutzl commented Jun 7, 2019

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.

Copy link

paul-lorica commented Sep 4, 2019

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 Azure/azure-functions-host#4345

Workaround is to add this to your host.json file

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

@PRMerger6 PRMerger6 added the Pri1 label Sep 4, 2019
@craigshoemaker
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests