We are excited to announce Programmatic error support for Kubernetes and ECS workloads. Programmatic Errors empower developers to customize, monitor, and troubleshoot non-fatal errors that may occur within their applications. With Programmatic Error support (through OpenTelemetry), you can now flag issues that may not interfere with the overall service, such as business logic errors.

Programmatic errors are created by adding span events with a custom attribute with the key name 'lumigo.type'.

For example, in Javascript, you can add a programmatic error in the following manner:

const { trace } = require('@opentelemetry/api');

trace.getActiveSpan()?.addEvent('', {'lumigo.type': ''});

To learn more about Programmatic errors and troubleshooting microservices with Lumigo, check out our docs page, and our OpenTelemetry distros for Java, Node.js, and Python 

In many cases, alerts our users configure in production are resource-specific. For example, they'd like to know when a specific Lambda function is experiencing elevated error rates. But in some cases, users need to alert differently based on the specific request. For example, they might want an alert to be more sensitive when errors are happening for a specific tenant, or when a specific value is present in the request.

Today, Lumigo adds this capability with Execution Tag based alerts, enabling users to configure alerts based on the request payload, whether it is a function invocation or a container request. To configure Execution-Tags based alerts, open the Condition section in the alert policy, select Execution Tags, and enter the key and value.

Before setting up execution tag-based alerts, make sure you've added execution tags for the data you'd like to alert on. Click here for more details about execution tags and how to add them.

The Node.js 18 runtime brings the latest and greatest LTS version of Node.js to Lambda, and as of today, it is officially supported in Lumigo!

What's new in the Node.js 18 runtime

Node.js 18 itself brings a built-in test runner, the support for the Fetch API, and a few other quality-of-life improvements. But what makes the Node.js 18 runtime very interesting, is the adoption of the AWS SDK 3 for Javascript: it is a rewrite of the AWS SDK that focuses on first-class Typescript support and modularity.

Extolling the virtues of Typescript's static type system (as opposing to effectively not having static type checks like Javascript), is something that can get me going for a while, and I am sparing everyone it.

But modularity has implications for cold starts. It is a known fact that the size of the Lambda bundle affects cold starts. It is pretty much as the intuition goes: the more code to load into the Node runtime, the longer the startup.

Another nice thing that can speed up your Lambda functions is with AWS SDK 3 is enablement by default of the TCP connection re-use, which can shave significant amounts of time across invocations for Lambda instances that are kept busy.

What do you need to do in Lumigo to use the Node.js 18 runtime?

Just turn on Lumigo autotracing as always. If you went ahead and adopted Node.js 18 a few days ago, and Lumigo told you the runtime is not supported, by now you will have noticed that Lumigo by now has set up autotracing for your Node.js 18 functions that you selected for autotracing in the UI, or using the `lumigo:auto-trace=true` AWS Tag. Nice and easy :-)

System Map, one of Lumigo's most useful features that visualizes distributed application architectures to help understand service dependencies, just got much better. 

Today, we are introducing System Map autocomplete filters. Similarly to Explore's autocomplete filters, System Map filters make it easier to discover and inspect  the resources that comprise your application.

For more information on System-Map, see the System Map documentation.

We hear a lot from users that execution tags are one of Lumigo's most powerful features. Through execution tags, you can mark, filter and alert invocations based on data like on behalf of which of your customers did the invocation run. Developer Steve gave an excellent overview of execution tags in this Quick Bytes video.

Executions tags and OpenTelemetry

Until now, execution tags were limited to the Node.js and Python Lumigo Lambda tracers. Today, any OpenTelemetry tracer, including but not limited to the Lumigo OpenTelemetry distributions, can send execution tags to Lumigo using OpenTelemetry's Span.setAttribute(key, value) API.

This is how you can set the execution tag foo to the value bar via the Lumigo OpenTelemetry Distributions for JS and Python:

// Typescript
import { trace } from '@opentelemetry/api';

// Note: 'trace.getActiveSpan()' is available from version 1.8.0 of the Lumigo OpenTelemetry Distro for JS

trace.getActiveSpan()?.setAttribute('lumigo.execution_tags.foo','bar');

// Javascript
const { trace } = require('@opentelemetry/api');

// Note: 'trace.getActiveSpan()' is available from version 1.8.0 of the Lumigo OpenTelemetry Distro for JS

trace.getActiveSpan().setAttribute('lumigo.execution_tags.foo','bar');

// Python
from opentelemetry.trace import get_current_span

get_current_span().set_attribute('lumigo.execution_tags.foo','bar');

Setting multiple values to the execution tag is also supported (this time, both bar and baz):

// Typescript
import { trace } from '@opentelemetry/api';

trace.getActiveSpan()?.setAttribute('lumigo.execution_tags.foo',['bar','baz']);

// Javascript
const { trace } = require('@opentelemetry/api');

trace.getActiveSpan()?.setAttribute('lumigo.execution_tags.foo',['bar','baz']);
}

// Python
from opentelemetry.trace import get_current_span

get_current_span().set_attribute('lumigo.execution_tags.foo',('bar','baz',)); # Both lists and tuples work

The APIs of OpenTelemetry SDKs for other programming languages differ slightly, but the gist of the matter is: if an OpenTelemetry tracer can send span attributes (and they all can :D), they can send execution tags to Lumigo!

End-to-end filtering

Lambda and container tracers use different APIs to set execution tags, but you can filter by execution tags in Explore irrespective of their source:

Requirements

Execution tags rely on the Span.setAttribute OpenTelemetry API, which is supported by virtually all OpenTelemetry SDKs. As far as looking up the current span is concerned, the trace.getActiveSpan() is available with the Lumigo OpenTelemetry Distro for JS version 1.8.0 and above. All versions of the Lumigo OpenTelemetry Distro for Python offer the opentelemetry.trace.get_current_span API.

Further reading

* Execution tags documentation page

When we announced the support for the mongodb package in our OpenTelemetry Distro for JS, we heard a lot of feedback that can perhaps be best described as "Very cool, but what about Lambda Node.js?!?"

Fast forward to today: we have updated our Node.js Lambda tracer to support the mongodb version 4.x version that, among others, is compatible with MongoDB Atlas and AWS DocumentDB.

To trace mongodb v4.x, you need to:

1. Use the Lumigo tracer @lumigo/tracer version 1.76.0 or above, or the Lumigo layer for Node.js in these versions or above (the actual version is dependent on the region).
2. If you use a bundler like WebPack or ESBuild, you must keep mongodb as an external package; refer to the MongoDB and Bundlers section of the Lumigo AWS Lambda Node.js documentation.

Happy tracing :-)

Update: In the original post we pointed at the wrong version (1.75.1 instead of 1.76.0) of the @lumigo/tracer


You can now use Lumigo to easily create AWS Cloudwatch alarms and get notified in real-time in Slack, PagerDuty, and other tools when services like DynamoDB and SQS experience issues. 

With Lumigo's new Cloudwatch metric alerts you'll no longer have to create alerts one-by-one in CloudWatch, and instead can configure multiple alerts at the same time, in just a few clicks. You can define dimensions and thresholds directly from the alert page, and setup notifications to your workflow tools without any need to integrate Cloudwatch manually.

To create a CloudWatch metric alert, go to the Alerts page and:

• Select CloudWatch Metric as the Alert Type
• Select the AWS Region and namespace
• Select the AWS metric and dimensions 
• Define the alert criteria: stat, threshold, and evaluation period 
• Define the notification preferences: channels and frequency

Once submitting the alert, Lumigo then creates the corresponding Alarms in CloudWatch.

The documentation about creating CloudWatch metric alerts with Lumigo is available here.

P.S. Ensure your IAM role includes the following permissions, or go to Settings > AWS and update to the latest IAM role. 

{
   "Effect" : "Allow",
   "Action": [
      "cloudwatch:PutMetricAlarm",
      "cloudwatch:DeleteAlarms",
   ],
   "Resources": "*"
}

 

Lumigo just got better at tracing your applications end-to-end! Since the launch of the support for Amazon Elastic Container Service, Lumigo has known how to trace HTTP requests issued by containers instrumented with OpenTelemetry and served via Lambda functions with Lumigo tracers (we call it the "Container -- HTTP -> Lambda" flow). Today, we launch support for "the other direction": tracing HTTP requests issued by Lambda functions and served by containers using OpenTelemetry ("Lambda -- HTTP -> Container" flow). Lambda functions interacting over HTTP with containers is a pattern we see, for example, in projects that started out as entirely serverless, and then introduced containers for specialized workloads that require specific hardware capabilities like GPUs for computation-intensive tasks. It is also rather common in lift-and-shift scenarios, where existing, on-premise workloads get containerized, and new capabilities surrounding them are developed serverless.

How does it work?

This new capability is based on the [W3C TraceContext standard](https://www.w3.org/TR/trace-context/), which is implemented by all OpenTelemetry SDKs and the [Lumigo OpenTelemetry distributions](https://docs.lumigo.io/docs/containerized-applications#lumigo-opentelemetry-distributions), and now is also implemented for outgoing HTTP requests in the Lumigo Lambda tracers for Python and Node.js. (Details on the precise versions of the tracers and Lambda layers are found below.)

Opt-in support for W3C TraceContext

Note that the support for W3C TraceContext in the Lumigo Lambda tracers is opt-in,  activated via the `LUMIGO_PROPAGATE_W3C=true` environment variable to be set on the Lambda function. No additional work is needed on the container /  OpenTelemetry side. There, W3C TraceContext support is built-in and enabled by default by the Lumigo OpenTelemetry distributions and virtually all upstream OpenTelemetry SDKs.

Supported Lambda tracer and layer versions

Node.js:

• @lumigo/tracer v1.75.0 and above
• Minimum layer versions (applicable to all supported Node.js runtimes)

Python:

• lumigo-tracer v1.1.206 and above
• Minimum layer versions (applicable to all supported Node.js runtimes)

How to activate W3C TraceContext support for your Lambda functions

1. Ensure you are using a supported version of the tracer or the layer providing the tracer to your application (see previous section)
2. Set on your Lambda function the `LUMIGO_PROPAGATE_W3C=true` environment variable

Further reading

• Lambda Python tracer documentation
• Lambda Node.js tracer documentation

We launched support for the `dotnet6` runtime of AWS Lambda. Similarly to Lumigo's support for previous versions of .NET in Lambda, the support is provided via the Lumigo.DotNET NuGet package. Your Lambda functions running on previous versions of .NET on Lambda should require no code changes to upgrade: just update the version of the Lumigo.DotNET package, and enjoy the latest and greatest (and, frankly, pretty awesome) .NET version on Lambda.

The documentation about instrumenting .NET Lambda functions with Lumigo is available in the AWS Lambda .NET tracing documentation.