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

Installation and Configuration

Installation

Installation of Thundra's .NET agent can be done in two ways, both of which are extremely simple. This includes installation through NuGet or through the Thundra template which you can add on into your dotnet CLI templates.

NuGet

The .NET Thundra agent can simply be downloaded with the command below:

dotnet add package Thundra.Agent.Lambda --version 1.0.0

Similarly, including agent can be done via the NuGet Package Manager of your IDE if it is available. For example, Visual Studio allows you to add packages through the IDE itself, and a simple search of Thundra .NET will allow you to procure the correct agent to be added to your project.

After installation, you shall now be required to wrap your handler function with Thundra's .NET agent, and this is done by first calling for the agent with the using statement.

Next, you should extend Thundra's LambdaRequestHandler within your handler class and override the DoHandleRequest method which basically encapsulates your handler code. This can be seen in the illustration below.

Using Thundra Template

Thundra provides a template for .NET that can be accessed from the dotnet CLI. This approach will set up a basic Lambda function already configured with the basic Thundra dependencies and monitoring capabilities, and you may simply build your project starting off with the template.

To use the template, you must first install the template into your dotnet CLI by using the command:

dotnet new -i Thundra.Templates

After installing the template, you will be able to see it listed along with all the previous templates already included in your dotnet CLI, with the command:

dotnet new -all

You may then set up the template in the template of your choice using the short name of the template with the command:

 dotnet new thundra.Sample

Configuration

Configuring your Lambda functions allows you to control what information you would like to monitor and how you would like to monitor it. Thundra for .NET functions can be configured in three ways, providing flexibility in how you prefer to monitor your applications. These include:

Programmatic Configuration - Setting initialization parameters in modules

Configuration via Enviornment Variables - Setting environment variables in AWS console

Configuration Files - Using .json file to configure monitoring

A detailed list of configuration variables can be found here.

Programatic Configuration

Thundra allows you to configure your monitoring experience within your code itself. The first thing you need to do is ensure that you import the Thundra.Agent.Lambda.Config dependency by using the using statement that will allow you to set configuration variables programmatically. Hence you must state using Thundra.Agent.Lambda.Config; along with all other required function dependencies.

Programmatic configuration after importing the required config dependency can be done by overriding the Thundra's GetConfig method when you extend Thundra's LambdaRequestHandler<string, string> in your handler class. At the end of the method, you will return an instance of a ThundraConfig instance with your preferred configurations. This can be done as is shown in the code snippet below:

using Thundra.Agent.Lambda.Config;

namespace demoThundra
{
    public class Function : LambdaRequestHandler<string, string> 
    {
        public override string DoHandleRequest(string request, ILambdaContext context)
        {
            return "Hello Thundra";
        }
    }
    protected override ThundraConfig GetConfig()
    {
        var config  =  new ThundraConfig();
        config.ApiKey = "demo_thundra_Api_Key";
        return config;
    }
}

If you use the method .LoadProperties() your 'ThundraConfig()' object takes in the values of the environment variables.

For example, in the code snippet below, if the api key is set up programmatically, but if the environment variables are also used to configure the api key, then config.LoadProperties() takes up the api key from the environment variables.

protected override ThundraConfig GetConfig()
{
  var config  =  new ThundraConfig();
  config.ApiKey = "demo_thundra_Api_Key";
  config.LoadProperties();
  return config;
}

There are several programmatic variables which you can use and a full list can be found in .NET's Configuration Variables and Parameters section.

Configuration via Environment Variables

This allows you to set Thundra’s environment variables in your AWS lambda function console itself. Hence allowing you to set them through AWS. Moreover, environment variables can be set when using the AWS dotnet CLI by setting environment variables in the aws-lambda-tools-defaults.json file.

When manually putting environment variables through the AWS console, you can use the 'tags' field on the AWS Lambda console after you have uploaded your Lambda function to the console.

An alternative regarding adding environment variables to your Lambda functions is using the AWS dotnet tools to deploy your function. In that case, you can add your environment variables in the aws-lambda-tools-defaults.json file that AWS provides for you to configure when deploying your .NET Lambda function via the AWS tool. Below is a snippet of the configuration variables as present in a file, with the environment-variables tag holding the environment variables you would like to put up.

{
  "Information": [
    "This file provides default values for the deployment wizard inside Visual Studio and the AWS Lambda commands added to the .NET Core CLI.",
    "To learn more about the Lambda commands with the .NET Core CLI execute the following command at the command line in the project root directory.",

    "dotnet lambda help",

    "All the command line options for the Lambda command can be specified in this file."
  ],

  "profile": "DefaultProfile",
  "region": "DefaultRegion",
  "configuration": "Release",
  "framework": "netcoreapp2.1",
  "function-runtime": "dotnetcore2.1",
  "function-memory-size": 256,
  "function-timeout": 30,
  "function-handler": "BlueprintBaseName.1::BlueprintBaseName._1.Function::FunctionHandler",
  "environment-variables" : "\"thundra_apiKey\"=\"thundra_demo_api_key\";\"thundra_agent_lambda_trace_request_skip\"=\"true\";\"thundra_agent_lambda_metric_disable\"=\"true\""
}

For a detailed list of all the environment variables, you can check out the .NET Configuration Variables and Parameters section.

Configuration Files

Another way you may configure Thundra's .NET agent is by using configuration files in which you specify all your preferred configurations with the available list of environment variables. Below is an example of a configurations file:

{
    "thundra": {
        "properties": {
            "thundra_apiKey" : "demo_thundra_Api_key",
            "thundra_agent_lambda_debug_enable" : "true"
        }
    }
}

The configuration file should preferably be located in the root of your project and should be loaded to your project by including it in your .csproj file as a <ItemGroup>.

<ItemGroup>
      <None Include="thundra-config.json" CopyToOutputDirectory="Always" />
 </ItemGroup>

Additional Configs

The configuration file can facilitate configurations of other services and resources that your project may need, and simply need to be specified under a different field, but thundra should be present.

Installation and Configuration


Suggested Edits are limited on API Reference Pages

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