Tracking activity in cloud applications

Reading this, you’ve probably built something on cloud and know that modern cloud apps can be quite distributed and complex.

Reading this, you’ve probably built something on cloud and know that modern cloud apps can be quite distributed and complex.

For a lot of developers, building distributed cloud applications, introduces an interesting issue.

Tracking events across your (managed) cloud applications.

For example, how do you know that an error or other event happened in any one of your services (ECS, Lambda, Auth0)? If you haven’t found a good answer to that question, don’t worry. You’re not alone. A lot of developers seem to struggle with it.

But I think we’ve figured it out.

The problem

How do I know that it’s even a problem? Well, we run a service that tracks 250k Lambda functions across 4k AWS accounts used by many thousands of developers.

We are the most widely adopted serverless monitoring offering today.

We have spoken to a lot of developers.

People come to us with the following questions:

• Can I track Lambda/API Gateway/AppSync/whatever errors?
• How can I track events that aren’t fatal to my code execution (say when a
  DynamoDB call fails with a ThroughputExceeded error but the execution keeps going)?
• How about custom business events like signups, payments, churns? Would want a good way to track those as well.

A couple of months ago, we decided that enough is enough — let’s solve this for the community once and for all.

So what did we do?

We built the worlds first log gateway!

It’s called Logbird and essentially, it parses events from logs and passes them forward.

It can recognise everything from AWS Lambda errors, API Gateway misconfigurations, slow API or database calls to code exceptions. Fargate, ECS, Appsync, RDS, CloudTrail, ELB… the list goes on and the sky is the limit.

The kicker? It does not retain logs — which means… it’s going to be a lot cheaper and scalable than any log analytics service out there.

Simply put — log analytics will never be priced cost-efficiently for managed applications at scale.

But Logbird can.

Because it parses log streams and catches events and throws the rest away.

Another kicker? You can react to individual events by sending SNS notifications, with the data you extracted from them. Which enables a lot of cool stuff on top of mere error tracking.

The possibilities are endless.

Not only can you track failures and problems in your applications. You can automate workflows. You can build alternative execution flows or communicate between applications through logs.

In a world of event-driven, hybrid, distributed applications, logs can be used as an alternative communication channel.

Let that sink in for a moment.

The library

Logbird features its own query language but it also supports regular expressions and glob patterns to match events. All that makes it easy for developers to create their own filters.

However, that’s not enough.

We’re going a step forward and launching a community-driven library for filters, allowing YOU to contribute to the serverless community. This will make it easy to get going in minutes, not hours.

Available today

Logbird has been tested and is already used by dozens of teams building serverless applications. Today, we’re opening it up for you. You’re welcome to come and try it out! It’s in beta and we do not charge money for it.

Now let’s get back to building awesome apps!