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

Using traces, you can gain end-to-end visibility on what's happening inside your functions. It helps you to pinpoint the problematic areas and latencies in your application. Thundra's agents are OpenTracing completable. You can use OpenTracing API to create custom spans, set tags to the current span. The .NET agent also has automatic instrumentation capability for most used AWS SDK libraries since version 1.2. You do not have to change your code to monitor the relation between your Lambda and the other AWS services. Check Trace AWS SDK for more information.

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;

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.

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.