feat: add request measurement for requests

[stijnmoreels]

Use a new RequestMeasurement object to measure requests.

Closes #268

[netlify]

✔️ Deploy Preview for arcus-observability ready!

🔨 Explore the source changes: 730bb27

🔍 Inspect the deploy log: https://app.netlify.com/sites/arcus-observability/deploys/61efa4f6ba241c000856953d

😎 Browse the preview: https://deploy-preview-270--arcus-observability.netlify.app

[stijnmoreels]

Point of notice: the current .LogRequest and its overloads don't use the DepenencyMeasurement, so no obsolete-making was necessary. They use a single TimeSpan for duration and are using the DateTimeOffset.UtcNow internally as start time.

[fgheysels]

Great, nice implementation & docs!

I just wonder why the LogHttpRequest methods do take a Timespan as argument instead of a RequestMeasurement ?

[stijnmoreels]

Great, nice implementation & docs!

I just wonder why the LogHttpRequest methods do take a Timespan as argument instead of a RequestMeasurement ?

They use DateTimeOffset.UtcNow internally as startTime. This is more a convenience here, bc it allows users not to worry about this. These extensions are for example used in the request middleware of our Web API where can directly call this, and it uses the current time as start time.
Other than Azure Service Bus (where you have to peek/receive the message yourself), this start time can be a little different, so we allow consumers to determine themselves when it should be tracked.

But you're actually right. We could have additional extension methods that takes in this measurement. But since there's nobody yet asking about it, I'm not sure if we should. On the other hand, one could argue if we should then include it here 😉 .

[fgheysels]

Great, nice implementation & docs!
I just wonder why the LogHttpRequest methods do take a Timespan as argument instead of a RequestMeasurement ?

They use DateTimeOffset.UtcNow internally as startTime. This is more a convenience here, bc it allows users not to worry about this. These extensions are for example used in the request middleware of our Web API where can directly call this, and it uses the current time as start time. Other than Azure Service Bus (where you have to peek/receive the message yourself), this start time can be a little different, so we allow consumers to determine themselves when it should be tracked.

But you're actually right. We could have additional extension methods that takes in this measurement. But since there's nobody yet asking about it, I'm not sure if we should. On the other hand, one could argue if we should then include it here 😉 .

I was just thinking: why not being consistent and use the measurements types there as well. But if you have a good reason we can leave it as is. If we have a request for this, we can add it indeed.