Zero Overhead with Asynchronous Monitoring

Using Thundra, you can monitor and troubleshoot your serverless-centric system and get insights about the whole architecture. Thundra allows you to instrument your application with no code change. You can send these monitoring data to have these insights in two ways:

  • Synchronous monitoring

  • Asynchronous monitoring

To send data synchronously to Thundra, an HTTP call to Thundra's collector is made by your Lambda function before invocation ended. This method is quite easy but can be risky. HTTP call can be failed, there could be latency during this call and all of these issues can affect your Lambda function's performance. Also, making an HTPP call will add a duration overhead to execution time of your Lambda function. At this point, Asynchronous monitoring is provided by Thundra with zero overhead.

In async approach, trace, metric and log data is structured in JSON format to be written to CloudWatch. After that the data is gathered by Thundra's AWS integration working in your account. In this way, the observability data becomes visible in your Thundra console slower (depends on the when it appears at CloudWatch) than synchronous but you're getting rid of the communication overhead which can go up to 100ms when the observability data is too big.

Configuring asynchronous monitoring is quite easy. Just set the following environment variable to true in your Lambda function and make sure that you're using Thundra's AWS integration.

thundra_agent_lambda_report_cloudwatch_enable

If you aren't using AWS integration, you'll need to install a Lambda function called thundra-lambda-adapters-cw.

There are three ways of installing thundra_lambda-adapters_cw to your AWS account:

Manual Setup of Async

1. Setup “thundra-lambda-adapters-cw”

Thundra provides an AWS CloudFormation template to setup thundra-lambda-adapters-cw Lambda function with required configurations, permissions and roles on user end.

  • Access CloudFormation on AWS console.

  • Click Create Stack

  • Enter stack name such as thundra-lambda-adapters-cw-stack, configure memory size and timeout parameters if needed, and click Next

  • No need to add extra options, so click Next

  • Select I acknowledge that AWS CloudFormation might create IAM resources with custom names. under Capabilities section and click Create.

  • Then stack creation starts. You need to wait until creation process ended.

2. Subscribe to Lambda functions to be monitored

Go to the thundra-lambda-adapters-cw function in the AWS Lambda console. For each Lambda function to be monitored:

  • Add CloudWatch Logs trigger

  • Configure trigger

    • Log Group: Name of the log group of the Lambda function to be monitored. Log group is in the /aws/lambda/<function-name> format.

    • Filter Name: Enter the desired name of the filter

    • Filter Pattern: Pattern to filter AWS CloudWatch logs to accept only formatted monitor data. It must be {$.type = Invocation || $.type = Trace || $.type = Span || $.type = Metric || $.type = Log || $.type = Composite} and click Add

  • Then click Save to apply the changes.

Serverless Framework

You need to install our custom serverless plugin, but before installing that, please keep in mind that:

External Plugins are added on a per service basis and are not applied globally. Make sure you are in your service's root directory, then install the corresponding plugin with the help of NPM

So, go to your service’s directory and then,

  • Install the plugin by npm install --save serverless-plugin-thundra-lambda-adapters-cw

  • Import the plugin in your serverless.yml

...
plugins:
- serverless-plugin-thundra-lambda-adapters-cw
...
  • Enable your lambda to publish on CloudWatch

functions:
my-function:
...
environment:
...
thundra_agent_lambda_report_cloudwatch_enable: true
...
...
...
functions:
my-function:
...
environment:
...
thundra_apiKey: <my-awesome-api-key>
...
...
...
custom:
...
thundraAdapterFunctionMemorySize: 1536
thundraAdapterFunctionTimeout: 300
...
functions:
my-function:
...
thundraIgnored: true
...
...
...
Serverless: Operation failed!
Serverless Error
---------------------------------------
An error occurred: ...LogGroup - /aws/lambda/... already exists.
...

You should skip log group creation for the mentioned function or for all functions. By default this plugin creates log groups of monitored functions to subscribe them. But if the log group was already created without this plugin (by invocation or manually), log group creation should be skipped, otherwise you will get log group already exist error something like above.

  • For skipping function specific log group creation, you can set thundraSkipLogGroupCreation flag individually.

functions:
my-function:
...
thundraSkipLogGroupCreation: true
...
...
  • For skipping log group creation for all monitored functions, you can set the thundraSkipAllLogGroupCreations property globally.

custom:
...
thundraSkipAllLogGroupCreations: true
...

Deployer Tool

Download the tool from https://s3-us-west-2.amazonaws.com/thundra-dist/thundra-lambda-adapters-cw-deployer.jar

This tool has the following usage format:

java -jar thundra-lambda-adapters-cw-deployer.jar
-mode=(adapter|subscription|full|export)
-region=<region>
[-profile=<profile>]
[-memory=<memorySize>]
[-timeout=<timeout>]
[(-functionNames=func1,func2,...) | (-functionNamesFile=functionNamesFile.txt)]
  • mode: Specifies mode of the deployer tool. This property is mandatory and it can be one of the following values:

    • adapter: Deploys and sets-up thundra-lambda-adapters-cw Lambda function.

    • subscription: Subscribes thundra-lambda-adapters-cw Lambda function to the logs groups of Lambda functions to be monitored.

    • full: Executes both of the adapter and subscription modes sequentially.

    • export: Executes both of the adapter and subscription modes sequentially without doing actual deployment but just exporting generated AWS CloudFormation template files (thundra-lambda-adapters-cw-cloudformation-template.yaml and monitored-function-resource-def-cloudformation-template.yaml) to the directory where you run deployer tool.

  • region: Specifies the AWS region to deploy. This property is mandatory.

  • profile: Specifies the AWS profile defined in the ~/.aws/credentials. This property is optional.

  • memory: Specifies memory size of the thundra-lambda-adapters-cw Lambda function. This property is optional. Default value is 512 MB.

  • timeout: Specifies timeout value of the thundra-lambda-adapters-cw Lambda function. This property is optional. Default value is 300 seconds (5 minutes).

  • functionNames: Specifies names of the functions to be subscribed for monitoring. Multiple function names can be separated by comma (,) without space. This property is mandatory if the mode is either subscription or full and if the functionNamesFile property is not specified.

  • functionNamesFile: Specifies path of the file which contains names of the functions to be subscribed for monitoring. Multiple function names can be separated by comma (,). This property is mandatory if the mode is either subscription or full and if the functionNames property is not specified.

For example:

  • Deploy thundra-lambda-adapters-cw into region us-west-2: java -jar thundra-lambda-adapters-cw-deployer.jar -mode=adapter -region=us-west-2

  • Subscribe thundra-lambda-adapters-cw to my-func-1 and my-func-2 at region us-west-2: java -jar thundra-lambda-adapters-cw-deployer.jar -mode=subscription -region=us-west-2 functionNames=my-func-1,my-func-2

  • Do the examples above at one step: java -jar thundra-lambda-adapters-cw-deployer.jar -mode=full -region=us-west-2 functionNames=my-func-1,my-func-2

1.Setup “thundra-lambda-adapters-cw”

  • Run deployer tool with the adapter mode by -mode=adapter argument as explained above.

  • Wait until the application terminates.

2.Subscribe to Lambda functions to be monitored

  • Run deployer tool with the subscription mode by -mode=subscription argument as explained above.

  • Wait until the application terminates.

3.Full setup

  • Run deployer tool with the full mode by -mode=full argument as explained above.

  • Wait until the application terminates.