AWS re:Invent 2024: Discover the latest & greatest from Coralogix
As we gear up for AWS re:Invent this December, we’re excited to share some of the latest innovations that make our platform stand out. Coralogix continues…
Whether you are just starting your observability journey or already are an expert, our courses will help advance your knowledge and practical skills.
Expert insight, best practices and information on everything related to Observability issues, trends and solutions.
Explore our guides on a broad range of observability related topics.
AWS Lambda is a serverless compute service that runs your code in response to events and automatically manages the underlying compute resources for you. The code that runs on the AWS Lambda service is called Lambda functions, and the events the functions respond to are called triggers.
Lambda functions are very useful for log collection (think of log arrival as a trigger), and Coralogix makes extensive use of them in its AWS integrations.
This post will provide you with few tips on how to troubleshoot a situation where you don’t see or receive logs in Coralogix that are supposed to be collected and shipped by an AWS Lambda function.
The first things to check are some of the most trivial, but still very common, reasons for not seeing your logs within Coralogix (we promise not to tell anyone if this happens to you).
If none of these have uncovered the problem, the next step is to start and drill into the Lambda itself using AWS’s Lambda function monitoring graphs.
In AWS, go to Services->Lambda->Functions and click on the name of the specific Lambda you are troubleshooting. Then click on Monitoring.
We will use some of these graphs to identify issues with the Lambda.
When there are errors in the Lambda, you should see a red dot or red line depending on the period the errors have been happening.
Using the graphs, compare the duration to historic values when you know the Lambda worked. A significant difference might indicate an issue. You do not want to see a duration that is very short (around 1-2 ms) that tells you that the lambda did not run properly.
You also don’t want to see a Lambda duration that ends with 00 (i.e. example 9000.00). This means that the lambda timed out. In this case, increase the timeout parameter in the lambda configuration. Maximum time out is 15 minutes.
Make sure the memory allocated to this Lambda is more than the memory used. If the memory used is more than the memory allocated that indicates that you need to up the memory for the Lambda function.
Check the logstream for the last invocation for the lambda in Cloudwatch. Usually, AWS saves lambda logs in cloudwatch under /aws/lambda/lambda-function-name. You want to check this logstream and see if there are any errors. If there are, take a look and try to fix them.
If none of the above fixed the problem, it is time to dive deeper into the Lambda function and turn on debug mode.
Each one of our integration Lambda functions is shipped with an optional debug execution mode. Enabling debug is done by removing the comment form the debug line at the bottom of the Lambda function code.
You want to check monitoring under the Lambda in question to make sure there are no errors in the log of the LAMBDA execution.
If none of these steps have uncovered the source of the problem, you can always reach out to Coralogix Support to get help with resolving the issue.
As we gear up for AWS re:Invent this December, we’re excited to share some of the latest innovations that make our platform stand out. Coralogix continues…
When discussing what makes a product different, what makes it unique, we are led down the path of feature comparison. It is a natural thing to…
When we talk about Real User Monitoring (RUM), it’s easy to get wrapped up in metrics—the hard numbers that tell us about our users’ experiences. But…