aws-xray-sdk-node VS aws-embedded-metrics-node

You see in the node xrays sdk that each AWS service is customized with the captureAWSRequest function, which is responsible for the X-Ray calls.

Generally speaking, it is encouraged on serverless-heavy environments (assuming Lambdas, API Gateways, AppSync, DynamoDB and similar services were configured to use it). However, some crucial pieces are still missing, like a proper SQS integration. Bear that in mind.

So what do we get for that? The Tracer module wraps the AWS X-Ray SDK (as a transitive dependency). It doesn't really add any net new capabilities, but makes the SDK easier to work with. In my experience, that SDK is a bit of a bear so this may be well worth it. We can decorate class methods to introduce new trace segments in a single line of code. We can also use the imperative form to add new traces where we see fit. We can capture AWS clients, but that simply exposes the X-Ray SDK.

aws-xray-sdk-node: https://github.com/aws/aws-xray-sdk-node/issues/208

Lamby will now publish CloudWatch Embedded Metrics in the Lamby namespace with a custom dimension for each application's name. Captured metrics include counts for Cold Starts vs. Proactive Initializations. Here is an example running sum of 3 days of data for a large Rails application in the us-east-1 region.

I was looking into CloudWatch Embedded Metrics - which is a format that converts logs into cloudwatch metrics automatically.

Often when it comes to metrics, we think about CPU, latency and other operational metrics and AWS services usually provide those out of the box. This kind of thinking can be flawed when we end up having to use 3rd parties such as google analytics to infer critical business events. A simpler solution is to have the application emit a metric when a business event (say a customer signup) occurs. We have a few options for doing this: We can use aws-sdk, we can use the aws-embedded-metrics lib and now we can use Powertools Metrics. Which is the best? Let's see.

Let's explore the next core utility in Lambda Powertools, the Metrics utility. This utility lets you easily push metrics to CloudWatch by taking care of all the necessary boilerplate. It works asynchronously by using Amazon CloudWatch Embedded Metrics Format, by logging the metrics to stdout. It also aggregates all metrics from each invocation to save on the number of calls to CloudWatch.

To make it easier to create such an object, AWS has provided libraries for Node.js, Python, Java, and .NET. The above example using the AWS SDK can now be written as follows:

Custom metrics have a pricing structure which can be expensive. Embedded Metrics Format can help manage the cost and is supported by Lambda Powertools TypeScript. Again, the docs here are pretty good, so no need for me to break it down. Instead let's look at the experience. I've added a custom metric of "collectionSuccess" to my collectionSuccess function. In my hypothetical app, some payments wind up in collections and here I'm marking whether or not the collection resulted in a payment.

You can use metrics to aid debugging by adding them to your dashboards that we talked about earlier. It’s also possible to add custom metrics, and there are many libraries and tools (e.g. node, python, etc) which can help you do this.