When we first announced the support for .NET of Thundra in January, we got very positive feedback and encouraging comments. It was only the first step but we definitely flattered by the interest and decided to sharpen the skills of our .NET library. Many users used v1.0.0 with a warmup module that prevents the cold start and an essential instrumentation capability that shows request/response and the duration time. In April, we came up with distributed tracing for serverless applications, and the .NET community was pushing us to provide the same capability with .NET serverless applications. Hence, we decided to bring our .NET agent to the same level as our agents in other languages to meet the demands of our users. .NET agent v1.1.0 released one month ago with the OpenTracing compatibility. It was another step moving forward to bring observability compatible with standards. With v1.2.0 released today, our .NET agent is now capable of automated instrumentation for the most used AWS services and supports distributed tracing.
When you update your agent version to 1.2.0, you will see automatically created spans that contain information about the request and interactions between your functions and AWS resources. Thundra's distributed tracing feature will make it much easier to troubleshoot your distributed system, which consists of many components and appears to be unmanageable.
The following AWS services are currently supported:
We built an example project that uses all the services above. Let's see Thundra in action.
The visual above shows a function that put an object to S3 and deletes it. One request for the put operation and one request for the delete operation. As you can see, Thundra's agent automatically created two spans for these two requests and put the request details into the spans that include Start/End time, Bucket Name and Object name along with the many useful tags. You can access this chart from the Invocation detail page or by clicking the arrow between interactions in the Trace map as shown below.
With Thundra, you can trace the flow in your distributed serverless applications with no effort. When you click on the
Traces menu in the left panel, Thundra will list the distributed traces happening in your application. You can filter these traces with respect to their entry point Lambda and the first trigger. After you filter these traces, you can click on one of these and start investigating.
Now, you want to see how everything is going on in your chain of invocations and track the messages. When you click on the Lambda nodes, you can see the local traces in the function. When you click on non-Lambda resources, you can see the messages being exchanged over these messages. As you can see, we are unique supporting the multiple upstream messages to Lambda functions.
Seeing is believing. As Thundra, we are making the invisible visible and reveal the secrets of your complex distributed system. Therefore you can troubleshoot faster, build a more efficient architecture and perhaps the most important one; decrease your AWS invoice. But how? We tried to make setting up Thundra for serverless .NET functions as seamless as possible. Follow our document to install the .NET agent to your application. You can wrap the lambda function, or you can configure template.yaml if you are using SAM to deploy, or you can configure serverless.yml if you are using Serverless framework to deploy.
We are implementing HTTP instrumentation for our .NET agent. We will publish the new release in the following weeks. We'll be happy to listen to your ideas and needs and come up with the best possible .NET support. Please submit your requests to firstname.lastname@example.org or come to our Slack and let's chat. You can sign up to Thundra or see the live demo to see Thundra in action.