In theprevious article, we deployed our simple function with Storage Queue trigger to Azure cloud. We saw how to view the log stream of our Function App. While reviewing logs this way is fine for testing, it is not a practical solution once the function is deployed and running. We simply cannot watch log stream all the time. Besides, it also means that we have to leave the browser tab open for the log stream to continue. In this article, we will configure our Function App to send logs to a centralized location using Azure Log Analytics.

Create Log Analytics Workspace

First, we will create a Log Analytics Workspace for collecting our function logs. Let's go to Azure Portal and search forlog analytics resource. Click onLog Analytics workspaces in the search results.

Click on+ Create to specify the details of the workspace.

We will create this new workspace in our existingblog-functions-rg resource group. We will name this workspaceblog-functions-log-analytics-ws and specify regionEast US that we have used so far. Click onReview + Create to continue.

We should see aValidation passed message. Click onCreate to create the workspace.

Configure Function App Diagnostics Settings

After the workspace is created, it needs to associated with our Function App so the logs can be routed to this workspace. To do this, we will navigate to our Function App and click onDiagnostic settings item in the left menu. In the panel that opens on the right, we will click+ Add diagnostic setting.

We will name this settingblog-function-app-log-diag-settings. Since we want to send function logs to the workspace we created, check theFunction Application Logs and theSend to Log Analytics workspace boxes. Choose the workspace we just created in theLog Analytics workspace list. ClickSave at the top to save this setting.

We should now see the setting in the list of Diagnostic settings of our Function App.

Invoke HTTP Function

We need to generate some logs before we can view them. For this, let's invoke our HTTP function. Open a new browser or tab, put URLhttps://blog-function-app.azurewebsites.net/api/SimpleHttpFunction into the address bar and press enter.

Note: Each function logs a single message. We will look for these messages in the log workspace.

View Logs

Now let's see if the logs show in the Log Analytics workspace. We will navigate to our workspace and click onLogs item in the left menu. We can close the pop-up that appears on the right as we won't be using any of these queries. Instead, we will write our own query.

Azure Log Analytics uses Kusto Query Language (KQL) to help query and filter logs. After closing the pop-up, note that the scope is our workspace name. SelectLast 30 minutes as the Time range, specifyFunctionAppLogs as the query text and click Run button. We will see logs appearing under the Results tab.

Note: There can be a delay of a few minutes for the logs to make it to the workspace.

There will be a lot of messages. Azure itself writes a lot of information to the workspace. Scroll down and look for message withCategory asFunction.SimpleHttpFunction.User and you should see the log message written by the function.

Next, let's get our SimpleQueueFunction to run. Go to theblog-queue and add a new message{ "msg": "Write to log analytics" } to the queue (seeprevious article for details).

When we run the query again in Log Analytics workspace, we should see the message logged bySimpleQueueFunction. Clicking the> sign will expand the details.

Advanced Log Analytics Queries

As mentioned earlier, we can use Kusto Query Language (KQL) to query logs. When we invoked our HTTP function, a lot of messages were generated. This is going to happen every time a function is executed. If there are many function executions, there will be a large number of messages and these could be from different functions. This makes it very difficult to get to the messages that we actually need to review. KQL is quite powerful and we can use its filtering capabilities to narrow down the messages we are interested in. For e.g., to look for messages generated by a specific function, we can use a query like this:

FunctionAppLogs| where Category startswith "Function."| where FunctionName == "SimpleQueueFunction"| project TimeGenerated, FunctionName, Level, FunctionInvocationId, Message| order by TimeGenerated desc

The above query will retrieve messages generated by our code as well as those generated by Azure. To see messages from only our code, we can add awhere Category endswith ".User" filter.

FunctionAppLogs| where Category startswith "Function." | where Category endswith ".User"| where FunctionName == "SimpleQueueFunction"| project TimeGenerated, FunctionName, Level, FunctionInvocationId, Message| order by TimeGenerated desc

Notice that KQL appears to be similar to SQL. HereFunctionAppLogs is the table. Data from this table can be filtered usingwhere clauses andproject clause can be used to include only the fields that we are interested in (likeselect clause in SQL). Ordering of results is also supported.

Checkout a few advanced KQL query examples inmy Github repo.

Conclusion

In this article, we set up a Log Analytics workspace and configured our Function App to send logs to it. This workspace acts as centralized location for retrieval and analysis of logs. We also saw how we can query and filter logs using KQL.

Note: It is possible to use the same Log Analytics workspace to collect all your logs - such as those from other Function Apps, App Services, Virtual Machines etc.

In the next article, we will take a look at Function App bindings.