Since I have been working with system integrations for quite some time, there is one thing I have learned. Building them is the “easy” part… Taking care of them, is the “hard” part. It is important to have some level of tracability of all messages in order for you to shorten incident times and to have full insights into what is actually going on. This is of course just the “half-truth” and on a very abstract level.
This is equally important when it comes to app development, developing the app is the “easy” part, but when it comes to putting the app into production and taking care of if from a maintaining perspective can become the hard part… Therefore we in this post have a look at Function App Logs.
Azure Function Apps helps us in this case – a lot!
Azure Function App Logs
When setting up an Azure Function App, you are required to connect it to an Azure Storage Account (see image 01 below).
You may wonder why this is… Well… there is a good reason and I am loving it! Azure Function Apps have built in logging capabilities as well as built-in statistics support. This allows you to trace every function call, as well as to know how often the function has been executed, how many times it succeeded and how many times it failed. But how do I get access to that you might ask… There are several ways of reading the logs.
Access invocation logs using the Azure WebJobs Dashboard
You might have noticed in the Function App blade, that you have 3 tabs (see image 02 below):
When you click on the Monitor tab, what you get is in the current version a simple coming soon image, but also above the image, two links.
- Invocation Log
- Live Event Stream
I do not need to explain more I guess, when clicking the Invocation Log you come to the Azure WebJobs Dashboard showing you how many times the available functions in your Azure Function App have been called, as well as you get a list of all calls that have been made, showing you the function that has been called, the status (success, etc.) and when the function app has been called. (see image 03 below)
The left column shows the statistics, clicking on one the functions you will get the invocation log of the selected function. The right column shows the invocation log for all functions available in your Azure Function App.
When clicking on one the invocation log rows you will get even more information about the call – basically the information about the request that has been made, as well as it shows you the function output (See Image 04).
Using the webjobs dashboard you get all the information you need in order for you to also troubleshoot. But this is not the only way reading the log of the Azure Function Apps.
Since we know the function app is required to have a storage account, you can imagine what lays beyond that – Azure Tables! 😉
Access invocation logs using the Azure Storage SDK
In order you to access the invocation logs by using Azure’s SDK for Storage Accounts you need to find out (if you forgot) which Storage Account is used. This can be done by following the steps below (see image 05 below).
- Open your Function App in your Azure Portal and click on settings
- Select Application Settings in the Settings blade of your Function App
- Scroll down in the Application Settings blade, down to the App Settings section and look for AzureWebJobsStorage.
The value of the AzureWebJobsStorage App Settings contains the connection string required for you to connect using the SDK. (Please follow this tutorial to get an understanding how the SDK works for Azure Tables).
Connecting using the Azure Storage Explorer you will find out what table the invocation log is saved in. (See image 06 below)
Azure Function Apps will automatically create a new table called “AzureFunctionsLogTable”. This information, together with the connection string is for you enough to get started with the SDK and connect to the Storage Account and do whatever you want with the invocation log.
You can imagine the power of it. Imagine you have 2 or more Azure Function Apps. This means that, whenever one of those fails, you need to know which function fails, find it in the portal and open its invocation log page… This is time consuming, since the number of Azure artifacts grow over time, making it difficult to find stuff. By using the SDK you could create a listener and push the logs to other applications and merge the data of the invocation logs into one application resulting in a single spot to look for your invocation log data.
See a code example below:
Let me know what you think, what you are doing with the logs… what are you missing? I am so far loving it, that we get that much information about the different function calls and it is fairly easy – not like tracking provided by logic apps for instance…