Changes in current releases

Dynatrace NAM 2018 SP1


External IdP configuration

As part of configuring an external IdP, you need to export the SSO metadata from the NAM Console and import it into the external IdP configuration. For example, in Using OpenAM as an external IdP , you export the NAM Console metadata in and import it into OpenAM.
Installing NAM 2018 Service Pack 1 will require you to export and import that metadata once more after you apply the service pack. Without doing so, you will be unable to sign in to the NAM Console through the external IdP.
See Using an external identity provider.

Language setting

The language setting has been removed from the NAM login screen.
To set the default language for your entire NAM deployment, sign in to the NAM Console and open Deployment > Settings.
To override the default language for any user, a NAM administrator can sign in to the NAM Console, select Security > Users, select Actions > Edit user for that user, and change the Language setting.
To override the default language for your own profile, any user can sign in to the NAM Console, select the dashboard icon, select My profile, and change the Language setting.
See Console settings.

Alerts update

  • On the Alert management page, you can select multiple alerts and then enable, disable, or delete all selected alerts with one click.
See Alert management.
  • On the the Notifications page of configuration wizard, you can click Build report URL to add a link to an external site or to a NAM report in the alert notification message, and to send details describing alerts (metrics, dimensions, modes, etc.) as parameters with those links.
See Alert notifications.

Dynatrace NAM 2018


NAM Probe firewall

The NAM Probe uses rtmgate to communicate with other Dynatrace components such as NAM Console, NAM Server, and AppMon server.
The fresh NAM Probe installation includes a system firewall that controls incoming and outgoing network traffic based on configured security rules. The rtmgate listens on TCP port 8443 and UDP port 9093 and, by default, it uses the system firewall to redirect incoming requests on these ports.
  • TCP 443 ► TCP 8443
  • UDP 514 ► UDP 9093
An upgraded NAM Probe installation that is already using the system firewall will preserve all existing rules and exceptions. The upgrade process will automatically add and map the required communication ports redirections.
Depending on your deployment scenario, you may require additional firewall exceptions or port redirections for your NAM Probe.
See Adding specific ports to the public zone.
See Adding specific interface to the trusted zone.
You can also use the official system documentation for more advanced firewall settings.

Single Sign-on

With NAM 2018 we introduced a Single Sign-on.
When you sign on to one component (NAM Console or NAM Server), you are also signed on to other NAM components in the deployment (providing you have the appropriate user role). That’s the essence of single sign-on.
User rights are still controlled in NAM with fine granularity to guarantee appropriate levels of user access to reports and configuration screens.
All users must have web access to the NAM Console. Whether you choose to use the external SSO federation services or not, the NAM Console always plays an essential part in every user’s authentication.
See Single sign-on (SSO).

ADOD

Advanced Diagnostics on Demand (ADoD) offers real-time access to discrete operation details, including load sequence charts. Your primary view of ADoD data is through the Operation details explorer, which (depending on your configuration) shows operation details down to the load, hit, or header level.
See Advanced Diagnostics on Demand.

Converting ADS reports

There is no automatic conversion of ADS reports into ADoD reports. Once upgraded, you can use the diagnostic console command that converts the exiting reports to use ADOD data views or, edit each of your custom ADS-based reports and change the DMI data view for each of them from ADS data views to ADOD data views. See Upgrading DC RUM 2017 with ADS.

Reports

Once you upgrade the CAS 2017 to NAM Server, most of the ADS-based reports will work in the same way. The exception are the reports that aggregate data across large data sets from the old CAS-ADS deployment. The ADOD feature extracts up to 1000 records per report and aggregates on these reports can only be calculated on such limited data sets.
Typically, ADS reports are focused on diagnostics. They present limited data sets filtered by specific dimensions for example, time, user name, URL and client IP address. ADOD supports such reports out of the box.

Built-in reports

All built-in NAM 2017 reports will work after the upgrade to NAM Server 2018. For example, all the user activity reports, waterfall charts and error detail reports will work out of the box on the NAM Server. Keep in mind these reports will use the ADOD feature data, not your old ADS 2017 server data.

Component licenses

DC RUM 2017 release supported two types of licensing: Capacity based and Component based. Typically, the capacity licenses were handled by the eServices licensing platform while the Component licenses were handled by Distributed License Management (DLM).
Starting with Dynatrace NAM 2018 release, all licenses (capacity based and component based) will be handled by the eServices licensing platform.
See Licensing.
NAM 2018 brings a redesigned, intuitive and simplified alert definition mechanism based on DMI concepts familiar to any analyst working on creating NAM server reports. Among many changes introduced in the UI, make sure you familiarize with the following important changes in the available alert features.

Listing alerts

User-defined and predefined alerts are no longer listed in separate tabs. Use the new filtering mechanism to quickly find the alert you're looking for.
Listing alerts

Delayed processing option

We removed the Delayed processing option from the Propagation settings tab. With the redesigned alert mechanism, this option would only be justified right after starting a newly installed server with a fresh database.

Filtering alert notifications

We no longer provide possibility to define additional conditions for sending alert notifications. As a workaround, we suggest defining more granular alert definitions dedicated to particular users.

Defining an alert for a non-working server

You won't be able to create a draft alert definition to be distributed by a server that's currently down.

Granularity of disabling alert notifications

You can no longer disable a selected alert notification for a particular user. Now, you can disable notifications globally, either for a particular alert or a particular user.

SNMP Traps

We changed the structure of the SNMP Trap message. In DC RUM 2017, the number of OID fields is the same among alerts of the same type. For example, METRIC_ALM type alerts always contain 25 fields - first three reserved for the metadata, such as ID of the alert, and remaining 22 the defined alert data. Each alert has uniquely defined OIDs, but the Trap message is sent using the base type OIDs. Therefore, once each OID is given a label, defining a new alert doesn’t require reading the MIB file again.
In NAM 2018, the number of OID fields may be different - only the first three metadata fields are consistent among the alerts of the same type, remaining fields are alert specific. An alert using only one dimension may only use two fields. It is necessary to read the MIB file to decipher what each OID means every time a new alert is defined or modified.

Changes in comparison modes

We removed Absolute and Relative comparison modes. The new available modes are Single, replacing the Value mode and the new modes, Absolute baseline and Relative baseline performing absolute and relative comparison against the NAM server calculated baselines.

Deprecated Synthetic Classic alerts

The Dynatrace platform is now the primary interface for all the users, including classic products. As Synthetic Classic customers upgrade to Dynatrace Synthetic, Dynatrace NAM 2018 Server will continue to acquire and process Synthetic Classic data; however, alerting on Synthetic Classic data is no longer supported.

DC RUM 2017


New AMD architecture

Since the 2017 release, the AMD is available only in the new architecture we referred to as AMD.
  • There's no direct upgrade from a Classic AMD. However, you can migrate your Classic AMD configuration.
See Upgrading Classic AMD.
  • AMD 2017 release supports Red Hat Enterprise Linux 7.3 only.
See Updating Linux.
In the context of the 2017 release, whenever we mention AMD, we mean new architecture AMD.

AMD network configuration using a tool of your choice

When setting up your AMD, the rtminst program will accept the network configuration performed with any system tool. We no longer handle the network configuration in rtminst.
See Configuring AMD communication interface where we show you how to use nmtui to configure the network.

AMD installation options

Upgrade.bin , the AMD installation program has now two installation modes, automatic and manual. There's no default option. You must choose one using --automatic or --manual parameters.
When you test your system compatibility using upgrade.bin with the --test-system parameter, we now also indicate if the firewalld service is enabled on Red Hat 7. AMD expects it to be disabled.
See Installation and upgrade options.

User access and security handled by RUM Console

We drop CSS. Now, you will manage your users and security using RUM Console.
The RUM Console installation program will import all your users and settings from a current CSS installation.
See Upgrading the RUM Console. We introduce a concept of API tokens for authorizing the safe communication between the DC RUM concepts.
See API tokens.
Once the upgrade process is complete and your DC RUM is up and running, you can uninstall the CSS and delete the database.

Browser support

We're adding support for Edge and dropping support for Internet Explorer 10.
See Supported browsers.

Bulk insert properties

The bulk insert source and destinations were controlled by the advanced properties RtmJob.bulk.read and RtmJob.bulk.write and corresponding user properties bulk.read and bulk.write . Since the 2017 release, we rely only on the user properties. If your current configuration used the advanced properties, we will convert RtmJob.bulk.read and RtmJob.bulk.write to bulk.read and bulk.write during the upgrade to 2017 and delete them.

Data access permission

The Transaction,Tier, and Reporting group dimensions are considered as deprecated for data access permission. You can still use these dimensions to control data accesses in DC RUM 2017, however won't be able to do so in future releases. Consider changing your configuration now.
See Data access permission.

Server think time

The Server think time metric is considered as deprecated. It's available in the current version DMI, but you can expect it to disappear in the future releases. Modify your reports to use the Server time metric instead. Server time provides more refined measurements and deals better with complex operations.
See Calculating primary reason for slow operations to learn how we calculate server time.

Reorder of request breakdowns

To make it consistent with other breakdowns, we changed the order of components for a number of request breakdowns. Now the order is Failures/Failed, Aborts [if exists], Slow, Fast. The affected metrics are:
  • In Application, transaction, and tier data view: Requests breakdown, Requests percentage breakdown (with tooltip), Requests breakdown (with tooltip)
  • In Application, transaction, and tier data view: Requests breakdown, Requests percentage breakdown (with tooltip), Requests breakdown (with tooltip)
  • In Synthetic and sequence transaction data view: Transaction requests breakdown
  • In Synthetic Monitoring page data view: Pages executed breakdown
  • In RUM Browser data view: User actions attempts breakdown, User actions breakdown

Dimension name changes in RUM browser data view

To make it consistent across all data views, we changed Browser name to Client type . This dimension stores the browser names used to collect the UEM monitoring data. Consequently, we changed the name of the old Client type to Client platform . This dimension has four possible values: Desktop, Mobile, Synthetic, and Unknown.

SAP GUI operation name change

SAP GUI Operation name now contains the Screen Id. You can expect the change both, in fresh installations and after you upgrade your AMD to the 2107 release.

ACK RTT measurement improvements

We improved the algorithm used to calculate ACK RTT. Expect slight changes in the ACK RTT metrics values.

SSL connection setup time

We no longer treat SSL Connection Setup Time as a part of SSL Handshake . We noticed that a particularly long setup time could confuse the analyst, as it would unnecessarily affect the SSL Handshake and overall Operation time measurements. Consequently, the SSL Connection Setup Time metric is no longer available and we report it as a separate operation.