4 minutes read

POSTED Mar, 2020 dot IN Distributed Tracing

Tracing EventBridge events with Thundra

Fatih Aydilek

Written by Fatih Aydilek


Software Engineer @Thundra

 X

What is EventBridge:

Amazon EventBridge is the most recent and effective way to stream near real-time data from various data sources such as Opsgenie, PagerDuty, Thundra, etc. to AWS services like SQS, SNS, Lambda and others. It works on the old school event bus idea and rule filtering based on event schemas. For those who work with AWS CloudWatch events, this concept isn’t new. EventBridge inherits CloudWatch capabilities thus has new features like creating custom event bus and SaaS partner event bus. Events that are created from CloudWatch using the default event bus are still available. Users can access their default event bus, rules and events in EventBridge console and also CloudWatch console.

Amazon EventBridge can be integrated with third-party SaaS partners. This is the way to process SaaS application data in the AWS environment using AWS services. Currently, Amazon EventBridge supports 24 SaaS applications like Thundra, Zendesk, and others as a data source and 15 AWS services as targets. Amazon EventBridge perfectly fits with the event-driven paradigm on serverless architectures, with its ability to publish/subscribe model without provisioning any server. Amazon EventBridge is a completely managed service, scalable to the sky, reliable and robust.  

How to take advantage of EventBridge with Thundra

Let's demonstrate how EventBridge works with a simple example. In this example, we will use Thundra AWS EventBridge partner event source and SaaS Webhook as the data sources to process Thundra events according to their severity level. In Thundra, you can set up alerts on flexible Thundra queries and assign a severity level to the alert policies. When any event violating this policy occurs, an event with that severity is generated. In our example with Thundra’s EventBridge integration, events that have a severity level “critical” needed to handle differently than severity level “info”. Mostly, immediate action is required for critical alerts and it is a good idea to hold them in a data store to understand the general health of the application. On the other hand, severity level “Info” may give a clue about the performance and usage of the application and possibly not that important. In order to process events, we will use AWS Lambda as a computation service and we may like to keep outputs in DynamoDB for later usage. For the SaaS webhook we have a preProcessor lambda to convert incoming event type to Thundra Event type and send these events to processor functions using AWS EventBridge  custom event bus named “custom-event-bus”. 

First, we need to create a Thundra event partner source from the Thundra console in the settings page EventBridge tab. 

image7-1

Thundra console Settings Page Alert Integrations tab

After the source is created in Thundra we need to activate the pending event bus in AWS console.

image4

AWS console EventBridge partner event source page

Thundra event source is ready and we can now filter events according to their severity property in JSON. You can see the example Thundra event as a result of a violation below. For more information, please have a look at our documentation.    

image5

Thundra Event in JSON format

There will be two processor functions named ProcessCriticalEvent and ProcessInfoEvent. These functions will be triggered by EventBridge according to the pattern that we give in the event rule. AWS SAM is a framework for building serverless applications and we will use SAM to deploy our functions into the AWS account. Regarding two functions in the template.yaml as follows:

image3-1

Configuration for ProcessCriticalEvent function

We add two trigger rules for the ProcessCriticalEvent function that has two properties. EventBusName is the event source that we create in the first step named “aws.partner/thundra.io/3FvbRU6S-thundra-event-source” and also “custom-alert-bus” for SaaS webhook. Pattern is the filter rule and the “detail.severity” value is the event property that we are interested in and it’s value “critical”.

image8-1

Configuration for ProcessInfoEvent function

ProcessInfoEvent function has the same triggers event but “detail.severity” value is “info” since this function processes only info level events. Note that, we didn’t add other parts of template.yaml to make this blog short.

preprocess

Configuration of PreProcessCustomEvent function

PreProcessCustomEvent function receives events from SaaS webhook and transforms them to Thundra Event format. After transformation, send these events using a custom event bus named “custom-alert-bus” to be processed according to their severity level.

Let’s summarize what we have done so far: 

  • Creating Thundra Event Source
  • The activating partner event bus
  • Creating processor functions: ProcessInfoEvent, ProcessCriticalEvent and PreProcessCustomEvent
  • Generating event rule and add this lambda as a trigger event

How to monitor the flow with Thundra?

Until now, we built an event-driven architecture and this brings mainly, asynchronous event-driven functionality, loosely coupled structure and scalability. Note that EventBridge automatically scales based on the number of events ingested. This definitely makes EventBridge a reliable service and guarantees the delivery of events with high performance but monitoring is still crucial since integration with other services might have problems and we need to check the whole flow. Thus, Thundra adds EventBridge support and we will add Thundra integration to monitor applications which include EventBridge service. 

Integrating Thundra using AWS SAM is one of the various options and we will continue with AWS SAM. For a detailed explanation please follow the doc.

image9-1

Thundra Configuration

After we update the template.yaml, the application is ready to deploy.

After several events generated by Thundra monitoring your serverless architecture, we will be able to see the flow triggered by EventBridge. In the Thundra Architecture tab, it is shown that “Thundra-Event” is one of the entry points of the application where the flow starts and another is the Http endpoint ending with “/alerts”. Then, Process functions call according to the pattern that we registered. As you may notice with a ticker edge, our app receives a comparatively bigger amount of info alerts. 

image2-1Architecture View of Application

Thundra also enables developers to track PreProcessCustomEvent trace individually in addition to the ability of seeing complete architecture. Trace starts from SaaS webhook and AWS Api finishes DynamoDB table where we hold processed events.

image1-1

UniqueTrace of ProcessInfoEvent

Conclusion

EventBridge solves challenging problems around the integration of SaaS platforms with AWS services with its flexible integration. When you create necessary patterns on the application, you can redirect the events to Lambda functions or directly to the other AWS services such as SQS. 

Distributed tracing is crucially important in event-driven architectures to understand the application behavior and manage the application health. Considering the advantage EventBridge provides, developers might want to use it where necessary to make their event-driven architectures ultimately scalable for any events. However, tracing the events out of EventBridge created hesitation using it. We are proud to solve this problem with our latest update enabling tracing of EventBridge events. You can start trying it for free today either by signing up directly or from AWS Marketplace. Finally, I definitely recommend our newly released online debugging feature that enables debugging AWS Lambda invocations natively from IDE.