Log analysis with PurePath® technology

Logs are often a crucial component for understanding the behavior of your environment. Use the log enrichment to view related long entries right in the distributed traces view and enhance your analysis capabilities. By combining logs with distributed traces, you can check log records in the full context of a transaction. Automatic contextualization of log data works out of the box for popular languages like Java, .NET, Node.js, Go, and PHP, as well as for NGINX and Apache web servers.

With logs available for individual services over the flow of the transaction, you can trace user interaction with your application via log records. To view logs related to an individual transaction, navigate to the trace you want to analyze and select the Logs tab.

You can also view all logs related to the trace in the Log viewer. To open it, select View logs for this trace.

Example

Walk through this example of problems in a web shop to see how logs can enhance your distributed traces analysis. The problem affects multiple services and combines a failure rate increase with response time degradation.

We begin our analysis with the affected Go service and check its dynamic requests.

To investigate the failure rate, we select the Failure rate tile. This takes us to the Failure rate tab of the Details page.

The chart highlights the time period over which the failure rate increase occurred. To find out more, we select Analyse failure rate degradation.

We immediately see that a lot of requests are affected and that Dynatrace suggests some possible root causes. We select Details for the first one to inspect that possible root cause.

The first extension on the list is an issue with a credit card payment, which has a serious impact on users, so that matter requires investigation. You can find related logs at the bottom of the page. For now, let's select View all logs in the log viewer to check all possible logs.

We can see right away that there's a problem with loading shipping holidays. Expand a log record to see more. Among additional attributes, we can find the trace_id property, which links the log record to a distributed trace.

Select the value of the property to navigate to the related distributed trace. It contains a detailed overview of application behavior and user experience for this particular transaction.

We can see at a glance that two traces are in an erroneous state. If we went through them, we'd find an error log for the /cart trace.

The log shows an error while attempting to load shipping holidays, so we can check this trace for more information, as it contains an error as well, hinting that it might be the cause of response time degradation.

Looking at the distributed trace, we conclude that there's something wrong with the GetCart service, which contributes significantly to the overall response time. If we check its logs, we'll find the "slow request" entry.

Now that we have identified components contributing to the problem, we can contact responsible teams and ask them to investigate.

Let's go back and check logs for more errors. Because we have attended to the shipping holiday problem, we can filter out those logs with advanced query mode.

Remaining logs indicate a problem with an unsupported card type. Let's expand the log and navigate to the distributed trace.

By going through the distributed trace, we can see that the application is functioning normally, and that the problems are caused by an unsupported card type.

Because this is not something we can fix in our application, we contact our payment handling provider to see how this issue can be resolved.

As a side-effect of this analysis, we notice that the card number appears in the log, so we might also contact the responsible team to change logging rules to prevent logging of sensitive information.