DYNATRACE

DYNATRACE:

Dynatrace is a software-intelligence monitoring platform that simplifies enterprise cloud complexity and accelerates digital transformation. With Davis (the Dynatrace AI causation engine) and complete automation, the Dynatrace all-in-one platform provides answers, not just data, about the performance of your applications, their underlying infrastructure, and the experience of your end-users. Dynatrace is used to modernize and automate enterprise cloud operations, release higher-quality software faster, and deliver optimum digital experiences to your organization's customers.

Dynatrace seamlessly brings infrastructure and cloud, application performance, and digital experience monitoring into an all-in-one, automated solution that's powered by artificial intelligence. Dynatrace assists in driving performance results by providing development, operations, and business teams with a shared platform, metrics. In this way, Dynatrace can serve as your organization's single "source of truth."

ONE AGENT

OneAgent is responsible for collecting all monitoring data within your monitored environment. A single OneAgent per host is required to collect all relevant monitoring data—even if your hosts are deployed within Docker containers, microservices architectures, or cloud-based infrastructure.

A single instance of OneAgent can handle monitoring for all types of entities, including servers, applications, services, databases, and more. OneAgent gives you all the operational and business performance metrics you need, from the front-end to the back-end and everything in between—cloud instances, hosts, network health, processes, and services. OneAgent discovers all the processes you have running on your hosts. Based on what it finds, OneAgent automatically activates instrumentation specifically for your unique application stack. It also injects all tags required for user-experience monitoring into the HTML of your application pages. New components are auto-instrumented on the fly.

OneAgent is comprised of several code modules that enable OneAgent to work for most technologies out-of-the-box.

After OneAgent is installed on a host, it monitors all applications running on that host. As a starting point, all monitoring data is encapsulated in a placeholder application called My web application. The reason we offer this placeholder application is to allow for more flexibility, as we leave it up to you how your application should be organized. To do so, Dynatrace provides you with the following options

Smarscape

Smartscape, our near real-time environment-topology visualization tool, is one of the most powerful features of Dynatrace.

Smartscape auto-discovery delivers a quick and efficient visualization of all the topological dependencies in your infrastructure, processes, and services

With just a few clicks, Smartscape gives you access to a detailed topological view of your entire environment, giving you more insight into and control over your environment.

• Make better decisions, such as adjusting your service architecture or infrastructure to improve application performance.
• Examine cross-tier and same-tier process, host, and service interdependencies to better understand how dependencies affect the performance of your applications.
• Drill down to gain clearer insight into problems. For example, Dynatrace might identify an issue with third-party dependencies and help you understand the impact of the issue on your application's performance.

Service Flow

Dynatrace understands your applications’ transactions from end to end. This transactional insight is visualized through Service flow, which illustrates the sequence of service calls that are triggered by each service request in your environment. With service flow, you see the flow of service calls from the perspective of a single service, request or their filtered subset. Along with the specific services that are triggered, you can also see how each component of a request contributes to the overall response time.

The service flow visualization isn't designed to show when service calls are executed relative to one another. While the service flow visualization is helpful for understanding the sequence of service-call chains, it doesn't necessarily show the order in which calls were made relative to one another across services.

Service flows can become highly complex. For improved readability of service-flow data, Dynatrace aggregates services that contribute little to overall response time. If you select one of the aggregated services, the service flow will display the requests path of the selected service.

Aggregations are calculated dynamically based on the size of your browser window. You can use your browser's zoom in/out feature to make more space available.

PurePaths

PurePaths combine distributed tracing with code-level visibility, topology information, and metadata to provide the highest level of data granularity and fidelity.

OneAgent automatically captures PurePaths across the entire transaction, spanning multiple devices, operating systems, page actions, and code methods. The rich and contextualized information of PurePaths fuels unique features like method-level analysis, detailed error analysis, database analysis, and request attributes. On top of that, the collected data enables you to explore various aspects of your systems by slicing and dicing in a multidimensional analysis.

PurePaths are vital ingredients for Dynatrace Davis to perform automatic baselining with a unique root cause analysis that provides you with actionable insights.

Through PurePath technology, Dynatrace enables you to efficiently find the proverbial needle in the haystack and focus on those few requests (out of tens of thousands) that you’re interested in. You can view requests from multiple vantage points—from the perspective of the services you’re responsible for or from the point of view of where a request originates in your system.

Service Backtrace

More than just knowing which service directly calls one of your services, it's helpful to know the sequence of service calls that leads up to each request—all the way back up to the browser click that triggered the sequence of calls. Dynatrace Service-level backtrace can show you such call sequences.

Say for example that you’re analyzing a SQL database service and you want to understand the sequence of preceding service requests that ultimately triggered the incoming requests to the SQL service. With service-level backtrace you might learn that, for example, the SQL database service is called by Service1, while Service1 is called by Service2, which in turn was triggered by a click on a login button.

Service analysis timings

Service analysis operates with many different timings, describing the behavior of the service. The table below provides an overview of such timings. Timings vary in different analysis types:

• PP: PurePath.
• RT: Response time.
• SF: Service flow.
• MH: Method hotspots.

Regardless of which analysis you're running, it is not guaranteed that you'll see all of the timings listed here. The actual timings you see depend completely on how you're running your services. For example, if the PurePath runs completely on one host without any networking involved, you won't see any network-related times.

Dynatrace offers the ability to detect clustered services. Clustered services are services that are served via multiple processes. Dynatrace enables you to analyze the load distribution, response time distribution, and failure rates of each individual service instance.

Service response time hotspots

With deep process monitoring enabled, Dynatrace analyzes the response time of each service running within each process. This is applicable to Java, .NET, Node.js, PHP, Apache webserver, IIS, NGINX, and other technologies.

Each Service page enables you to analyze response time hotspots. Response time hotspots indicate which activities are consuming the most time for each service.

The Current hotspot pane displays top hotspot findings of the service. 

• Requests with slow response time
• High failure rate
• High CPU consumption 

The pane also displays requests with high consumption of request resources. The percentage shows the share of the request in the overall response time of the service. In the example below, 85% of the findJourneys service response time is spent on execution of the findJourneys request.

Automatic Hotspots

The Top findings section of the Response time analysis infographic lists the hotspots that are the key contributors to the analyzed request.

Outlier analysis 

To gain a deeper understanding on how response times vary across requests during the selected period, click the Analyze outliers button to navigate to the Response time distribution page.

Click any distribution-percentile bar to view the number of requests that fall into that response time range. As you can see in the Top web requests section beneath the chart, the slowest requests (the longest response times) may take dramatically longer to execute than the fastest requests. Such outliers can have a big influence on the overall response time of a service.

Application types supported by Dynatrace 

Dynatrace supports different application types: web, mobile, AMP(Accelerated Mobile Pages) as well as rich client applications over apps running in a car up to IoT applications with user interactions. Each type is associated with different monitoring capabilities as well as a different UI within Dynatrace. However, all types are permeated by common concepts like user sessions and user actions.

Web applications

• User interface: JavaScript enabled browser (mobile or desktop)
• Monitoring approach: Dynatrace RUM JavaScript
• Injection type: Injection of the Dynatrace RUM JavaScript can be done automatically by OneAgent or manually for agentless monitoring or by using the Dynatrace browser extension.
• How to get started: Define your applications via the "My web application" placeholder

AMP applications:

• User interface: JavaScript enabled browser (mobile or desktop) – pages are following the AMP specification
• Monitoring approach: Dynatrace RUM JavaScript
• Injection type: Injection is done manually by the customer by passing special AMP settings to the AMP pages.
• How to get started: Set up AMP monitoring

Mobile apps

• User interface Native mobile apps on iOS or Android
• Monitoring approach: OneAgent for iOS or Android; for hybrid apps the browser part is monitored by the Dynatrace RUM JavaScript
• Injection type: No injection is required—lifecycle events, user actions and web requests are monitored out of the box.
• How to get started: Get started with Android monitoring and Get started with iOS monitoring

Dynatrace OpenKit

There are many ways your business can interact with your customers in the digital world. Monitoring user experience and behavior in your web and mobile applications is a great way to get started with digital experience monitoring; Dynatrace easily detects and automatically monitors all application touchpoints using OneAgent. However, your business likely has many other digital touchpoints outside of your applications where your customers interact with your brand that are also key to the success of your business. With Dynatrace OpenKit, you get a set of open source libraries that enable you to instrument all other digital touchpoints in your environment, whether or not they’re traditional rich client applications, smart IoT applications, or even Alexa skills.

Dynatrace OpenKit is a set of open source libraries that provides an easy, lightweight means of instrumenting the source code of your custom applications so that you can monitor their performance with Dynatrace or AppMon. Dynatrace OpenKit is best suited for client/server applications that communicate via HTTP (for example, rich-client-applications, embedded devices, and terminals).

The main advantages of OpenKit are:

• Ease of use
• No 3rd-party or OneAgent library dependencies
• Ease of portability to other languages and platforms

With Dynatrace OpenKit, you can:

• Track user sessions and user actions
• Report on events, errors, and crashes
• Trace web requests to server-side PurePaths
• Tag user sessions with user tags
• Maintain compatability with both Dynatrace and AppMon

With Dynatrace OpenKit, you can't:

• Create server-side PurePaths: This functionality is provided by the Dynatrace OneAgent SDK.
• Create metrics: You can however use the Custom network devices & metrics API to report metrics.

The Dynatrace OneAgent SDK

Enables you to instrument your application manually to extend end-to-end visibility for frameworks and technologies for which there is no code module available yet. With the SDK, you get full access to all analysis and monitoring functionality, including auto-baselining and AI-based root cause analysis.

The Dynatrace OneAgent SDK is available on GitHub

How OneAgent works

OneAgent is essentially a set of specialized processes that run on each monitored host. OneAgent collects metrics from the operating system it runs on and compares the metrics to performance metrics. The most important metrics are then reported to Dynatrace.

Additionally, OneAgent detects which processes run on each host and collects performance metrics for the most important processes. OneAgent can also monitor specific technologies (Java, Node.js, .NET, and more) in greater detail by injecting itself into those processes and monitoring their performance from within. This provides you with code-level insights into the services that your applications rely on.

To deliver Real User Monitoring, OneAgent injects a JavaScript tag into the HTML of each application page that is rendered by your web servers. With these JavaScript tags in place—along with a corresponding module that is automatically installed on your web server and requires no configuration

Injection formats 

Find the injection format that best suits your web application and needs in the following subsections related to each injection type.

• Automatic injection
• Manual insertion
• Retrieve via REST API

What are the ways that Dynatrace can inject the JavaScript Tag to enable monitoring?

• Automatically, or manually

Where can a JavaScript tag e injected into HTML?

• In the header, or through a custom location in the settings of the app.

What is the significance of the script containing the string "/ruxitagentjs"?

• That is the injection from Dynatrace into the HTML
• It shows that the injection happened and is being monitored (if a 200 status is returned)

Why don't I see my applications or monitoring data?

If you don't see any of your applications or Real User Monitoring data in Dynatrace, the first thing you need to do is confirm that there is traffic in your web front-end processes (web server, Java, Node.js, etc). To do this, interact with one of your applications' pages to generate some traffic.

Once you're certain that your web front-end processes have traffic on them, check the following to determine the cause of the problem:

• Confirm that the RUM JavaScript tag has been correctly injected into your application's HTML.
• Confirm that the RUM JavaScript tag has downloaded correctly.
• Confirm that RUM monitoring data is being sent to Dynatrace.
• See the expandable sections below for details on confirming these points.

How can I confirm the JavaScript tag is injected correctly?

The first thing to do in verifying that Real User Monitoring has been set up correctly is to search for the Dynatrace RUM JavaScript tag in your application's HTML.

Load one of your pages, inspect its source in the web browser and check that the <HEAD> element contains a reference to the Dynatrace JavaScript. If you are not able to locate the Dynatrace JavaScript, make sure that your HTML is a valid formed HTML with both opening and closing tags for <HTML> and <HEAD>. For more details on whether your HTML fulfills the requirements for auto injection, visit Real User Monitoring JavaScript injection.

For standard OneAgent installations (automatic tag injection)

• Search for a script that contains the string ruxitagentjs in its file name.

For agentless monitoring (no OneAgent, no automatic injection)

• Search for a script that's loaded from js-cdn.dynatrace.com (or your own CDN or domain in Dynatrace Managed; CDN is recommended) and ends with the string _bs.js.

If you don't see the JavaScript tag automatically injected by OneAgent, it's probably because one of the following reasons:

• The defined application detection pattern is incorrect.
• Rules on firewalls, load balancers, or proxies aren't configured properly. For more details, see firewall constraints for RUM.
• Dynatrace OneAgent aborted the injection due to an invalid HTML structure or wrong encodings. 
• You might have defined exclusion rules for browsers, robots, and spiders.
• If the injections fails only for a single session, Dynatrace might have throttled the capture rate of your application.
• Dynatrace OneAgent can't automatically detect the hostname of your web application, because the associated web servers operate behind firewalls or proxies that are using different hostnames.

One Agent is able to monitor the response times and performance experienced by your customers in their mobile and desktop browsers.

OneAgent is also capable of monitoring the log files of a specific host or process group. It can discover and analyze a default system or process-created logs. Depending on your configuration, you can store these log files, which makes the log data available independently of the log files themselves. 

This can be beneficial in the following situations:

• Short log-retention periods
• Volatile log storage
• Legal requirements for keeping logs archived centrally for long time periods

OneAgent can dig deeper and get network metrics at the process level. Through our process-to-process monitoring of network communications Dynatrace can:

• Ensure high-quality process communications over networks.
• Understand your network topology in dynamic environments.
• Process-level network capacity monitoring.
• See integrated network health monitoring.

Communication from OneAgent to Dynatrace is outbound only; Dynatrace never initiates communication with OneAgent. So there's no need to open ports for inbound communication when using Dynatrace. OneAgent can communicate directly to Dynatrace or it can communicate via a Dynatrace ActiveGate.

OneAgent offers a rich set of monitoring capabilities

• Real User Monitoring
• Mobile app monitoring
• Server-side service monitoring
• Network, process, and host monitoring
• Cloud and virtual machine monitoring
• Docker container monitoring
• Root-cause analysis

Agentless Real User Monitoring

Agentless monitoring is meant to be used in cases where you don't have access to your web server and therefore can't install OneAgent. However, before deciding on a third-party library, consider the following points: The full benefits of Real User Monitoring can be obtained only after you’ve installed Dynatrace OneAgent. The installation of Dynatrace OneAgent is highly recommended for the following reasons:

With agentless monitoring, you need to manually insert a RUM JavaScript tag into each of your application’s pages, which can be challenging. Dynatrace OneAgent handles the insertion of all JavaScript tags for you.

Unless you use the code snippet option for agentless monitoring, the JavaScript tags embedded into your application’s pages won't be automatically updated when you change application monitoring settings. You’ll have to update the tags manually.

Maintenance effort 

Agentless monitoring requires you to insert tags by yourself, which is why you must ensure that it requires as little manual effort as possible. You don’t want to have to change your code every time your configuration changes or when a new version is released. The code snippet added to your application usually doesn't need to be changed as it takes care of loading the right configuration and version for you.

Insertion methods 

The right JavaScript tag insertion method depends upon the application and your requirements. There are five options to choose from, Code snippet async being the default option.

Insertion method

JavaScript tag Requires manual insertion of the RUM JavaScript tag into the HTML head of every application page. This approach is compliant with Content Security Policy. Depending on your configuration, the tag is updated periodically.

Code snippet (synchronously)

Requires manual insertion of the code snippet into the HTML head of every application page. The snippet initializes Dynatrace and dynamically downloads the monitoring code into your application. The tag need not be updated.

Code snippet (deferred)

Requires manual insertion of the code snippet into the HTML head of every application page. The snippet initializes Dynatraces and dynamically downloads the monitoring code into your application. This approach reduces impact on page load but reduces visibility because certain XHR calls may not be instrumented. The tag need not be updated.

OneAgent JavaScript tag

Requires the same JavaScript tag that is inserted automatically by Dynatrace OneAgent. The tag must be updated each time the configuration is changed or monitoring code is updated.

Inline code

Requires manual insertion of the full JavaScript code inline into the HTML head of every application page. The tag must be updated each time the configuration is changed or when new JavaScript code versions become available.

Real User Monitoring

Real User Monitoring (RUM) is one of the two fundamental constituents of Digital Experience Monitoring (DEM), the other one being Synthetic monitoring. DEM is defined by Gartner as an availability and performance monitoring discipline that supports the optimization of the operational experience and behavior of a digital agent, human or machine, as it interacts with enterprise applications and services.

Dynatrace RUM gives you the power to know your customers by providing performance analysis in real-time. This includes all user actions taken and how the various actions impact performance. 

You can also easily identify problems or errors that occurred as well as user experience ratings, geolocation breakdowns and much more. You can also gain insight into the behavior of your users. This among others includes the number of customers who return to your site. With Dynatrace RUM, you have the context over time and immediate analysis to the complete picture of your end-user experience.

Brief overview of the RUM concepts

The basic concepts of RUM revolve around user sessions and user actions. A user session is essentially a "user visit" performed in your application. Dynatrace captures user sessions of web applications, mobile apps and custom applications. For web applications, a user session can span multiple applications.

A user session of a web application includes at least one user action. In this case, a user action is an interaction with the web browser that involves one or more calls to a web server, i.e. one or more web requests.

Dynatrace can trace the activity of a single user along different devices. This means that if a user starts using your application on a mobile phone and then at a later point in time continues through a desktop browser, Dynatrace can associate all these user sessions with this specific user.

USER ACTION:

A user session, sometimes known as a "visit," is a group of user actions that are performed in your web application during a limited period of time. A single session typically includes multiple page loads, 3rd-party content requests, service requests, and user actions (for example, button clicks and file downloads). Each user session includes at least one user action.

Live user sessions are differentiated from ended user sessions by color, thereby allowing you to spot active sessions at a glance.

Dynatrace typically shows all the sessions of each individual user, even when those sessions are anonymous (non-authenticated users identified via browser cookies) or when a user tag has been edited or deleted. For mobile apps, Dynatrace identifies individual users based on the specific mobile device they use. For web applications, user identification is achieved by storing a persistent cookie within each user’s browser. Cookies enable Dynatrace to assign even anonymous user sessions to known users. As long as a user has logged into your application at least once, you can search for and identify that user, even when the user accesses your application within anonymous, unauthenticated sessions. This is particularly useful for analyzing periods of time when a user may not have been able to log into your application due to an issue with your authentication service.

When does a user session start? 

    A user session starts when the first user action is initiated.

When does a user session end? 

    A user session ends in one of the following ways:

• After 30 minutes of browser inactivity.
• When the user closes their browser. Note that the session only ends when the browser is closed and remains live in the UI until 30 minutes of inactivity.
• Once the limit of 200 user actions per session is reached.
• By calling the JavaScript API function dtrum.endSession(). This function can be used within your application to end user sessions automatically when, for example, the user logs out. You can also use this API call if, during testing for example, you want to immediately end browser sessions. To use this function, open your browser's console and enter the call dtrum.endSession(). Your user session will then appear in the User sessions view 2-4 minutes after the end of the session.
• Maximum session duration is 6 hours.

How long does it take for a user session to be visible in the user session search? 

Typically, a user session is visible in the search within 4 minutes. However, this could sometimes exceed to 10.5 minute

How is user session duration calculated? 

User session duration is the elapsed time between initiation of the first user action in a session and the completion of the last user action in the session.

How to differentiate live user sessions from completed sessions 

Live user sessions are colored light purple and don't have any information about the user experience score or duration, as those are calculated at the end of the session. Live sessions can still get new user actions.

USER ACTIONS TYPES:

A user action is an interaction with the web browser that involves a call to a web server, which can potentially have multiple nested calls.

Why would you mark a Key User Action?

• Could customize the Apdex rating for the action
• Can be pinned for quick and easy access

For how long are key requests stored?

• By default, 10 days.

Key Requests:

You can measure mission-critical requests or functionality, based on certain text or information or header in a request. You can have custom alerting thresholds

User action types

A user action can be a load action, an XHR action, or a custom action. The key difference among these action types is the way action duration is calculated and that for each type there are different metrics available.

Load action:

A load action is defined as an actual page loading in your browser. If you type a URL in your browser and press enter, a load action occurs. During a load action, many resources are loaded, including images, HTML, and CSS.

XHR action 

Most modern applications, including single page applications, rely on a single load action that downloads the framework and initializes the page. After that, the DOM of the page is changed via JavaScript and all communication with the web server is done via XmlHttpRequest or via fetch().

An XHR action starts with the user's click on a control on a web page. All metrics are calculated in relation to this point in time and are based on the initial XHR that triggers the user action.

Fetch API

The Fetch API provides an interface for fetching resources (including across the network). It is similar to XMLHttpRequest, but the API provides a more flexible feature set. The generic definitions of Request, Response and other network request objects in Fetch allow them to be used at any time they are needed, whether it’s for service workers, Cache API, or anything that handles or modifies requests and responses. Fetch also supports the Cross Origin Resource Sharing (CORS).

Custom user actions 

Rather than relying on default user action generation, you may want to fine-tune your Real User Monitoring by adding additional user actions directly into your application’s HTML. This can be useful if our automated user-action generation doesn’t catch specific actions or you want to introduce specific fine-grained timings into your application monitoring. For example, you could measure how long it takes to open a JavaScript-only drop-down menu, or measure the duration time of some JavaScript code. To define custom actions you can use the JavaScript API for Real User Monitoring.

User action naming rules 

Many applications allow users to accomplish the same goal through different UI controls. When monitoring such applications, it can be difficult to differentiate between actions that have the same result and goal, but are executed by using different parts of the application UI. Likewise, if the UI of an application is translated into multiple languages, the same application function or control can appear under varying names. With user action naming rules, Dynatrace can detect such subtle variations and intelligently group related user actions (i.e., user actions that achieve the same goal) into logical groups for monitoring.

Action name detection:

Dynatrace tries to assign meaningful names for actions. To do this, it checks several action properties, such as inner HTML, caption, and hint, of the HTML element that triggers the action. This element can either be a button or an anchor. It also tries to get the caption if there's a more complex HTML structure with multiple nested tags

Key user actions:

Most applications, both web and mobile, include user actions (for example, signups, checkouts, and product searches) that are particularly important to the success of your digital business. Such key user actions might take longer to execute than others or they might have the requirement to be of shorter-than-average duration.

For instance, consider that you've set your global Apdex threshold to 3 seconds. While this threshold might be acceptable for the majority of user actions, it might not be acceptable for a sign-up user action. Alternatively, there could be a search action that is quite complex and requires longer than the allotted 5 seconds.

With the key user action feature, you can customize the Apdex thresholds for each of these user actions. You can use this feature to monitor key actions with a dedicated dashboard tile and track historic trends.

Note: Dynatrace allows you to create a maximum of 500 key user actions per environment across all applications and a maximum of 100 key user actions per application. When you reach that limit, consider using calculated metrics for Real User Monitoring, which offer similar capabilities.

Mobile app monitoring:

OneAgent supports real user monitoring for mobile applications as well. The process of monitoring the user experience of your native mobile applications is fundamentally different from monitoring browser-based web applications. This is because mobile-app monitoring involves the compilation, packaging, and shipment of a monitoring library along with your own mobile application package. The process of instrumenting your mobile application largely depends on the platform of your mobile application. Dynatrace supports both Android and iOS platforms

Server-side service monitoring:

Web applications consist of web pages that are served by web servers (for example, Apache Tomcat) and web containers (for example, Docker). The web requests that are sent to a specific Tomcat server are an example of a server-side service. Server-side services may be of various types like web services, web containers, database requests, and custom services. OneAgent can provide information such as which applications or services use which other services and whether or not a service makes calls to other services or databases.

Dynatrace automatically detects and names server-side services of your applications based on basic properties of your application deployment and configuration.

Dynatrace visualizes the complexities of your application stack and delivery chain with Smartscape technology. In a Smartscape visualization, you can see which individual web page calls which specific web server, the application server that receives the resulting web requests, and where the resulting web request service calls are sent.

As service landscapes can become quite complex, Dynatrace automatically categorizes services based on their dependencies to other entities like services or applications.

Dynatrace automatically groups related processes into process groups. When Dynatrace detects multiple process groups, it assumes that the process groups represent separate applications, or at least separate logical parts of a single application. Process groups therefore represent boundaries for the services they contain.

Process Groups

a logical cluster of processes that belong to the same application or deployment unit and perform the same function across multiple hosts

When Dynatrace detects the same service in multiple processes within the same process group, it represents the service as a single service running on multiple processes or hosts. Conversely, if Dynatrace detects a seemingly identical service in multiple process groups, it represents the separate service instances as separate services, even though the services appear to be the same.

Web request services:

Web request services serve the web applications that you deploy either via a web server (for example, Apache, IIS, or NGINX) or within web containers (for example, Java, .NET, Node.js, or PHP). Dynatrace considers three discrete concepts when identifying and naming web services: Web server name, Context root, and Web application ID.

• Web server name

There are three different terms—Virtual host, Server block, and Site—that represent similar concepts across different technologies.

• Context root

Within any given web container you may have multiple applications in multiple directories. For example /admin leads to the admin application while /shop leads to the online store. In the Java world this is called a context root. Microsoft IIS refers to this concept as a Virtual directory. Most web servers don't even include this as a concept.

• Web application ID

Some technologies allow you to assign specific names to your deployed web applications.

Web services:

Web services are defined by Web Services Description Language (WSDL), which is part of your deployment. WSDL defines services, how services are called, and service names. Dynatrace picks up service names along with targetNamespace values and combines these values to uniquely identify each service.

Dynatrace detects web services based on technology-specific frameworks. For details on the web-service frameworks that are monitored by Dynatrace out-of-the-box, see supported web service frameworks for Java and .NET.

Sometimes it's technically not possible to easily detect a web service name. In such cases Dynatrace uses the web service endpoint rather than the name.

Merged Service

Services in the same process group, with the same technology, but may exist across separate nodes

A merged service is a service that aggregates multiple web-request services of the same process group that performs identical functions across separate cluster nodes. Service merging is available only for web-request services that perform the same function within the same process group, and so are effectively identical from a performance-monitoring perspective. A merged service appears in Dynatrace as a single service that contains all the data of all aggregated services.

Say you have an Apache web server with several virtual host definitions (for example, dynatrace.com, dynatrace.at, and dynatrace.pl). From the Apache perspective, these are independent virtual hosts. Dynatrace therefore detects them as separate services. For your monitoring purposes however, you might want to view these services as a single merged service called Dynatrace web page.

Before the merge:

• Once merged, the data of individual merged services can no longer be distinguished—monitoring data is then only available in aggregate for all the merged services.
• Once you create a merged service, original services are no longer updated as data sources. While historical data remains available (for example, for charting), no new data is tracked for the original services. All new aggregated data will be assigned to and associated with the new merged service.
• If you split a service from a merged service ("unmerge" the service), the historic data will be available only for the merged service. All newly captured data will be associated with the new standalone service.
• Only services of the same type can be merged. Mergeable services must, for example, belong to the same process group, share the same underlying technology, and follow the same naming pattern. Multiple virtual hosts, context roots, or listen ports that represent the same logical entity are often candidates for service merging.
• A merged service can't be merged into another merged service. Only near-identical, standalone web-request services of the same process group can be merged.

Opaque Services

Opaque services are services that are detected on the calling side by Dynatrace for which code-level visibility isn't available. Dynatrace can detect requests to opaque services and identify which processes they are processed by, but Dynatrace can't monitor these services directly.

Code-level visibility isn't possible if:

• Service is of a technology type for which deep monitoring isn't supported.
• Service is of an unrecognized or unsupported technology.
• No deep monitoring support 
• Code-level visibility might not be available for some technologies, even though the technology is supported by Dynatrace.

Dynatrace can detect all requests to such services that are sent by services with full visibility. Dynatrace calculates response times and failure rates and generates appropriate alerts.

Dynatrace understands the impact that host and process performance problems can have on services. This is why Dynatrace correlates host and process issues with corresponding slow-downs in service requests. For example, if a service without code-level visibility crashes, Dynatrace will interpret the crash as the root cause of any increased failure rate in calls to this service.

When a service is of an unrecognized technology or a technology that is recognized but not currently supported by Dynatrace, the service is considered to be opaque

Opaque services of unrecognized or unsupported technologies are included in Smartscape. This ensures a complete representation of your infrastructure’s topology, even when your environment includes opaque services

Other reasons services may be classified as opaque

There can be cases where a service is considered opaque even when the service is recognized and of a supported technology. This can occur for multiple reasons, such as:

• A process is offline but the service still makes calls to it. These opaque services are used to visualize dependencies in the context of availability problems.
• A process never started processing a request (the calling service receives an error or timeout) and therefore Dynatrace cant track the request in the process.
• A process hasn't completely restarted following OneAgent installation. By the time the process restarts, it should no longer appear as opaque.
• The framework processing the request at the specific port is not currently supported by OneAgent. If this is important to you, please submit a Request for Enhancement request for the specific framework and version by visiting our Dynatrace Community.
• The framework is supported, but OneAgent has run into a technical problem. In such a case, please submit a support ticket. Describe the issue as best you can and include all details regarding your underlying framework, technologies, and versions

Database services:

When Dynatrace detects that your application makes database requests, it identifies the name of the database or schema, the database vendor, and the IP address/port of the database. It uses this information to define a unique monitored database service and, where possible, detect on which process the database service runs.

All database statements executed during the selected timeframe are listed in the Database statements section at the bottom of the Details page (see example below). By default, database statements are sorted based on median response time. 

With code-level database monitoring you can:

• See the impact of your database statements on the response times of your services.
• Find expensive database statements based on the service calls or user actions from which they originate.
• Find out which services talk to databases most frequently.
• See how much load is placed on your databases by individual services.
• Understand why some statements are slow.
• Be notified of increased SQL statement costs and execution.

How does Dynatrace identify unique monitored database services?

• It identifies the name, vendor and IP address/port and uses it to detect on which process the database service runs.

How database activity is monitored:

In monitoring databases, Dynatrace doesn't consider methods, but rather commits, queries, and modifications related to your database services. By monitoring such calls, Dynatrace is able to deliver automatic root-cause analysis for performance problems with your database services. For example, if your database queries or commits slow down, we'll notify you immediately. We'll even show you which services are impacted by the problem.

Database calls that are made through monitored Java, .NET, PHP and Node.js processes are monitored automatically as long as the interaction with the database relies on a supported database framework, such as JDBC, ADO.NET, or PDO. 

When OneAgent is installed on the host that runs your application server, Dynatrace ensures that all database statements are logged, as long as deep monitoring is active for the calling processes. As soon as the first calls to your database are monitored, the Databases page is updated with the new database entry.

When monitoring database activity, Dynatrace shows you which database statements are executed most often and which statements take up the most time. You can also see which services execute the database statements. For example, Dynatrace knows automatically when a service begins sending too many database statements and pushes a database server beyond its capacity.

When a database-related problem is raised, for example due to a drop in response time, Dynatrace tells you if there is a correlation between the problem and any load increase on a related service, which may be the root cause of the problem.

Detection of IP addresses, geolocations, and user agents

Dynatrace automatically detects IP addresses, geolocations as well as browsers, devices, and operating systems.

IP addresses

IP addresses are automatically identified from the HTTP headers of web requests and the Dynatrace Real User Monitoring signal. However, when load balancers, CDNs, or proxies are used, the remote IP of the HTTP(S) request might be different from the original IP address from your end users' devices. For such cases, Dynatrace watches the HTTP headers most frequently used for identifying the originating IP address of a client connecting to a web server through an HTTP proxy, a CDN or a load balancer. To view which headers Dynatrace watches by default, go to Global Settings > Web & mobile monitoring -> IP determination. These headers are processed in a specific order. Dynatrace however allows you to change the processing order as well as to add your own headers.

Geolocations

 

Dynatrace Real User Monitoring tries to assign every user session a geolocation (city, region, country) in order to group user sessions and user actions per location and show them on the world map.

For web applications, Dynatrace uses the MaxMind Geo2 Database to map and resolve IP addresses to geographical locations. Dynatrace automatically updates the MaxMind Geo2 Database in your environment with the release of each new version of Dynatrace.

For mobile apps, Dynatrace uses the coordinates from the device (GPS or wifi) if the app has the permission to use this information, and then Dynatrace calculates the city that is closest to the reported GPS location. If the mobile app doesn't have permissions to access geolocation information on the mobile operating system, it uses the IP address to determine the geolocation in combination again with the MaxMind Geo2 Database.

For custom locations using internal or private IP addresses, like for example your different offices, you can define custom IP mappings or even import a CSV file. You can even overwrite the default IP address mappings with custom IP address mapping rules.

Dynatrace by default also masks the GPS coordinates.

Browsers/Devices/Operating Systems 

For web applications, distinguishing user sessions of real users from synthetic and robots is based on the user agent string sent by the browser. This string is used also for the identification of operating systems and device types like desktop, tablet, or mobile. For browsers classification, Dynatrace uses the www.udger.com user agent database. ISPs are detected based on the IP address. Dynatrace uses information provided by bgp.potaroo.net and www.cidr-report.org to identify the ISP for a given IP address.

Synthetic Monitoring

Just because your web application is accessible from your office and runs great on your laptop doesn't mean that your customers around the world are also having a great experience with it. Therefore, it's imperative to ensure constant availability and performance of your application from your users' point of view.

Dynatrace Synthetic Monitoring makes it easy for you to monitor the availability and performance of your applications as experienced by your customers around the world and around the clock. Availability is the success rate at a given instant or time period that indicates if your application is fully functional and available to users. Performance measures whether your web page or recorded interaction experiences significant slowdowns compared to a threshold.

The availability and performance of your internal resources are equally important. With the ability to execute monitors from private locations, you can bring the testing capabilities available in public locations right to your own infrastructure.

Dynatrace offers the following types of synthetic monitors: single-URL browser monitors, browser clickpaths, and HTTP monitors. 

Types of synthetic monitors

Synthetic monitoring is about proactively simulating user visits, regardless of whether or not real users are currently visiting your site. Dynatrace Synthetic Monitoring provides you with 24x7 global visibility into your applications. 

An HTTP monitor uses simple HTTP requests. 

A browser monitor involves much more—it drives real web browser sessions with full HTML5/AJAX support.

Dynatrace offers these types of synthetic monitors:

single-URL browser monitors

browser clickpaths

HTTP monitors.

Single-URL browser monitors 

A single-URL browser monitor is the equivalent of a simulated user visiting your application using a modern, updated web browser. Browser monitors can be configured to run from any of our public global or private locations at frequencies of up to every five minutes. Browser monitors alert you when your application becomes inaccessible or when baseline performance degrades significantly.

Synthetic monitoring gives you the option of creating two kinds of browser monitors—single-URL and clickpaths—to check the availability and performance of your web application at regular intervals. Single-URL browser monitors conduct availability tests of a single page of your website or web application

Browser clickpaths 

Browser clickpaths are simulated user visits that monitor your application’s business-critical workflows. You can use the Dynatrace recorder to record an exact sequence of clicks and user input that you're interested in monitoring for availability and performance. Once you’ve captured the mouse clicks and additional user actions that you want your browser clickpath to include, you can set the browser clickpath to run automatically at regular intervals to test your site’s availability and performance.

There are different event types to simulate interaction and control the clickpath, for instance, navigating to a URL, a click, selecting an option, entering information, or a JavaScript snippet

Browser clickpath times

5 minutes script timeout, 60 second event timeout

Record a browser clickpath

Your web application provides certain key functionality to your customers that is critical to the success of your business. Monitoring your application via browser clickpaths ensures that this functionality is available to your customers 24/7.

With our easy-to-use Dynatrace Synthetic Recorder (a Google Chrome browser extension), you can gain visibility into the availability and performance of your application's most important functionality involving all the elements of your IT infrastructure with just a few clicks.

Use the Dynatrace Synthetic Recorder to record the exact sequences of interaction that you want your simulated user visits to follow. The recorder captures events (such as button clicks, page scrolls, or user input) and converts them into a script that is played back each time you run the clickpath.

Allow extension in incognito 

After installing the Dynatrace Synthetic Recorder extension, you need to enable the Allow in incognito permission. This is necessary to have a clean browser state for recording and local playback in Chrome incognito mode

Notes

Browser clickpaths are hard-coded to time out after 5 minutes. When recording a clickpath, ensure that the clickpath does not exceed this time limit.

Local playback in Dynatrace is in emulation mode, based on the device profile and user agent you select during monitor configuration. That is, playback emulates your chosen device. If you navigate to the same URL or perform the same transaction outside Dynatrace, your experience might vary

HTTP monitors 

HTTP monitors comprise simple HTTP requests. You can use them to monitor the availability of your API endpoints or perform simple HTTP checks for single-resource availability. You can also set up performance thresholds for HTTP monitors. As with browser monitors, HTTP monitors run automatically at regular intervals from our global public or private locations. HTTP monitors executed by an ActiveGate from a private Synthetic location can be used to check the availability of your internal resources that are inaccessible from outside your network.

You can create synthetic HTTP monitors to check the availability of your resources—websites or API endpoints. Because HTTP monitors can be executed by an Environment ActiveGate, you can use them to check the availability of internal resources that are inaccessible from outside your network.

HTTP monitors can be run from our global public or private Synthetic locations, or from cluster-wide private locations in Dynatrace Managed.

View the analytics of an HTTP monitor 

• Availability
• Performance (response time)
• Response size
• HTTP status codes

HTTP monitor times

        1, 2, 5, 10, 15, 30 or 60 minutes

Private Synthetic location

With Dynatrace Synthetic Monitoring, you can run your monitors from a private Synthetic location, which is a location in your private network infrastructure where you install a Synthetic-enabled ActiveGate.

With monitors executed from a private location, you can bring the testing capabilities available in public locations right into your own environment. With private locations you can:

• Measure internal web page performance and availability.
• Measure complex internal applications with browser clickpath monitors.
• Measure external resources with synthetic monitors run from internal locations.
• Monitor APIs, both internal and external.

• You cannot execute synthetic monitors using an ActiveGate that's configured for multi-environment support.
• You can create a private location using a clean-installed Synthetic-enabled Environment ActiveGate version 1.169+ or Cluster ActiveGate with Dynatrace Managed version 1.176+. 
• The Synthetic-enabled ActiveGate is used exclusively to run synthetic monitors. A clean ActiveGate installation set to Synthetic monitoring disables all other ActiveGate features, including communication with OneAgents.
• You need to make sure the ActiveGate can connect to other Dynatrace components as well as the resource you want to test. See Setting up a proxy for private synthetic monitoring.
• Only IPv4 and DNS UDP are supported for network configuration.
• In Dynatrace Managed offline deployments, you will not be able to save screenshots.

Supported browsers 

The supported browser for the Dynatrace Synthetic Recorder is Google Chrome (latest version, backwards compatible).

The browser used for executing browser monitors from public locations is listed on the frequency and locations page when you create or edit a browser monitor.

MISSION CONTROL:

Dynatrace Managed automatically solves many common maintenance and support challenges for you. With Dynatrace Mission Control, you get fully automated management capabilities in a pro-active way that keep Dynatrace server secure, reliable, and up-to-date—all while saving you from the hassles of administrative tasks like upgrades and troubleshooting. Once you've granted the required permissions, our Dynatrace ONE team can remotely access your Dynatrace server to assist with upgrades and troubleshooting when you run into problems. You are in full control of privacy settings

How Mission Control works 

To facilitate pro-active support, your Dynatrace server transmits status information to Dynatrace Mission Control. The only data that our Dynatrace ONE team can access comes from the Dynatrace Managed components. At no time can our Dynatrace ONE team access your operating system or file system not related to Dynatrace installation.

Given appropriate permission, our Dynatrace ONE team can analyze the hardware utilization of your Dynatrace Managed installation and alert you if more resources are required.

Our goal is to provide the highest possible system uptime for UI and monitored data. 

What Mission Control does

Dynatrace Mission Control is responsible for processing:

Usage and billing information

License consumption data containing detailed information of hourly license utilization. 

Dynatrace cluster health

We gather basic Dynatrace Managed deployment statistics for quick alerting in case of infrastructure issues, and to provide configuration automation. Mission Control gathers such information as number of nodes, status of Dynatrace services, or disk partitions usage.

Dynatrace Cluster events

Events like server starts/shutdowns, added/removed nodes, and ActiveGate registrations are tracked automatically. Our Dynatrace ONE team can remotely analyze and address problems or incompatibilities with your Dynatrace server based on system events. If you should ever need to contact Dynatrace ONE, you won't need to collect the required log files for problem details—Mission Control gathers this data for you automatically. To see the list of Dynatrace server system events that are automatically logged, select Events from the navigation menu in your Cluster Management Console.

Cluster settings

Our Dynatrace ONE team can remotely optimize your Dynatrace Managed settings to ensure optimum performance and stability.

Software updates

Dynatrace Managed software updates are mandatory and are typically published every four weeks. You can customize the timing of Dynatrace Managed updates (daily or weekly). Updates are automatically communicated to your users at least 24 hours in advance. Dynatrace Managed updates are fast and allow monitoring to continue seamlessly.

What happens if your connection to Mission Control Support Services is lost? 

To keep your cluster pro-actively supported, you need a constant connection to Dynatrace Managed Mission Control. To get information about the data that's sent, and how often it's sent, see Dynatrace Managed data exchange. If your cluster is disconnected, the most critical communication requests (for example, billing requests or license verifications) will be automatically retried once the connection is reestablished. For connection outages that last longer than 14 days (7 days for free trial accounts), the cluster will disable allowance for licensing overages. However, the monitoring of your applications within licensed volumes and quotas will not be affected by a lost connection.

ACTIVE GATES:

ActiveGate works as a proxy between Dynatrace OneAgent and Dynatrace Cluster and can be installed on Windows or Linux. 

What is the main functions of the ActiveGate?

• Message routing- routing messages from OneAgents to server endpoints
• Bufffering/Compression - collects messages from OneAgents and bulks and compresses them to reduce network overhead.
• Authentication (SSL Handshake)
• Entrypoint for sealed networks

Dynatrace supports two types of ActiveGate:

Environment ActiveGate and Cluster ActiveGate. 

If you use Dynatrace SaaS, you only need to install an Environment ActiveGate. 

Dynatrace Managed deployments typically require both ActiveGate types, although the most important type for Dynatrace Managed is the Cluster ActiveGate.

Cluster ActiveGate

Shared between tenants or multiple environments within a cluster. Remote agents, JS agents, need to communicate with your cluster though a firewall

Environment ActiveGate

an ActiveGate for one specific environment. If one or more network segments need their own private ActiveGate for whatever reason.

ActiveGate use cases:

• Access sealed networks
• Large memory dump storage
• Collecting large external logs
• AWS load distribution monitoring
• Monitoring using AG
• Virtualized infrastructure
• Monitor cloud foundry, Kubernetes
• Execute private HTTP monitors
• Execute private browsers outside of the network

Environment and Cluster ActiveGates accept incoming connections on this port

    9999

Environment and Cluster ActiveGates make outgoing connections to the Dynatrace Server on this port

    443

Customers must do this to make sure ActiveGates work properly

    configure firewall settings to permit communication through these ports

Dynatrace scores and ratings

Dynatrace uses different ratings and scores to measure the performance of your application as well as the user experience it delivers.

These ratings are especially handy when you have a number of applications and want to get a quick overview of their states or compare their performance. There are a number of metrics, such as visually complete or the number of errors produced, to make such comparisons. However, because applications vary in so many ways, it's sometimes not so helpful to make 1-1 comparisons using specific metrics. For example, a median Visually complete measurement of 5 seconds for an image gallery application might be fine for its end users while a 2-second lag for a plain-text news application would be unacceptable.

In such cases, comparing only the raw metrics isn't optimal. Scores and indices give a better picture because they combine different metrics and rules into a single number that factors in the individual thresholds defined for each of your applications. Scores and indices enable you to look at a single number and see if your applications are healthy and your users are satisfied.

• Apdex ratings are application-level scores used to determine the performance of an application.

• User experience score is session-based and is used to determine the experience delivered across applications within a single session.

APDEX Ratings

Dynatrace calculates Apdex ratings to provide you with a single metric that tells you about the performance of your application and the errors that impact user experience

Apdex is calculated for each discrete user action and each application overall. In this way, it provides quick insight into the user experience provided by your application.

Default Apdex ratings in Dynatrace are based on application-specific thresholds.

• An Apdex measurement rating between 0.94 to 1.0 equates to Excellent performance.
• An Apdex rating above 0.85 equates to Good performance.
• An Apdex rating between 0.7 and 0.85 equates to Fair performance.(razoável)
• An Apdex rating below 0.7 equates to Poor performance.
• An Apdex rating below 0.5 is considered Unacceptable

Dynatrace Apdex ratings can be customized based on the specific requirements of your application. Once configured, they give you a quick and easy way of evaluating the performance of all user actions that you're monitoring: a value of 1.0 is perfect; values below 0.5 are unacceptable. It’s recommended that you define appropriate user-satisfaction timing thresholds and error impact configurations for each monitored user action.

How errors and HTTP status codes affect Apdex 

User actions with JavaScript errors are rated as Frustrated. It can happen that your user actions are in fact fast and below the Apdex threshold, but they are colored red and rated as Frustrated nonetheless because some of the user actions have JavaScript errors.

User experience score

User experience score in Dynatrace is a single metric that categorizes every session recorded with Real User Monitoring.

With User experience score, you can categorize each session that has been recorded by Real User Monitoring into the following:

• Frustrated
• Satisfied
• Tolerating

To determine these categories, Dynatrace applies performance metrics, error metrics, and usability metrics on each recorded session. These metrics, when combined with the information derived about user flow, are used to calculate User experience score.

It also takes into account issues such as slow performance, rage clicks, errors occurring right at the end of a user session, and other usability problems that can cause the user to abandon the session.

Session Replay:

Session Replay is a powerful tool that can modernize your Digital Experience Monitoring (DEM) strategy. You can use it to capture and visually replay the complete digital experience of every user.

You can record all interactions that customers have with your web application and replay each click and action in a movie-like experience. Session Replay also makes it easy for your QA teams to reproduce production issues, which can be used by your developers to bridge the gap between code and user experience.

Session Replay helps identify errors that should be fixed immediately and other problems such as malformed pages and infinite spinners.

Session Replay can also be used to identify and analyze areas of struggle in your application and improve its overall usability.

Uses for Session Replay 

With Session Replay, you can drill down further into the details of detected errors:

• Detect JavaScript errors and other issues.
• Understand the exact user actions that led to an error.
• Understand the severity of the problem and its effect on user experience.
• Observe the customer impact by replaying and viewing a session (in cases where the problem isn't obvious).
• Developers can use Session Replay as a means to view, analyze, reproduce, and fix errors.

For the purpose of error drill-down, you don't need to have all sessions recorded. You could use cost and traffic control to record only a subset of sessions. If the error to be analyzed isn't too sporadic, it can be detected even if only 20% of sessions are recorded.

The default data retention timeframe of 35 days is applied to these sessions.

Important

The ability to play back recorded user sessions, with or without playback masking settings, is permission controlled. Permissions are available at the environment level as well as the management-zone level. 

QUALITY REPORTS:

Service quality reports are generated each week on Sunday at midnight, so they'll be there for you at the start of your workweek.

Each service quality report summarizes the monitoring insights that Dynatrace has compiled over the past week. 

Each service quality report summarizes the monitoring insights that Dynatrace has compiled over the past week

They offer an overview of your:

• applications
• services
• infrastructure utilization
•  performance problems
•  the impact of performance problems on your customers.

Application scores are based on application Apdex ratings. In brief, the Application score is the average of your application Apdex value and the percentage of user actions that are not affected by problems

Scope

Service quality reports address service quality across the entire environment, not per management zone. Analyzing and persisting the required aggregated data per management zone isn't possible. You need to have access to the entire environment to view these reports.

Davis data units (DDUs)

Davis data units (DDU) provide a simple means of licensing certain capabilities (custom metrics, log monitoring, and events) on the Dynatrace platform. Think of DDUs as a kind of Dynatrace currency. 

In the same way that license consumption for Dynatrace RUM and Synthetic Monitoring relies on Digital Experience Monitoring (DEM) units, DDUs provide a seamless, shared consumption model across custom metrics, Log Monitoring, and events.

Because DDUs are consumption-based, you buy a certain volume and your available quota is consumed over time based on the amount of monitoring your environment consumes. This licensing approach makes it much easier for you to control and monitor your metric consumption (for example, in the case of misconfigured metrics) and to identify top consumers in your environment. To learn more about how metrics are licensed with DDUs, see Metric cost calculation.

Davis data unit volumes 

DDUs are purchased in volumes of 1 million units based on 1-3 year contract terms, with the full amount of licensed units renewing at the beginning of each year. For example, if you buy 100 million DDUs for a 3-year term, you can consume 100 million DDUs annually for 3 years.

You can purchase additional DDUs at any time if you run low. Reach out to your Dynatrace sales representative for details. To assist you in adjusting your monitoring consumption and avoiding cost overages, in-product notifications are displayed to alert your Dynatrace environment users when 90% and 100% of your licensed DDUs have been consumed.

Davis data units - Free tier 

Every new Dynatrace SaaS environment and each Dynatrace Managed license receives 200,000 DDUs free of charge. This translates into 381 metrics, captured at a 1-minute frequency. This free tier enables you to test out features and experience Dynatrace monitoring value before you pay. The free tier of 200,000 DDUs automatically renews annually at the beginning of each new license term for each account (not for Offline accounts).

Metric consumption (DDUs)

The Davis data units model counts all incoming data points from your metrics. Each data point deducts 0.001 DDU from your available quota. If you send a metric via the API at 1-minute frequency, this translates into 1 data point x 60 min x 24 hours x 365 days x 0.001 DDU weight = 525.6 DDUs per year, per metric.

All built-in metrics sent via the default OneAgent (for example, host metrics) are provided free of charge.

Conversion goals

Conversion goals are a versatile way of measuring how well your application fulfills your company's business objectives. You can set up separate goals related to key pages (for example, a shopping cart "add item" page or a newsletter signup page), session length, or number of actions per session. You can then compare the conversion rates of various user actions against each of your conversion goals.

   

You can define conversion goals for specific user actions to understand how successfully you're meeting your conversion milestones (for example, successful checkouts, newsletter signups, or demo signups). Goals can be defined for reaching specific user actions or destination URLs and also for session information (for example, session duration longer than 5 minutes or sessions with more than 10 user actions. For this example, a user would need to complete at least 10 user actions in a single session to reach this conversion goal).

You should carefully monitor these user actions, not only from a technical point of view, to ensure that everything is working as expected and that action durations are acceptable, but also to see how many customers are actually using the features. This can be achieved by following the key action and conversion goal approach.

Goals are defined per application. Goals can be based on:

• Destination URL
• Specific user action
• Session duration
• Number of actions per session. 

You can define a maximum of 20 conversion goals per application.

User behavior analysis

The User behavior analysis section displays a number of key performance metrics regarding user behavior, like bounces, top landing and exit pages, conversions and many more. Just expand the User behavior analysis section of the infographic on the application overview page to view the user behavior analysis options.

The infographic 

Each area of the infographic appearing at the top is clickable, offering access to deeper detail regarding each metric. Whenever you click a part of the infographic, the left section right below the infographic shows different data that reflect the selected part. The discrete infographic parts are briefly described below.

• Top users
• Top user types
• Geolocation breakdown
• Sessions
• Entry actions
• Exit actions
• Other actions
• Bounce rate
• Overall conversion

Top conversion goals 

The Top conversion goals section shows the conversion rate of your defined goals. Alternatively, you can access the conversion analysis page, if you click a specific conversion goal.

What is required for a browser clickpath monitor?

1. Chrome

2. The Dynatrace Extension

3. Allowing the Dynatrace extension in incognito mode

Know the six different major types of events within - Event Categories in Descending order

1. Availability
2. Error
3. Slowdown
4. Resource
5. Custom Alerts
6. Information Only Events (no alarms)

• Availability - indicates high-severity within your environment, such as complete outages or unavailability of servers or processes.
• Error - increased error rates or other error-related incidents that interfere with the regular operation of environments.
• Slowdown - decrease of performance in one of your operational services or applications
• Resource - Indicates resource contention, many of which in link of name.
• Custom Alerts - can be defined when a specific threshold notification on a selected metric is required.
• Info - alerts of issues that may not be detrimental, but should have notifications of changes of occurrence. Indicate manually triggered events that don't result in the creation of a new problem.

After how much time are automated baselines available to the end user?

Baseline cube is calculated 2 hours after the app or service is initially detected

What requests are included in Hot Spot Analysis?

• Slow response time, high failure rate, or high CPU.
• Response Time hotspots: indicate which activities are consuming the most time for each service.

Anomaly detection

Is an effective means of identifying unusual or unexpected events and measurements within a web application environment. As the term “unexpected” can also be read as “statistically improbable,” it should be clear why anomaly detection depends heavily on deep knowledge of a system's baseline performance and behavior for its insights and load forecasts. This is why Dynatrace monitors entire technology stacks end-to-end within web-scale environments. Dynatrace monitors the baseline performance and behavior of applications, services, infrastructure components, and more. Dynatrace captures metrics related to availability, error rates, response times, service load, user traffic, and resource dependencies across millions of entities.

Because there are differing assumptions involved in evaluating load anomalies than there are in evaluating performance anomalies, Dynatrace relies on a wide spectrum of measures and methodologies to identify anomalous events that affect customer experience and therefore require your attention. While multidimensional baselining is used to automatically detect anomalies in the response times and error rates of applications and services (response times should never rise to critical levels, even during high-load situations), a prediction-based methodology approach is used to detect abnormalities in application traffic and service load. This is because traffic and load are entirely dependent on daily, seasonal, and business-cycle related patterns that are driven by an application's business model, related marketing efforts, and sociological factors. Examples of such cycles include weekends/workweeks, workday/evening hours, and holiday-driven customer activity. Black Friday is a great example of an extraordinary seasonal event that occurs on an annual cycle

Dynatrace anomaly detection within application traffic is based on the assumption that most businesses follow cyclical patterns that recur with daily and weekly frequency. Dynatrace therefore automatically learns all such application traffic patterns. After a week of learning an application's baseline traffic patterns, Dynatrace sends out alerts when anomalies are detected within these patterns. Following the initial learning phase, Dynatrace can also predict the following week's traffic. Actual application traffic measured the following week is then compared with the predicted traffic levels. If Dynatrace detects a statistically relevant deviation between actual and predicted traffic, it generates either an Unexpected low traffic or an Unexpected high traffic problem for tracking purposes and alerts you.

Davis automatically generates performance baselines for your services based on monitored performance during a recent reference period. The default reference period is the past 7 days.

Automated multi-dimensional baselining

Context-rich data collection and baselining are the two fundamental pillars that anomaly detection is built on. A huge amount of high-quality and accurate data is necessary to determine baselines that can effectively be used to distinguish between normal and anomalous situations. This distinction however is often blurred due to high data fluctuation or simply because the definition of “normal” is very much context-specific and changes as applications, platforms, infrastructure, and algorithms evolve. This makes the generation of accurate alerts a real challenge.

When an alert is created for a situation that is indeed anomalous, it is a true positive, while if the situation is in fact normal, the alert is false positive. It's also possible that an abnormal situation is missed and therefore no alert is generated. This is characterized as a false negative. True negatives are normal cases that were correctly identified as non-anomalous events. To generate accurate alerts an anomaly detection system should aim at maximizing true positives and true negatives while minimizing false positives and false negatives. To achieve this goal, Dynatrace has developed an intelligent baselining approach. 

Traffic 

Dynatrace application traffic anomaly detection is based on the assumption that most business traffic follows predictable daily and weekly traffic patterns. Dynatrace automatically learns each applications’ unique traffic patterns. Alerting on traffic spikes and drops begins after a learning period of one week because baselining requires a full week’s worth of traffic to learn daily and weekly patterns. Following the learning period, Dynatrace forecasts the next week’s traffic and then compares the actual incoming application traffic with the prediction. If Dynatrace detects a deviation from forecasted traffic levels that falls outside of reasonable statistical variation, Dynatrace raises an alert. 

Baselining dimensions 

The identification of reference values is based, as explained above, on a baseline cube calculation. For applications, this cube is generated by the combination of four application dimensions while for services, they are based on two dimensions.

Alerting on error rate increases begins once the baseline cube is ready and the application or service has run for at least 20% of a week (7 days)

Application baselining dimensions

• User action: An application's user action (for example, orange.jsf, login.jsp, logout, or specialOffers.jsp).
• Geolocation: Hierarchically organized list of geolocations where user sessions originate. Geolocations are organized into continents, countries, regions, and cities.
• Browser: Hierarchically organized list of browser families, such as Firefox and Chrome. The topmost categories are the browser families. These are followed by the browser versions within each browser family.
• Operating system: Hierarchically organized list of operating systems, such as Windows and Linux. The topmost categories are the operating systems. These are followed by the individual OS versions.

TAGs and METADATAS

Dynatrace OneAgent automatically discovers components in your environment, such as process groups, services and real user applications. Not only can these entities be auto-discovered, their underlying technologies can also be accurately identified (for example, Apache HTTP server, IBM WebSphere, and much more). As part of this auto-detection, Dynatrace discovers network topology as well. Once traffic is monitored, Dynatrace detects also load balancers and proxies. Moreover, Dynatrace supports 3rd party integrations, thus augmenting this data with topology and monitoring information from AWS, VMWare, Azure, OpenStack, and more.

Managing such a huge amount of information, however, and organizing such large monitoring environments is a real challenge. To effectively cope with this challenge, Dynatrace supports tags and metadata. Tags and metadata enable you to organize your monitored environments in a meaningful way. 

Tags in Dynatrace are basically labels or markers while metadata are key/value pairs that are inherent to any monitored entity. Metadata are mainly used for defining extra information for entities while tags are used for organizing entities. You can also create tags based on metadata. In general, although tags and metadata are closely related, they are different concepts and are created and used in different way.

Dynatrace differentiates between tags and metadata. Metadata properties are key/value pairs that are inherent to any monitored entity. Tags in Dynatrace are labels or markers that do not belong to an entity. Tags however may also have a key/value structure. For example, you can define a tag with key SecurityIsolationLevel that has a different value for different entities. Once a tag and its rules are defined, Dynatrace will apply the tags to new entities automatically.

How are tags and metadata created 

Metadata is detected during startup or discovery of a monitored entity and is immutable from within Dynatrace. 

For processes, all metadata is discovered during startup of each process. Metadata is typically not refreshed until a process is restarted. Metadata is considered part of the deployed application or deployed entity and is discovered and/or configured as part of that deployed application. Metadata can't be changed using the Dynatrace web UI.

Tags, on the other hand, aren't information about an entity and don't belong to one specific entity. Tags are used to find/filter/designate sets of entities. Tags in Dynatrace can be changed without changing the deployment itself. They are configurable from within the Dynatrace web UI.

There are several ways to create tags for monitored entities. The best option for you depends on your environment and your needs. The easiest way is to use the Dynatrace web UI to manually apply tags to your entities. However, the manual approach forces you to manually tag each new entity. This maintenance challenge makes it difficult to enforce a standard and is impractical within larger environments. Therefore, within larger environments, it's recommended that you use a combination of auto-tagging based on metadata and tags that are part of the monitored deployment. Through this approach, tags can be dynamically assigned within Dynatrace, based on immutable metadata that come from the monitored system.

Importing tags/metadata from external sources 

Dynatrace not only discovers all processes running on a host, it also identifies their nature. As part of this, Dynatrace captures the most important domain-specific metadata. If Dynatrace discovers, for example, an Oracle WebLogic entity, the entity will also have metadata about the WebLogic Domain, the WebLogic Server name and the WebLogic Cluster. If Dynatrace identifies a Kubernetes environment, then every process will have metadata concerning its pod name and namespace. The same is true for VMWare and AWS hosts.

Dynatrace only knows about a subset of domain-specific information. This is why we also enable you to enrich this information with your own metadata as well as with additional metadata from other sources. In particular:

• Kubernetes and OpenShift annotations are automatically reflected as metadata on processes and process groups in Dynatrace.
• You can use system environment variables to define your own metadata on any kind of process.
• Dynatrace adds custom metadata for hosts as well.
• Dynatrace adds custom metadata for Cloud Foundry.
• This metadata is shown in the properties of each entity within the Dynatrace UI and it's part of the data when you access these entities via the API.

Tagging is a powerful mechanism. However, to reap its benefits, tagging should be used carefully and in a meaningful way. With auto-tagging based on metadata, tags can be generated automatically and assigned to monitored entities with the specific metadata values that Dynatrace detects automatically.

Within dynamic or large environments, manual host tagging can be impractical. For dynamic deployments that include frequently changing host instances and names (for example, AWS or MS Azure), you should automate adding tags and metadata to your hosts.

It's strongly recommended that you use tags rather than specific entity names when setting up custom charts, filtered service or host lists, and alerting profiles. Basically, anywhere that you might want to refer to a set of entities, you should use a tag instead of defining a direct reference

You can also set up automated tagging of the hosts in your environment using:

• Automated rules,
• Environment variables,
• Smartscape and topology API.

Know the relationship between tags and metadata intimately.

• Tags are labels or markers.Used to filter/find/designate sets of entities.
• Metadata are key/value pairs. Used for defining extra information.
• Detected during startup or discovery of a monitored entity.

Where to use tags and metadata 

Tags involve a wide spectrum of usages, but in principle they are used to find certain types of entities or to filter views and actions for certain entities. As tags have predominantly an organizational and management purpose within Dynatrace, they are useful for:

• Filtering lists
• Defining which entities you want to chart in a custom chart or dashboard.
• Specifying where to send problem notification based on problem context in alerting profiles.
• Defining custom alerts.
• Accessing metric data via the REST API.
• Finding and inspecting monitoring results via Dynatrace search.
• Defining a maintenance window.

Management zones 

Management zones are an important concept in Dynatrace and of high importance in large environments, as they can make large organizations work. Management zones are based on the same idea as automated tags, but designed for the explicit purpose of defining groups of entities that either belong together or have common security levels.

It's recommended that you define zones for all teams that specify what they are supposed to view and the different lines of business. It also makes sense to add different zones for different support teams, so that the large amount of data is consumable and so that security layers are introduced. Every user can have access to multiple zones. Zones can overlap, so you don't need to worry about assigning one entity to a specific zone. Shared entities can therefore be in many or all zones.

The best way to create management zones is to define rules based on your entities metadata (including custom metadata). However, if you want to maintain your management zones outside of Dynatrace, you can also base them on tags

What are the different types of thresholds that can be set for Processes?

• Actions duration degradation
• Traffic drops
• Traffic spikes
• Increases in failure

What is the difference between a process and a process group?

Process group is the processes that perform the same functions across multiple hosts

Processes are the instances of computer programs and be containers that host service

What is a bounce?

When a user only does one action then leaves the page

Cookies

Other than HTTP requests and headers, Dynatrace Real User Monitoring (RUM) also relies on browser cookies to correlate user interactions in the browser, such as user actions, with general page and backend performance metrics.

Cookies are used to:

• Monitor site performance.

• Analyze website usage.

• Track user behavior.

The data stored in cookies is made up of random values, time stamps, and data that are required to correctly identify the applications in your monitored environment. The Real User Monitoring JavaScript library must be able to set and modify these cookies. This means that Dynatrace cookies don't support the HTTPOnly flag. Cookies must be included with each request so that user actions can be correlated with backend performance. You can use the Secure cookie flag; however, this leads to loss of visibility into any unencrypted HTTP communication.

Dynatrace cookies are essential for providing you with all the benefits of Real User Monitoring. If you provide your users with the option to decline the use of these cookies, Real User Monitoring won't work to its full potential.

Global privacy settings

Dynatrace offers environment-wide settings that serve to ensure your compliance with the data-privacy regulations of your region.

Mask end users' IP addresses and GPS coordinates

With this setting enabled, end user IP addresses & GPS coordinates are masked during Real User Monitoring and server-side monitoring. User IP addresses for web, mobile, custom applications, and services are masked when this feature is enabled. IP addresses are immediately masked as they are received by Dynatrace. They are masked before storage, never in their original form.

Mask personal data in URIs 

URIs contain personal data, such as a user names. When this setting is enabled, Dynatrace automatically detects UUIDs, credit card numbers, email addresses, IP addresses, and other IDs and replaces these values with a placeholder.

Mask user actions 

This setting only affects Real User Monitoring for web applications. With this setting enabled, no input data is captured. Instead, generic values are used as the basis for user action names.

What data is displayed in the Waterfall analysis view?

Primarily built around W3C timings. The view organizes the waterfall entries into three sections:

Document requests

Displays all content that is identified as the page load of the user action. This includes the initial HTML, as well as any other content that's displayed in frames.

Each entry contains the details that are captured by W3C navigation timings.

XHR requests

These entries contain all the details that are accessible through the W3C resource timings, in addition to the JavaScript callback execution time.

Resources

Displays all W3C timing details

Monitor key requests

For how long are key requests stored?

By default, 10 days.

Key requests are requests that need special attention, either because they're a critical measure of the success of your business (for example, a login request or a shopping-cart checkout request) or because they provide vital technical functionality that your application relies on.

Key requests feature long-term metric history and dedicated dashboard tiles for charting and direct access from your dashboard. Key requests are always alerted on, even when they contribute less than 1% of throughput. They also provide custom thresholds.

Key requests are highlighted in the Key requests section of each service overview page. This visibility is particularly valuable for low-volume, high-importance requests that would otherwise appear at the bottom of the Top requests section of a service overview page.

Long-term trend data for key requests 

Dynatrace enables you to chart any request that it detects during monitoring. By default, detailed history of all requests is retained for 10 days. Longer-term historical data is maintained for requests that you manually identify as key requests. Trend lines for key requests are retained perpetually, but the granularity of long-term history is gradually reduced over time:

• 0-14 days: 1-minute interval granularity available for dashboarding and API access.
• 14-28 Days: 5-minute interval granularity available for dashboarding and API access.
• 28-400 days: 1-hour interval granularity available for dashboarding and API access.
• 400 days-5 years: 1-day interval granularity available for dashboarding and API access.

Static thresholds

Dynatrace infrastructure monitoring is based on numerous built-in, predefined static thresholds. These thresholds relate to resource contentions like CPU spikes, memory, and disk usage. You can change these default thresholds by navigating to Settings > Anomaly Detection > Infrastructure.

For applications and services, you can disable automated baselining-based reference-value detection anytime and switch to user-defined static thresholds. If you set a static threshold for response time and error rate on an application or service level, events will be raised if the static threshold is breached. A slowdown event is raised if the static thresholds for either the median or the 90th percentile response times are breached

Predefined static thresholds for hosts 

CPU saturation:

• Alert if CPU usage is higher than 95% in 3 of 5 one-minute intervals.

Memory event usage:

• Alert if memory usage is higher than 90% on Windows or 80% on Linux
• AND memory page fault rate is higher than 100 faults/s on Windows or 20 faults/s on Linux in 3 of 5 one-minute intervals.

GC activity:

• Alert if GC time is higher than 40%
• OR GC suspension is higher than 25% in 3 of 5 one-minute intervals.

Java out of memory:

• Alert if the number of Java out-of-memory exceptions is 1 per minute or highe

Predefined static thresholds for networks

Number of dropped packets:

• Alert if receive/transmit dropped packet percentage is higher than 10%
• AND total packets rate is higher than 10 packets/s in 3 of 5 one-minute intervals.

Network utilization

• Alert if sent/received traffic utilization is higher than 90% in 3 of 5 one-minute intervals.

TCP connectivity for process

• Alert if percentage of new connection failures is higher than 3%
• AND number of failed connections is higher than 10 connections/min in 3 of 5 one-minute intervals.

Retransmission rate

• Alert if retransmission rate is higher than 10%
• AND number of retransmitted packets is higher than 10 packets/min in 3 of 5 one-minute intervals. 

Predefined static thresholds for disks 

Low disk space:

• Alert if free disk space is lower than 3% in 3 of 5 one-minute intervals.

Slow running disks

• Alert if disk read time and write time is higher than 200 ms in 3 of 5 one-minute intervals.

Inodes number available

• Alert if percent of available inodes is lower than 5% in 3 of 5 one-minute intervals

Monitor third-party services

Dynatrace captures and monitors all outgoing requests from your monitored server-side services. This includes web requests that your server-side components send out across the internet. There can be many such requests.

Most of them probably are not important to you, so Dynatrace collects them into a special service called Requests to public networks.

Some of them, however, probably are important to you. For example, your application may rely on the performance and availability of third-party service providers that you want to monitor as regular "first class" services.

For this reason, Dynatrace provides a way to monitor these requests as standalone services.

The requests to that domain are monitored as a standalone service. This service:

• Appears on the Services page as a standalone service.
• Appears in Smartscape, Service flow, and elsewhere as a standalone service. This enables you to track the response time better.
• Can be pinned to your dashboards as a dedicated tile.
• Generates alerts when the services experiences performance problems.

Memory health 

Host pages include two memory-related metrics for your hosts, Memory used and Page faults. Both measurements and other factors, are used to correlate and calculate host high memory incidents.

·         Memory used
Percentage of total RAM used by processes. RAM used by system caches and buffers isn't included in this metric. Dynatrace calculates memory usage as:

·         Page faults
Number of major page faults per second. Major page faults involve loading a page from disk, thereby adding disk latency to the interrupted program’s execution.

Measures for host health

Individual Host pages show problem history, event history, and related processes for each host. To assess health, the following performance metrics are captured for each host and presented on each Host overview page:

• CPU
• Memory
• Disk (storage health)
• NIC (network health)
• Network services (currently, DNS performance)

USQL:

Dynatrace User Sessions Query Language (USQL), you can easily run powerful queries, segmentations, and aggregations on this captured data.

User Sessions Query Language isn't SQL and Dynatrace doesn't store user session data in a relational database. User Sessions Query Language is a Dynatrace-specific query language, though it does rely on some SQL concepts and the syntax is similar, which makes it easy to get started

Why is transfer size an important Digital Experience Management (DEM) metric?

A large transfer size might not lead to poor performance, but it does use up data from a user's data plan when accessed on a mobile device.
How often does the SaaS cluster update?

• Automatically every 2 weeks

How often does a Managed Cluster update?

• Every 4 weeks

How often does the OneAgent update?

• Every 4 weeks but optional

How often is the OneAgent updated for managed customers?

• Every 4 weeks

How long is Code Level and Performance Data stored for Service Requests in a Managed environment?

• 35 days but can be configured

How long is Code Level and Performance Data stored for Services at the Code Level in a Managed environment?

• 10 days but can be configured

How long is RUM Waterfall analysis data stored and retained for Managed customers?

• 10 days but can be configure

"My Web application"

• The default application used as a "catch all" for all user sessions and user actions that do not match an existing application rule.

What are the different types of services?

• Web request services
• Web service
• Database service

What are the problem TYPES?

• Applications
• Services
• Infrastructure
• Synthetic

Process groups

Dynatrace automatically merges related processes into process groups. A “process group” is a logical cluster of processes that belong to the same application or deployment unit and perform the same function across multiple hosts. Process groups are key building blocks of most modern web-based applications.

Dynatrace automatically detects application types such as Tomcat, JBoss, Apache HTTP Server, MongoDB, and many others technologies.

Request attributes

Dynatrace tracks all requests, from end to end, and automatically monitors the services that underlie each transaction. The performance and attributes of each request can be analyzed in detail. You're not limited to just certain predefined attributes. You can also configure custom request attributes that you can use to improve filtering and analysis of web requests.

Request attributes are essentially key/value pairs that are associated with a particular service request. For example, if you have a travel website that tracks the destinations of each of your customers’ bookings, you can set up a destination attribute for each service request. The specific value of the destination attribute of each request is populated for you automatically on all calls that include a destination attribute (see the destination attribute example below). A single request might have multiple request attributes.