Lumigo Release Notes logo

Release Notes

Back to Homepage Subscribe to Updates

Labels

  • All Posts
  • Announcement
  • feature
  • Improvement

Jump to Month

  • June 2024
  • April 2024
  • January 2024
  • October 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • February 2022
  • November 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
feature
2 years ago

Create AWS Cloudwatch metric alerts with Lumigo

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": "*"
}


 

feature
2 years ago

Tracing HTTP from Lambda to containers

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
feature
2 years ago

Lambda .NET 6 Runtime Is Supported

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.


feature
2 years ago

Complete queries faster with Explore autocomplete

Explore autocomplete helps complete the query you intended to do, taking user experience to the next level by allowing you to query events across your application quickly and uncover deeper insights.


For more information read the documentation here.


feature
2 years ago

Support for MongoDB package added to Lumigo OpenTelemetry Distro for JS

We introduced support for the mongodb package in the Lumigo OpenTelemetry Distro for JS, with support for versions 3.6.6 to 3.7.3 and 4.0.0 to 4.9.1 (the current latest & greatest).

The only step necessary to get MongoDB tracing to containers already traced, is to update the @lumigo/opentelemetry dependency to 1.3.0.

P.S. This update does not apply to the Lambda Node.js tracer, but stay tuned :-)

Improvement
2 years ago

Improved batch containerized workload support

Since we launched Amazon ECS support earlier this summer, we have come across many user workloads that behave like batch jobs (which, incidentally, we see often scheduled via AWS Batch and, occasionally, via AWS Step Functions). Rather than relying on long-running processes that receive request over HTTP, these workloads execute jobs pulled from the Amazon SQS or sometimes the process environment, perform computation involving databases, other services and messaging queues, and then terminate.

The most intuitive representation for such transactions consist of a "root" span representing the "main" method, with the outgoing requests to databases, messaging queues and other service nested directly under the "main" span. And this is how Lumigo will now represent these workloads, provided that you use the OpenTelemetry API to create the "root" span.

Lumigo now also supports the case where the distributed trace starts with an outgoing request, but given there is no common parent span, multiple such ongoing requests will each result in a separate transaction.

Enjoy this improved support for your containerized workloads and let us know what you think about it!

P.S. If you want a hand using the OpenTelemetry API to create root spans, we are happy to help! Let us know through the support channel, and we'll gladly arrange a call to help you out. It's usually just 5 minutes coding, and then pushing it to your environment to validate :-)

P.P.S.S. Lumigo now also shows Elastic Load Balancers that serve HTTP requests issued by containerized workflows.


feature
2 years ago

In-Platform Demo Experience

Get the full Lumigo experience—even if you aren’t using every feature—with a new in-platform demo. In one-click, fill your project with demo data and see how Lumigo can debug even the most complex of environments. 


feature
2 years ago

Support for Lambda → SNS → SQS → Lambda

You can now see and understand Lambda → SNS → SQS → Lambda transactions as one complete trace, end-to-end. This new view gives you critical context into one of the most common–but unobservable–serverless architectures so you can now troubleshoot it faster and easier, with no blindspots. 

This feature is available for Node.js and Python. To see the full trace update your Node.js tracer to version +1.72.0 and Python tracer to version +1.1.199.


feature
2 years ago

Understand how cold starts affect your application

Cold start duration is now displayed in the timeline of your traces to make it even easier to improve latency end-to-end. Set up alerts to notify you when functions experience a high percentage of cold starts to keep an eye on critical and user-facing functions.

 

Improvement
2 years ago

Amazon ECS OpenTelemetry Resource Attributes Now Supported


We extended Lumigo's support of OpenTelemetry resource attribute semantic conventions to cover the `cloud.platform` key and the Amazon ECS semantic conventions.

Our goal with implementing the OpenTelemetry semantic conventions is to enable you to get the best integration with Lumigo for your workloads even when not using the Lumigo OpenTelemetry distributions, but rather using upstream OpenTelemetry SDKs.

The Amazon ECS semantic conventions are not yet widely implemented in OpenTelemetry SDKs, but we are very much looking forward to contributing them to the community!

For more information about the OpenTelemetry semantic conventions supported by Lumigo, refer to the OpenTelemetry Supported Semantic Conventions documentation.