Lumigo will trace the invocations of your application. The first thing we will use it for is to get an understanding of how our application looks in real life.
Notice how this is identical to the architecture diagram we drew by hand, except it’s drawn from the actual invocations that Lumigo has traced, so it’s always up-to-date and based on actual data.
Clicking on the
Metrics tab would show you some additional metrics like the number of cold starts as well as cold start durations.
requestUnicornfunction and you should see something like this:
requestUnicornfunction, you should see its return value, invocation event, environment variables and its logs:
Similarly, if you click on the
unicornDispatched SNS topic, you will see the
sns.Publish request that
requestUnicorn function made to it. Notice that sensitive data like API keys and auth tokens are scrubbed and were never sent to Lumigo’s backend in the first place.
Where a resource was accessed multiple times during a transaction, you can also iterate through all the individual requests too. For example, the
requestUnicorn function did a
dynamodb.Get and then
dynamodb.Put against the
Having all these information at your fingertips makes it easy for you to understand what actually happened during this transaction without spraying your code with manual instrumentation code!
Timelineshows you where the time was spent on this transaction to help you identify culprits when performance issues arise.
Now that you know your way around Lumigo, let’s use it to troubleshoot the issues we are seeing in the demo app.