Add request logging in the Arcus.Templates.AzureFunctions.Http template

[pim-simons]

The Arcus.Templates.AzureFunctions.Http looks amazing and will save me a lot of time in the future setting up new HTTP triggered Functions!

I usually add a Logger.LogRequest in the finally statement of the try catch so I log the original request, how long it took to process it and optionally some telemetryContext. In the Arcus.Templates.AzureFunctions.Http it would look like the code below (in the code in the try I also set the httpStatusCode if the IsJson or AcceptsJson or TryHttpCorrelate fails).

var httpStatusCode = System.Net.HttpStatusCode.OK;
var stopWatch = Stopwatch.StartNew();
var telemetryContext = new Dictionary<string, object>();

try 
{
...
}
catch (JsonException exception)
{
   Logger.LogError(exception, exception.Message);
   httpStatusCode = System.Net.HttpStatusCode.BadRequest;
   return BadRequest("Could not process the current request due to an JSON deserialization failure");
}
catch (ValidationException exception)
{
   Logger.LogError(exception, exception.Message);
   httpStatusCode = System.Net.HttpStatusCode.BadRequest;
   return BadRequest(exception.ValidationResult);
}
catch (Exception exception)
{
   Logger.LogCritical(exception, exception.Message);
   httpStatusCode = System.Net.HttpStatusCode.InternalServerError;
   return InternalServerError("Could not process the current request due to an unexpected exception");
}
...
finally
{
   Logger.LogRequest(request, (int)httpStatusCode, stopWatch.Elapsed, telemetryContext);
}

My question is if this is good practice to log the request like this? And if so, maybe it can be added to the Arcus.Templates.AzureFunctions.Http template?
I can create a PR for this but first wanted to check if the setup is correct.

[stijnmoreels]

First of all: thanks for the feedback on the template! We hope it does help in the future to kickstart your next project!

About your idea: good thinking! Request tracking is indeed something we have not yet added to the template; but could definitely be included. As far from the approach you took. Since there's no middleware (by default, built-in or provided by Microsoft) we are left with our own implementation. So tracking the request in the finally seems ok to me.
Some contextual information would be nice indeed. We could also look for options to include some request headers or even parts of the body in the context (like we did for our web API request tracking).

Adding @tomkerkhove for the final approval for this to be added as an issue.

[tomkerkhove]

Fine by me

[stijnmoreels]

Tracked here: #312