We're thrilled to announce a makeover of our Live Tail page, designed to enhance your debugging experience, with a more user-friendly, efficient, and visually appealing interface. 

Here's what you can expect from the new Live Tail:

1. Autocomplete filter for simplified search: Say goodbye to multiple filters! With the autocomplete filter, finding specific requests or invocations has never been easier. 
2. Links open in new tabs: We understand the importance of preserving your workflow. Now, all links within the Live Tail page, including open channels and collected data, open in new tabs.
3. Direct link to Issue Details view: Quickly delve deeper into any issues you encounter with a direct link to the Issue Details view, where you can gain comprehensive insights into the root cause of problems.
4. Better and easier-to-use UI: Our new UI is thoughtfully crafted to provide a seamless user experience.

For further information refer to our documentation.

We're excited to announce an upgrade to Lumigo's Live Tail feature. Now, Live Tail supports container requests, offering real-time monitoring and troubleshooting for your containerized services, in addition to Lambda function invocations.

Live-Tail streams your requests and invocations and adds the much-required information such as exceptions and the payload of each request that are needed to troubleshoot containerized services easily in near real-time.  

Use Live-Tail for:

• Faster Debugging: Identify and resolve container-related issues with ease, reducing debugging time.
• Streamlined Development: Get quick feedback during development with real-time insights.
• Real-Time Troubleshooting: Access critical details like exceptions and request payloads for proactive issue resolution.

For further information refer to our documentation.

Container orchestration services, such as Kubernetes, have many types of constructs (e.g. objects in Kubernetes) for different functionalities. When something goes wrong, this can make troubleshooting difficult, as the same trace can be associated with many different constructs. 

To help solve this challenge, Lumigo has introduced the notion of service constructs that allow users to find traces associated with the different types of services and constructs easily. For further information refer to our documentation.

The (usually) fine-granularity of APIs exposed by Lambda functions, where one function deals with one type of event, is one of the exceptions in cloud computing; most APIs like HTTP, GRPC APIs, and other services expose multiple different functionalities, often with varying characteristics of performance, SLIs & SLOs, failure modes, and dependency graphs.

In our ongoing efforts to make troubleshooting containerized applications as easy as we made it with serverless, we are delighted to introduce the notion of Endpoints.

Endpoints describe the API of a service and give a detailed view of the operations exposed by the service. Lumigo uses default rules to automatically discover endpoints, which can then be seen on the platform and used for finding particular traces.

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 

The Python 3.10 runtime brings the latest and greatest LTS version of Python 3.10 to Lambda, and as of today, it is officially supported in Lumigo!

What's new in the Python 3.10 runtime

What makes the Python 3.10 runtime very interesting is the structural pattern matching addition allowing to use patterns to match against data structures such as lists, tuples, and dictionaries and run code based on the match. Structural pattern matching lets you write code that processes complex data structures more easily and can help you improve code readability and maintainability.

Python 3.10 has also improved error messages providing more context about the error, such as the line number, the location where the error occurred, and the exact nature of the error. Additionally, Python 3.10 error messages provide more helpful information about how to fix the error, such as suggestions for correct syntax or usage.

Other nice additions to Python 3.10 are a new syntax for parenthesized context managers, making it easier to read and write code that uses the “with” statement, which simplifies managing resources such as file handles or database connections, ensuring they are released correctly, writing union types as X | Y instead of the previous versions’ syntax of typing Union[X, Y] and use user-defined type guards to handle custom data types or to refine the types of built-in types that aim to reduce boilerplate code and improve readability and maintainability.

What do you need to do in Lumigo to use the Python 3.10 runtime?

Just turn on Lumigo autotracing as always. If you went ahead and adopted Python 3.10 already, and Lumigo told you the runtime is not supported, by now you will have noticed that Lumigo set up autotracing for your Python 3.10 functions that you selected for autotracing in the UI. Of course, also using the lumigo:auto-trace=true AWS Tag is supported. Nice and easy :-)

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.

Kubernetes is the container orchestration platform of choice for many teams. In our ongoing efforts to bring the magic experience of Lumigo’s serverless capabilities to the world of containerized applications, we are delighted to share with you the Lumigo Kubernetes operator, a best-in-class operator to automatically trace your applications running on Kubernetes using the Lumigo OpenTelemetry distributions for Java, Node.js and Python.

We designed the Lumigo Kubernetes operator with ease of use and automation in mind: to get your applications traced with Lumigo on Kubernetes, all you have to do is install the Lumigo Kubernetes operator with Helm, and then create in the namespaces where you want applications traced, a Lumigo resource:

apiVersion: v1
kind: Secret
metadata:
name: lumigo-credentials
stringData:
# Kubectl won't allow you to deploy this dangling anchor.
# Get the actual value from Lumigo following this documentation: https://docs.lumigo.io/docs/lumigo-tokens
token: *lumigo-token # Example: t_123456789012345678901
---
apiVersion: operator.lumigo.io/v1alpha1
kind: Lumigo
metadata:
labels:
app.kubernetes.io/name: lumigo
app.kubernetes.io/instance: lumigo
app.kubernetes.io/part-of: lumigo-operator
name: lumigo
spec:
lumigoToken:
secretRef:
name: lumigo-credentials # This must match the name of the secret; the secret must be in the same namespace as this Lumigo custom resource
key: token # This must match the key in the Kubernetes secret

(You find your Lumigo token in your Lumigo project.)

The Lumigo Kubernetes operator will update your deployments, daemonsets, replicasets, statefulsets, cronjobs and jobs to be traced with the Lumigo OpenTelemetry Distro for Java, Lumigo OpenTelemetry Distro for Node.js and Lumigo OpenTelemetry Distro for Python.

Monitoring applications on Kubernetes has never been easier ;-)

For more details on how to use the Lumigo Kubernetes Operator, refer to the documentation on GitHub. And if you are curios about how we managed to make it so easy, we have an in-depth look at the magic behind the Lumigo Kubernetes operator waiting for you on the Lumigo blog.

Many serverless and microservice applications are polyglots, with components written in different programming languages based on the task to accomplish, desired performance characteristics, libraries to reuse, developers' preferences and many other reasons. Lumigo now shows you the Lambda runtime and OpenTelemetry SDK language in the invocation and transactions graph, making it easier for you to contextualize the transaction and its components, and react faster to issues. Also, it is a nice splash of color ;-)

P.S. To keep transactions easy to read, the runtime will be hidden when, due to zoom level and screen size, graph nodes are less than 40px wide.