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

Invocation

Invocation data, which is Serverless functions specific, represents the specific serverless function invocation. It has the following fields in addition to the monitoring base fields mentioned here.

Invocation Data is not Vendor Specific

The invocation data model is not specific to any serverless vendor (such as AWS Lambda) but for all serverless vendors (such as AWS Lambda, Azure Functions, Google Cloud Functions, etc …)

  • traceId | string
    If the invocation resides in a trace, this field represents id of the owner trace. This field is optional. An empty value means that the invocation is not connected with any trace.

  • transactionId | string
    If the invocation resides in a transaction, this field represents id of the owner transaction. This field is optional. An empty value means that the invocation is not connected with any transaction.

  • spanId | string
    If the invocation resides in a span, this field represents id of the owner span. This field is optional. An empty value means that the is not connected with any transaction.

  • functionPlatform | string
    Name of the serverless function. For example: "user-get".

  • functionRegion | string
    Region, which is platform specific, of the serverless function. For example: "us-west-2".

  • startTimestamp | long
    Start time of the invocation as UNIX Epoch time in milliseconds.

  • finishTimestamp | long
    End time of the invocation as UNIX Epoch time in milliseconds.

  • duration | long
    Duration of the invocation in milliseconds.

  • erroneous | boolean
    true if invocation failed with error, false otherwise.

  • errorType | string
    Type of the error. For example: “HttpError”, "DBError”.

  • errorMessage | long
    The message of the error.

  • errorCode | integer
    Numeric code of the error. The default value is -1 which means no error code was specified. For example: 404 for HttpError.

  • timeout | boolean
    true if timeout occurred, false otherwise.

  • coldStart | boolean
    true if invocation is cold start, false otherwise

  • tags | map<string, \>*
    Tags of the invocation in key-value format. For Example: <customerId, 1234567890>, <customerName, “John Doe”>, <isEnterpriseCustomer, true>.

Notes on `tags`

Note 1:
For labeling support, tag in <string, boolean> format can be used. So, for label based searches, tag with label name and value true can be queried.
Note 2:
Only tags with string, number or boolean typed values can be queried.