Thundra

Thundra: Serverless Observability for AWS Lambda

The black box nature of AWS Lambda and other serverless environments means that identifying and fixing performance issues is difficult and time-consuming. Built for straightforward debugging, monitoring, and observability, Thundra provides deep insight into your entire serverless environment. Thundra collects and correlates all your metrics, logs, and traces, allowing you to quickly identify problematic invocations and also analyzes external services associated with that function. With Thundra’s zero overhead and automated instrumentation capabilities, your developers are free to write code without worrying about bulking up their Lambdas or wasting time on chasing black box problems.

Get Started    Discussions

Troubleshooting

I have added “thundra-lambda-audit” dependency but cannot trace my Lambda application internals automatically, why?

“thundra-lambda-audit” module only provides support for tracing invocations automatically, not for the Lambda application internals. You can still instrument your applications manually but for automated instrumentation support by annotation and environment variable, you need to add “thundra-audit-instrument” module into your dependencies for bytecode level instrumentation. See https://docs.thundra.io/docs/java-audit-trace-support for more details.

I have added “thundra-lambda-log” dependency, added Thundra’s log4j appender but cannot see logs in the invocation, why?

By default, com.opsgenie.thundra.log.MonitoredLogAppender publishes log events from any logger if the logger is com.opsgenie.thundra.log.MonitoredLogger log events from other org.apache.log4j.Loggers are ignored. See https://docs.thundra.io/docs/java-log-support for more information.

Why I should configure my build tool to merge service definition files under META-INF/services/?

Thundra has a plugin-based architecture and discovers its plugins based on Java Service API (https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html) protocol. So the plugins are defined under META-INF/services folder and discovered by Thundra’s core engine from there. Since there might be multiple plugin (or service) definitions of the same plugin interface (so has same plugin definition file name), the plugin definitions must be merged. So Thundra has its own annotation processor to be invoked at compile time by “javac” for merging service definitions natively without any extra configuration. However annotation processors might not be invoked by some build tools or development environments. For this reason, it is also advised to add the required configurations to your build tools for merging service definitions at build time explicitly. See https://docs.thundra.io/docs/java-installation for more information.

I have implemented my Lambda handler from ThundraLambdaRequestHandler but I am getting ClassCastExceptions like java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to ..., why?

For your handler config, you SHOULDN’T specify method name (handleRequest) but just handler class full name. Because if method name is specified, AWS Lambda tries to resolve the request type from method arguments by Java Reflection API. But since generic types are not available at method level, requests data is deserialized into java.util.Map instance and this leads to ClassCastExceptions while passing request to your handler. Therefore, at your handler config, just specify handler full class name without method name (which it is not needed).