SnehaAgrawal-MSFT
commented
3 years ago @Vipin-Sharma Thank you for your feedback! We will review and update as appropriate.
Open Vipin-Sharma opened 3 years ago
SnehaAgrawal-MSFT
commented
3 years ago @Vipin-Sharma Thank you for your feedback! We will review and update as appropriate.
Vipin-Sharma
commented
3 years ago @PramodValavala-MSFT please tell me if you need more details on the questions here.
PramodValavala-MSFT
commented
3 years ago @Vipin-Sharma Hope the below answers your queries
The object of ExecutionContext class is available to us at the entry point of the function app, are we supposed to pass along this object in all the classes/methods we call so that we can use this for logging there?
Yes. If you plan to use the built-in logging of the Function Runtime, then you would have to pass this along as required.
When is it recommended to use slf4j/log4j or any other framework to use logging in Java azure function, this is the standard way of logging for Java applications.
The built-in logging functionality is great when writing simple functions. But if you already have lots of java library code that leverages java-native logging, its best to leverage the same.
What are the differences when logging using context.getLogger() vs slf4j/log4j, I know when context.getLogger() is used we can see logs via logs streaming(very helpful feature), can we also see slf4j/log4j logs in same logs stream?
The built-in logging is simple to work with because you don't have to configure anything. The logs are directly sent to Application Insights by the Functions Runtime. This is much simpler compared to setting up your own logging framework when starting out with azure functions and/or simple functions.
Other than streaming, what are other things are done differently for context.getLogger() vs slf4j/log4j?
The built-in logging as mentioned before, ties into the Functions Runtimes logging setup which uses Application Insights out of the box.
There is a discussion on the language worker repo where you could weigh in on this requirement.
PramodValavala-MSFT
commented
3 years ago @Vipin-Sharma Just following up here... Hope my previous comment clears things up.
Vipin-Sharma
commented
3 years ago @Vipin-Sharma Hope the below answers your queries
The object of ExecutionContext class is available to us at the entry point of the function app, are we supposed to pass along this object in all the classes/methods we call so that we can use this for logging there?
Yes. If you plan to use the built-in logging of the Function Runtime, then you would have to pass this along as required.
Passing this in all methods may not be nice/clean solution, can we tie this with threadLocal? I am using this in function app, if every http request is served with new thread, it is probably good idea. I am not sure exact behaviour of function apps.
When is it recommended to use slf4j/log4j or any other framework to use logging in Java azure function, this is the standard way of logging for Java applications.
The built-in logging functionality is great when writing simple functions. But if you already have lots of java library code that leverages java-native logging, its best to leverage the same.
What are the differences when logging using context.getLogger() vs slf4j/log4j, I know when context.getLogger() is used we can see logs via logs streaming(very helpful feature), can we also see slf4j/log4j logs in same logs stream?
The built-in logging is simple to work with because you don't have to configure anything. The logs are directly sent to Application Insights by the Functions Runtime. This is much simpler compared to setting up your own logging framework when starting out with azure functions and/or simple functions.
Does built-in logging using ExecutionContext have any overhead or it is similar to other logging frameworks?
Other than streaming, what are other things are done differently for context.getLogger() vs slf4j/log4j?
The built-in logging as mentioned before, ties into the Functions Runtimes logging setup which uses Application Insights out of the box.
If I want to use logging framework like log4j, is there any way to configure these logs in application insights as well?
There is a discussion on the language worker repo where you could weigh in on this requirement.
Vipin-Sharma
commented
3 years ago @Vipin-Sharma Just following up here... Hope my previous comment clears things up.
@PramodValavala-MSFT your answers are very helpful, not having enough information available online on such topics is big trouble for app developers. Posted few more follow up questions on this thread.
PramodValavala-MSFT
commented
3 years ago @Vipin-Sharma
Passing this in all methods may not be nice/clean solution, can we tie this with threadLocal? I am using this in function app, if every http request is served with new thread, it is probably good idea. I am not sure exact behaviour of function apps.
Based on the worker code, I suppose that is something you could try. It would be best to share this on the linked issue to get more perspectives on this.
Does built-in logging using ExecutionContext have any overhead or it is similar to other logging frameworks?
This is just a simple logger instance that is passed as seen here in the worker code.
If I want to use logging framework like log4j, is there any way to configure these logs in application insights as well?
Yes. You can check the Application Insights docs for more information.
@PramodValavala-MSFT your answers are very helpful, not having enough information available online on such topics is big trouble for app developers. Posted few more follow up questions on this thread.
Thanks for the feedback! We have assigned this issue to the content author to review this information and update the docs accordingly.
As per this page, we can use below for user generated logs
context.getLogger().info("My app logs here.");To understand best practices and how logging can help function app users:
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.