x

Meet with us at AWS re:Invent and learn a better way to troubleshoot and secure your applications. Schedule Now!

Monitoring Golang AWS Lambda functions in deep with no code change!

Apr 4, 2019


mastering-java-blog-middle

Thundra’s Go agent has gained a bunch of great capabilities with our latest announcement of OpenTracing compatible manual instrumentation. We can create multiple spans manually, add logs, metrics, and tags to achieve more meaningful and handy traces. Today, we are proud of making another great progress in achieving our goal of fully automated instrumentation for serverless Go functions. We are announcing both the HTTP and the AWS SDK Integration for Thundra’s Go Agent!

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:

go-1

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.

go-2 

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:

go-3

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:

go-4

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 your architecture of your Go lambda functions in Thundra Web console! To recall, our architecture view lets serverless

go-5

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

Conclusion

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 to our web console and start experimenting with Thundra. Don’t forget to explore our demo environment — no sign up needed. We are very curious about your comments and feedback. Join our Slack channel or send a tweet or contact us from our website!