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

Trace Support

Thundra's .NET agent allows you to use trace data to evaluate the running of your function in terms of duration and response and request. At the moment, the automatic instrumentation feature is not available in our dotnet agent, only manual instrumentation with OpenTracing is available. The Automatic instrumentation is currently under development and will be released in next months. Nevertheless, even you do not instrument your code with OpenTracing spans; essential trace support is available for your .NET functions.

Manual Instrumentation with OpenTracing

Thundra’s agents are fully compliant with OpenTracing API(If you are not familiar with OpenTracing terminology, you could check this documentation). It means that you can access Thundra’s tracer via OpenTracing’s GlobalTracer instance and build new spans and add some business information to increase observability. The Thundra agent is already creating the root span automatically, where you can track the request time. Also, you can create individual span for the parts of your function that you want to monitor (for database requests, external web service calls, or business transactions). Sample code is as follows.

using System;
using System.Linq;
using System.Threading;
using Amazon.Lambda.Core;
using Microsoft.Extensions.Logging;
using Thundra.Agent.Lambda.Core;
using Thundra.Agent.Log.AspNetCore;
using OpenTracing.Util;
using OpenTracing;

[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.Json.JsonSerializer))]
namespace blog_opentracing
{
    public class Function : LambdaRequestHandler<string, string>
    {
       public override string DoHandleRequest(string request, ILambdaContext context)
       {
           
           var loggerFactory = new LoggerFactory().AddThundraProvider();
           var logger = loggerFactory.CreateLogger<Function>();

           Console.WriteLine("Hello OpenTracing.");

           ValidateEntity();
           using (IScope updateEntityScope = GlobalTracer.Instance.BuildSpan("UpdateEntity").StartActive(finishSpanOnDispose: true))
           {
               updateEntityScope.Span.SetTag("updatedEntityID", 1);
               updateEntityScope.Span.SetTag("entitySize","1KB");
               using (IScope updateDatabaseScope = GlobalTracer.Instance.BuildSpan("UpdateDatabase").StartActive(finishSpanOnDispose: true))
               {
                   UpdateDatabase();
               }
           }

           return request?.ToUpper();
       }

       private void ValidateEntity() {
           IScope validationScope = GlobalTracer.Instance.BuildSpan("Validation").StartActive(finishSpanOnDispose: true);
           //some validations...
           validationScope.Dispose();
       }

       private void UpdateDatabase()
       {
           //some database calls...
       }
   }
}

The resulting trace chart that you will see in Thundra web console for this function, will be like the following image.

As you can see, there is a root span that Thundra automatically created, and other spans are the child of the root span, as they should be.

Configuration with SAM Template

You do not have to change your every function separately to achieve observability with Thundra if you are using SAM to deploy your serverless application. You can change your SAM template.yaml as follow:

...

FirstFunction:
       Type: AWS::Serverless::Function 
       Properties:
           Handler: Thundra.Agent.Lambda::Thundra.Agent.Lambda.Core.ThundraProxy::Handle
           Environment:
               Variables:
                   thundra_agent_lambda_handler: <your_handler>
                   thundra_apiKey: <your_api_key>

   SecondFunction:
       Type: AWS::Serverless::Function 
       Properties:
           Handler: Thundra.Agent.Lambda::Thundra.Agent.Lambda.Core.ThundraProxy::Handle
           Environment:
               Variables:
                   thundra_agent_lambda_handler: <your_second_handler> 
                   thundra_apiKey: <your_api_key>

...

You should replace all your handler to “Thundra.Agent.Lambda::Thundra.Agent.Lambda.Core.ThundraProxy::Handle” and give the real handler path as environment variable separately.

Configuration with Serverless Framework

You do not have to change your every function separately to achieve observability with Thundra if you are using Serverless framework to deploy your serverless application. You can change your serverless.yml as follow:

...

functions:
  FirstFunction:
    handler: Thundra.Agent.Lambda::Thundra.Agent.Lambda.Core.ThundraProxy::Handle
    environment:
      thundra_agent_lambda_handler: <your_handler>
      thundra_apiKey: <your_api_key>

  SecondFunction:
    handler: Thundra.Agent.Lambda::Thundra.Agent.Lambda.Core.ThundraProxy::Handle
    environment:
      thundra_agent_lambda_handler: <your_second_handler>
      thundra_apiKey: <your_api_key>

...

You should replace all your handler to “Thundra.Agent.Lambda::Thundra.Agent.Lambda.Core.ThundraProxy::Handle” and give the real handler path as environment variable separately.

Configuring Trace

Trace support can be configured in three various ways. This involves programmatic configuration, configuration via environment variables, and finally, using configuration files. All three ways allow you to configure your .NET function to enable and disable trace support. By default, trace support is enabled, and upon invoking your lambda expression you can always procure its trace data on the Thundra console.

Dependency when using Programmatic Configuration

If you opt to disable your trace data using programmatic configuration, please ensure you state using Thundra.Agent.Lambda.Config;

 protected override ThundraConfig GetConfig()
 {
   var config  =  new ThundraConfig();
   config.ApiKey = "demo_thundra_Api_Key";
   config.DisableTrace = "true";
   return config;
 }
{
    "thundra": {
        "properties": {
            "thundra_apiKey" : "demo_thundra_Api_key",
          	"thundra_agent_lambda_trace_disable": "true"
        }
    }
}

Viewing Trace

Trace data of your .NET Lambda invocations can be seen when you enter the Invocations detail page displaying information about specific information. The trace data is present in the Trace Chart section of the page and upon clicking on the trace you can view the trace 'Summary', 'Logs', and 'Tags'.

Configuring Trace Response/Request

If you would like to disable the 'Response' or 'Request' data that can be viewed when you open your trace data then you can also go about one of the three ways as described when configuring the main trace data above. here you shall use the following environment variables and parameters:

Environment Variables

  • thundra_agent_lambda_trace_response_skip - Set to 'true' to disable response data
  • thundra_agent_lambda_trace_request_skip - Set to 'true' to disable request data

Programmatic Parameters

  • SkipResponse - Set to 'true' to disable response data
  • SkipRequest - Set to 'true' to disable request data

Trace Support


Suggested Edits are limited on API Reference Pages

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