Once your API is running in production, you realize the necessity of having end-to-end traceability of every single API call.  So, it’s better to think about it upfront.  This blog shows you an easy way to achieve this.

Configure Application Insights

Let’s set up integration with Application Insights

• Create an Azure Application Insights instance
• Add a Logger under the Application Insights tab

• Configure monitoring for All APIs

Configure the global policy

Configure the global policy, so it affects all API calls.  This inbound policy performs the following actions:

• Take the consumer-provided correlation-id from the x-correlation-id HTTP header or generate a new guid if none is provided
• Set the correlation id in the HTTP header for downstream traceability
• Log the correlation id with a descriptive context to App Insights via the Trace policy

<!--Use consumer correlation id or generate new one-->
<set-variable name="correlation-id" value="@(context.Request.Headers.GetValueOrDefault("x-correlation-id", Guid.NewGuid().ToString()))"/>

<!--Set header for end-to-end correlation-->
<set-header name="x-correlation-id" exists-action="override">
   <value>@((string)context.Variables["correlation-id"])</value>
</set-header>

<!--Trace the correlation id-->
<trace source="Global APIM Policy" severity="information">
   <message>@(String.Format("{0} | {1}", context.Api.Name, context.Operation.Name))</message>
   <metadata name="correlation-id" value="@((string)context.Variables["correlation-id"])"/>
</trace>

With this simple outbound policy, we return the correlation id, so it can be used for troubleshooting.

<!--Set header for end-to-end correlation-->
<set-header name="x-correlation-id" exists-action="override">
   <value>@((string)context.Variables["correlation-id"])</value>
</set-header>

Enjoy the result

As a test, I called my Communication API without providing a correlation-id.  I used the returned correlation-id, for a Transaction search in my connected Application Insights instance.

• Searching on the unique correlation-id, returns this little trace

• When clicking on the trace result and choosing for the View timeline option, you can find all details of this API call

This timeline nicely shows what my Communication API is doing:

• The API call is received by API Management
• It forwards the call to a Logic App (preview)
• The Logic App consumes an Azure Function to perform a Liquid transformation
• The Azure Function relies on Azure Storage to retrieve the Liquid templates
• The Logic App sends an email via the Office365 connector

These interactions are also visible within the Application Map:

Conclusion

It’s important to understand that the correlation between all the Azure components is done “auto-magically”, by just enabling Application Insights on every individual service.  By linking this very valuable information to a single API call, via a consumer-provided correlation-id, we can easily find out what went wrong during troubleshooting.

A great way to run your API platform!

Cheers,
Toon