Thundra

Thundra: Serverless Observability for AWS Lambda

The black box nature of AWS Lambda and other serverless environments means that identifying and fixing performance issues is difficult and time-consuming. Built for straightforward debugging, monitoring, and observability, Thundra provides deep insight into your entire serverless environment. Thundra collects and correlates all your metrics, logs, and traces, allowing you to quickly identify problematic invocations and also analyzes external services associated with that function. With Thundra’s zero overhead and automated instrumentation capabilities, your developers are free to write code without worrying about bulking up their Lambdas or wasting time on chasing black box problems.

Get Started    Discussions

Configuration

If your Lambda functions are wrapped by Thundra agent, there is no additional effort required.

You just need to specify Lambda functions to be monitored. There are two ways for this:

  • Active way: Lambda functions to be warmed-up are specified by thundra_lambda_warmup_function environment variable as comma separated. This environment variable is put onto thundra-lambda-warmup Lambda function. For example environment variable key (name) is thundra_lambda_warmup_function and value is my-func-1,my-func-2,my-func-3
  • Passive way: Lambda functions to be warmed-up declare themselves by thundra_lambda_warmup_warmupAware environment variable enabled (environment variable key (name) is thundra_lambda_warmup_warmupAware and the value is true). Note that this environment variable is put onto Lambda function to be warmed-up (NOT onto thundra-lambda-warmup Lambda function).

By default Lambda functions are warmed-up with concurrency factor 8 which is the number of warmed-up container count to be kept up . This factor can be configured by thundra_lambda_warmup_invocationCount environment variable. In here there are a few points you should know:

  • This approach is just best effort way for keeping multiple containers up. So this means that even though concurrency factor is 8, there is no guarantee that there are exactly 8 containers up. There are might be more or less containers up. But in practice, mostly there are 8 containers up as we tested since long time.
  • In addition, even though there are active containers and they are not busy with the invocation, AWS Lambda might dispatch the request to a new container. So this leads to cold start unfortunately.

As a result, thundra-lambda-warmup Lambda function can dramatically reduce your cold starts (it is battle-tested on production). However keep in mind that it is not %100 cold start free and cannot guarantee that there won't be any cold start due to reasons explained above.

NOTE: Currently all the agents (Java, Node.js, Python, Go and .NET agents) have warmup support.

See here for more details.

Java Agent Specific Configurations

ThundraLambdaRequestHandler

If your Lambda function implements from com.opsgenie.thundra.lambda.core.ThundraLambdaRequestHandler, you need to provide information about request POJO whether it is empty due to warmup message. There are two ways for providing this information:

  • Override isEmptyRequest method ThundraLambdaRequestHandler in your Lambda handler and decide yourself whether received request is empty (warmup) message. For example:
...

import com.amazonaws.services.lambda.runtime.Context;
import com.opsgenie.thundra.lambda.core.ThundraLambdaRequestHandler;

...

public class UserGetHandler 
        implements ThundraLambdaRequestHandler<UserGetRequest, UserGetResponse> {

    ...

    @Override
    public boolean isEmptyRequest(UserGetHandler.UserGetRequest request, Context context) {
        return StringUtils.isNullOrEmpty(request.getCallerId()) && 
                StringUtils.isNullOrEmpty(request.getId());
    }

    ...

}
  • Implements isEmpty method from com.opsgenie.thundra.lambda.core.ThundraSelfAware in your request class and let the request POJO decide itself whether it is empty (warmup) message. For example:
...

import com.opsgenie.thundra.lambda.core.ThundraSelfAware;

...
  
public static class UserGetRequest implements ThundraSelfAware {

    ...

    @Override
    public boolean isEmpty() {
        return StringUtils.isNullOrEmpty(callerId) && 
          StringUtils.isNullOrEmpty(id);
    }

    ...

}

ThundraLambdaRequestStreamHandler

If your Lambda function implements from com.opsgenie.thundra.lambda.core.ThundraLambdaRequestStreamHandler, you DON'T need to take any extra action for handling warmup messages. Warmup messages are detected and ignored by Thundra without triggering your code.

.Net Agent Specific Configurations

ThundraLambdaRequestHandler

When enabling warm up functionality for your .Net Lambda functions using Thundra, make sure to implement the 'IsEmpty' method that is implemented when the 'ISelfAware' class is extended to your Request object class.

For example, if your handler class extends the Thundras Lambda Request Handler as below:
public class HandlerClass : LambdaRequestHandler<GetAlbumRequest, Album>
then you must extend 'ISelfAware' in the GetAlbumRequest class.

using Thundra.Agent.Lambda.Core;

namespace dotnet
{
    public class GetAlbumRequest : ISelfAware
    {
        public int id { get; set; }

        public GetAlbumRequest()
        {
        }

        public bool IsEmpty()
        {
            return id.Equals(0);
        }
    }
}

Non-Object Request

If you are not passing an object as a request, and instead, a string for example, then you do not have to implement the IsEmpty method. The same goes for dealing with Stream handlers.

Configuration


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.