3 minutes read

POSTED Apr, 2019 dot IN Serverless

Monitoring Golang AWS Lambda functions with no code change!

Hamit Burak Emre

Written by Hamit Burak Emre

Ex-Software Engineer @Thundra


Thundra’s Go agent has a bunch of great capabilities with its OpenTracing compatible instrumentation. It is capable of automatically instrumenting your serverless Go functions. You can both use HTTP and the AWS SDK to auto instrument your functions with Thundra's Go agent and get started monitoring your workloads.

Additionally, you can create multiple spans manually, add logs, metrics, and tags to achieve more meaningful and handy traces.

AWS SDK Integration

As we can do for our Java, Node.js, and Python agents, our Go agent can automatically trace and collect useful information about your AWS SDK requests now. The great thing is that it provides all this information with almost no code change (just 1 additional line). All you have to do is to wrap your aws.Session object with thundraaws.Wrap method and use this session object to create AWS services as normal. Thundra’s Go agent will handle the creation of the corresponding spans for AWS SDK calls and the addition of useful information for each of the supported services which are the followings:

  • DynamoDB
  • Lambda
  • SQS
  • SNS
  • S3
  • Kinesis
  • Firehose

 Using this information, you can gather a handful of insights about your serverless application with minimal effort. For example; you can measure the requests to the DynamoDB table and detect the bottlenecks occurring because of AWS resources.

HTTP Integration

In addition to the AWS SDK Integration, now you can also trace your HTTP calls using the new HTTP integration of our Go agent. Just like the AWS SDK integration we have mentioned above, it requires almost no code change(again just 1 additional line). This time you have to wrap http.Client with the thundrahttp.Wrap and then use the wrapped client to make your HTTP clients. Thundra’s Go agent will create the corresponding spans for your HTTP calls and adds some useful information about your requests like the host, the path, and the query parameters.

New integrations in action

Let’s see a demo lambda function that shows what these new integrations provide us. In this lambda function, we will first get some messages from SQS. Then, we will extract the `userId` attribute from these messages. We will look for the user with `userId` in DynamoDB and in another external server by making an HTTP call. If we will not be able to find the user, then we will create a new user in DynamoDB and publish an SNS message. 

In our handler let’s first create a session object that we are going to use to create AWS service clients like DynamoDB, SQS, and SNS: 

sess, err := session.NewSession(&aws.Config{
Region: aws.String("us-west-2"),

Now, let’s wrap this session object to use Thundra’s AWS Integration:

sess = thundraaws.Wrap(sess)

We can use this wrapped session object to create the AWS service clients that we are going to use as normal:

sqsClient := sqs.New(sess)
dynamoClient := dynamodb.New(sess)
snsClient := sns.New(sess)

Let’s also create and wrap the HTTP Client that we are going to use to make HTTP requests in one line:

httpClient := thundrahttp.Wrap(http.Client{})

We have our AWS service clients and HTTP client ready to use, from now on all we have to do is using these clients just like we normally do. Resulting trace should look like as follows:


As you can see in the trace chart even though we didn’t explicitly create any span, we have spans representing our AWS SDK calls and the HTTP call! That’s because integrations created spans automatically for us. Let’s see what else integrations provided us by clicking the spans.


When we clicked the first DynamoDB span, we see that in the Summary tab we have some useful information like Operation Type, Table Name, Request Name, and the Statement. If you don’t want your statements to be collected you can also disable it by setting “thundra_agent_lambda_trace_integrations_aws_dynamodb_statement_mask” environment variable to true. 

Let’s see the HTTP span this time and see why we have an error sign in our HTTP request:


This time we have URL, Query Params and Method information in the Summary tab. See that it also says that we have an error about this span. Let’s switch the Tags tab of the HTTP span to see what is the corresponding error message:


With spans are created and identified automatically using the AWS SDK and the HTTP integrations of Thundra’s Go agent, you will also be able to see the architecture of your Go lambda functions in Thundra APM's console! 


To recall, our architecture view lets serverless developers see the problematic interactions in the application at a glance. When you see an error that is not green, you can see that there are some errors happening between a Lambda function and the resource. Clicking on an edge enables one to see the problems in the architecture. Detailed information about our architecture view can be seen in our blog


We have seen how much useful information Thundra’s Go agent can provide us about our lambda function by just adding 2 lines, with the help of the new HTTP and AWS SDK integrations. It's great to have automatically created spans and the bird’s eye view of our architecture for free, without using the OpenTracing interface to explicitly create spans. Also, this was only a start for the Thundra’s Go agent’s integrations, and it will continue with the integrations like Redis, MySQL, Elasticsearch, MongoDB, and many more.

 You can sign up for Thundra APM and start experimenting with Thundra. Don’t forget to explore our demo environment  (no sign-up or credit card required!). We are very curious about your comments and feedback. Join our community Slack or send a tweet or contact us via our website!