Team,
I need to host a .net core web api as app service in azure. Is it mandatory to enable file system option to view console logs. This option will any way work for 12 hours and not recommended in production then how could we see our logs. I have used only console log provider in my application. Is there any way to view logs on some console rather than saving in the file.
How can we get the console like in linux based systems or kubernetes.
Thank you
Hi,@TaB-8489 You can check Find Azure App Service Logs for Your Appand Enable web server logging first.
@JerryCai-MSFT , Hello. But how it can suffice the problem. Either,
We have to enable Application Logging(Filesystem), which is of no use in production as it remains for 12 hours,
Or, enable Application Logging(Blob) but in this case we need a paid blob storage
If azure has the option of API App as well in the app services then we can expect that it providing a medium to host microservices, rest services etc. In .net core or python or golang etc there are millions of logs we prefer to throw only on STDOUT console rather than saving in a file system.
How to get that console in azure. Paying only for console logs is little difficult to digest. Don't you think it as a very important feature missing in azure app services.
@TaB-8489, It's a good feedback. Appreciate your feedback!
Based on similar users feedback on (Uservoice’ (Azure Web Apps) Please add a setting to persist the application log)- Azure monitor integration feature was released. You can use the Azure Monitor integration (Preview) to route your logs to an Azure Storage Account, Event Hub, or Log Analytics workspace. Persisting all logs on the file system indefinitely would fill your app’s file system eventually.
Supported log types (related): AppServiceConsoleLogs, AppServiceHTTPLogs, AppServiceAppLogs etc.
Kindly check this App Service Integration with Azure Monitor (Preview). It's still in preview, please do share your feedback on this below, we shall relay this to our product team.
@TaB-8489, With the curl itself, you can scope the live traces to any providers/folders, you may additional specify the path.
Kudu service (as well as its application) write traces to the /Logfiles folder. The logstream endpoint (/logstream in the Kudu service) enables you to view with any real time traces as they are being written.
/api/logstream/kudu/trace => kudu related traces intended for diagnostic kudu issues.
/api/logstream/kudu/deployment => kudu deployment traces intended for application developers/operators.
/api/logstream/application => application traces.
/api/logstream/http => iis logs.
Kindly see this Diagnostic Log Stream for more details.
Yes, you can change DIAGNOSTICS_TEXTTRACETURNOFFPERIOD to a value greater than 12 hours (12 60 60 * 1000 in milliseconds) based on your requirement (considering the space).
@ajkuma-MSFT , Done. Thanks a lot for the details. I'll make file logs for fatal errors only and enable debug logs only in case of troubleshooting. Will use kudu stream for here.
Thanks a lot once again. Have a great day and happy new year.
@TaB-8489, Glad you found the information helpful. Thanks for the update and your best wishes. A Very Happy New Year to you!
@TaB-8489, Just to add more clarity
Failure to disable the stdout log can lead to app or server failure. There's no limit on log file size or the number of log files created. So it is recommended to only use stdout logging to troubleshoot app startup problems and disable stdout logging when troubleshooting is complete by setting stdoutLogEnabled="false".
For general logging in an ASP.NET Core app after startup, use a logging library that limits log file size and rotates logs. For more information, see third-party logging providers.
We avoid any feature that involves writing to the app's file system in a continuous manner, which can degrade performance.
Kindly refer Logging in .NET Core and ASP.NET Core doc for more details.
@ajkuma-MSFT , Sorry to say but how it cannot be a recommended approach. Today, whole devops model is depending upon STDOUT logs. Majority of golang/python applications are depending upon STDOUT. I don't know why microsoft is not recommending it.
Could you please share the complete technical reason behind that.
@TaB-8489, Also, kindly see Inside the Azure App Service Architecture - This article covers the basic internal architecture of App Service (how the service is built and operates) and offers a few best practices for certain scenarios.
The app logs are not indefinitely stored on the WebApps because your application is stored on the same storage, having constant increasing of logs on the site would strain the system.
Any app needs storage to hold content (HTML, .js files, images, or code files, and any other content required) for the application to work. A file server mounts Azure Storage blobs and exposes them as network drives to the Worker. A Worker, in return, maps such network drives as local, allowing any application running on any given Worker to use the “local” drive, just like you would expect if the application were running on a server using its local disk. Any file-related read/write operation performed by the application passes through a file server.
Kindly see this doc Operating system functionality on Azure App Service for more details on this :
You're limited to a maximum of 100 megabytes of logs when you use the file system. (File system logs are only for short-term retention. Azure deletes old log files to make room for new ones after the limit is reached.)
In cases when configuring logs to go to File System/, they go to a different LogFiles folder: D:\home\LogFiles\SiteExtensions\Kudu. If you need to stream them, you can run (log in with your deployment credentials):
curl https://{app}.scm.azurewebsites.net/api/logstream/SiteExtensions/Kudu -u YourDeploymentUser
Or if using Azure site log tail (which wraps the same API), pass -p SiteExtensions/Kudu to tell it to stream from that path.
Timeout in milliseconds to keep application logging on (Default is 43200000, which is 12 hours) is on the app:
https://github.com/projectkudu/kudu/wiki/Configurable-settings#diagnostics-related-settings
@ajkuma-MSFT , Please correct me if I'm wrong. So we've 2 options here. Save the log files let say using any 3rd party logger in some folder for eg. D:\home\LogFiles\somedirectory\mylogs
Now, if we need to access it then we can open kudu portal and check the logs manually.
Secondly, if we need to use the azure log stream feature for STDOUT logs then firstly, we have to enable azure application log file system option. To increase that default 12 hours period we have to create this variable in app settings and specify the value.
DIAGNOSTICS_TEXTTRACETURNOFFPERIOD
And, once the time expires I have to manually enable it again.
If we need to access stdout logs then we can fire the curl command like this or use log stream tab in azure(default place for logs is D:\home\LogFiles\SiteExtensions\Kudu)
curl https://{app}.scm.azurewebsites.net/api/logstream/SiteExtensions/Kudu/ -u YourDeploymentUser
Am I correct here or mixed-up the steps. Could you please confirm.
Hi @TaB-8489
You can try enabling logging features and later use Kudo to view logs.Some minor cost for using storage to store file but still you can always limit.
Azure Monitor integration to route your logs to an Azure Storage Account or Log Analytics workspace. Persisting all logs on the file system indefinitely would fill your app’s file system eventually.
https://azure.github.io/AppService/2019/11/01/App-Service-Integration-with-Azure-Monitor.html
Kudo Steps :: https://docs.microsoft.com/en-us/learn/modules/capture-application-logs-app-service/
http://sitecore.skowronski.it/sitecore/how-to-get-the-latest-logs-from-azure-with-kudu/
https://docs.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs#enable-web-server-logging
(Please don’t forget to "Accept the answer" and “up-vote” wherever the information provided helps you, this can be beneficial to other community members. Thank You)
Regards,
J.D.
Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.
8 people are following this question.
