Anomalies are clues that something in your system isn’t behaving as expected. Detecting these early warnings gives SREs and developers a critical window to investigate and resolve the issue before they impact customer experience. But detection alone isn’t enough. You need to identify the root cause so teams can take action before a minor glitch cascades into something more serious that impacts revenue and customer experience.

Dynatrace automatically connects synthetic monitoring, traces, and logs, so you can go from spotting an anomaly to uncovering the exact root cause in under a minute. Without a unified solution, you’d have to sift through logs spread across different systems, which is not only time consuming but can also result in human error. With Dynatrace, you can drill down to the failed test execution and then jump directly into distributed trace and related logs to expose the precise error in code. Instead of just showing data, Dynatrace delivers answers fast.

Let’s take a look at how this works in practice by walking through an example.

From error to answer in a few steps

The Dynatrace platform was built to solve complex challenges, whether they originate in the frontend, backend, or database. Modern applications are distributed systems, where a single user action can trigger a chain of events across dozens of services. To understand this chain, you need to link the beginning (the user’s action) to every subsequent step. Synthetic monitoring and distributed traces are powerful capabilities that provide visibility into this complex chain, but only when automatically connected do they deliver easy insight into end-to-end performance and user experience.

Now, let’s walk through this process step-by-step.

1. Spot the anomaly on the dashboard

Our journey begins on the ready-made synthetic monitoring dashboard. This high-level overview aggregates results from all monitors and locations, making it easy to spot issues—like a sudden spike in HTTP 500 errors in our travel booking system. Each of these errors could negatively impact user experience, so we want to get to the bottom of this quickly before we see a major degradation of service that could lead to lost revenue or brand reputation damage.

A single click on the problematic metric begins the investigation.

2. Isolate the failing monitor

With the context of time and error type carried over, you’re directed to a filtered list of all synthetic monitors that experienced a 500 error in that timeframe. Here, we can instantly see that the Easytravel storeBooking monitor has a low availability of 77.78% and has registered five failed requests.

Clicking “Analyze errors” allows us to drill down further.

3. Analyze the failed execution

This page presents a list of individual test executions over time. On this timeline, you can instantly identify the specific failed run (marked in red) and move from a general problem to a concrete instance of failure. Selecting the failed execution and clicking “View traces” is the final step in our investigation.

4. Uncover the root cause with distributed tracing

With one more click, you’re taken across the automated bridge to the Distributed Tracing Explorer. Dynatrace automatically carries over all the context, showing you the exact end-to-end trace for that specific failure.

Here, the root cause is exposed. The trace shows that Exceptions are captured, also linking directly to the related logs. There, the technical reason and the detailed error message is waiting: an ArrayIndexOutOfBoundsException occurred within the storeBooking service. This tells you precisely what broke in the code and where to look to solve the 500 error spike. Dynatrace consolidates this experience onto a single platform, saving you the time and effort that would have been required to sift through disjointed pieces of data scattered across multiple tools and enabling you to solve the problem before it escalates.

The advantage: actionable answers, not disjointed data

This entire workflow, from a high-level dashboard to a code-level root cause, takes less than a minute! Whether you start from a dashboard or the Problem app, the result is the same: you get a definitive, actionable answer in moments.

The post From anomaly to root cause in under a minute appeared first on Dynatrace news.

Business Insights is a unique team within Dynatrace that partners with organizations to maximize their value from Digital Experience Monitoring (DEM) and Business Analytics, through our deep product expertise and exclusive technology capabilities. The Business Insights team provides product configuration and best practices, exclusive analytics and analysis to drive improved customer experience, and expertise on demand. Dedicating the necessary time, resources, and focus to deliver excellent end-user experiences can be a challenge. This is why Dynatrace’s largest and most sophisticated customers rely on Business Insights to deliver the strategic value that helps drive improved customer experience and business outcomes, whether that’s:

• Deploying a synthetic monitoring strategy to help a large beverage company achieve 100% age-verification compliance for the first time across 3,000+ properties
• Using our deep expertise in real user analysis to help a global automaker drive a 90% reduction in frontend errors, a 50% reduction in search results load time, and a 58% year-over-year reduction in outages
• Identifying the root cause of a performance issue impacting customers on one of the UK’s largest retail sites, which, when fixed, reduced exit rate by 2%, driving $500k+ of additional monthly revenue
• Working with senior executives and cross-functional teams at one of the world’s largest airlines to implement a holistic Business Observability strategy combining DEM, Business Analytics, and the broader Dynatrace platform to provide an end-to-end view of how infrastructure, services, and front-end applications impact critical business flows and KPIs in real time

Business Insights has long worked closely with Dynatrace customers to help accelerate adoption and value from the Dynatrace Digital Experience Monitoring (DEM) and Business Analytics capabilities; however, customer collaboration could be challenging at times with information scattered across emails and PowerPoint slides, multiple channels of engagement, and analysis disconnected from the Dynatrace platform. The Business Insights app simplifies and enhances the experience and engagement of Business Insights services, making it more seamless and accessible. It’s also the starting point for delivering more advanced AI-driven analysis, like those pioneered in the Opportunity Insights app.

Dynatrace delivers more value than its competitors

The Business Insights app directly addresses these pain points through unified, contextual delivery on the Dynatrace platform that transforms how insights are received, consumed, engaged with, and acted upon.​​​​​​​​​​​​​​​​

Bringing Business Insights into an app on the Dynatrace platform creates an enhanced experience of both the service and the platform through targeted, actionable analysis and recommendations directly in Dynatrace, in the context of the rest of the product, and with the ability to move seamlessly between them.

Timeline view: Your complete analysis history

As a Business Insights customer, keeping track of communications (enablement content, historical analysis, value over time, etc.), bringing new team members up to speed on the service, and summarizing value received over time for key stakeholders could be a challenge, with everything buried in emails. The Business Insights app centralizes all engagement and analysis in a single timeline view, making it easy to review everything the Business Insights team has provided for your organization, including:

• Analysis value moments
• Announcements
• Enablement material

Invites to live sessions such as Tech Talks and Customer Connects.

Each analysis value moment is tagged with helpful metadata, including type (performance, operational, business), product component (web, mobile, synthetic), application/synthetic monitor name, and specific page or event details. Enablement moments help you ramp up on the product more quickly, while announcements make sure you’re always up to date with what’s happening with the DEM and Business Analytics capabilities in the context of what matters to you. This comprehensive view helps new team members quickly understand your digital experience landscape and previous insights, accelerating onboarding for the service and Dynatrace DEM.

Value moment detail: Rich interactive content

Value moments are small and consumable DEM insights and analysis deliverables put together by our analysts for operational, performance, and business use cases to help you understand where to focus. Selecting a value moment from the timeline opens the main view with structured, easy-to-navigate content. Each value moment includes an optional video summary at the top for a quick overview, followed by indexed sections that allow you to jump directly to relevant information. Content links seamlessly to other Dynatrace Apps, Notebooks, and Dashboards for deeper context, eliminating the need to switch between tools. Each value moment also includes a shareable deep link, making bringing additional team members into the conversation simple. The structured, consumable content of value moments and easily navigable content help teams quickly identify focus areas and collaborate on operational decisions and actions.

Collaborative engagement and real-time feedback

The Business Insights app transforms analysis from a one-way delivery into a collaborative experience. Simply select any content within a value moment to leave comments or questions directed to the Business Insights team or your team members. Our team receives immediate notification and responds directly in the comment thread, keeping everyone aligned and in context. You’ll also receive email notifications with direct links when we reply. Threaded discussions and immediate notifications keep teams aligned and engaged with the Business Insights team.

Each value moment also includes a dedicated feedback section, allowing you to quickly indicate value and direct our future analysis and priorities.

Early feedback

The ability to easily provide feedback has been pivotal in quickly refining our interactions with the Insights team and the value we get from the service
– North American gaming company

By centralizing everything in one place, we’re inspiring people to use RUM and freeing them from digging through multiple tools and endless emails to find the context they need.
– UK insurance company

What’s next

The Dynatrace Business Insights app has been built to transform the way you engage with Business Insights and increase the value you receive from the Dynatrace platform, giving you:

• Centralized communication – All analysis, discussions, reports, and material in one searchable location
• Contextual engagement – See analysis in context of your real-time data within the product, with direct links to other apps/notebooks/dashboards
• Increased adoption and team exposure – Easy sharing of value moments with deep links, making insights more accessible across your organization
• Simplified collaboration – Comment directly on specific content to seamless interaction with Business Insights and your internal teams
• Historical access – Timeline view for easy tracking of past interactions, discussions, and analysis
• Self-service access – Anytime access to reports and insights without waiting for emails and calls
• Enhanced service through direct feedback – Simple, built-in mechanisms indicate value and guide future analysis

This first release is just the beginning, not merely a new interface but the foundation for next-generation Business Insights that will allow advanced machine learning and AI capabilities for enhanced analysis.

Get started

The new app is now generally available for Dynatrace Business Insights customers running a Dynatrace SaaS deployment. We’ll progressively roll the app out to existing customers over the coming weeks:

• If you’re interested in being part of the initial wave of adopters, please talk with your Dynatrace analyst or submit this form.
• If you’re not a Business Insights customer and are interested in learning more, please reach out to the Dynatrace Sales team.

___

© 2025 Dynatrace LLC

Dynatrace and the Dynatrace logo, are trademarks of the Dynatrace, Inc. group of companies. All other trademarks are the property of their respective owners.

The post The Power of Business Insights expertise now directly on the Dynatrace platform appeared first on Dynatrace news.

The improved UI of the new Synthetic app makes managing your synthetic tests and analyzing their results easier and more effective. Exploratory analytics now cover more bespoke scenarios, allowing you to access any element of test results stored in the Dynatrace Grail™ data lakehouse. This allows you to build customized visualizations with Dashboards or perform in-depth analysis with Notebooks.

Traditional insight into HTTP monitor execution details

For nearly two thousand Dynatrace customers, Dynatrace Synthetic HTTP monitors provide insights into the health of monitored endpoints worldwide and around the clock. Customizable notifications about particular problems causing test failures are delivered as soon as the problems are discovered. This allows you to analyze issues and react immediately, ideally before your users are affected.

For more complex cases, where the basic information about an HTTP monitor’s execution failure delivered with a notification is insufficient, Dynatrace provides complete details of the last failed execution of said HTTP monitor. Analyzing the delivered payload (response body), response headers, or even details of requests sent during the monitor’s execution is invaluable when analyzing the failure’s root cause.

But nowadays, with complex and dynamically changing modern IT systems, the last result details might not be enough in some cases. And it was spotted and delivered to us as feedback from our customers within the Product Idea community:

“Currently, for HTTP monitors, only details for the last failed execution per location are shown. Sometimes, when there are several failures before that you weren’t able to track (like during the weekend or night), you have very few details of what failed.”

— DT community user

How the new Synthetic app better supports root cause analysis (RCA)

As always, Dynatrace listens to your feedback! Therefore, with the release of a new version of the Synthetic app supporting HTTP monitors, we’re happy to announce that HTTP monitors’ result details are no longer limited to the last successful and failed executions. Thanks to the power of Grail, those details are available for all executions stored for the entire retention period during which synthetic results are kept.

The new Dynatrace Synthetic app allows you to analyze these results. It now fully supports not only Network Availability Monitors but also HTTP synthetic monitors. The Refreshed Analyze Executions page has been enhanced with a scatter plot chart showing all executions of configured HTTP monitors.

Each dot represents an HTTP monitor execution. Select any execution you’re interested in to display its details, for example, the content response body, its headers, and related metrics. Details of requests sent during each monitor execution are also available. The filtering panel on the left-hand side of the page allows you to focus only on those elements that are critical for your analysis.

Your analysis might require comparing the details of two executions, for example, a current failing execution and a historical one when the test passed. Or perhaps you need to compare two failing executions, as the details of the first failure (for example, what happened overnight) might provide additional input for your analysis. With the new Dynatrace Synthetic application, you can select any two executions for comparison.

The Dynatrace platform supports your analysis

The benefits of HTTP monitors on the latest Dynatrace platform are visible not only within the new Synthetic app. All metrics and events storing information about execution details are available for further exploratory analytics utilizing Dashboards, Notebooks, or Davis^® CoPilot. This provides nearly endless possibilities for building customized reporting tailored exactly to your needs.

“Data in Grail available with DQL look very powerful; the possibility of combining response payload with info on how much time it (monitor’s execution) took looks very useful“

– Tim Buedts, IT Reliability Engineer at Telenet group

Within the new Synthetic app, we provide you with a link to a Notebook you can use for further analysis. The Notebook contains three predefined queries, which you can use to query events stored in HTTP monitor results.

Let’s take a look at the three included queries:

Query 1: Get events with information about all executions of a selected monitor within a given time range

This query, the most basic of the three DQL queries, returns the list of all executions of a given monitor, which is identified by its unique ID (dt.synthetic.monitor.id). The fields clause identifies which fields should be shown as a query result. A filter for the location ID (filter dt.entity.synthetic_location), commented out by default, can be used to narrow down the results to only the executions from the selected location.

fetch dt.synthetic.events
| filter dt.synthetic.monitor.id  == "HTTP_CHECK-75952DA89EB1DB45"
| filter event.type == "http_monitor_execution"
| fields timestamp, result.status.message, result.statistics.duration, result.status.code, dt.entity.synthetic_location, execution.type, event.id 
| sort timestamp desc 
// | filter dt.entity.synthetic_location == "SYNTHETIC_LOCATION-0000000000000001" 

Query 2: Get events with basic information about the results of each step within a selected monitor execution

The main difference with this query is the filter event.type == "http_step_execution" clause. This query returns basic information about all the steps of a single selected execution of the selected HTTP monitor. The execution is selected with the filter filter event.id == 100925201952 //event.id == execution id (Note that we’re using the ID from the latest execution as a default filter.)

fetch dt.synthetic.events
| filter dt.synthetic.monitor.id  == "HTTP_CHECK-75952DA89EB1DB45"
| filter event.type == "http_step_execution"
// | filter dt.entity.synthetic_location == "SYNTHETIC_LOCATION-0000000000000001"
| filter event.id == 100925201952 //event.id == execution id
| sort dt.synthetic.execution.end_timestamp desc
| fields timestamp, result.status.message, result.statistics.duration, result.statistics.connection_time, result.statistics.tls_handshake_time, result.status.code, result.statistics.time_to_first_byte, dt.entity.http_check_step

Query 3: Get events with full details describing a selected HTTP monitor execution

This query fetches data from different event type from dt.synthetic.detailed_events. It can be used to find detailed information about a selected monitor execution, which can be helpful during troubleshooting.

Commented-out clauses can be used to narrow the scope to a particular step of the executed monitor, and the step ID value (dt.synthetic.step.id) can be retrieved, for example, from the results of Query 2.

fetch dt.synthetic.detailed_events
| filter dt.synthetic.monitor.id  == "HTTP_CHECK-DD85DA9C14659614"
| filter event.id == 4184255792508795805 //event.id == execution id
// | filter dt.synthetic.step.id == "HTTP_CHECK_STEP-0000000000000000"

Synthetic results available in Grail also offer additional possibilities from a reporting and visualization perspective, combining various metrics and events on a single dashboard

Look at the example dashboard in Figure 5, built on the results of a synthetic monitor that checks the health of a popular weather service. Apart from metrics indicating availability and service performance, we created a pie chart showing the forecast weather for Gdańsk, Poland. Input data for the chart was extracted from the payload of responses provided by the weather service.

“It is great to see those events also for historical executions. We’d like to use it for our dashboards.”
— Engineer from a leading workforce solutions organization

The Dashboard presented above is an example of combining data retrieved with HTTP monitors execution within the response body (here, the information about the weather) with metrics describing the health of the service used for retrieving that data (in this case, availability and duration reported by HTTP monitor)

Here’s an example DQL query illustrating how to use DQL language to retrieve data from events (containing, among other values, the response body)

fetch dt.synthetic.detailed_events | filter dt.synthetic.monitor.id == "HTTP_CHECK-75952DA89EB1DB45"
| fieldsAdd content = result.statistics.response_body
| parse content, "JSON:query"
| fields timestamp, dt.tenant.uuid, query
| fieldsFlatten query
| fieldsAdd days = query.days[0]
| fieldsFlatten days
| summarize count(), by:{days.conditions}

Content of the response body collected from all executions of the HTTP monitor is collected and parsed as JSON. Then, the number of executions that returned a forecast of a particular weather type (returned in days.condition field) is counted.

Discover what you can do with HTTP monitors on the latest Dynatrace platform

• Create your HTTP monitors with the new Synthetic application.
• Check the results of your new (and existing) HTTP monitors.
• Get familiar with the out-of-the-box synthetic dashboard delivered with the new Synthetic. app! Check out the new dashboard within the Dynatrace Playground environment.
• Use the power of DQL to query synthetic data and report it with Notebooks and Dashboards.
• Share your feedback with us using our Feedback channel in the Dynatrace Community.

The post HTTP monitors on the latest Dynatrace platform extend insights into the health of your API endpoints and simplify test management appeared first on Dynatrace news.

Customer and employee expectations for seamless, high-quality digital experiences are continually rising. Digital experience monitoring (DEM) is crucial for organizations to meet this demand and succeed in today’s competitive digital economy. By proactively implementing digital experience monitoring best practices and optimizing user experiences, organizations can increase long-term customer satisfaction and loyalty, drive business value, and accelerate innovation.

DEM solutions monitor and analyze the quality of digital experiences for users across digital channels. They collect data from multiple sources through real user monitoring, synthetic monitoring, network monitoring, and application performance monitoring systems. This data provides organizations with end-to-end visibility of the entire user journey across the tech stack. It also enables ITOps to identify performance issues in real time for fast mean time to detect/repair and to continuously optimize performance to improve the overall user experience.

How to improve digital experience monitoring

Implementing a successful DEM strategy can come with challenges. Depending on where an organization is on its journey, these challenges may include the following:

• Digital ecosystems complexity
• Data overload
• Existing IT systems and cloud frameworks integration
• User experience variability
• Business objectives alignment
• Data privacy and security
• Scalability

Addressing these challenges requires a combination of IT process improvements, clearly defined objectives, and organizational alignment.

Here are 10 digital experience monitoring best practices that can improve a DEM solution’s effectiveness and enhance the quality of your organization’s digital offerings.

1. Identify and review key user journeys

Understanding users’ paths when interacting with your applications provides a roadmap of how a customer or employee interacts with your services. To start, define different user journeys within your digital application and create a visual map from start to finish. Was the user able to accomplish their goal?

The map should illustrate every step a user takes as they interact with different pages, forms, and features. It can help understand the flow of user interactions, identify areas for improvement, and drive a user experience strategy that better engages customers to meet their needs. Review and refine key user journeys at set intervals to ensure maps are up to date and relate to clear business goals.

2. Define monitoring goals and user experience metrics

Next, define what aspects of a digital experience you want to monitor and improve — such as website performance, application responsiveness, or user engagement — and prioritize what to measure for each application. This allows ITOps to measure each user journey’s effectiveness and efficiency.

Align business and development teams’ input on what user experience metrics to measure to understand users’ most critical digital experience aspects. Prioritize monitoring efforts to ensure the performance metrics align with your organization’s goals and user expectations.

Common user action metrics (or performance testing metrics) measured and monitored in DEM include the following:

• User action duration. The time taken to complete the page load.
• Time to first byte. The time from browser request to the first byte of information from the server.
• Time to render. The time it takes for a page to load enough that a user can interact.
• Visually complete. The time to fully render content in viewpoint.
• HTML downloaded. The time it takes the user to receive the last byte or transport connection closes, whichever comes first.
• Speed index. How quickly visible parts of the page are rendered.
• Load event start. The time it takes to begin the page’s load event.
• Load event end. The time it takes to complete the page’s load event.

3. Establish baseline performance metrics

Establishing a baseline for key performance indicators (for the metrics listed above and others) enables ITOps to continuously monitor and compare application performance to identify deviations, anomalies, and recurring issues that may impact customer experience (CX). When analyzing the data, consider factors such as time of day, device types, geographic locations, and user demographics.

Document these metrics, including the benchmark values and any insights gained from analysis, to use as a reference for tracking progress and evaluating the effectiveness of optimization efforts over time.

4. Monitor end-to-end transaction paths

Monitor end-to-end transaction paths leveraging distributed tracing to gain visibility into the entire user journey. This includes monitoring components such as web servers, databases, application performance interfaces (APIs), content delivery networks, and third-party integrations. It should also extend from the user experience to the backend for AI-driven root cause analysis with real-time alerts that pinpoint where an issue is occurring and why.

A unified DEM platform with advanced AIOps observability can provide precise, automated insights and the context of each user’s digital journey in real time.

5. Leverage synthetic monitoring

Synthetic monitoring involves simulating user interactions and transactions to proactively monitor your digital services’ performance and availability. Use synthetic monitoring to conduct regular tests and identify potential issues before they impact real users. Synthetic tests and monitoring can be used across development and production environments, as well as for public and private locations, to provide a comprehensive view into performance and availability.

6. Implement real-time monitoring

Implementing real-time monitoring of all transactions out to the end user allows ITOps to detect and respond to performance issues in real time and near real time before they impact the user experience or affect service-level agreements (SLAs). It also tracks performance metrics in real time so ITOps can take corrective and proactive measures to comply with SLAs.

7. Enhance visibility with video-like recordings

Session replays (also called session recordings) show you exactly what the user saw when interacting with your application. Use these recordings to get a more qualitative view of the user experience and better understand negative and positive interactions. Session replays can also help align teams by simplifying communication and increasing collaboration with clear-cut video evidence that both technical and non-technical stakeholders can understand.

8. Extend your team with dedicated expertise

Digital experience monitoring requires specific skills that some organizations may not have in-house. Depending on the resources you have, you can enhance your team with experts who work full time across different businesses. This will ensure you have the right skills, experience, and analytic power to implement the best digital experience monitoring strategy for your organization and goals.

9. Adopt proactive performance optimization

Fostering collaboration between different teams involved in digital experience monitoring requires a product mindset approach that encourages knowledge sharing. Hold regular meetings and troubleshooting sessions to ensure a holistic approach to DEM that considers all aspects of your infrastructure and CX.

10. Establish cross-functional collaboration

Continuously optimizing your digital services’ performance with cross-functional collaboration of all company stakeholders, not just IT, will boost the end user’s experience. Regularly analyze monitoring data, identify performance bottlenecks, and take necessary actions to improve the speed, responsiveness, and overall performance of your applications and services.

Digital experience monitoring with Dynatrace

DEM encompasses various practices to optimize the performance, usability, and reliability of digital services and applications from the end user’s perspective. By following best practices with advanced AIOps and observability, organizations can effectively monitor and optimize digital experiences to meet users’ expectations and drive business success.

DEM is a core solution within the Dynatrace unified observability and security platform, providing AI-driven, automated, frontend-to-backend context into end-user experience. With real user monitoring, synthetic monitoring, and Session Replay natively built within Dynatrace, it empowers development, operations, and business teams with a single source of truth to deliver flawless user experiences and drive business results.

The post 10 digital experience monitoring best practices appeared first on Dynatrace news.

To give your customers a top-quality digital experience, it’s important to make sure your applications are always working properly. Synthetic monitoring, also known as synthetic testing, can help to confirm your applications are performing as intended, and if they’re not, help you quickly figure out what’s going on. Although synthetic monitoring tools have become a crucial part of application performance monitoring, not all solutions cover all types or yield the best results.

As modern cloud architectures are evolving, so too are the ways users can interact with your applications. We’ll get into how the different types of monitoring work, but first, some background.

What is synthetic monitoring?

Synthetic monitoring is an application performance monitoring practice that emulates the paths users might take when engaging with an application. It uses scripts to generate simulated user behavior for different scenarios, geographic locations, device types, and other variables.

After collecting and analyzing this valuable performance data, a synthetic monitoring solution can:

• Give you crucial insight into how well your application is performing
• Automatically keep tabs on application uptime and tell you how your application responds to typical user behavior
• Zero in on specific business transactions — for example, by alerting you to issues users might experience while attempting to complete a purchase or fill out a web form

How does synthetic monitoring work?

In synthetic monitoring, a robot client application that has been installed on a browser, device, or computer transmits a series of automated transactions to your application. These server calls and testing scripts simulate an end user’s clickstream as they navigate through key areas of your application. Typically, they run every 15 minutes, but you can configure them for different frequencies or to run immediately based on a specific action.

Once the robot client receives a response from your application, it reports the results back to the synthetic monitoring system. If the client detects an error during one of its regularly scheduled synthetic tests, the monitoring system will ask it to run that test again. If the follow-up test also results in an error, then the monitoring system will consider the error confirmed and escalate it within the organization as appropriate.

Teams can configure synthetic monitoring tools in various ways according to a company’s requirements. For example, you can set up a robot client on a machine that’s located behind your firewall to confirm that the internal environment is running as you expected, or you can deploy a robot client to a computer outside the firewall to get a sense of how well an application is performing. If you want a more comprehensive view of application availability and performance, you can configure several robot clients on browsers in multiple locations.

Synthetic monitoring vs. real user monitoring

Synthetic monitoring is often compared with another application performance technique known as real user monitoring (RUM). As the name suggests, RUM tracks actions taken by actual users instead of emulating them. Organizations often implement RUM by injecting JavaScript code into a webpage and then collecting performance data in the background as actual users interact with that page.

So, what is synthetic monitoring typically used for, and when might a business decide to use RUM instead? Synthetic monitoring is often helpful to identify short-term performance issues that may impact the user experience while an application is still under development. Early detection helps businesses nip potential performance issues in the bud. This approach is handy for regression testing and production site monitoring, for example. Real user monitoring, by contrast, can help a business understand long-term trends in an application’s performance after it has been deployed.

Why use synthetic monitoring?

If your application doesn’t perform well when your customers try to use it, they will quickly leave in pursuit of a better customer experience. This could play out in a variety of ways. For example:

• High bounce rates. Your website might take too long to load, resulting in a high bounce rate. Or, you might be lagging behind your competitors when it comes to application performance without even knowing it. This will hurt your ability to acquire new customers and grow your market share.
• Difficulty troubleshooting. Even when your organization is aware something is amiss with an application, it may not know where to begin troubleshooting. When it comes to application performance, IT teams can’t always get to the bottom of what’s going on quickly — especially when they’re overextended and juggling several priorities. And while your people are in the dark and searching for answers, your organization could feel an immediate and significant impact on its bottom line.

Emulating user behavior paths in a test environment helps you avoid these issues so you can:

• Monitor system health. Synthetic monitoring can tell you if your website is available, how fast it’s running, if key transactions are functioning as expected, and where a potential slowdown or failure might lie.
• Improve performance. Over time, synthetic monitoring can give you performance benchmarks, highlighting areas for improvement and optimization.
• Prevent issues early. You can also use synthetic monitoring to find and fix potential errors before they affect your users, raising the bar on the user experience. This is particularly useful in continuous integration and continuous deployment (CI/CD) environments.
• Increase resiliency. Synthetic monitoring can also help you prepare for peak traffic periods or anticipate performance requirements in a new region or market.

Synthetic monitoring tools are also useful for making sure you’re honoring service level agreements (SLAs) with your end-users. If an issue comes up involving third-party providers, you will be better equipped to hold them accountable, as well.

Types of synthetic monitoring

Synthetic monitoring usually includes three types: availability monitoring, web performance monitoring, and transaction monitoring.

• Availability monitoring enables an organization to confirm that a site or application is available and responding to requests. Availability monitoring can also use a more granular approach — for example, by checking to make sure specific content is available or that a specific type of API call is successful.
• Web performance monitoring typically looks at specific web metrics such as page load speed and the performance of specific elements on a webpage. It checks web content, errors, and sluggish response times.
• Transaction monitoring attempts to complete specific transactions such as logging in, completing a form, and checkout.

Within the realm of synthetic monitoring, there are also two main categories of synthetic tests:

• Browser tests – a robot client simulates a transaction a user might attempt (such as making a purchase)
• API tests – an organization monitors specific endpoints across each layer of the network and application infrastructure

Within API tests, there are different types of tests, including HTTP, SSL, and DNS. For example, API tests often use HTTP tests to monitor application uptime and responsiveness. Meanwhile, SSL tests confirm if users can securely complete transactions on a site using valid SSL certificates, and DNS tests make sure the site’s DNS resolution and lookup times are within expected parameters. A company might use multiple API tests to monitor whether a specific workflow is working properly from end to end — this type of API monitoring is called a multistep API test.

Challenges of synthetic monitoring

Modern applications are inherently complex. Because users access them from a variety of locations and contexts, synthetic monitoring is often not comprehensive enough to account for all the potential errors or situations that might arise. DevOps teams are accounting for this problem by placing a higher priority on introducing application testing earlier in the software development life cycle. However, synthetic monitoring is still often difficult to properly set up without specialized technical knowledge, and it is time-consuming even for the team members that have the required skill set.

Synthetic tests aren’t very resilient, and they can easily fail when small UI changes are introduced, generating unnecessary alert noise. This means that whenever a minor application element such as a button is changed, the corresponding test must be, too. And lastly, many synthetic monitoring tools lack the context needed to explain why a specific failure happened or what the business implications might be, lengthening time to resolution and making it unnecessarily difficult to prioritize application performance issues.

Benefits of synthetic monitoring

Proactive Monitoring: Synthetic monitoring allows you to proactively spot performance issues and availability problems. By imitating user interactions, it identifies irregularities before they impact real users. This early detection helps prevent potential outages and ensures a smoother user experience.

Global Testing: You can assess your application’s performance in various locations. Synthetic tests run from multiple regions, providing insights into regional variations in performance.

Browser and Device-Specific Testing: Synthetic monitoring lets you evaluate your application’s behavior across different browsers and devices. This helps identify compatibility issues and ensures consistent performance for all users.

Works Inside and Outside the Firewall: Unlike Real User Monitoring (RUM), which relies on actual users, synthetic monitoring can be completely automated and run inside and outside your organization’s network. This flexibility ensures comprehensive coverage.

Automated with Regular Frequency: Synthetic monitoring can run at regular intervals, such as every minute or hour, 24/7. This continuous monitoring ensures timely detection of any performance degradation.

Synthetic monitoring tools

A good synthetic monitoring solution should give your organization complete, 24/7 visibility into your applications. To accomplish this, it should include the following kinds of synthetic monitors:

• Single-URL browser monitors. A single-URL browser monitor simulates the experience a user would have while visiting your application using an up-to-date web browser. When run frequently from public and private locations, a browser monitor can alert you when your application becomes inaccessible or when baseline performance degrades significantly.
• Browser click paths. Browser click paths also simulate a user’s visit, but they monitor specific workflows in your application. An advanced synthetic monitoring solution can let you record the exact sequence of clicks and user actions you want to monitor, then set the browser click path to automatically run at regular intervals.
• HTTP monitors. HTTP monitors are useful for monitoring whether specific API endpoints are available, and they can also perform straightforward HTTP checks to confirm single-resource availability. HTTP monitoring tools should allow you to set up performance thresholds for HTTP monitors, too.

Synthetic monitoring use cases

Financial Services

Online Banking Systems: Synthetic monitoring ensures that online banking platforms remain available and responsive for users.

Payment Gateways: Monitoring payment gateways helps prevent transaction failures and delays.

Trading Platforms: Synthetic tests verify the performance of trading systems, which are critical for financial institutions.

Healthcare Technology

Electronic Health Record (EHR) Systems: Synthetic monitoring ensures EHR systems are accessible and responsive for healthcare professionals.

Patient Portals: Monitoring patient portals helps maintain seamless communication between patients and healthcare providers.

Telehealth Platforms: Synthetic tests validate the reliability of telehealth services, especially during high-demand periods.

General Web Applications

Availability Testing: Proactively detect failures even when there is no user traffic (for example, off business hours).

API Endpoints: Monitor the availability and performance of third-party API endpoints.

How Dynatrace can power your synthetic monitoring

If you’re thinking about better understanding how your applications are performing, you might be wondering what synthetic monitoring tools you need to get started. You’ll want to pick a solution that simulates business-critical journeys through your most important applications across your mobile and web channels. This can give you immediate answers to questions about application availability and the impact it’s having on the user experience. Your synthetic monitoring solution should also be able to help you quickly identify the root cause of any application performance issue so you can resolve it as soon as possible.

Dynatrace Synthetic Monitoring provides all the information you need to know the moment an application’s performance falters. By using all major desktop and mobile browsers to simulate user activity, Dynatrace helps ensure that web, mobile, cloud, and streaming transactions go smoothly for customers around the globe.

This is key for evaluating whether applications meet your SLA requirements, and it can determine whether business outcomes have been impacted. It can also eliminate troubleshooting through AI-driven automation, as well as rank problems in order of importance to the business — significantly reducing the time required for your IT team to identify and address root causes.

To catch those longer-term trends, Dynatrace RUM uniquely captures the full visibility of the customer experience to eliminate user experience blind spots, and Session Replay provides indisputable video evidence of the complete digital experience, so business, development and operations stakeholders can collaborate and agree where to make improvements.

These advanced digital experience monitoring capabilities help you proactively identify and address application performance issues from anywhere in the world. With the right synthetic monitoring solutions in place, your business can go a long way toward ensuring a consistent, satisfying customer experience.

The post What is synthetic monitoring? appeared first on Dynatrace news.

Synthetic testing simulates real-user behaviors within an application or service to pinpoint potential problems. Here’s a look at why this testing matters, how it works, and what companies need to get the most from this approach.

What is synthetic testing?

Synthetic testing is an IT process that uses software to discover and diagnose performance issues with user journeys by simulating real-user activity. Also called continuous monitoring or synthetic monitoring, synthetic testing mimics actual users’ behaviors to help companies identify and remediate potential availability and performance issues.

For example, teams can program synthetic test tools to send large volumes of simultaneous resource requests to a new application and evaluate how well it responds. Are all requests met in a reasonable amount of time? If not, what was the median increase over baseline response times? Did these requests impact users’ overall application experience? How?

By understanding how an app or service may respond in real-world conditions, teams can better pinpoint potential problems and fix these issues before live deployment or before users are affected. Along with real user monitoring (RUM), synthetic testing provides a comprehensive view into the user experience to ensure software meets user requirements.

Synthetic testing vs. real user monitoring

Both synthetic testing and real user monitoring (RUM) play a role in application development. The biggest difference between synthetic testing and RUM is synthetic simulates real-world scenarios, whereas RUM measures actual real-user behavior.

Another difference is where they happen in the development life cycle. Because synthetic tests don’t require a live environment, teams can conduct them in production or test environments to assess overall performance or the performance of a specific application component. In addition, these tests’ simulated nature requires minimal resource overhead, meaning teams can run them continuously.

RUM, meanwhile, requires actual users. As a result, it can only be conducted once applications or services are live. While this makes RUM more limited in scope, it doesn’t negate its value. Synthetic tests attempt to mimic both common and uncommon user behaviors, but even the best simulations are no substitute for the real thing. Users often interact with technologies in unpredictable ways that could reveal previously unknown issues.

Put another way, users may act out of frustration in response to a set of circumstances — such as “rage clicking” if an application doesn’t respond fast enough. Synthetic tools, meanwhile, can only simulate frustration. While teams can program them to rage click after a certain point or even randomly, they can never truly replicate the real-user experience.

As a result, organizations benefit from a mix of RUM and synthetic tests.

Types of synthetic testing

There are three broad types of synthetic testing: availability, web performance, and transaction. Each offers its own strengths and abilities for different needs.

Availability testing

Availability testing helps organizations confirm that a site or application is responding to user requests. It can also check for the availability of specific content, or if specific API calls are successful.

Web-performance testing

Web-performance testing evaluates metrics including page loading speed, the performance of specific page elements, and the occurrence rate of site errors.

Transaction testing

Transaction testing sees robot clients attempting to complete specific tasks, such as logging into accounts, filling in an on-site form, or completing the checkout process.

How synthetic testing works

Synthetic testing works by using a robotic client application installed on a browser, mobile device, or desktop computer. These applications send a series of automated test calls to a service or application, which simulate a user’s “clickstream,” or the actions they take while on the site.

Consider a synthetic test designed to evaluate an e-commerce shopping application. First is a test of the home screen. Does it open quickly and consistently with no visual artifacts? Next, the synthetic test links to product pages. It then moves on to shopping carts, shipping rates, and, finally, a simulated purchase. The robotic client application reports if any of these transactions fail or perform too slowly, allowing companies to make changes before services go live.

When designing synthetic tests, it’s worth using a combination of browser-based, mobile, and desktop tests to assess application performance. This is because each of these traffic vectors comes with unique challenges. For example, even if response times are consistent across all testing environments, mobile users could still experience issues with automatic screen size scaling or application design choices that favor desktop users.

Requirements for synthetic testing

To create a reliable testing environment, several components are critical.

Well-defined goals

Effective synthetic testing depends on well-defined goals. Organizations need to identify what they’re trying to measure before they write and deploy test scripts. Then, it’s ensured the data captured is relevant to these goals.

Customizable robot clients

Robot clients are the foundation of synthetic testing. But in the same way that testing needs to evolve over time, organizations need client components that can be configured to keep pace with change as their on-premises, cloud, or hybrid environments evolve.

Comprehensive synthetic testing tools

To effectively evaluate and optimize digital experiences, organizations need synthetic testing tools that cover the major user touchpoints with their environments. At a minimum, a synthetic monitoring program should include the following tools:

• Single-URL browser monitors. Single-URL browser monitors simulate a user’s visit to a site using an up-to-date web browser. By consistently running single-URL browser testing from both public and private sources, organizations can ensure that sites maintain an established baseline performance.
• Browser clickpaths. Browser click-path testing monitors specific click sequences through critical application workflows. Running browser click paths regularly can ensure that specific function sequences remain available and high-performing.
• HTTP monitors. HTTP monitors use simple HTTP requests to ensure that specific application programming interface (API) endpoints and website resources are available.

In addition to running these tests regularly, organizations should ensure their synthetic testing tools follow basic security best practices. For example, a synthetic testing tool should not send requests to local hosts or default IP addresses.

Synthetic testing best practices

A few best practices can help organizations achieve reliable, actionable data from synthetic testing tools. The following are three strategies worth considering.

1. Reduce setup complexity

The level of application integration required for synthetic solutions to collect key data can lead to complexity. To help mitigate this risk, clearly define your goals before setting up tests to streamline configuration and leverage tools designed to simplify the process with visual or script-based setups.

2. Prioritize continual monitoring

Continual monitoring is critical for organizations to understand how applications and users interact over time. It also plays a key role in addressing the issue of test fragility. Even small changes to the user interface — such as removing or replacing a button — can cause tests to fail. Continual monitoring allows organizations to detect and fix these failures immediately.

3. Keep context front and center

Testing doesn’t drive action without context. While many synthetic tools provide data about what’s happening when users interact with applications, they don’t answer the question of why. Keeping context front and center with synthetic testing integrated into an end-to-end observability platform provides complete visibility without adding additional tools.

Synthetic testing as part of a unified observability strategy

To make synthetic testing easy to develop and maintain, it should be part of a wider observability strategy. By taking a unified platform approach to observability, organizations can integrate synthetic testing into their overall application performance efforts.

Dynatrace synthetic monitoring provides continuous and on-demand answers to questions about application performance, reliability, and the overall user experience. By combining this approach with Dynatrace RUM, it’s possible to capture the full range of customer behavior, from common clickstreams to unexpected actions that may suddenly tax resources or lead to strange application behavior.

Dynatrace helps organizations proactively evaluate the performance of applications no matter where they are in the development cycle. The result is enhanced application performance and improved user experience that keeps customers coming back.

The post What is synthetic testing? appeared first on Dynatrace news.

Many organizations today are utilizing Kubernetes to orchestrate their containers’ deployment, scaling, and management. The benefits of this approach include faster deployment, easier and more effective management, cost reduction, and more. Because it’s critical that operations teams ensure that all internal resources are available for their users, synthetic monitoring of those resources is important. Private locations are crucial in achieving this goal. So why not use the advantages of K8s to make synthetic deployment monitoring easier and more effective?

Large enterprises face different challenges

A well-described synthetic check can reduce, and in many cases avoid, unforeseen downtime due to failure domains by replicating the expected user journey and measuring its performance. Global corporations with offices in multiple countries need to ensure that their internal systems are accessible to all employees, regardless of their location.

To simulate those users’ journeys, multiple synthetic locations deployed within various sections of internal networks are required. A prominent solution is virtual machines, however, this is inadequate for customers who deploy their systems with Kubernetes. For large enterprises, this is not even a consideration. Some organizations need to weigh cost considerations due to technology and business scalability limitations whereas others need to adhere to company policies. In addition, the need for automation dictates proceeding with containerization, particularly for monitoring services that are not exposed outside of Kubernetes. This is in line with market trends which indicate that the growing number of open source vendors providing container platforms, the rising popularity of microservices, the increasing digital transformation of businesses, and the requirement to abide by regulatory requirements are all expected to contribute to the growth of the Kubernetes market by 23.4% CAGR in the forecasted period ending 2030.

Private locations in K8s offer numerous benefits

Dynatrace identified that it is insufficient to deploy private locations in virtual machines only, where modern and truly cloud-native solutions require support for container-based application development. With this update, we’ve expanded our offerings to cover deployment trends in Kubernetes. Instead of treating this as merely another supported platform along with Windows and multiple Linux distributions, auto-scalability was built to simplify efforts related to the management and maintenance of private locations. In the case of one of the largest banks in the US, this was decisive in the deployment of Dynatrace Synthetic Monitoring, where a practitioner quoted, “deployment of private synthetic locations in K8s allows our organization to proceed with synthetic monitoring to proactively react on issues with our systems.” Not only do operations personnel now have an easier time deploying synthetic tests faster with fewer resources, it’s also no longer necessary to track utilization.

For operations personnel working with Kubernetes, this is a significant leap ahead. This is how Synthetic deployment should be for cloud-native environments. With this update, practitioners can easily manage synthetic locations for multiple environments. Furthermore, they can schedule deployments when needed while leaving the hassle of scaling to the Dynatrace platform. With the deployment of private locations in containers, development teams can increase the velocity of deployments, improve infrastructure durability, and automate the building, running, and maintaining of applications throughout their production environments. This has been confirmed by the operations lead of a European organization catering to disabled people, “it significantly speeds deployment up and allows us to replicate the locations very quickly in a test environment.” To stay in lockstep with container usage across industries, synthetic monitoring solutions are making tools available to cater to those trends.

Compared to the alternate approach of deploying in VMs, containerized location deployment is much faster and does not require setting up new virtual machines for each node.

Who can benefit from this update?

If you’re part of any one of these groups, you can benefit from the private locations in K8s

• If you’re exclusively a virtual machine user using Dynatrace Synthetic Monitoring but haven’t migrated to containers due to a lack of support.
• If deploying synthetic ActiveGates on separate VMs is a hassle while using Dynatrace Synthetic.
• If you partially deploy your applications as containers.
• If you’re already using containers for your software and have requested private locations for them but aren’t entirely satisfied with the need to set up virtual machines.

How does it work?

To begin, it’s important to be aware of the difference in approach employed by this update compared to existing solutions in the market. Kubernetes takes care of keeping the necessary minimum number of nodes alive for executing all the tests assigned to a location. This way the location is always big enough to effectively handle the load but does not consume more resources than needed. Also, instead of deploying single Synthetic-enabled ActiveGates and assigning them to selected locations (including tracking utilization metrics and adding new ActiveGates the same way, if required, for executing more tests) in a containerized version, Dynatrace deploys the whole location immediately with a minimum and a maximum number of nodes as the necessary input parameters.

The configuration process is straightforward. Simply define the new location name and geographic location, as well as the size for a single node (XS, S, or M) and the minimum and maximum number of nodes. These numbers serve as limits for scalability, utilizing the power of the Kubernetes platform.

Dynatrace always recommends using 2 as a minimum number of nodes to achieve a high availability setup. A maximum number is specified for resource control purposes. Automation practitioners may utilize an API-based to achieve the same results. After saving the location’s configuration, you’re allowed to download the generated YAML file automatically which will be the basis for your deployment.

In the Deployment of Synthetic Private Location section, you need to either provide existing tokens or create new ones. You also have the option to adjust Kubernetes namespace and/or ActiveGate names if necessary. Lastly, you’re given a series of commands to execute on the K8s/OpenShift cluster.

Now, all you need to do is execute the commands.

After just a few minutes your pods are up and running, as is your new synthetic private location. As a next step, you could assign tests to it or execute tests from a new location in on-demand mode.

Deployment of containerized locations is now significantly faster as it negates the need to be repeated for each node, particularly in comparison to the virtual machine approach which requires setting up new virtual machines beforehand.

Take advantage of Dynatrace Synthetic Monitoring today

If you’re considering ways to cut down on resource expenses, streamline deployment processes, and improve your synthetic monitoring capabilities, private location deployment in containers with auto-scalability can be incredibly beneficial. These solutions will allow your SMEs to concentrate on crucial areas where their expertise is most needed.

The post Dynatrace delivers flexible and scalable Kubernetes native synthetic private locations appeared first on Dynatrace news.

Strict rules and high volume make for difficult management of secrets

Our customers use Dynatrace Synthetic Monitoring for 24/7 monitoring of their websites, web applications, and API endpoints. These systems are protected by various authorization mechanisms. The problem in modern, complex environments with very strict security rules is that the sheer volume of secrets is not only difficult to manage but is also growing rapidly. To add another layer of complexity, these secrets need to be rotated frequently and regularly to comply with security policies. One of the reasons that companies have opted to use external vault solutions (such as HashiCorp Vault, Azure Key Vault, CyberArk Vault, and others) is to make management of authorization secrets easier.

In a typical setup, the team that maintains synthetic monitors and furnishes them with application credentials is different from the team managing and rotating company secrets in an external vault system. This scenario can present challenges as rotating passwords twice can be redundant and pose a potential security risk. To address such concerns regarding credential rotation and security, we introduced a mechanism for automatically synchronizing credentials stored within Dynatrace with those stored in external vaults.

Auto-synchronized credentials from external vaults

To make synthetic monitoring more effective, we already introduced the Dynatrace credential vault for storing passwords, tokens, and certificates needed by monitors to access API endpoints and websites. Now, with automatic synchronization of credentials, you can easily and securely integrate Dynatrace synthetic monitors with external secret vaults. All you need to do is create a new entry within the Dynatrace credential vault, mark it as synchronized, and provide the necessary details to authorize access to an external vault and path to a particular secret stored there—Dynatrace takes care of the rest!

Dynatrace automatically creates a synthetic HTTP monitor whose sole purpose is to synchronize the new entry within Dynatrace vault with data stored in the external vault. This synchronization is automatic with no additional actions required on the part of the teams managing your Dynatrace synthetic monitors.

How it works

There’s a small albeit important new element when creating new credentials within the Dynatrace credential vault—a toggle for enabling synchronization with an external vault.

After turning the toggle on, you need to select the type of external vault that contains the source credentials. Next, you’ll need to provide details regarding the exact location, such as the URL of the external vault of the secrets you want to synchronize as well as the preferred method for authenticating within the external vault. At the time of this publication, HashiCorp Vault and Azure Key Vault are the supported external vault types with AppRole-based or certificate authentication for HashiCorp and certificate authentication for Azure Key Vault.

You can find a detailed description of how to set up a credential for external synchronization in Dynatrace Documentation. Note that you never need to provide sensitive information as plain text; it’s quite the opposite—any such information would need to be stored in the Dynatrace credential vault in advance and used directly from here.

After you’ve set up and saved the credential to be synchronized, a new synthetic HTTP monitor is automatically created with the goal of executing the requests necessary for performing secret synchronization. Its configuration is based on information provided earlier. You can analyze the execution details of an automatically created synchronization monitor in the same way as you would any other HTTP monitor. However, please note one important difference—to ensure the security of secrets, the details of headers and payloads are not stored to avoid exposing the secrets in execution details.

By default, synchronization monitors are assigned to a single location and run once an hour, but those values may be adjusted as needed. From each synchronized entry within the Dynatrace credential vault, there’s a link to the HTTP monitor performing synchronization.

Overwriting a credential that’s synchronized with an external vault achieves a slightly different end than in the case of standard credentials. The goal here is not to provide a new password or username value, but, rather, to adjust parameters necessary to access data from the external vault.

Of all the ways we could have implemented credential synchronization, we opted for synthetic monitors for one special reason—it makes it possible for you to adjust their definitions easily in order to build your own support for a different authorization method or experiment with different vaults. If keeping a copy of your credential within the Dynatrace credential vault is forbidden, you might consider obtaining the secret directly within the monitors testing the business logic of your application.

What’s next

Synchronization with external vaults is not our only big improvement for Dynatrace Synthetic Monitoring—expect more to come soon. In particular, keep an eye out for:

• On-demand triggering of synthetic monitor executions.
• Deployment of containerized private Synthetic locations within Kubernetes clusters.

Get proactive with Synthetic Monitoring

External credential synchronization is available with Dynatrace version 1.239. For private locations, ActiveGate 1.237+ is required. With these conditions met, you may start configuring synchronization of your secrets for use within your synthetic monitors.

Please don’t forget to share your comments with us. You can find me on the Dynatrace Community, or you can leave your comments in the Product Ideas channel focused on external credential vaults. Your feedback will be factored into decisions around which other external vaults should be supported (CyberArk is top candidate right now) or which other authentication mechanisms are in demand.

New to Dynatrace? Sign up for a free trial.

The post Dynatrace boosts Synthetic Monitoring with auto-synchronized credentials from external vaults appeared first on Dynatrace news.

Organizations can now accelerate innovation and reduce the risk of failed software releases by incorporating on-demand synthetic monitoring as a metrics provider for automatic, continuous release-validation processes. With this approach, teams can scale testing for all environments, which reduces efforts in replicating, updating, and maintaining test scripts. No external tools or additional configurations are needed. Dynatrace relies on Davis^® AI  to identify the root cause of issues found via Dynatrace Synthetic Monitoring-powered pre-production and production release validation. This significantly accelerates release cycles, reduces time to market, prevents unexpected disruptions, and lowers costs by catching issues early in the software development lifecycle (SDLC).

The ability to scale testing as part of the software development lifecycle (SDLC) has proven difficult. It negatively affects the lead time for changes (LT), a DORA metric¹ that DevOps teams use to measure platform and team performance. This metric indicates how quickly software can be released to production.

Utilizing a collection of tools for synthetic CI/CD testing can identify an issue while still leaving DevOps and SRE teams responsible for root cause analysis, which they often have to perform manually. Consequently, finding the root cause and fixing the problem is time-consuming and tedious because proper root cause analysis isn’t possible for diverse tool stacks.

Missing integration with Dynatrace Real User Monitoring (RUM) for canary releases and blue/green deployments can leave teams blind to customer experience.

Last but not least, traditionally, testing occurred relatively late in the SDLC, which boosts the cost of every identified vulnerability.

Dynatrace combines Synthetic Monitoring with automatic release validation for continuous quality assurance across the SDLC

Dynatrace customer Duke Energy utilizes synthetic on-demand execution capability.

“We don’t have to wait 5, 15, or even 60 minutes” states Travis Anderson, Application Performance Management at Duke Energy. Dynatrace Synthetic Monitoring on-demand execution allows us to “repurpose“ the existing synthetic monitors we use for continuous production validation for our automated release validation of new deployments. This “eliminates the need” to invest in additional release validation testing and “saves time” as we get instant feedback and don’t have to wait for the next test cycle to kick in.

DevOps best practices include testing within the CI/CD pipeline, also known as shift-left testing. Running tests early and often helps DevOps teams catch issues before they impact users.

Synthetic CI/CD testing simulates traffic to add an outside-in view to the analysis. It emulates user journeys (clickpaths), as well as HTTP(S) API requests, to provide insights into how well applications or services are performing at every stage of the development process. This 360-degree visibility into user journeys and the underlying applications or infrastructure are key insights provided only by Dynatrace.

In combination with release validation, synthetic monitors measure adherence to service-level objectives (SLOs) to determine whether software versions should progress in the SDLC. Synthetic-powered release validation can be executed continuously, for example, with every commit, providing ongoing information about software quality.

Synthetic monitors can be created with our innovative web recorder or through MONACO, our Monitoring-As-Code approach. Facilitating both practitioner groups—those commonly working with UIs and dashboards and those working with the GitOps approach.

With Dynatrace you can create Synthetic Monitoring powered release validations via either our web UI or the GitOps approach with MONACO.

MONACO enables development teams to define monitoring configuration as code that is checked into version control alongside application source code. This enables configurations such as SLOs, alerts or dashboards, and synthetic monitors to be changed and managed alongside an application’s source code.

SREs visualize the state of the system they’re responsible for with powerful Dynatrace dashboards. With Dynatrace Cloud Automation and synthetic monitors, SREs can now rely on continuous validation of SLOs, presentation of the root cause when validation fails, and automatic problem remediation.

The Dynatrace Software Intelligence Platform provides a fully integrated approach for synthetic CI/CD testing and pipeline automation

• Synthetic monitors for single-page views, multistep user journeys, or API checks can be created without scripting, thanks to our innovative web recorder in the DEM module. With a “Build once, run anywhere approach” the same monitors can be used in early development through to production environments.
• With Dynatrace Cloud Automation—an integrated enterprise control plane—organizations can use synthetic monitoring insights for full lifecycle orchestration of applications, automated release validations with quality gates, and closed-loop remediations for automated problem resolution.

Dynatrace seamlessly combines Synthetic Monitoring with Real User Monitoring for canary releases, blue-green deployments, and production releases. This enables DevOps teams to seamlessly navigate between simulated and real-user journeys. DevOps teams can analyze user behavior analytics and, with Dynatrace Session Replay, video-like replay of individual user sessions.

Dynatrace provides a holistic approach to synthetic CI/CD testing for browser applications with desktop and mobile synthetic devices, leveraging public as well as private locations to cover all applications.

Dynatrace adds annotations to all on-demand monitor executions and thereby captures all related execution overview details (see callouts below). This provides the convenience of easily knowing which monitor executions are scheduled and which are triggered on demand.

Request your Dynatrace Synthetic Monitoring and Cloud Automation demo, or integrate them into your SDLC directly

Dynatrace is happy to provide you with a demo or proof of concept for Cloud Automation. We also offer a free Dynatrace trial if you’d like to get started directly!

Dynatrace customers use metrics provided by our synthetic monitors to ensure that every release is automatically validated by Cloud Automation. This way, our customers ensure the desired state of their software—both in pre-production and production environments.

In production, SREs utilize Cloud Automation to, for example, continuously validate the availability of their applications across the globe from our 80-plus global Synthetic Monitoring locations.

Dynatrace customers achieve faster delivery of software and eliminate manual work in problem resolution. They find more time to drive automation, which makes the software delivery experience more enjoyable and metrics based, which ensures quality and security across their environments—powered by Dynatrace Synthetic Monitoring.

__________

_{¹ DORA stands for the DevOps Research and Assessment team, a Google-headed project tasked with analyzing DevOps practices. The DORA team’s analysis identified four key DevOps metrics: Deployment frequency, Lead time for changes, Time to restore service, and Change failure rate. See DORA research program for full details.}

The post Dynatrace ensures continuous software quality by combining synthetic monitoring and automatic release validation appeared first on Dynatrace news.

In today’s competitive business environment, customers demand seamless user experiences. As businesses compete for customer loyalty, it’s critical for organizations to harness tools that help them see how users interact with their services. By understanding the difference between two such tools, synthetic monitoring vs. real user monitoring, teams can use them to develop high-performing applications and services that deliver loyalty-building user experiences.

Although both of these development and testing practices examine user behavior, they have distinct—and complementary—goals. Here, we’ll explore synthetic monitoring and real user monitoring, and how both help to deliver user experiences that win—and keep—customers.

What is real user monitoring?

Real user monitoring (RUM) is a performance monitoring process that collects detailed data about users’ interactions with an application. RUM gathers information on a variety of performance metrics. If you collect data on page load events, for example, it can include navigation start (when performance measuring begins), request start (when the user initiates a server request), and speed index metrics (measure page load speed).

A user session, also known as a click path or user journey, is a user’s sequence of actions while working with an application. User sessions can vary significantly, even within a single application. RUM collects data on each user action within a session, including the time required to complete the action. As a result, IT pros can identify patterns and where to make improvements in the user experience.

Ideally, a RUM tool would record all user actions to capture the complete picture of a user’s experience. In reality, only highly scalable RUM solutions can collect data on all user actions, while less scalable tools must sample user actions and make inferences from partial data.

Benefits and challenges of RUM

Real user monitoring is great for providing real metrics from real users navigating a site or application. The benefits of RUM include the following:

• Access to data from real end users across various applications, services, and environments.
• The ability to collect a diverse set of data points for every user accessing the application or services.
• Customizable variables to track, collect, and evaluate application-specific data points using JavaScript.
• Real-time monitoring of user application and service interactions.
• Enhanced issue remediation with the option to watch visual session replays of users interacting with web services or applications.

RUM, however, has some limitations, including the following:

• RUM requires traffic to be useful. If teams use RUM in a pre-production environment, it’s challenging to get useful information. Because teams use pre-production environments for testing before releasing an application to end users, they have no access to real-user data.
• RUM works best only when people actively visit the application, website, or services.
• In some cases, you will lack benchmarking capabilities. Because RUM relies on user-generated traffic, it’s hard to indicate persistent issues across the board.
• RUM generates a lot of data. RUM’s attention to detail results in a more accurate diagnosis of end-user issues and experiences. However, the volume of data it generates can make responding to specific issues cumbersome and difficult to prioritize.

What is synthetic monitoring?

Synthetic monitoring, also known as synthetic testing, is a performance monitoring practice that emulates users’ paths when engaging with an application. It uses scripts to generate simulated user behavior for different scenarios, geographic locations, device types, and other variables.

After collecting and analyzing this valuable performance data, a synthetic monitoring solution keeps tabs on application updates and how an application responds to typical user behavior. For example, synthetic monitoring can zero in on specific business transactions, such as completing a purchase or filling in a web form. This gives teams crucial insight into how an application is performing.

Benefits and challenges of synthetic monitoring

Synthetic monitoring is good at catching regressions during development lifecycles, especially with network throttling. The benefits of synthetic monitoring include the following:

• Simulation of entire user journeys in a controlled application environment.
• The ability to identify application performance issues and potential issues by running interval tests.
• Customized tests based on specific business processes and transactions — for example, a user leveraging services when accessing an application.
• Complex transaction and process monitoring that might have deeper dependencies. For example, in e-commerce, you can validate and test checking out a shopping cart.
• Application or service lifecycle testing at every stage. This includes development, user acceptance testing, beta testing, and general availability.
• Geofencing and geographic reachability testing for areas that are more challenging to access. For example, the ability to test against a wireless provider in a remote area.
• Performance testing based on variable metrics (i.e., connectivity, access, user count, latency) of geographic regions.

Much like RUM, however, synthetic monitoring has its limitations. Here are some drawbacks:

• Synthetic monitoring can be too predictable. In synthetic monitoring, tests and results are generated in a controlled and predictable testing environment. Because synthetic monitoring doesn’t track real users, you’ll have challenges gauging what an end user might experience in the event of an unpredictable variable.
• Tools may be limited. Depending on the vendor or technology you work with, you may not be able to integrate existing tools with scripts for your tests.
• The range of costs and feature sets can vary widely for synthetic monitoring tools. It’s recommended to work with partners that can deliver RUM and synthetic user monitoring to deliver the most value.

Synthetic monitoring vs. real user monitoring: Which do you need?

The real answer may not be one or the other. Instead, when working with websites, applications, or services, you may need both. While synthetic monitoring allows you to create a consistent testing environment by eliminating the variables, both RUM and synthetic monitoring provide feedback about site, application, or service performance. The strength of both solutions comes when you combine them.

By using synthetic monitoring and RUM together, you can thoroughly investigate specific user issues, and discover and resolve shortcomings. Furthermore, both tools provide full visibility into user and service performance. Using both, you can gauge how fast a site or service needs to be to ensure user satisfaction and to deliver optimal performance.

Together, RUM and synthetic monitoring can accomplish the following:

• Help correlate business requirements with performance levels by providing the performance data you need to analyze the end-user experience.
• Pinpoint challenges before active users access your website or services by identifying problems, such as configuration issues, so you can fix them before users log on.
• Use data from one engine to facilitate testing for the other. For example, you can use RUM data to provide real use cases you can use for simulation in synthetic monitoring for detailed testing in a staging environment.

Finally, combining RUM and synthetic monitoring data can make troubleshooting faster and easier. For example, real-user monitoring metrics might reveal a user performance issue that you can then apply to synthetic testing to replicate the issue by exercising the same transaction across several different variables.

Synthetic monitoring and RUM—better together

The bottom line? Both RUM and synthetic monitoring tools provide insight into every step within the application delivery chain and life cycle.

Working with both RUM and synthetic monitoring creates a healthy long-term solution to support the best possible user experience. While using one or the other tool will undoubtedly help to analyze performance in different ways, the true power comes when you use them as a complementary toolset. The result is a more comprehensive and robust monitoring strategy that will have a longer-lasting impact on user performance and experience.

The post Synthetic monitoring vs. real user monitoring: Understanding best practices appeared first on Dynatrace news.

Particularly during the COVID-19 pandemic, we’ve seen how poor application performance can impact business bottom lines and lead to lost revenue for many organizations, as laid out in our recent blog post about digital experience. To provide “quality signals that are essential to delivering a great user experience on the web,” Google introduced their Core Web Vitals initiative last year, advocating the Largest contentful paint, Cumulative layout shift, and First input delay metrics. Google recently included these metrics as “user experience signals” in their search result rankings, demonstrating that these metrics aren’t just nice to have but are a necessity.

While the information provided by Google Core Web Vitals is certainly valuable, it leaves you to resolve any high-level issues that are reported by tools such as the Google Search Console without giving you the option of drilling into details or seeing necessary context information across your application front and back ends.

Read on to understand why the Google Search Console is a great place to start but why you also need to understand how you can use Dynatrace Digital Experience Monitoring (DEM) to get valuable context information that you can proactively act on. Dynatrace is the leader in this space, giving you the ability to see business outcomes and monitoring data in the same distributed trace, capturing all details from each user click down to each database call, and using the Dynatrace Davis AI causation engine to identify the actual root causes of issues.

Google Search Console is a great place to start but it leaves you with more questions than answers

As a product manager or application owner, you care a lot about how discoverable your business is on Google. Therefore, SEO and improving your search rankings should be high on your agenda.

To get started, you might use the Google Search Console and select the Core Web Vitals  tab. Browsing through this section, you can check the report for each Core Web Vital  metric  that requires action and view all the individual URLs that are affected. You have two options for each URL:

• You can visit a URL in the browser to better identify the page in question.
• You can jump to PageSpeed insights, analyzing the URL in a single run.

While all this is certainly valuable, it leaves you with:

• Aggregated field metrics rather than valuable details from single instances.

You might wonder, what about details of the requests made on this page? Which of them is slow?

• Metrics and recommendations rather than helpful context information.

You won’t know, for example, whether your 75th-percentile value for Largest contentful paint (LCP) is the result of some users experiencing slow resources because of a CDN issue or a poorly performing service in your back end.

• Ex-post information rather than ex-ante insights to act on proactively.

PageSpeed insights has never been straightforward enough to use with non-public development or staging environments. Therefore, you often end up reacting to changes that are introduced with a release.

Dynatrace complements Google Core Web Vital measurements with insights across your application front and back ends

With zero configuration, you can leverage all three Core Web Vital metrics in Dynatrace and get details with just a few clicks:

• Largest contentful paint (for load actions in RUM and Synthetic Monitoring) provides you with an indication of how fast your page is loading.
• First input delay (for load actions in RUM) gives you an idea of how interactive your page loads are.
• Cumulative layout shift (for load actions in RUM and Synthetic Monitoring) offers you the means to understand whether elements on your page are stable through the page load process.

In the following sections of this blog post we’ll explain how you can:

• Unleash Core Web Vitals by defining them as key performance metrics.
• Analyze the Core Web Vitals in session detail pages and use them in USQL.
• Improve Core Web Vitals timings using Synthetic Monitoring.

Unleash Core Web Vitals by defining them as key performance metrics

After gathering your valuable feedback and Google’s recent announcement, we decided to integrate the Core Web Vital metrics more deeply into Dynatrace RUM and Synthetic Monitoring to acknowledge their importance. So we’ve accorded them full key performance metric status, allowing you to:

• Define them as such for browser monitors, applications, and single key user actions.
• Leverage Google’s predefined thresholds for your Apdex calculation.
• Automatically capture long-term data for all three metrics.
• Fetch each of the three metrics via the Metrics API and query them with USQL.
• Create custom alerts for Core Web Vitals.
• Create dashboards based on these out-of-the-box metrics in custom charting and the new Data explorer.

To get started, pick any of the Web Vitals as a Key Performance metric in the RUM General Application settings. Or, for a synthetic browser monitor, configure Largest contentful paint or Cumulative layout shift as key performance metrics in the Monitor Setup tab of monitor settings.

From here on, the Davis AI has you covered and will automatically baseline your selected Core Web Vital and detect anomalies in the metric.

Whenever you want to explore and analyze any of the Core Web Vitals, simply start on the Synthetic or RUM multidimensional analysis page, where you can filter for synthetic monitor actions or RUM user actions. For example, when you see a reported Core Web Vital issue in the Google Search Console, navigate to the corresponding RUM user action in Dynatrace, as shown below.

After finding the corresponding load action, go to the action detail page for additional, rich context information that helps identify the reasons for a poorly performing Web Vital metric. For example, you can select View analysis in waterfall chart to immediately:

• Check how resources are requested on that page (script files, images, etc.) and find any particularly slow request.
• If a request is slow, get additional context information across the application front and back ends to narrow down the issue. Analyze whether slow requests are back-end or front-end related. For instance, use Dynatrace PurePath to jump from the front end to slow back-end requests so you can further analyze them. Or, use front-end-related metadata such as the effective connection type and network downlink of the given user.
• If your requests are fast, check for Long task times, which indicate that an issue is front-end related and whether heavy JavaScript execution is blocking your page from loading quickly.
• Act proactively by getting these signals early on, from every environment, not just production environments. Davis AI knows when your key performance metric slows down from one release to the next.

Here’s how a similar analysis of Largest contentful paint and Cumulative layout shift would work for synthetic browser monitors.

1. Select Synthetic from the navigation menu.
2. Select a single-URL browser monitor or clickpath to view the details page.
3. Select the performance infographic on the right.
4. Select Analyze performance to view multidimensional analysis of performance.
5. Make sure to have Load actions analyzed based on Largest contentful paint and Cumulative layout shift.

Analyze the Core Web Vitals on session detail pages and use them in USQL

But what if the user action alone isn’t enough? What if you need more context? That’s easy! Just jump to user sessions and find all the metrics for every load action. Simply expand a given load action and check out the measurements and scores in the breakdown.

If you’re a fan of USQL, then no worries, we’ve also included the Core Web Vitals here. Use them to start your exploratory analysis at a higher level in USQL and use all the relevant context data to segment them. For those of you who want to build custom solutions based on the metrics, we’ve got you covered. User session export now includes all three Core Web Vital metrics.

Improve Core Web Vital timings using Synthetic Monitoring

Core Web Vitals are available for synthetic monitors out of the box, without any additional configuration. Leveraging Dynatrace Synthetic Monitoring is the perfect addition to Real User Monitoring, so you can analyze and improve your Core Web Vital metric timings. Synthetic (or lab) data provides a stable baseline, as the metrics are always measured with exactly the same parameters (network conditions, screen resolution, device type, CPU, etc.). This makes synthetic monitors a great option for monitoring performance during development and allows you to catch performance regressions as early as possible.

What about First input delay for synthetic monitoring?

You might have noticed that First input delay is not available as a key performance metric for synthetic browser monitors. Google argues that it doesn’t make much sense to look at First input delay for synthetic data as there isn’t any actual user input (which is only simulated). They suggest using Total blocking time (TBT) instead.

TBT is currently not available in Dynatrace. However, we recommend looking at a new metric that we’ve added instead—Long tasks (which TBT is based on). This metric is captured via the browser Long Tasks API and has the advantage (over TBT) of also being available for real users.

Long tasks is the total time of all long JavaScript tasks (over 50 ms) added together. It’s measured from Navigation start for the entire User action duration.

Long tasks is currently not a key performance metric, but you can find it in multidimensional analysis and you can also create a calculated metric based on it if you want to have long-term data or be alerted on it.

Seeing is believing

Prepare for the change to Google search rankings and improve user experience by fine-tuning Web Vital metrics with Dynatrace today.

• Already a Dynatrace customer? Start using all the Core Web Vitals today with zero configuration in all your applications!
• New to Dynatrace? Try Dynatrace by starting your free trial today.

What’s next

• Pages: Ever wondered where you can find your route changes for single-page applications? Rest assured that you’ll have an answer soon!
• CSP violations: You’ve probably already seen that we’ve added another Request error type in Dynatrace RUM—expect an official explanation of this soon in a future release.
• Errors in USQL and session export: As mentioned in previous troubleshooting-related releases, we’re currently looking into bridging some gaps in our error-analysis flows. In particular, we’re looking into adding high-level error information to USQL as well as making this information available to you via session export.

The post Full support for Google’s Core Web Vitals improves your user experience and search rankings appeared first on Dynatrace news.

APIs are everywhere these days—from internal APIs that are used within your microservice architecture, third-party APIs that your software relies on, to external APIs that you offer to your customers. So when an API breaks, your business is impacted. Dynatrace HTTP monitors help you to ensure that your APIs are available and performing well from all locations around the world in compliance with your SLAs. HTTP monitors are the perfect tool for proactively monitoring API endpoints, API transactions (for example, CRUD scenarios), health-check endpoints, and your mobile back-end services.

Since their introduction in 2018, Dynatrace HTTP monitors have proven to be the most unique and complete solution available for monitoring your APIs and are now considered to be a critical component of the observability strategies of many of our customers. 

As we’re seeing an ever-increasing interest in HTTP monitor usage, we’ve also received quite a bit of feedback from our customers. Therefore, today we’re happy to announce that we’ve greatly enhanced our HTTP monitor and third-party monitor details pages.

All insights at your fingertips with the revamped HTTP monitor details page

With the new page design, you can:

• Instantly understand the scope of problems with aggregated availability
• Understand global performance at a glance
• Use filters to focus on the locations that you’re most interested in
• Explore further with detailed timings for HTTP requests
• Actively monitor your mobile app’s back-end service availability

In the next sections of this blog post, we’ll walk through some of the highlights of the new page design. All screenshots featured in this blog post are taken from an actual HTTP monitor that we use at Dynatrace for self-monitoring (in the spirit of “eat your own dog food,” or, “drink your own Champagne” as we prefer to say). 

Instantly understand the scope of problems with aggregated availability

HTTP monitors are usually executed from multiple, private (internal on-premises) and public locations to ensure availability from different geographies. The new availability card now offers a simplified view of global, overall availability. 

At a glance, you can easily distinguish if an outage was local (unavailable at only a subset of locations) or global (unavailable at all locations). Whenever you need more detailed information, just select Show availability breakdown per location to see availability details per location. 

Understand global performance at a glance

Usually, the second most important question after “is it available?” is “is it performing well?” Following the same principle used for aggregating availability data, the Performance card now shows the minimum and maximum response times by default. The range chart makes it easy to understand the spread of the response time. If the response time changes, it provides a clear indication as to whether or not the requests have slowed generally or only at a specific location. 

Select Show response time breakdown by location to view the response time split by monitoring locations.

Use filters to focus on the locations that you’re most interested in

In some instances, you might want to focus on one or multiple locations to better understand geography-specific behavior. You can now easily filter the entire details page for specific locations using the filter field at the top of the page. This helps you focus on the details that are most relevant to your analysis. 

Explore further with detailed timings for HTTP requests

An HTTP monitor can consist of one or multiple HTTP requests. The HTTP request card gives you an overview of all executed requests, their order, name, and the HTTP method used. 

If you expand a request, you’ll see detailed timings for the request. The stacked chart shows all individual timings that add up to the overall response time of the request. 

• DNS lookup time: Amount of time taken to resolve the host name—If there are multiple DNS calls because of a redirect, this is the total time of all DNS calls. 
• TCP connect time: Amount of time taken to establish the TCP connection—If there are multiple TCP connections because of a redirect, this is the total time of TCP connection attempts. 
• TLS handshake time: Amount of time taken to complete the TLS handshake
  
• Waiting: Amount of time taken for the server to respond with the first byte—This equals Time to first byte minus (DNS lookup time + TCP connect time + TLS handshake time). 
• Download: Amount of time taken to download the HTTP response

Actively monitor your mobile application’s back-end service availability

HTTP monitors are a great way to monitor the most important APIs used by your mobile apps. Usually you have some key back-end services for login, checkout, or search operations. These APIs are worth actively monitoring 24/7 to ensure the availability and functionality of your mobile apps around the globe. Now you can link HTTP monitors to mobile apps (as well as web and custom applications) via the Assign synthetic monitor to an application card.

After you have linked an HTTP monitor to a mobile  app, synthetic monitor availability is displayed directly on the mobile app details page, and Davis® automatically associates detected synthetic monitor problems with the linked app.

Push third-party synthetic data to Dynatrace—analyze all your monitoring data in a single location

We’ve also refreshed the third-party monitor details page in a similar way. Third-party monitors allow you to ingest third-party synthetic data into Dynatrace. 

For example, you can use third-party monitors to enrich Dynatrace data with synthetic results from a homegrown synthetic solution. You can even assign external synthetic data to the applications that you monitor with Dynatrace. As soon as they’re linked, Dynatrace augments its real user data with external synthetic data and correlates any detected problems. With this approach, you can analyze external synthetic data directly on your Dynatrace dashboards.

Third-party monitors are also a good way to perform synthetic DNS lookups, port checks, and pings, as my colleague Michael Lundstrom describes in his blog post. 

We’d love to hear your feedback!

As mentioned earlier, a lot of these improvements are based on your feedback. But we’re not done yet, and this is just the first iteration of the new page design. If you have feedback you’d like to share with us, please select the Give us feedback button that appears on each monitor details page. 

You can try out the new monitor details pages at any time. And for now, you can switch back and forth between the new and the old versions of the page.  

What’s next

For the HTTP monitor details page, these changes are only a first step toward providing you with even more insights. We’re working on capturing additional details, like response body and header details that will help you (and the Dynatrace Davis AI causation engine) to better understand HTTP monitor–related problems and ensure that all your APIs are 100% available and working at all times.

The post Revamped HTTP monitor detail pages to effortlessly monitor API endpoints and mobile back-end services appeared first on Dynatrace news.

Dynatrace OneAgent is great for monitoring the full stack. However, you can’t install OneAgents on every single type of device. There are certain situations when an agent based approach isn’t possible, such as with network or storage devices, or a very old OS. In those cases, what should you do if you want to be proactive and ensure that your infrastructure is always up and running?

You could of course create a custom device in Dynatrace and send data to it using our API or an ActiveGate extension. While this will give you a lot of information about the health of these components, sometimes a simple synthetic monitor is sufficient. Whether you need to make sure that your SQL database is listening on port 1433 even when there is no traffic, that your switch is responding to a ping or that your DNS server is up and running, the more devices you proactively monitor, the quicker you can react to unforeseen events.

Platform extensions

Heading up the Platform Extension Services team at Dynatrace, we’re the go-to team for anything that isn’t available out of the box. Whether you are looking to augment Davis® with additional metrics and events using our extensions framework, integrate Dynatrace with your CMDB or ticketing system, or add insight into unsupported technologies or frameworks using the OneAgent SDK or OpenKit, our global team has you covered.

In the past couple of years, the team has received several requests to provide synthetic monitoring for non-web-based protocols, such as ping, port checks, and DNS lookups. Using a combination of the ActiveGate extension framework and the Third-party Synthetic API, the extensions team has created a template that we use to quickly fulfill such requests.

Third-party synthetic monitors

Are you looking to monitor your infrastructure using one of our ready-made extensions, or would you like to draw on our experience and create your own synthetic monitors?

The Platform Extensions Services team is pleased to announce the open sourcing of our implementations for DNS lookups, port checks, and ping in GitHub.

To further simplify the integration of extensions with Dynatrace, as of Dynatrace version 1.198, we’re launching an Early Adopter program with the first version of a dedicated flow that makes it easy for you to find example extensions that can support your needs.

Get started with Dynatrace extensions

To get started, download and install one of the extensions by following the instructions on GitHub. Once that’s complete, you can create the synthetic monitors via the Custom extensions tab on the monitored technologies page.

Visualize your synthetic monitor data

Once you’ve filled in the information for your synthetic monitor, the captured monitoring data will be displayed on the monitor’s overview page. Now you can analyze the results, link the synthetic monitor to a Dynatrace monitored application, create dashboards with the data, and much more.

Easy and flexible infrastructure monitoring

In just a few simple steps, you’ve now expanded your infrastructure monitoring possibilities! Following this same approach, you can add as many synthetic monitors as you need. For example, querying a database, doing an LDAP lookup, performing a get/put to (S)FTP, checking if a file exists and much more. If you don’t have the time to create additional monitors based on our template, you can reach out to the Dynatrace Platform Extension Services team at extensions@dynatrace.com. We’ll be happy to assist you.

For more information on creating ActiveGate extensions, please see Introduction to ActiveGate extensions.

For further details, see Third-party synthetic API.

The post Easily monitor your entire infrastructure with Dynatrace Synthetic monitors appeared first on Dynatrace news.

In my role as DevOps and Autonomous Cloud Activist at Dynatrace, I get to talk to a lot of organizations and teams, and advise them on how to speed up delivery while also increasing the delivery in order to minimize the impact on operations. While optimizing delivery is very important, I haven’t focused enough on how Dynatrace helps IT Service Operation teams answer key questions they are faced with every day in their demanding job to keep Service Levels of their systems, services and applications within the defined agreements (SLAs).

In order to better understand what IT operations really need, and how Dynatrace can help modernize their tasks, I sat down with Stephan Dannewitz, DevOps Engineer at avodaq. While Stephan is as much into optimizing delivery as I am, he better understands the challenges and needs of IT-Service Operation teams from their own experience at avodaq.

We came up with list of four key questions, then answered and demoed in our recent webinar.

If you’re interested in the German version of the webinar feel free to watch it in our native tone😊

For those that like to read rather than watch a webinar, here I’ll give you a quick rundown of the four steps we covered, so you can start your modernization in areas where you feel Dynatrace can help your existing processes:

Step #1: Monitor your SLAs using Dynatrace Synthetic

Dynatrace Synthetic allows you check the availability and performance for your business-critical applications. This can be your external-facing website, internal business applications. or even your 3^rd party SaaS platforms such as Office 365 or Salesforce.

Stephan demoed how avodaq internally leverages Dynatrace Synthetic. SharePoint – part of Office 365 – is a critical business application for them. That’s why he setup Dynatrace Synthetic checks from the public available locations Frankfurt and Ohio as well as from their own Hamburg-based Data Center using Dynatrace Synthetic Private Locations. The Synthetic check constantly monitors if SharePoint is accessible, if login works, and if documents can be accessed with acceptable user experience:

In case Dynatrace alerts on a problem – whether this is a complete outage, slowness, or broken functionality – it provides all the details for quick root cause analysis, which leads to faster problem resolution. In the demo, Stephan showed the waterfall view highlighting issues in connectivity, bad HTTP requests or even JavaScript errors. The view also gives automated recommendations on how to optimize page load times:

Automation tip: These synthetic checks can also be created automatically through the Dynatrace API which allows your delivery and release teams to include the setup of these checks into your release process. This makes sure that every service or application you deploy is always automatically monitored with a synthetic check.

Step #2: Ensure user experience on business-critical apps with Dynatrace RUM

Dynatrace Real User Monitoring (RUM) allows you to monitor your real end-users (web, mobile, kiosks, cars, smart gadgets etc). This not only works for your custom developed applications, but also works for 3^rd party applications you host, e.g: SAP or even those that are hosted as a SaaS offering, such as Office 365 and Salesforce.

Stephan demoed RUM for both a custom developed application as well as for Office 365 where he logged on to SharePoint and navigated through some pages. The latter is done through Dynatrace’s SaaS Vendor RUM capability. For all scenarios Dynatrace not only captures page loads, clicks, swipes and form submissions. Thanks to Session Replay you can even see the full user journey in a 4k video like replay.

This is a great capability to have to understand where users are really struggling in their journey. In Stephan’s demo, he showed how problems that may or may not be directly visible to the end-user are captured by Dynatrace in the level of detail needed to fix issues. Such as the JavaScript error we detected when browsing through their Cary app below:

Deployment tip: There are multiple ways to enable Dynatrace RUM; installing the Dynatrace OneAgent on your hosting infrastructure, embedding the Dynatrace JavaScript agents in your HTML pages, or through the Dynatrace RUM browser extension. These options give you full flexibility.

Step 3: Automate operational tasks through Dynatrace AIOps

The advantage of Dynatrace’s Davis® AI, as compared to other AIOps solutions, is that thanks to the dependency data gathered by the OneAgent we can notify your teams about problems, their impact and the actual root cause. This information can be used to notify only those teams that should work on a problem and don’t immediately engage in a company wide war room. The other benefit of this level of detail and the automation capabilities is to automate remediation tasks that would otherwise need manual intervention.

Stephan did a great job in his demo, where he simulated a log spam of an application leading to a full disk which subsequently would impact other applications running on the same infrastructure. Thanks to Dynatrace AIOps this problem was detected automatically and routed to a remediation action Stephan implemented using AWS Lambda.

Besides Lambda, Dynatrace provides integrations into ServiceNow, xMatters, PagerDuty, JIRA, Keptn and many other tools to trigger incident workflows. In this case the Lambda function analyzed the details of the Dynatrace problem and – in case the root cause was a log spam from an app – cleared that log directory to bring the host back to a healthy state:

The detailed monitoring dashboards for example, disk utilization also show the positive impact the auto-remediation action had on fixing this issue:

Infrastructure Monitoring tip: Dynatrace OneAgent not only monitors your on-premise physical hardware, but it can also monitor any environment on-premise or in the cloud as well as cloud native platforms such as k8s, OpenShift or serverless environments. During Stephan’s demo, he walked us through the diverse landscape of infrastructure their IT Operation team is responsible for – including k8s clusters as you can see in the below screenshot:

Step #4: Extend monitoring beyond Dynatrace OneAgent

While Dynatrace’s OneAgent has the broadest coverage of technology in the industry, there are always situations where OneAgent cannot be used, such as you won’t be able to install a OneAgent on your coffee machine – unless of course – it runs Linux or a lightweight k8s!

Stephan did a great job walking us through the monitoring extension options of Dynatrace through either Plugins (OneAgent and Active Gate) or through the Dynatrace REST API. He showed us how he used an extension to monitor UDP endpoints as well as SNMP:

Extension tip: If you want to learn more about extending Dynatrace, or get an overview of available extensions, check out the Dynatrace Hub or my Performance Clinic on Extending Dynatrace with Custom Plugins.

Summary & next steps

I first want to start with saying thank you to Stephan who gave me the opportunity to learn more about the relevant use cases and challenges in IT Operations. It was fantastic to see how avodaq has implemented Dynatrace in their environment to modernize their IT Service Operations using Dynatrace. At the end of the webinar I must conclude that all questions were answered and supported by live demos:

If you want to watch the webinar you can either get the on-demand version in English or German:

• Modernize your IT-Service Operations with the Dynatrace Software Intelligence platform (English)
• Modernisieren Sie Ihre IT-Service-Operations mit Dynatrace (Deutsch)

Avodaq is not only a Dynatrace customer. As mentioned in the beginning, avodaq is also a Dynatrace partner. If you have any needs of modernizing your IT Service Operations, modernize your delivery or migrate to the cloud feel free to reach out to them.

The post 4 steps to modernize your IT service operations with Dynatrace appeared first on Dynatrace news.

With today’s high expectations for the speed and availability of applications, you need a deep understanding of real user experiences to make the best business decisions. Dynatrace Digital Experience Monitoring, as part of the Dynatrace Software Intelligence Platform, connects front-end monitoring and the outside-in user perspective with application performance to understand the impact of performance issues across your full stack on user experience and business outcomes. Dynatrace Synthetic Monitoring ensures that your application is available and performs well from anywhere in the world to meet your SLAs.

With synthetic HTTP monitors, you can now also cover all endpoints that don’t directly expose a front end. These can be APIs used by your mobile apps or health-check endpoints provided by microservices. HTTP monitors are lightweight and a perfect fit for monitoring coverage for everything delivered via HTTP/S.

Get an outside-in view of all your applications with Dynatrace Synthetic Monitoring

Dynatrace Synthetic Monitoring helps you quickly verify if your application is delivering the expected end user experience by offering an outside-in view of all your applications and services, independent of real traffic. Synthetic monitors are executed at defined intervals from various locations to catch regional issues from a clean-room environment so each execution has exactly the same conditions. Synthetic Monitoring helps you cover use cases such as:

• Reporting SLA/SLOs internally as well as externally.
• Being alerted as soon as a critical endpoint/transaction is unavailable.
• Receiving immediate insights on performance changes from a clean-room environment.
• Detecting regional issues by leveraging private and public Synthetic locations.

Previously, you had to deploy a private Synthetic location in order to use HTTP monitors. We’re now proud to announce the first set of fully integrated, worldwide, multi-cloud, and high-availability public locations for HTTP monitoring.

Directly create HTTP monitors via the Dynatrace web UI or API

The newly added public locations are fully managed by Dynatrace and allow you to get started with HTTP monitors right away. This means you can now directly create HTTP monitors via the Dynatrace web UI or the API without any prerequisites—you don’t have to worry about maintaining Synthetic locations yourself. Here is the first batch of 15 public locations for HTTP monitoring:

• Chicago (Azure)​, Virginia (Azure), N. Virginia (AWS)​, N. California (AWS), San Jose (Azure), Texas (Azure), Ohio (AWS), Toronto (Azure)​, London (AWS), London (Azure), Frankfurt (AWS)​, Sydney (AWS), ​Hong Kong (Azure), Tokyo (Azure), Sao Paulo (AWS)

We’ll expand the number of public HTTP locations in the upcoming weeks to fully match our public location offering for browser monitors, which currently stands at 72 locations. Please ensure that your endpoints are available publicly or exclude the location IP addresses from your firewall rules. HTTP monitor locations use the same set of IP addresses as the browser monitoring locations. And, as before, you can always use private Synthetic locations that are located within your network infrastructure to measure complex internal applications and APIs.

What makes Dynatrace HTTP monitors unique?

All features previously available for private HTTP monitors are also available from the public locations. Here are some of the highlights that make HTTP monitors on the Dynatrace platform unique.

Full integration into the Dynatrace platform

HTTP monitors are fully integrated into Dynatrace and provide you with an additional layer of visibility into your applications and services. Dynatrace automatically detects if an HTTP monitor is running against a service that is already monitored by OneAgent and links them together. With just one click, you can drill down to the service, which is filtered for requests coming from the HTTP monitor.

This allows you to compare synthetic traffic to real traffic, look at service flow to understand all involved dependencies, and even drill down to the code level to understand failures and root causes.

Automated SLA/SLO monitoring using the HTTP monitoring API

HTTP monitors are not only great for monitoring API endpoints. They provide a complete API that allows you to automate SLA monitoring and SLO monitoring. You can create, modify and delete HTTP monitors using the API. Automating the process of setting up HTTP monitors can make your Ops life a lot easier, as Andreas Grabner explains in his recent blog post.

Additionally, you can also query all metrics captured by an HTTP monitor to build reports and present data to various stakeholders.

Execution of complex transactions via scripting

With Dynatrace HTTP monitors, you can chain multiple requests (GET, POST, PUT, DELETE, HEAD, PATCH, OPTIONS) together. You have full control over each request and can configure HTTP headers, valid status codes, as well response validation. Additionally, you have the option to add pre- and post-execution scripts. These enable you to add custom logic between HTTP monitor requests to do things like parsing the response, modifying the request URL, or skipping requests under certain conditions. To learn more about and pre- and post-execution scripts (with examples), check out Dynatrace Help.

But wait, there’s more!

• Support for OAuth 2.0, NTLM, and basic authentication
• Storage and management of credentials via the Synthetic Monitoring credential vault
• Prebuilt methods for encoding, generation of random values, and date formatting for pre-execution scripts
• Easy configuration via the UI or in script mode
• Full integration into the Dynatrace platform (custom charts, API, custom events, integration with Slack/PagerDuty, etc.)

How to get started

Creating a new HTTP monitor is easy—simply select Synthetic from the Dynatrace navigation menu, then select Create a synthetic monitor > Create an HTTP monitor.

For a simple monitor, just provide a name and the URL for the first request. Then Select frequency and locations from the new public HTTP monitoring locations. After you’ve created the monitor, it will be scheduled to run from the selected locations, and the first results will show up in the UI.

HTTP monitors vs. browser monitors

Dynatrace offers both HTTP and brower monitors. It’s important to understand the differences between these kinds of synthetic monitors to better decide when to use them.

HTTP monitors execute single HTTP/S requests. You have full control over each request and can also chain them together to solve more complex use cases. You can think of them as similar to executing a curl command (with no browser involved): curl https://example.com.

Browser monitors, on the other hand, use a real browser (Chrome) to monitor the availability of a web application or the most important user-facing workflows (clickpaths) through your application. A browser monitor also begins with a single (GET) request after you enter a URL into the address bar. However, a lot more happens after that. Modern applications make hundreds of requests and also make heavy use of JavaScript.

Summary and what’s next

HTTP monitors are great for monitoring uptime, performance, as well as your defined SLA/SLOs. With the new public locations for HTTP monitors, Dynatrace provides global coverage as well as fully managed and highly available locations. These new locations allow you to get started with HTTP monitoring right away without the need to deploy any extra component.

We’re also already busy working on the next improvements, such as access to execution details like the response and HTTP headers or logs, an updated UI for the HTTP monitor details page based on your feedback, and linking HTTP monitors to custom and mobile applications. So stay tuned!

Related blog posts:

• Synthetic HTTP monitors for private locations are now GA
• Dynatrace HTTP monitors go multi-request, leaving no API unmonitored!
• Automated scripted API monitoring with HTTP monitors

The post Easy SLA and SLO reporting for all your API endpoints with public synthetic HTTP monitors appeared first on Dynatrace news.

Private Synthetic locations allow you to monitor internal applications from inside your private network infrastructure. In such a setup, you often need to deal with some kind of proxy configuration.

To handle complex proxy configurations, as of Dynatrace and ActiveGate versions 1.183, private browser monitors now also support Proxy Auto-Configuration (PAC) files.

What is a PAC file?

A Proxy Auto-Configuration (PAC) file is a JavaScript function that determines whether web browser requests (HTTP, HTTPS, and FTP) go directly to the destination or are forwarded to a web proxy server (from developer.mozilla.org).

How to provide a PAC file to your browser monitors

Currently you can provide PAC files via the script mode for single-URL browser monitors and browser clickpaths.

• For new monitors, switch from Visual mode to Script mode.
• For existing monitors, select Edit to open settings and select Recorded clickpath for clickpaths. Then switch to Script mode. For existing single-URL browser monitors, select Monitor script.

You’ll need to add the following in the configuration object of the JSON file:
"proxy": {
"pacUrl": "https://www.example.com/test.pac"
}

where pacUrl points to your hosted PAC file.

Important to know

• PAC file configuration is only considered for private synthetic locations, not public locations.
• PAC file configuration takes place on a per-monitor level.
• If a PAC file is specified, it overrides the proxy settings specified at the ActiveGate level for communication with the tested resource.
• The PAC file must be served via HTTP/S.

Want to configure a proxy for Dynatrace private synthetic monitoring?

You’ll find all the details for doing this in Dynatrace Help.

The post Easily handle proxy configurations in your private browser monitors with Proxy Auto-Configuration (PAC) file support appeared first on Dynatrace news.

Real User Monitoring (RUM) is one of the building blocks of Dynatrace Digital Experience Monitoring and the only way to monitor your users’ experience. Another building block is Synthetic Monitoring, which adds two additional and important use cases that are hard to cover with RUM.

• Availability monitoring—Is my application working 24 x 7?
• Performance baseline monitoring—Did my performance baseline change (based on a clean-room environment)?

When talking to Dynatrace customers who only leverage RUM, we find they usually agree that Synthetic monitoring adds tremendous value to RUM. However, the next question is often, “How do I get started with Synthetic monitoring”?

24×7 monitoring from three locations with a single click

With the latest release of Dynatrace, we’ve made it super easy to start monitoring your application’s availability using synthetic monitors. You’ll see an extra card (Monitor your application’s availability) on the application overview page. Just select Monitor availability and you‘re done!

The main entry points of your application are now actively monitored 24×7 from three locations worldwide.

Customize automatically created monitors, add new locations, and more

When you select Monitor availability, Dynatrace takes the top three entry actions of your application and automatically creates synthetic monitors for them in the background. An entry action is the first action of a user session. By selecting the top three entry actions, your users’ most frequent entry points to your application are covered.

The generated monitors are configured to run from three automatically selected locations to provide geographical coverage and are executed every 15 minutes. The image below shows the Availability card on the application overview page after you have opted to automatically configure the three synthetic monitors.

Monitoring the top three entry actions from 3 locations every 15 minutes is a great starting point for synthetic monitoring, and you can always mix this up to your taste. Instead of choosing Monitor availability, simply expand the card by selecting Manual setup and choose the entry action you want to create a monitor for. You can also always further configure automatically created monitors to add additional locations or change the frequency.

Prerequisites

The Availability card (see example above) only shows up on the application overview page if the following conditions are met:

• The user has change monitoring permission for the environment.
• The application has at least one entry action.
• There are no synthetic monitors configured.

What’s next?

We’re already working on some improvements to this feature. In the upcoming versions, Dynatrace will automatically pick synthetic locations based on the top geographic locations that your real users access Dynatrace from. We’ll also automatically check if an application is only accessible internally and will choose the most appropriate locations accordingly.

The post Start monitoring your web application’s availability with one click appeared first on Dynatrace news.

Kubernetes automatically validates the health of your pods within your k8s cluster, by continuously evaluating the health end-points (livenessProbe and readinessProbe) of your deployed services. While this is a key capability, as k8s will restart pods that are unhealthy, it doesn’t guarantee that services exposed via Ingress are also available and responding within your SLAs to those that rely on these services: your end-users or service consumers outside k8s that call your services.

Christian Heckelmann, Senior Systems Engineer at ERT, inspired me to write this blog when he brought up this topic in a conversation a couple of weeks back. He said that any mistake with Ingress configuration, Load Balancers, or any other network component that sits between the consumer and the actual service running in k8s can lead to SLA violations while Kubernetes internal health checks still report that everything is green. Not only did Christian bring this to my attention – he also came up with two automated solutions to fix this problem!

Option 1: Automate external SLA and SLO checks through Delivery Pipeline

To tackle this problem Christian experimented with automatically creating Dynatrace Synthetic Tests as part of his GitLab Pipelines. You can find his sample project on his Dynatrace Pipeline GitLab repo and explore the individual Dynatrace extensions in the ci-includes subfolder:

Here’s what Christian is doing in the individual phases of the pipeline run:

Deploy Phase:

1. Deploy Application: in this case mostly to EKS but could also be any non-k8s systems.
2. Create Deployment Event: the Dynatrace Events API is used to push a deployment event to Dynatrace.
3. Create Synthetic Test: Query the readiness endpoint and ingress of the deployed service, then create a Dynatrace Synthetic Test through the Dynatrace Synthetic API. This automatically tests this endpoint from various external locations.

After he is calling dt_create_synthetic the newly created synthetic test shows up in Dynatrace and gets executed on the defined scheduled to validate the SLAs of the deployed service:

After the deployment phase is done it’s time to validate the deployment, by doing the following:

Verify phase:

1. Get problems: Pulls any identified problems through the Dynatrace Problems API and reports it back to the pipeline.
2. Get performance: User queries some metrics from the Dynatrace Timeseries API that are important to observe.
3. Keptn Quality Gate: User calls the Keptn Quality Gate API to validate SLOs.

If there’s a problem accessing the service, such as a high failure rate or slow response, then Dynatrace automatically opens a problem like:

In the event a problem was detected, Christian pulls the problem details back to the pipeline in the Verify Phase. His dt_get_problems script uses the Dynatrace Problem API to query whether there are any open problems detected by the test created earlier. If there are, he reports this back to his pipeline.

Option 2: Automate external SLA checks through Kubernetes Operator

While the pipeline approach works very well, it only covers changes which are deployed through pipelines that include the Dynatrace extensions he scripted. It wouldn’t cover deployments or configuration changes done by other tools or those done manually by him or his colleagues.

To enable automated SLA monitoring from outside the k8s cluster for deployed services exposed via an Ingress, Christian turned to the Operator Framework. He developed the Synop Operator that automates the creation of the Dynatrace Synthetic Tests with every deployment of an Ingress – no matter who or which tool is deploying or changing that Ingress. The Synop Operator picks up annotations from the Ingress and then:

1. Decides whether the ingress should be monitored – synop/create: “true”.
2. Configures a Dynatrace Synthetic Monitor for that exposed endpoint: synop/endpoint.
3. Additional configures locations, frequency and tags through defined through optional k8s annotations.

For full documentation check out the Synop Operator GitLab Repo. The video below which shows:

1. Installing the Synop Operator.
2. Deploying a new application including ingress.
3. Operator automatically creates the Dynatrace Synthetic Test.

As part of the video above Christian shows the log output of his Synop Operator showing that a new Synthetic Test got created when the Operator was notified about a new Ingress configuration:

Just as before, the new test immediately shows up in Dynatrace and from now on validates SLA of that Ingress endpoint:

This is a great use case for an Operator, as this enables everyone who defines Ingress in k8s to automatically get SLA Ingress Monitoring with Dynatrace. With the addition of tags you can also leverage Dynatrace Problem Notifications with Alerting Profiles to send alerts to the right teams, e.g: via Slack.

Making Ops-life easier

Thanks to Christian for implementing these two solutions that make Ops-Life Easier as you so nicely put it in the description of your Synop Operator.

Very glad you’re contributing to the NoOps / ACM (Autonomous Cloud Management) community so that more can benefit from these automation solutions. To hear more from Christian and his expereince, make sure you visit our Breakout Session at Dynatrace’s Perform Las Vegas 2020 conference in February. Christian is co-presenting in my Release Better Software Faster Track on the topic Build resiliency into your continuous delivery pipeline with AI and automation. If you are reading this and if you are attending Perform make sure to meet Christian and give him your direct feedback on his work.

The post Making Ops Life Easier: Automating SLA Monitoring for Deployed Services on Kubernetes appeared first on Dynatrace news.

With the release of Dynatrace 1.178, we’ve added a new type of content validation capability for synthetic browser and clickpath monitors. The contains visible text option mimics the Find (Ctrl+F/Cmd+F) functionality of a web browser.

• Contains visible text is the new default option for content validation
• The old default option  contains text was renamed to contains text on DOM or any resource

How the new validation approach differs 

The previous default content validation approach (contains text in DOM or any resource), validates against all HTML/CSS/JavaScript included in page source code. This means that, for example, validation is successful even if a validation string is only part of a CSS file and not visible on the page.

With the new default validation approach (contains visible text), validation is only performed against visible text on the selected page. This mimics the Find (Ctrl+F/Cmd+F) functionality of a browser and results in more accurate validation.

Technical details

The new option validates against the content of document.body.innerText (https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/innerText) for each frame of the target window/tab. Validation is case-insensitive.

When the Evaluate as regular expression option is used, the string is interpreted as regex, which is case-sensitive.

Why this change was made

We received feedback from customers stating that the new validation functionality is what customers had long expected the behavior of contains text validation should be. This change will, therefore, make contains text content validation more predictable and accurate by avoiding false positives.

What’s next

We’re constantly improving the quality of our synthetic offering (for example, read about the latest changes to the synthetic recorder) and we have many new enhancements in the pipeline:

• Automated scripted API monitoring with HTTP monitors
• Credential Vault
• Additional public locations

…and much more.

The post Improved content validation for Synthetic browser and clickpath monitors appeared first on Dynatrace news.

As microservices and automation continue to drive API usage, most organizations have either already introduced, or plan to introduce, an API testing process.

With Dynatrace Synthetic you can easily create API tests with synthetic monitors. Now we’re making it easier for you to test APIs that are secured by OAuth 2.0!

What is OAuth?

OAuth is an open standard for access delegation that is currently used by Amazon, Google, Microsoft, PayPal, Facebook, Twitter, and other companies.

Note that the word “authentication” hasn’t yet been mentioned. And why are we referring to OAuth while discussing APIs?

By definition RESTful APIs should be stateless, meaning that each request should be individually validated for authentication/authorization by the receiving server.

This is the key. OAuth provides an authorization method (not authentication) for such requests.

This is where OAuth shines. Because API security is a primary concern these days, OAuth is listed as one of the recommended authorization methods for API requests.

How to monitor an OAuth protected API with Dynatrace Synthetic

To monitor an API that’s secured with OAuth 2.0, the monitor needs to execute a request that authorizes with an OAuth 2.0 instance. You can now do this by creating a pre-populated request directly in the Dynatrace web UI. Just fill in the necessary information in the OAuth 2.0 authorization request.

Once you’ve created an OAuth 2.0 authorization request, you can use the request in future requests by selecting OAuth from the list, which will add the required pre-execution script.

What you need to get started

• A synthetic monitoring location that’s based on ActiveGate version 1.173+

What’s next

Stay tuned for more Synthetic news including:

• Synthetic credentials vault
• New synthetic public locations
• Public locations provided by a new cloud vendor

…and much more!

The post Monitor your OAuth 2.0 protected APIs with Dynatrace Synthetic appeared first on Dynatrace news.

We’re happy to announce the launch of Dynatrace Synthetic private browser monitors!

We continue to grow our public synthetic monitoring locations, but customers using Dynatrace Synthetic still need to monitor the performance and availability of internal web applications. One of the most-requested features has been the ability to run synthetic browser monitors on premise.

New capabilities with no learning curve!

If you have been using Synthetic already you know how easy it is to set up browser monitors. Now with private locations supporting browser monitoring, it’s as easy as selecting appropriate locations from the list during monitor creation/edition.

Monitoring corporate applications has never been so easy!

With private synthetic browser monitors, we bring the testing capabilities available in public locations right into your own environment. Now, you’ll be able to:

• Measure internal web page performance and availability with single-URL monitors.
• Measure complex internal applications with clickpath monitors.
• Measure external resources with synthetic browser monitors from internal locations.

Whatever internal tools you are using to drive your business, for example, Atlassian Jira or Confluence, SAP Concur, Salesforce, Workday, MS Office 365 and every internal web application—these tools are crucial for your success. So far Dynatrace has allowed you to do Real User Monitoring (RUM) for these applications. Now whether it’s making sure that branch offices accessibility to the internal applications has been affected or if there are issues with SaaS tooling you are using in your business, with private browser monitors you can have these use cases covered with Dynatrace Synthetic as well.

In Dynatrace we have a mantra of so-called dogfooding so using our own product ourselves whenever and wherever possible. As soon as the private browser monitors became available, we had an idea to monitor the local tooling for copyright management. It took us no time and has already payed off, detecting issues during the weekend when nobody in our offices was using the tested apps.

Private synthetic browser monitors use the same ActiveGate technology that our private synthetic HTTP monitors are based on, providing the following benefits:

• Automatic failover support
• Scalability and load balancing
• Improved scheduling by grouping machines together in a single location
• Ability to mix and match performance tests with availability and API tests

How do I set up private browser monitoring?

Install a private browser monitoring-enabled ActiveGate (see the ActiveGate requirements below) and add it to an existing private location or spin up a new one to make that location capable of executing browser monitors as well!

That’s it; you can then assign your browser monitors to the private location.

What are the ActiveGate requirements?

Each private synthetic location consists of at least one ActiveGate.

To successfully execute browser monitors from a private location, the ActiveGate requirements are:

• Environmental ActiveGate 1.169+
• ActiveGate OS: Ubuntu Server 16.04 LTS, RHEL server 7, CentOS server 7

Currently, the new synthetic-enabled ActiveGates are, by default, Synthetic exclusive, meaning that these ActiveGates only perform Synthetic assignments and not other typical ActiveGate tasks.

Go to Deploy Dynatrace and select to install a synthetic-enabled ActiveGate to start synthetic monitoring from private locations! For detailed prerequisites, hardware requirements, and installation guidelines, see our help page for browser monitors in private locations.

I have a private synthetic location—which tests should I deploy?

Dynatrace Synthetic has been supporting private locations for a while now, and you might already be running synthetic HTTP monitors on your private locations. If you do, you already know that these are perfect for:

• API testing (both internal and external)
• Internal application availability monitoring
• REST API testing for mobile app monitoring

Browser monitors provide you with a way to simulate real user situations with a synthetic test based on a web browser-based experience. You can run both single-URL browser monitors or browser clickpaths that have multiple actions and URLs from your private locations. Your browser monitor can:

• Download all the web page resources and objects.
• Execute client-side JavaScript.
• Measure the performance of complete web pages.
• Display a waterfall graph for each monitored URL and action.
• Test your internal applications.
• Run from wherever you decide to deploy your private synthetic monitoring locations.

FAQs

Q: I already have a private synthetic monitoring location I’ve been using with my private synthetic HTTP monitors. Can I use it for browser monitors as well?

A: Yes, of course. Although, the upgrade process involves reinstallation of the ActiveGates that make this location or adding new ones enabled for synthetic monitoring. For more information, see the installation instructions.

Q: I want to share my location across multiple tenants—how do I do it?

A: While currently not supported, this feature is already planned and will be available for Dynatrace Synthetic with Cluster ActiveGate support.

Q: I already have a lot of ActiveGates, though none of them are Environment ActiveGates. Can I use these?

A: Currently, private synthetic locations have to be based on the Environment ActiveGates. With future releases, we want to allow the use of Cluster ActiveGates for private locations on Dynatrace Managed.

Q: Can I use synthetic-enabled ActiveGates for Dynatrace features than Synthetic Monitoring?

For now, the ActiveGates for private synthetic locations must be installed with parameters making them exclusive to Synthetic Monitoring. This means that they cannot act as typical ActiveGates. While reusing existing ActiveGates will be possible in the future, it is not currently supported.

Q: Is there a plan to support more operating systems?

A: We currently support Ubuntu Server 16.04 LTS, Red Hat server 7 and CentOS server 7 for the execution of private browser monitors; Windows Server 2016 support is coming soon as well. Support for newer versions of these systems will be introduced as well.

Q: Do I need a special network configuration, opening non-standard ports and/or allowing access to certain locations?

A: It all depends on your internal network architecture. Nothing has changed in this matter from the private synthetic monitoring locations used for private HTTP monitors. You need to ensure that the ActiveGates that make up your private synthetic monitoring location have access to the monitored assets and that they can communicate with the Dynatrace cluster.

The post Availability monitoring with synthetic browser monitors from within your corporate network appeared first on Dynatrace news.

Synthetic monitoring is typically used for service level and availably monitoring of your critical websites, pages and user journeys. That was also the initial use case for a Dynatrace customer in a large, US-based insurance company, as he explained to me in an email he recently sent me. “Our company utilizes Dynatrace Synthetic Monitors to ensure core applications are up and running both for our staff and our insured customers. These Synthetics monitors do a fabulous job of testing out site, logging in, provide availability metrics for management and waterfall analysis of each test and action, all with the ability of alerting us when availability is compromised and or the user is experiencing degradation. This is a very powerful feature that helps us provide that exceptional customer experience that all companies strive for.”

He continued: “We wanted to take this idea to the next level and not just only test and collect data on our customer experiences, but why not on our industry competitors. Well, we did just that! I personally use two insurance providers that are competition for my company. I set up two separate Synthetic Monitors pointing to the login pages of our two main competitors. I supplied my credentials to Dynatrace and ensured that these two new Synthetic Monitors were identical to our current monitor. (Locations and Frequency)”

He concluded: “Dynatrace has allowed us to synthetically test our competitors whenever we want to ensure that we continue to provide that top-notch customer experience that all customers expect. And in the event that my company fails to outperform a competitor, we now have that Waterfall Analysis that App Dev and the Web Developers can analyze to provide a better experience while giving staff that critical insight and ideas of how these customer pages can load based off of our competitors.”

Awesome use cases! Now – let me show you how the customer is actually doing all of this with Dynatrace, so that you can replicate this for your business-critical websites!

Step #1: Monitoring your own key end user scenarios

If haven’t used Dynatrace Synthetic yet, I suggest you do so. If you don’t have a Dynatrace tenant, you can simply sign up for the 15 day SaaS-based trial which also includes Dynatrace Synthetics.

As the customer explained in his email, he recorded a browser click path test that is first loading this company’s website and then login. He then selected to run this test from two of our synthetic test locations, which resemble key geographical regions for their business. The following screenshot shows how Dynatrace visualizes the collected synthetic data, how it gives you screenshot visualization of every step, highlights top findings and allows you to drill into the details of every test execution and step:

Tip: To learn more about locations, simulated browsers or bandwidth simulation, check out the documentation on Configure a browser monitor. And if your websites might not be accessible from the internet, you can also look at our Browser monitors in private location capability.

Step #2: Optimizing your own Page Load Times

Just as Dynatrace Real User Monitoring (RUM) does for your real end users accessing your web & mobile applications, Dynatrace Synthetic gives the same level of waterfall analysis for the synthetic test executions. This company uses this level of detail to optimize their web page performance on a continuous basis. The following screenshot shows the level of detail their web developers get. It is the same detailed information they receive from the browser built-in diagnostics tools – but in this case it comes from the synthetic test executions from the different geographical regions. A great way to learn how pages & resources load differently from different regions, different browsers, different bandwidths:

Tip: Hover the mouse over the individual resources in the waterfall to access all captured W3C Resource & Navigation Timings. This gives you good insights into DNS, connection time or sizing issues of these resources.

Step #3: Setup Synthetic Monitors for your Competition

As the customer explained, he was setting up similar synthetic tests for their 2 main competitors. They are not running these tests all the time, but run them from time-to-time to make sure they are not falling behind the user experience delivered by their two closest competitors.

Tip: You can define multiple Synthetic Tests and can set them active or inactive. This is what the customer is doing. They are running the Synthetic test against their own website 24/7 as they also leverage the automatic alerting in case there is an outage or a performance degradation. The tests against their competitors’ sites are executed less frequent.

Step #4: Analyze and learn from your competition

As every synthetic test provides full waterfall analysis, the web developers at a large US-based insurance provider can also learn from their competitors engineers. Simply analyze their page structures, how they load their JavaScript files or images, which CDNs they are using …

Step #5: Celebrate your Wins!

If the continuous effort to optimize page load times, page sizes, availability … leads to outperforming the competition, it is time to celebrate! The below screenshot is an example of what the customer sends to him team when Dynatrace tells them that their critical pages critical pages (such as login), are clearly faster than their main competitors:

Now its time for you to compare yourself!

A big thank you goes to this customer, who keeps feeding me with these great use cases and stories. Make sure to also check out the previous story he told me around Modern Windows Workstation Monitoring with Dynatrace.

I hope this blog got you curious about how you compare against your competition. As you could see, Dynatrace Synthetic makes it really easy. Start today by signing up for your Dynatrace Trial, setting up your first synthetic tests, optimize your own page and then continuously compare against your competitors.

The post Staying ahead of your competition with Dynatrace Synthetics appeared first on Dynatrace news.

HTTP cookies are an essential part of the web. Although modern alternatives for storing state information on the client side exist (for example, Web storage API), cookies are still widely used for session management, personalization, and analysis of user behavior.

One of the main use cases of synthetic monitoring is the monitoring of a performance baseline. In order to generate a stable baseline, it’s crucial that every synthetic execution be based on the same “clean room” state. Especially with modern, custom web experiences, you need to make sure you’re monitoring the same state in order to compare “apples to apples.”

Easily set cookies to simulate application states

Consider an A/B test that’s triggered randomly for a certain percentage of users. To generate meaningful synthetic baselines in such scenarios, Dynatrace now allows you to set cookies to force one or other state.

The new Set cookies option allows you to:

• Set cookies on a monitor level or as a separate event.
• In addition to the cookie name and value, you can specify the domain and path the cookie is set for.

How to set cookies for browser monitors and clickpaths

You can Set cookies in the Additional options section while creating a single-URL browser monitor or multi-step browser clickpath (Synthetic > Create a synthetic monitor > Create a browser monitor). You can also set cookies while editing an existing monitor. The cookies set in Additional options during monitor creation are valid for the entire monitor execution. If you want to set cookies only for a specific portion of your clickpath, you can use the Cookie event.

In both cases, you must define the cookie name, value, and the domain the cookie is to be applied to. Optionally, you can specify the specific path the cookie should be sent to.

When you specify cookies during monitor creation, they are already set when you begin recording your clickpath. They are valid for local playback as well as for every monitor execution.

Simulate application state

Use the new option to set cookies to force a specific application state (as in the A/B tests mentioned above that are triggered randomly for a percentage of users) and start monitoring and analyzing the performance baseline with browser monitors.

We’ve also recently introduced another Additional option during monitor creation—the ability to block specific requests during monitor execution. This option can also be set/edited following monitor creation.

The post Easily create synthetic monitors for personalized web offerings with the new Set cookies option appeared first on Dynatrace news.

Dynatrace offers powerful and fully integrated synthetic monitoring capabilities out-of-the-box. With synthetic monitors, you can monitor application availability and complex business-critical workflows effortlessly with a real browser from locations across the world. You can also synthetically monitor your APIs quite easily with HTTP monitors.

But maybe you already have a synthetic monitoring solution in your toolkit; don’t worry, Dynatrace has you covered as well. Dynatrace now offers an API that enables you to push external synthetic test results. This allows you to integrate third-party or homegrown synthetic solutions that can enrich your Dynatrace monitoring data.

Why send synthetic data to Dynatrace?

You can analyze all your monitoring data in a single location. You can even assign external synthetic data to the applications you monitor with Dynatrace. As soon as they’re linked, Dynatrace augments its real user data with synthetic data and correlates detected problems. With this approach, you can analyze external synthetic data directly on your Dynatrace dashboards.

What types of data can be sent to Dynatrace?

Some of the high-level items you can push into Dynatrace via the API are listed below. For details, look at the Dynatrace API Explorer or Dynatrace Help.

• Tests
  • Locations (results by location)
  • Results at the test and step level (Availability/Response time)
• Events
  • Outage and slowdown events
• General
  • Name and icon of external synthetic engine or tool sending the data (For your own scripts, you can enter any label; for external tools such as Pingdom, you can use the tool name and icon.)

Let’s get started

To begin, you’ll need to create an API token with adequate access scope so that you can send external synthetic data to Dynatrace.

1. Select Settings from the navigation menu.
2. Expand the Integration section and select Dynatrace API.
3. Click the link to the Dynatrace API Explorer at the top of the page.
4. Click the Generate token button and make sure the option Create and configure synthetic monitors is enabled.

Head over to GitHub where you’ll find a simple Python example to get you started.

How are external synthetic data sources displayed in Dynatrace?

The POST external events to Dynatrace call and the POST external tests to Dynatrace call automatically push external synthetic data to Dynatrace. External synthetic data sources appear next to your Dynatrace synthetic monitors. To access them, select Synthetic from the navigation menu. You can tag your external synthetic data to easily identify and filter for external synthetic data by the tags. The screenshots below show external synthetic test data and event data in Dynatrace, respectively.

Pricing and feedback

Update: As of May 2020, the external synthetic/third-party synthetic API is billed via DEM units; see DEM monitoring consumption for details.

If you have any questions, feedback, or would like to partner with Dynatrace for an integration, we’d love to hear from you. For general details about the extensive Dynatrace API, see Dynatrace API Help.

The post Integrate external synthetic data with Dynatrace via API appeared first on Dynatrace news.