Azure-functions-host: Use scopes to direct logs to correct file

[brettsam]

Today the FileLogger (what you see in the portal when invoking functions) figures out the correct file to write to based on the Function.{FunctionName}.User standard category that we use. However, we should be able to look at the scope as well to see if there's a function name. If so, write there.

[GFoley83]

Is there a temp work-around I could use to get the logs to show up in the log-streaming console window of the Azure function? https://github.com/Azure/azure-functions-host/issues/4425#issuecomment-512623724

[pvmraghunandan]

@brettsam Can you confirm if there is any workaround?

[SashaPshenychniy]

I just wonder how such bugs get to production at Microsoft? Didn't anyone try using logger with DI? Don't you have single unit-test checking that logs messages get to destinations using default setup?
It's hard to estimate the amount of time wasted by the community to find those workarounds...

I had to inject ILoggerFactory instead of ILogger<> into constructors and initialize logger manually with name which starts with "Functions.":
_log = logFactory.CreateLogger("Functions.Default");

[brettsam]

@SashaPshenychniy -- are you trying to log to a specific function file? If not, you're likely hitting https://github.com/Azure/azure-functions-host/issues/4345. There's a workaround listed there -- explicitly let your category through our filter.

For others trying to log to the streaming logs for a specific function. The current ways you can get your logs to show up there are:

• Use the ILogger that we pass into the function for your logging
• Construct a logger yourself from the ILoggerFactory with the category generated from calling Microsoft.Azure.WebJobs.Logging.LogCategories.CreateFunctionUserCategory("{FunctionName}");. All this really does is create the category Function.{FunctionName}.User (you can do this manually as well), which should then route correctly. Those logs will then route to the correct file to show up in streaming logs for {FunctionName}.

If that doesn't work (say you need a different specific category for this logger), that will have to wait until we can get this issue fixed.

[arek-avanade]

@brettsam Any update? Is this being actively developed? What's the release plan for this?

[Oxoproline]

This is really annoying bug/stupid feature. If you use injected services and you want to see logs in those services you have to pass Ilogger instance form function to every method. Please fix this.

[SinghManvir]

I am at serious loss of words on how this made into production and then ignored for over an year. Do Microsoft not use Azure Functions?
I have services that are referenced in a Web API and also in a Functions App (for batch jobs), so none of the above mentioned workarounds are good for me. Can we please have an update on this?

[Oxoproline]

@SinghManvir Somebody can correct me, but custom dependency injection was not supported in earlier versions of azure functions. So having ILogger injected into the specific function was the correct way how to do logs in azure functions, but azure functions involved and unfortunately some parts of the code/functionality missed the train.

[m-ghaoui]

@brettsam 's workaround works for me, but really I shouldn't be doing:

_logger = loggerFactory.CreateLogger(Microsoft.Azure.WebJobs.Logging.LogCategories.CreateFunctionUserCategory("MyFunctionClassName"));

This breaks the very concept of Dependency Injection. Is there a fix for this?

[coreice]

How do you use this "workaround", if you have for example a helper class which is used in multiple functions? I noticed the CreateFunctionUserCategory only works for me if you specify the name of a certain Azure Function.

[andybooth]

I feel the current need to us ILoggerFactory and LogCategories.CreateFunctionUserCategory with DI rather than ILogger should be clearly documented at https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-class-library?tabs=v2%2Ccmd#logging. Googling and Microsoft Docs leads you down the path of configuring host.json log level settings, rather than this guidance on how better to inject a logger.