Hello René,

While its true that you should manually create the "Logs” directory in the root of the web application (which is \site\wwwroot starting from the home folder in azure), when that directory is created the web gui will use it and start creating and updating debug.log for example.

Hi Edo,

I've checked it again (created the folder, stopped and started the app service) but unfortunately no log files are created. Any clues on what to check what could prevent creating the log files?

Does the application pool user have write permissions for the Logs folder?

Hi,

I'm not that experienced with Azure App Services and application pools: I have no clue where to, or even could configure that. I do know it's an IIS thing, but in the Azure Portal it's something like this:

However I did notice that the “Cache” folder is created and written, and the “App_Data” contains data, so I assume there should not be a permission issue. As a test I also did chmod Logs to 777, but that didn't help.

Your configuration seems ok.

Maybe check your Global configuration→Extended property for settings which override the settings in the ini-file. In particular one of these:

Executionmode = developer
CSVLogging = True
LogToFile = Yes

Maybe put them in the ini file again by typing them by-hand.

When you login, does the ribbon show a "Develop” tab?

I reviewed your ini file and I noticed you are starting against IAM. The "RuntimeConfiguration” property is Sf related. You should use "GlobalConfiguration” instead. I wouldn't expect it, but maybe that helps a bit.

Hi,

I've checked the extended properties, none of the listed one is present. I’ve tested it with a test application without extended properties, and with the real application having the following extended properties:

The “Developer” tab is visible. I’ve changed the ini file to the following:

Server               = server.database.windows.net
Database             = test-iam
RDBMS                = SQLSERVER
Metasource           = IAM
Language             = eng
Authentication       = rdbms
Executionmode        = developer
CSVLogging = True
LogToFile = Yes
Application_title  = Test
ApplicationLoginBlocked=No
ApplicationLoginBackground=test.jpg
ShowLoginInfo=No
ShowSplash=No

Maybe is what we're doing and what we want not ok: What we actually want is a log of failed query's / errors the users had. We had a situation an end user probably had a query error, but was not able to reproduce. It would be nice if there was some kind of logging, without the need of the “Developer” tab page. I'm not sure how I can achieve that? Because the documentation says you need ExecutionMode=developer for that, but I don't want the end users have to see that.

This logging is quite intense.

CSVLogging writes all executed SQL statements of all users to a text file, similar to what you see in the debug console of the Windows GUI.

LogToFile logs several other information like missing translations, errors, etc.

These are only enabled in developer mode, because they are not optimised to enable in a production environment.

In an on-premise environment, I would advice to check the Windows Events viewer for errors. For Azure it seems like you could find it here:
https://docs.microsoft.com/nl-nl/azure/azure-monitor/platform/data-sources-windows-events

Thanks for the advice. I think I will spend some more time on such features in Azure. We’re currently using an Azure SQL Database and an App Service. I'm pretty sure there must be something in both services. For the SQL part we’re especially interested in the query's that fail or are ‘heavy’. For the App Service part we’re interested in errors / warnings. If I've got some interesting results I'll update this thread .

You can also use SQL Server's Extended Events to find failed and long running queries. 

Some examples: 

• https://www.sqlservercentral.com/blogs/identifying-failed-queries-with-extended-events
• https://dbtut.com/index.php/2019/02/13/how-to-identify-long-running-queries-using-extended-events/