Centralize your AWS Lambda Errors

note: You need to deploy your Lambdas using CDK and our TypeScriptFunction construct from cdk-typescript-tooling for this to work. If you don't use it and don't want to start, no worries! We encourage you to take a peek at how we implemented it: https://github.com/xolvio/cdk-typescript-tooling/blob/master/src/typeScriptFunction.ts#L350-L356. It's pretty straightforward. Feel free to do something similar in your codebase :)

Why?

Having multiple independent lambda functions is great, but it comes with a price of difficult monitoring.
We like to be notified of things going wrong, as early as possible and in an automated fashion. New lambda functions should be connected to the system with a minimal setup.

What?

Our TypeScriptFunction has built-in ability to send Error logs to a passed lambda handler.
First, create a logHandler:

import { CloudWatchLogsDecodedData, CloudWatchLogsHandler } from "aws-lambda";
import zlib from "zlib";

export const handler: CloudWatchLogsHandler = async (event, context) => {
  const compressedPayload = Buffer.from(event.awslogs.data, "base64");
  const jsonPayload = zlib.gunzipSync(compressedPayload).toString("utf8");
  const parsed: CloudWatchLogsDecodedData = JSON.parse(jsonPayload);
  console.log(parsed);
};

This is the simplest possible one that will just log errors in a CloudWatch stream aggregating all errors from all lambda functions.

Now in your cdk define a TypeScriptFunction that will deploy that code. Assign its handle to a variable.

import { SubscriptionFilter, FilterPattern } from "@aws-cdk/aws-logs";
import * as LogsDestinations from "@aws-cdk/aws-logs-destinations";
//...
const logHandle = new TypeScriptFunction(scope, "logHandler", {
  entry: require.resolve("@sales/logHandler/src/handler.ts"),
});

Pass it to existing function like so:

new TypeScriptFunction(scope, "Purchase-Status-Endpoint", {
  entry: require.resolve("@sales/purchase-endpoint/src/handler.ts"),
  logFunction: logHandle,
});

Now, whenever any error (console.error or exception) shows up in the Purchase-Status-Endpoint, it will be passed and displayed by the logHandler.
Obviously, the usefulness of that increases with the number of lambdas you have. :-)

Enjoy!

cdk-typescript-tooling
AWS is great. Lambdas changed the way we think about programming. CDK makes it all even better.

Let me know if you have any questions or thoughts in the comments below.


Let us help you on your journey to Quality Faster

We at Xolvio specialize in helping our clients get more for less. We can get you to the holy grail of continuous deployment where every commit can go to production — and yes, even for large enterprises.

Feel free to schedule a call or send us a message below to see how we can help.

User icon
Envelope icon

or

Book a call
+
Loading Calendly widget...
  • Add types to your AWS lambda handler

    Lambdas handlers can be invoked with many different, but always complex, event arguments. Add to that the context, callback, matching return type and you basically start listing all the different ways that your function can fail in production.

  • How to expose a local service to the internet

    From time to time you might need to expose your locally running service to the external world - for example you might want to test a webhook that calls your service. To speed up the test/development feedback loop it would be great to be able to point that webhook to your local machine.

  • For loops in JavaScript (vs _.times)

    From time to time I still see a for loop in JavaScript codebases. Linters are frequently angry about them. Let's see how we can replace them.