As we’ve been looking at how to run GraphQL on Azure we’ve covered several topics of importance with Azure integration, but what we haven’t looked at is how we make sure that we are getting insights into our application so that if something goes wrong, we know about it. So for this post we’re going to address that as we take a look at logging using theAzure Application Insights platform (often referred to as AppInsights).

If you’re deploying into Azure in the ways that we’ve looked at in this series, chances are you’re already using AppInsights, as it’s the cornerstone of Azure’s monitoring platform, so let’s look at how to get better insights out of our GraphQL server.

Side note: There’s a lot more you can do with AppInsights in monitoring your infrastructure, monitoring across resources, etc., but that’ll be beyond the scope of this article.

Tracing Requests

Apollo has aplugin system that allows us to tap into the life cycle of the server and requests it receives/responds to, so that we can inspect them and operate against them.

Let’s have a look at how we have create some tracing through therequest life cycle with a custom plugin.

We’ll need theapplicationinsights npm package, since this is a Node.js app and not client side (there’s different packages depending if you’re doing server or client side JavaScript).

I’m also going to use theuuid package to generate a GUID for each request, allowing us to trace the events within a single request.

Let’s get started coding:

import{ApolloServerPlugin,GraphQLSchemaContext,GraphQLServerListener}from"apollo-server-plugin-base";import{TelemetryClient}from"applicationinsights";import{v4asuuid}from"uuid";exportdefaultfunction(input:string|TelemetryClient,logName?:string):ApolloServerPlugin{letclient:TelemetryClient;if(typeofinput==="string"){client=newTelemetryClient(input);}else{client=input;}return{};}

Here’s the starting point. I’m making this a generic plugin that you can either pass in the Instrumentation Key for AppInsights, or an existingTelemetryClient (the thing you create using the npm package), which allow you create a unique client or share it with the rest of your codebase. I’ve also added an optionallogName argument, which we’ll put in each message for easy querying.

Time to hook into our life cycle:

exportdefaultfunction(input:string|TelemetryClient,logName?:string):ApolloServerPlugin{letclient:TelemetryClient;if(typeofinput==="string"){client=newTelemetryClient(input);}else{client=input;}return{requestDidStart(context){constrequestId=uuid();constheaders:{[key:string]:string|null}={};if(context.request.http?.headers){for(const[key,value]ofcontext.request.http.headers){headers[key]=value;}}client.trackEvent({name:"requestDidStart",time:newDate(),properties:{requestId,metrics:context.metrics,request:context.request,headers,isDebug:context.debug,operationName:context.operationName,operation:context.operation,logName}});}};}

TherequestDidStart method will receive aGraphQLRequestContext which has a bunch of useful information about the request as Apollo has understood it, headers, the operation, etc., so we’re going to want to log some of that, but we’ll also enrich it a little ourselves with arequestId that will be common for allow events within this request and thelogName, if provided.

You might be wondering why I’m doingheaders in the way I am, that’s becausecontext.request.http.headers is anIterable and won’t get serialized properly, so we need to convert it into a standard object if we want to capture them.

We send this off to AppInsights usingclient.trackEvent:

client.trackEvent({name:"requestDidStart",time:newDate(),properties:{requestId,metrics:context.metrics,request:context.request,headers,isDebug:context.debug,operationName:context.operationName||context.request.operationName,operation:context.operation,logName}});

Thename for the event will help us find the same event multiple times, so I’m using the life cycle method name,requestDidStart, and popping the current timestamp on there. Since I’m usingtrackEvent this will appear in thecustomEvents table within AppInsights, but you could usetrackTrace or any of the other tables for storage, depending on how you want to query and correlate your logs across services.

This is an example of how that will appear in AppInsights, you can see the custom information we’ve pushed, such as the GraphQL operation and it’s name, the headers, etc.

We could then write a query against the table for all operations namedTestQuery:

customEvents| extend req = todynamic(tostring(customDimensions.["request"]))| where req.operationName == 'TestQuery'

The plugin can then be expanded out to cover each of the life cycle methods, pushing the relevant information to AppInsights, and allowing you to understand the life cycle of your server anf requests.

Conclusion

This is a really quick look at how we can integrateAzure Application Insights into the life cycle of Apollo Server and get some insights into the performance of our GraphQL server.

I’ve created aGitHub repo with this plugin, and it’savailable on npm.

There’s another package in the repo,apollo-server-logger-appinsights, which provides ageneric logger for Apollo, so that any logging Apollo (or third-party plugins) does will be pushed to AppInsights.

Happy monitoring!