Back in 2017, Our CTO Serkan and other Opsgenie engineers were having a hard time monitoring their Lambda functions. They were used to dive deep inside Java applications with existing tools back at that time, and they were not able to achieve the same level for AWS Lambda functions. They made research on the possible options and came across a tool specialized for serverless monitoring: IOpipe. The problem was IOpipe was only for Node.js and not supporting monitoring AWS Lambda functions written in Java. Serkan decided to create his own way of instrumenting serverless functions written in Java at that point just like IOpipe did for Node.js functions and created a Java library for this purpose. Opsgenie used that library written by Serkan to retrieve monitoring data out of AWS Lambda functions since then. In order to help other people in the serverless community, Thundra came out as a free product at the end of 2017 with a proper UI and support for only Java functions with local tracing. We have been working to provide the best serverless observability since then and now have a mature product supporting both distributed and local tracing for Node.js, Python, Java, .NET and Golang.
With all the respect, our first-ever competitor as a third-party tool, IOpipe was acquired by New Relic and is closing their operation by December 1st. It seems that IOpipe is migrating its customers to New Relic in the meanwhile but there might be some serverless friends who don’t want to take this way. In this blog post, I will guide you on how you migrate your serverless observability to Thundra and what benefits you will receive as a result.
How to remove IOpipe from your stack
Removal of IOpipe is explained below depending on how you used IOpipe:
Using Serverless plugin
You can uninstall it as follows:
- serverless plugin uninstall --name serverless-iopipe-layers
This should both uninstall the plugin and remove it from plugins in serverless.yml. You can remove IOpipe in the custom section of serverless.yml to remove it completely.
Using layers without the IOpipe serverless plugin
Without the plugin, assuming you have done integration by changing your functions handlers to IOpipe wrappers and put IOpipe layers to your function configurations:
- Reset handlers of your functions and remove IOpipe layer configurations.
Adding wrappers to your code, remove changes from your code
If you have used manual instrumentation, you can find substitute mechanisms for manual instrumentation that are easily applied to Thundra.
Using CloudWatch Logs Integration
If you have enabled CloudWatch log collecting, you can remove it by navigating to IOpipe Teams Page, choosing team and deleting AWS role.
Also, you can remove the stack you possibly created before for this role from AWS console.
How to get started with Thundra
After you’re done with removing IOpipe from your serverless stack, it’s normal to worry about integrating with a new tool. Fortunately, we provide different alternatives for getting started with Thundra. Let’s briefly talk about them.
Connecting Thundra to your AWS account and instrumenting seamlessly
In order to let you start troubleshooting your serverless issues as fast as possible, Thundra provides a completely automated way of getting started. In this way, you will need to follow the below steps:
- Step 1: Sign up to Thundra. We don’t require anything but your email, name and of course your password.
- Step 2: Connect Thundra to your AWS account by installing the CloudFormation template that provides. This basically gives access to Thundra on your Cloudwatch logs and Lambda functions in an account.
- Pre-tada moment and Step 3: After you complete this step, you will have a enough level of visibility on your serverless stack. You’ll be able to view all the invocations of all of your functions in an organized way. You can browse your logs very easily which lets you solve the issues faster. You can keep track of your metrics such as memory usage and duration with real-time visibility on Thundra. You can set up alerts on any problems and/or slowdowns in your functions. You may say that already listed enough till this point. Why is this pre-tada, then? Because you didn’t start with what Thundra is actually about yet. Our customers love Thundra with its unique end-to-end full tracing, architectural overview, operations search which gives unmatched wisdom to optimize your serverless stack thoroughly. You need to instrument your functions with Thundra in order to use those features. Bear with me! This is no longer a daunting task with our simplified monitoring over the Thundra console. You will basically need to select the functions that you want to instrument (I recommend selecting all) and click on “Instrument” and you are done! You will see yourself in the “ta-da moment”.
- Ta-da moment: From this point on, you can use the rich features of Thundra to see the architectural visualization of your system, keeping the track of serverless transactions, seeing the timeline of your function invocations method-by-method and even line-by-line. You can navigate in the real examples on our publicly open demo environment.
Some of our customers didn’t want to provide access to Thundra for their AWS accounts but still wanted to take advantage of Thundra visibility to debug, monitor and troubleshoot their serverless environments. For those, there’s still another way and all the steps listed above are optional.
Instrumenting the functions you want to monitor (A more manual way)
This option is for people who don’t want to provide access to Thundra. (you must be more used to this because IOpipe was not asking you to install a CloudFormation). In this way, you need to instrument the functions that you want to see on your Thundra console yourself. However, you aren’t left alone in the darkness because we also have different ways to ease your job to instrument functions. Let me show you the most common way, and let’s talk about the alternatives later.
- Step 1: Add Thundra Layer to your function: In order to include Thundra libraries in your project, you can use the Lambda Layer provided for each programming language. Here is the doc of Node.js on how you can do this.
- Step 2: Make necessary changes in your function: In order to use Thundra with your function, you should make sure that you added Thundra API key to your environment variable
thundra_apiKey. You may also need to make some other minimal changes in your function code like wrapping your handler or putting a decorator on the function depending on the runtime that you are using. You can consult our documentation for this configuration.
- Step 3: Repeat the first 2 steps for all of your functions.
I can feel your disappointment with repeating these steps for all of your functions. Luckily, we also have a solution for that. You can use Thundra’s serverless plugin to instrument all your functions at once. In this way, you can plug Thundra a lot easier and gain the unmatched visibility into your serverless stack.
What are the benefits of having Thundra in your toolset?
The biggest concern before starting for a new tool is whether this tool will provide the benefits that you are looking for. We are confident that Thundra will be part of your software development lifecycle like it is for Arcelik and many more customers. I will go over some key features that will ease your decision-making process for a serverless observability tool.
End-to-end visibility of serverless transactions with full tracing
Serverless applications generally have a distributed nature- functions calling other functions communicating over resources like SQS, SNS- Thundra makes the journey of serverless transactions transparent with
- Distributed tracing that shows how long the interactions between the functions took and what are the messages being exchanged.
- Local tracing that shows how long specific parts in the code took and what are the values of local variables while your code was being executed.
Thundra is unique with this combination of distributed and local tracing and can provide unmatched visibility over serverless transactions. You can debug not only single function but a whole transaction easily.
Architectural overview of your serverless stack
Chasing serverless transactions is great but sometimes all you need to is actually have control over the big picture of your serverless architecture. Thundra automatically discovers and draws the topology diagram of your serverless architecture with helpful metrics such as invocation and error counts, average duration and so on. You can spot the problems happening in your architecture thanks to Thundra’s color-coded diagram and put your focus on that part a lot faster than you could normally do. For example; in the following picture you can detect the issues with PostgreSQL table without even checking any invocation or log. Then, you can dive deeper to analyze the issue and see the sample problematic invocations.
Performance analysis for outliers
Performance optimization never ends in distributed systems. You don’t need to wait for the next alarm to improve the performance of your system. For this purpose, we are using our performance analysis screen internally at Thundra and it helps a lot. With the heatmap which lets you distinguish the long-running invocations easily, you can dive into the root cause of the slow-downs. When you focus on a problematic area, we show you which resources are causing the delay and how many of the long-running invocations are actually cold-started. In the following example; you can see that cold starts and abnormally slow causes the long-running invocations. Now, it’s your turn to figure out if there is something that you can improve related to this.
Debugging serverless apps with detailed granularity
Serverless functions are black-box. All you have is the log statements that you got from the vendor. That was the reason in the first place that you wanted to use IOpipe, right? Thundra gives a line-by-line tracing ability for Node.js, Python, and Java functions. You can see the source code and the values of local variables at each line of the code. In this case, you can understand how your function behaves in the cloud and fix the problems that you detect. In the following view, we see that line 127 took longer than other lines and we can see the code source, the values of the local variables (in our case it is id with String type) to see if there’s a possible fix there.
Reduced MTTR with actionable and flexible alerts
Thundra uses an extensive query language in order to let you navigate into your serverless architecture. The good part is you can save these queries as alert policies and get alerted. For example; you can say that “Alert me when the following queries return more than 5 functions in the last minute:
Health<90 and MonthlyEstimatedCost > 1. Thundra provides unique flexibility with the alerting on serverless systems. If you are looking for a smarter way of alerts rather than getting alerted for every single error, you should definitely give a try to Thundra.
IOpipe was letting its users define their own custom metrics and query it on their application. Thundra has the same capability as a feature called “Tags”. You can basically send as many metrics as you want to Thundra and use these tags to filter your data. In the following days, we will add the possibility of drawing custom charts using the custom metrics. In this way, you won’t be limited to Thundra’s own way of data representation but you will be able to interpret your data in your own preferred way.
It was always nice to compete with IOpipe and we’ll continue to compete with them which will provide useful tools and approaches for the serverless community. In this post, we tried to list possible migration options and benefits of using Thundra for your continuing serverless observability needs. You can either directly sign up to Thundra or you can subscribe to our service from AWS Marketplace. Please hit us with new questions over Twitter and reach out to us over email. Don’t forget to stop by Thundra booth with #627 at AWS re:Invent and let’s have some serverless chat.