Watch the recording of Episode 1 on YouTube!

Dynatrace assist developers on creating better software faster. This series is crafted for developers and performance engineers on helping them get the feedback they need and analyze the impact of every code change on every release. We will also learn how automated and intelligent QualityGates and Performance as a Self-Service stop bad releases going into production automatically.

This

Some of the topics you will learn:

perfclinic_devslovedynatrace_ep1.gif

In Episode 1 of this Performance Clinic Series, we will show you hands-on on how you can use Dynatrace in your development & test environments to automate observability and analysis of your applications & services. We will learn how to analyse problematic transactions in complex & hybrid distributed systems. We will dive into easy access of your distributed traces (we call them PurePaths) and how Dynatrace automatically shows the hotspots so that you can easily optimize or fix them.

In Episode 1 we will learn how to:

Dynatrace Secret Sauce

Observability and so much more

Features for Developers in a nutshell

The environment we want to analyze consists of a booking travel portal with a mix of technologies. A mix of Legacy and Classic Stack and also some new stack running on containers. You just need an ubuntu machine to spin it up.

Download install script

Download help script to install Easytravel, Nginx, Docker the OneAgent and other utils

wget https://raw.githubusercontent.com/dynatrace-perfclinics/why-devs-love-dynatrace/main/easytravel/ubuntu-setup-easytravel.sh

Add your Dynatrace credentials

## Set DT_TENANT_URL and API TOKEN
# ---- Define Dynatrace Environment ----
# Sample: https://{your-domain}/e/{your-environment-id} for managed or https://{your-environment-id}.live.dynatrace.com for SaaS
DT_TENANT_URL=
DT_PAAS_TOKEN=

Execute the script

sudo bash ubuntu-setup-easytravel.sh -i

Monaco stands for Monitoring As Code. In Dynatrace we love to automate. With monaco we can automate the configuration of one or multiple environments following a GitOps approach.

We will import the following configurations following a GitOps approach:

Download Monaco

Dynatrace Monitoring as Code

Download the latest release (depending the architecture of your OS) and add the binary to your path.

Check that you can execute the binary

monaco --help

Clone the GitOps configuration

git clone https://github.com/dynatrace-perfclinics/why-devs-love-dynatrace

Navigate to the GitOps directory

cd why-devs-love-dynatrace/monaco/devlove

Add your variables to a helper script set_dt_variables.sh

vi set_dt_variables.sh

# Sample: https://{your-domain}/e/{your-environment-id} for managed or https://{your-environment-id}.live.dynatrace.com for SaaS
DT_TENANT_URL=
# https://www.dynatrace.com/support/help/shortlink/token#create-an-api-token-
# Token in format dt0c01.STXXXX....
DT_API_TOKEN=

# DT_USER (Your login username in the environment, Click on the top right on the people icon and see your id, it can be your email or a username)
DT_USER=

Load the variables in the shell

source set_dt_variables.sh

Execute Monaco

monaco deploy -e environment.yaml --project episode1 -v

Understanding the Performance of any Environment

software-intelligence-dashboard

In this Performance Overview Dashboard you can see:

For getting a quick understanding on what is deployed on an enviroment, I recommend to start with the following sections:

Technologies

technologies

Applications

Get an understanding on the real users accessing the defined applications.
technologies

Smartscape

technologies

Diagnostic Tools 🔬🩺

technologies

requests

We will search for the following transactions:

🔎 Only failed transactions

requests

🔎 Transactions with more than 10 seconds over the last 6 hours

requests

🔎 Transactions calling dynatrace.com

requests

🔎 Transactions that makes more than 100 database calls.

requests

🔎 Transactions with Lock issues

requests

requests

We will search for the following transactions:

🔎 Do we have failing database statements?

requests

🔎 Which is the slowest database transaction of the day? Continue analysing with the outliers Detect the slowest execution and understand from where was this SQL triggered.

requests

requests

requests

🔎 Which SQL hast the most Fetch count and wich the most Row count? Where is this transaction coming from? Which application and which user action is triggering this SQL?

requests

requests

We will search for the following transactions:

🔎 All Exceptions of the day

ex

🔎 Failed exceptions

ex

REST Sign-In (Create Account) EasyTravel

We are asked to test the REST Sign-In and Login functionality of Easytravel. To understand the flow of the transaction, response time and architecture. We are only given the REST Endpoint where {{custom.easytravel_ip}} is the IP where easyTravel is deployed.

POST http://{{custom.easytravel_ip}}/easytravel/rest/signin

JSON Body

{
    "firstName": "{{custom.developer_name}}",
    "lastName": "{{custom.developer_name}} LastName",
    "email": "{{custom.developer_name}}",
    "password": "{{custom.developer_name}}",
    "state": "Bayern",
    "city": "Munich",
    "street": "Main Street 1",
    "door": "",
    "phone": "+49123456789"
}

We are going to pass the following attributes into the POST request.

HTTP Headers:
Content-Type: application/json
x-developer: yourname

For this excercise you can use cURL, VisualCode, Postman or any REST tool of your choice. Here is an API Test already preconfigured for you 🚦 API TEST Template for SingIn

alt

Create an Account via REST

alt

alt

alt

alt

{"error":"The email address you entered is already registered."}

REST Login (Log in to the created account) EasyTravel

Before we analyse the transactions in Dynatrace, let's test that we can create a Login with the created Account.

The endpoint is the following:

POST http://{{custom.easytravel_ip}}/easytravel/rest/login

JSON Body

{
    "username": "{{custom.developer_name}}",
    "password": "{{custom.developer_name}}"
}

Login via REST

MDA FeedBack Developer

alt

You'll find your request for each transaction twice, but on an Apache Tomcat and on an NGINX. The NGINX (which is running in a docker container) works as a reverse proxa and forwards all headers, hence Tomcat also captures the x-developer header. pretty easy to understand by showing the service flow or backtrace.

alt

Remove the filter of the sign request. When removing the request type you'll notice the 3 distributed trace of your requests (2x signin + 1x login).

alt

Now let's filter the transaction of the correct Account creation. Add a response code:200 and request:sign

alt

Now on the NGINX Service we click Analyze and go to the Response time hotspots. I like to think that I submerge into the service and navigate inside the service.

alt

Inside the Response Time hotspots Dynatrace shows us the average time of the selected transactions on the NGINX service. The distribution of its transactions (we have only one here) and the top findings.

alt

We see that the most of the time is spent on interaction with other services which is the Method signUser on the EasyTravel Service. We click on the filter to navigate forward.

alt

Notice how we jumped into the next service. Imagine that you are navigating within the distributed transactions and now you find yourself on the next service.

alt

Notice how we start adding a chain of filters into the analysis and we navigate through the services. Now the time changed to 13.9 ms because we are in the EasyTravelService. From those 13.9ms, 8 milliseconds are spent on code execution whitin this service (java code since its a tomcat) and 5.82 ms in calls to addNewUserin the AuthenticationService. We click on the filter on the addNewUserin the AuthenticationService to jump to the next service.

alt

Now we find ourselves in the AuthenticationService. The timings adapt and we see the information for this transaction and this service. By clicking to the Database we see there were 8 request = 4 Connection Aquisitions + 2 SQL Statements (1 x Select + 1 x Insert ) + its corresponding 2 Commits.

alt

Now let's show the Purepath so we understand how we navigated. Scrolldown and click on Backtrace and on the NGINX node, click on Analyze > Purepaths.

alt

Now it's showing us the purepath from the nginx as start (distributed trace with all it's spans and code insights). On the dropdown on the right, show the HTTP request data. Now we remove the filter of the response code 200 on the NGINX node and click apply. What happens?

alt

It's also showing us the transaction that failed.

If you compare them you'll notice that the one that succeded (besides having the response code 200 which is obvious) has an insert statement.

alt

This is due the fact that the previous select statement (select user...) does not find the account hence is able to insert a new account in the database.

alt

The subsequent account creation returns a row hence the double account can't be created.

alt

The rows returned can also be seen for both transactions by displaying the purepaths from the database node.

alt

Service-flow Login

ResponseTime Hotspots Login

Open the ResponseTime Hotspots from the ReverseProxy. Notice the contribution from Tomcat the Calls to AuthenticationService (4x) and VerificationService (1x)

Notice the contribution by Method within the AuthenticationService and how it can tell us which method is taking the most time within a single transaction (even though we are moving in 2 digit ms time)

How was your overall experience with this lab?How likely are you to recommend this lab to a friend or colleague?