The Synthetic experience on the latest Dynatrace platform is complete with the transition of browser monitors. Once activated, Dynatrace runs browser monitors using the newest RUM JavaScript, delivering more accurate simulations and tighter alignment with Real User Monitoring. The updated experience makes Synthetic more powerful and easier to act on, from rich waterfall analysis to trend visualization and automation with execution details stored as events in Grail® and available via Dynatrace Query Language (DQL).

Deeper visibility and smarter analysis with Synthetic on the latest Dynatrace platform

•  Waterfall chart report in the latest Dynatrace experience
  The transition of Synthetic to the 3rd generation of Dynatrace is complete: All Synthetic capabilities, including the Requests waterfall chart powered with data from the latest  RUM JavaScript, are now available directly in the latest Dynatrace experience.
• Explore synthetic events with DQL
  Use DQL to run ad‑hoc queries on synthetic event data to filter, aggregate, and correlate results with other telemetry for advanced troubleshooting and performance optimization.

How to turn on browser monitors and fully benefit from the latest Dynatrace capabilities

Turning on browser monitors fully in the latest Dynatrace is quick and flexible; you can flip it on for your whole environment or opt in per monitor to run a phased rollout.

• Go to Settings > Synthetic Monitoring > New Browser Monitors Experience.
• Set the Scope behavior: Turning on browser monitors at the environment level is the default; individual monitors can override the default so teams can test or migrate gradually.

Enhanced Requests waterfall chart

The new Requests waterfall gives you real troubleshooting power. It moves analysis from vague timing numbers to resource‑level visibility you can act on.

• See every resource that loaded with the page (type, name, and exact load duration in ms), so you can spot the single slow asset that drags down performance and, by extension, the user experience across the whole page.
• Know what triggered each request—the resource initiator (fetch, script, link, XHR, etc.)—to distinguish third‑party scripts, lazy loads, or XHRs that unexpectedly spike load time
• Identify render‑blocking and timing boundaries (start/end times) to separate network latency from rendering or scripting costs. This is critical when deciding whether to optimize CDN, defer scripts, or rework code
• Instantly spot failing resources—errors are flagged directly in the waterfall, so you don’t have to cross‑check multiple views to find missing or broken assets
• Understand retries and execution attempts—if automatic retry on error is turned on, the executions table and waterfall surface retry attempts (with icons), giving you the full story for flaky tests or transient network issues
• Delivered natively in the Latest Dynatrace experience. You get the enhanced Requests waterfall and resource‑level analysis without having to fall back to Synthetic Classic for detailed reporting

In short, the waterfall turns a monitor execution into a forensic timeline, resource by resource, initiator by initiator, so teams can pinpoint root causes faster and prioritize the fixes that deliver the biggest user‑facing improvements

DQL exploration

Browser monitors fully in the latest Dynatrace surfaces Synthetic and RUM events in Grail, so you can query execution details with DQL, turning monitor runs into searchable, automatable telemetry.

Core benefits

• Synthetic events give you execution-level context (monitor‑wide status, availability, and problems) and step‑level details (step duration, screenshots, errors). Use DQL to filter and aggregate executions by location, time frame, or error type for fast root‑cause discovery and trend analysis.

FETCH DT.SYNTHETIC.EVENTS
| FILTER EVENT.TYPE == "BROWSER_MONITOR_EXECUTION"
| LIMIT 10

FETCH DT.SYNTHETIC.EVENTS
| FILTER  EVENT.TYPE == "BROWSER_MONITOR_STEP_EXECUTION"
| FILTER EVENT.ID == "101546320749"
| SORT STEP.SEQUENCE_NUMBER ASC

• User events provide resource-level details for each asset loaded during a browser monitor execution (resource type, name, load duration, initiator, render-blocking status). Query these to isolate all or very specific failing resources and to detect lazy load patterns or third-party script behavior proactively

FETCH  USER.EVENTS 
| FILTER EVENT.ID == "101546320749"
| SORT STEP.SEQUENCE_NUMBER ASC
| FIELDS VIEW.URL.FULL, URL.FULL, PERFORMANCE.INITIATOR_TYPE, HTTP.RESPONSE.STATUS_CODE, 
PERFORMANCE.RESPONSE_END, PERFORMANCE.TRANSFER_SIZE

• Because execution details are available in Grail, you can build automations and workflows that react to synthetic outcomes; for example, alert enrichment, automated rollback, or validation steps in CI/CD, or ticket creation with execution context. A community product idea highlights demand for programmatic access to execution details via API as a practical automation enabler.

Enrichment of Synthetic data with primary Grail tags

To make DQL queries even more powerful, Grail can enrich synthetic events, user events, and the metrics that describe browser‑monitor executions with primary Grail tags. These are a small set of customer‑selected tags that Grail automatically attaches at ingest under the primary_tags.* prefix.

Why this matters for browser monitor telemetry

• Fast, consistent grouping: you can group executions, events, and metrics by business or operational dimensions (for example, primary_tags.team, primary_tags.app, primary_tags.environment) without adding ad‑hoc joins or expensive post‑processing.
• Precise filtering: filter DQL queries and dashboards by primary tags to focus on a particular team’s monitors, a specific application, or a cost center across Synthetic and RUM data in one query.

You can now set primary Grail tags per Synthetic monitor during creation or editing, so each monitor’s executions carry that metadata into Grail for queries and automations.

Take the next steps

Take the next step today: turn on the browser monitor experience in the latest Dynatrace and convert synthetic checks into actionable, searchable signals.

• Enable the browser monitor experience on the latest Dynatrace. Flip the new Browser Monitors Experience on to get the latest RUM JavaScript and enhanced reporting everywhere.
• Analyze with the modern Requests waterfall. Use the improved waterfall (fully in the Latest Dynatrace experience) to investigate executions at the resource level and pinpoint root causes faster.
• Leverage DQL and Grail. Query synthetic and RUM events to deepen analysis, build dashboards, and drive automations that react to real monitor outcomes. Check out this example Notebook in Dynatrace Playground to see DQL applied to Synthetic executions and error analysis.

What’s next

Expect improved access control capabilities to help you precisely limit who can view and act on Synthetic monitors and their results, making it easier to secure and share the right telemetry with the right teams.

The post Improved browser monitor experience: Synthetic on the latest 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.

Current synthetic capabilities

Dynatrace Synthetic Monitoring is a powerful tool that provides insight into the health of your applications around the clock and as they’re perceived by your end users worldwide. As HTTP and browser monitors cover the application level of the ISO /OSI model, successful executions of synthetic tests indicate that availability and performance meet the expected thresholds of your entire technological stack. Combined with Dynatrace OneAgent®, you gain a precise view of the status of your systems at a glance. But is this all you need?

Why browser and HTTP monitors might not be sufficient

In modern IT environments, which are complex and dynamically changing, you often need deeper insights into the Transport or Network layers. Whether necessary as part of deep root-cause analyses of issues faced by your users that impact your business or if you’re an engineer responsible for the infrastructure hosting your applications and network paths. You want to be able to answer questions like these:

• What is responsible for application slowdown? Is it a bug in the codebase, a malfunctioning backend service, an overloaded hosting infrastructure, or perhaps a misconfigured network?
• Are all network devices up and running, and is the network providing reliable and swift access to your systems?
• Do I have reliable and up-to-date info on the health of services that are not HTTPS-based but are still crucial elements of your business-critical systems?
• Are the hosts on which OneAgent can’t be deployed for technical reasons (for example, a legacy OS) or security-related reasons (for example, systems processing financial information and third party vendors) up and running? Are the corresponding services running on those hosts?

“ICMP ping tests in NAM are highly valuable and complement the overall value provided by the Dynatrace platform. They enable effective monitoring for devices where OA (OneAgent) cannot be applied due to technical or policy constraints.”

Robert Jędrzejewski– Senior Project Manager, BNP Paribas Bank Polska Spółka Akcyjna

How Dynatrace addresses these questions

Traditionally, Dynatrace provides powerful Platform extensions, which might answer all the above questions. However, those solutions have certain limitations:

• They are not scalable as a pure synthetic solution powered by an API for quickly defining and maintaining tests. Thus, covering an infrastructure the size of several thousand hosts, which is not unusual in modern enterprises, might be significantly challenging.
• Even though these issues were addressed with Extensions Framework 2.0, Synthetic Monitoring still boasts its own advantages with the combination of NAM and HTTP/Browser tests from the same location as well as higher capacity ActiveGates.

To help you enjoy a new and more powerful solution, we’re launching a tool that facilitates the automatic transformation of your existing extensions based on EF1.0 into NAM test definitions. Our script, available on GitHub, provides details.

Why Dynatrace NAM is the solution you need

Ease of deployment and management

Synthetic NAM monitors are executed from the same private locations used for monitoring your internal applications with HTTP and browser monitors. This guarantees oversight into high availability, as test executions are load-balanced between nodes hosting private locations.

Also, the API can be used to manage tests at scale, the same way you might use APIs to manage all other synthetic tests. This simplifies solution deployment (as it is available for current DT synthetic users) and managing tests covering a massive number of devices or services.

Test customization

Even though ICMP pings are not the most sophisticated tests, certain customization options can help tailor tests to your needs. For example, you may select the number of packets sent during each execution of the test (to mitigate the risk of temporary anomalies in the network that could impact your test result) and packet size (for example, to ensure that the given MTU is defined on the whole network path).

Of course, it is also possible to define the required success rate of ICMP packets for each test execution against a given IP address to determine if a test is successful.

Compared to other solutions I have tested, Dynatrace NAM monitors are the most configurable which is to my liking. We are already using three or more packets within all of my ping tests and see customized packets size as a valuable option for the future.

Observability Lead, Ivy League University

Similarly, you can adjust your TCP port check tests to validate if selected ports are not opened or closed as intended. Sometimes, the desired state of a port is not to accept connections. You might want to use a port to validate if security settings are properly applied and if ports that are supposed to be closed are closed.

Easier test management and integration with infrastructure monitoring tools

A single NAM test can cover one host (for ping) or socket (for TCP port check); however, you can make your life easier by creating single tests covering multiple (up to 1k) hosts at once. Whether you aim to check all addresses from a given IP list with ping tests, you can succeed with a single test! Similarly, a single TCP test can check if connections are accepted on multiple ports of one or more hosts.

But we went one step further here. Dynatrace NAM stands above all other competitive offerings because you can define a single ICMP ping test covering all hosts within a given host group (optionally narrowing down the IP addresses to a given range). The beauty of this solution is that even if the configuration of the host group changes, the configuration of your synthetic test stays up to date with no extra action needed.

Of course, the reporting side is properly adjusted to handle such monitors. For each failed monitor and each problem triggered as a result of such a failure, you can easily identify which requests (IP addresses, sockets) are responsible for the failure and might require appropriate attention.

How NAM tests work

You can use the API or our new web UI (Dynatrace SaaS only) to create NAM tests.

The new Synthetic app covers the configuration and reporting of network availability monitors thanks to the power of Grail™ and the new Dynatrace platform.

NAM monitors are defined in a similar manner to other synthetic monitors. Apart from elements specific to the given type of test, such as:

• IP address and number of packets for ICMP ping
• Port number for TCP port check
• Names to be resolved and DNS server for DNS tests

All other elements (like assigning locations or conditions for triggering alerts) are the same as those used in other Synthetic monitors.

The reporting also looks similar; there are easy-to-understand charts indicating the availability and performance of the whole network availability monitor, as well as metrics providing an overall summary and links to currently opened problems.

For more complex network availability monitors covering multiple requests, you might like to look at the chart presenting the request success rate, which shows a list of all requests in the form of a table or a separate chart reporting executions of separate requests.

NAM is available for Dynatrace Managed users

While the new, Grail-powered Synthetic app is available only in Dynatrace SaaS environments, Dynatrace Managed users can also benefit from NAM. Dynatrace Managed users get:

• A powerful API for creating and managing synthetic tests (the same as for Dynatrace SaaS users).
• A set of metrics allowing query results with Data Explorer and creating advanced reporting using Dynatrace Dashboards.
• Basic reporting, available out of the box, provides insight into values of the most important metrics describing the execution of all monitors and indicating which requests might be a reason for failures or slowdowns.

Next steps

• Get familiar with the new Synthetic app! It currently fully supports NAM monitors, but a preview of HTTP monitors will start soon.
• Find out how Synthetic NAM monitoring affects your billing on DPS and classic.
• Expect an easy way of integrating NAM monitors with network devices monitored within the IO app (coming soon).
• Configure NAM monitors directly from the Discovery and Coverage app (coming soon).

The post Dynatrace extends Synthetic Monitoring capabilities with Network Availability Monitors to validate the availability of infrastructure and services 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.