Known Issues

You can avoid most of below issues by installing latest NAM Service Pack. We strongly recommend it.

Script recipients can't be displayed when accessing Console over HTTP protocol.


Workaround

Reference : APMODCRUMM-10412

Applies to : NAM 2018

Details :

After upgrade to NAM 2018 the user is not able to display the script recipients in the NAM Console anymore. In Alert management the user can switch to Recipients and open the dropdown menu recipient type. But if the suer chooses Script, an "Internal Server Error 500" occurs.

Solution :

To be fixed in NAM 2018 SP1

Workaround :

Use HTTPS protocol to access NAM Console, or try Microsoft Internet Explorer 11.

Console can't connect to LDAP server due to unknown certificate.


Workaround

Reference : APMODCRUM-30590

Applies to : NAM 2018

Details :

The problem appears due to new JRE build (1.8.0_181) that has been included in RUM Console. In release notes there is an explanation (see http://www.oracle.com/technetwork/java/javase/8u181-relnotes-4479407.html)

To improve the robustness of LDAPS (secure LDAP over TLS ) connections, endpoint identification algorithms have been enabled by default.

There may be situations where some applications that were previously able to successfully connect to an LDAPS server may no longer be able to do so. Such applications may, if they deem appropriate, disable endpoint identification using a new system property: com.sun.jndi.ldap.object.disableEndpointIdentification.

Solution :

Apply correct certificate to LDAP server.

Workaround :

Define this system property (or set it to true) to disable endpoint identification algorithms.

In order to make Console working as previously it is enough the add the following flag to Console command line in registry:

-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true

Dictionary inconsistency


Reference : APMODCRUMM-8818

Applies to : DC RUM 2017 May

Details :

Fixing problems with dictionary inconsistency issues

Solution :

Please apply the following patch: dictionary consistency fix pack v17.jar

To clear dictionary inconsistency warning message please do following :

  1. Delete all ExportConfig* files from <installation directory>\temp\directory

  2. Go to the http://<your_CAS_address>/DiagConsole#/diag CAS page

  3. In Search box type: ALL and then DICTIONARY CLEAR FLAG

it is important to do this in order - 1st remove all ExportConfig* files then clear the flag.

Unable to connect to AMD after upgrade


Reference : SUPDCRUM-20563

Applies to : DC RUM 2017 May

Details :

When you've upgraded CAS to 17.0.x first and after that the AMD. After CAS upgrade it was able to process data from the AMD (12.4 ver yet), then AMD was upgraded to 17.0.x and the SSL connection (rtmgate) params have changed. AMD 17.0.x uses now TLS 1.2. While the CAS remembers the previous TLS connection params with this AMD (<1.2) it can't communicate any longer with AMD after upgrade.

The following messages may appear in server.log :

E ADM	17-09-05 14:15:46.369	Ex: java.net.SocketException: Connection reset.

See full output.

Solution :

The solution requires to restart CAS for it to re-establish SSL connection with AMD via TLS 1.2.

Compatibility issue between SP3 and pre-SP3 versions for intra-CAS-Cluster communication


Applies to : DC RUM 2017 May, SP1, SP2 and SP3

Details :

There is compatibility issue between SP3 and pre-SP3 versions of internal library (hazelcast) used for intra-CAS-Cluster communication. In order to avoid any issues when applying SP3 (on any < SP3 version) please take one of the two recommendations.

Solution :

Either:

  • apply SP3 at athe same time to all your CASes and ADSes, including Failovers, or

  • if you cannot do above then apply hazelcast-all-3.1.9.jar patch on less then SP3 version PRIOR starting applying SP3 anywhere.

If you do not apply any of above two recommendations you will find your CASes not starting with the following entries in the server.log:

E FARM	18-01-12 13:34:55.635	com.hazelcast.nio.serialization.
HazelcastSerializationException: 
Problem while reading DataSerializable, namespace: 0, id: 0, 
class: com.hazelcast.partition.CheckReplicaVersion

ADS operations limit exceeded due to SSL handshake operations


Reference :
APMODCRUM-28667
APMODCRUMM-9444
APMODCRUMM-9309
APMODCRUMM-8812
APMODCRUMM-9249

Applies to : DC RUM 2017 May

Details :

Reporting on SSL handshake operations is a new feature in DC RUM 2017.

We're reporting them on purpose learn why - how SSL connection setup relates to the web page load time. The downside is enormous number of new operations reported in hpdata files in ADS - size of these files can grow by 70%. Not all customers want this and worse, it can't be disabled (easily) today, resulting in ADS servers stop processing (new) data early during a day, as only the number of operations limit (default 2M operations / day) is reached.

We have discussed this issue with Product Management and there would be a long term solution implemented in 17.04 (SP4) (avail January 2018) allowing users to control (on/off) if they want to have these operations reported in CAS, ADS or both, globally and/or on a per software service basis.

Meanwhile, our DEV team came up with a hotfix that will filter out all "SSL handshake" records while processing hpdata files by ADS servers - those would still be produced by AMDs, but they won't be stored in ADS database and therefore the hpdata processing cycles should take less time now and therefore eliminate the processing delay). In many cases it would reduce number of operations stored in ADS by 65-70% and that's a big save!.

The make a similar change in CAS is not so straightforward. CAS works differently and relies on data consistency - metrics on operation related and "all other" entries have to sum up to what is passed in summary records. We can't remove only records with an operation as it would corrupt the data. We can't remove all records as we would lose track of whole servers.

Furthermore, SSL handshakes in hpdata do not necessarily have to correspond to what is passed to CAS in zdata and how long it takes in CAS. We have analyzed impact and it shows about 60% gain on ADS but only 20% on CAS end, therefore thus far we see this issue impacting ADS servers most often and not CAS servers that much.

Solution :

In NAM May 2017 SP4, we have implemented a RUM Console switch to turn off SSL handshake operations globally per AMD or individually per software service for the CAS or ADS.

By default, SSL handshake operations are turned on. You can find the SSL handshake operations switch for the following decodes: HTTP, SSL, TDS and other database decodes, RMI, ICA, SMTP, Universal Decode, IBM-MQ and LDAP.

  • Report SSL handshake in CAS data
  • Report SSL handshake in ADS data
  • Report only errors in ADS data

To change SSL monitoring settings, in RUM Console, select Global ► Front-End Monitoring ► SSL. See Front-end monitoring - SSL.

Once upgraded, publishing configuration changes causes some of the AMDs to restart.


Workaround

Reference : APMODCRUMM-7636

Applies to : All deployments with mixed AMD releases managed by the same RUM Console.

Details :

Deployments with various AMD releases managed by the same RUM Console are not supported however, such situation may occur during a deployment upgrade where only partial upgrade has been performed. In such situations, if configuration changes are published, the RUM Console will upgrade the configuration globally to the latest version. Any AMD with an earlier release version will be forced to restart (only once) after receiving an upgraded configuration version.

While this restart is performed silently (no messages are displayed), it will be logged and may be indicated on AMD status reports.

Workaround :

Since these restarts happen only during the first publish, and the deployment scenario (mixed AMD releases) is not supported, no fix is planned.

Can't integrate AMD 17.0 with AppMon 6.5.


Workaround

Reference : APMODCRUM-24580

Applies to : AppMon 6.5, May 2017

Details :

This is a known issue for AppMon adding a new AMD.

Connection error will occur if the AMD being added presents the certificate that is already present in AppMon Certificate manager. This is a typical occurrence when a given AMD is reinstalled and its new self issued certificate is presented to AppMon while a different (old) certificate is still listed in the AppMon certificate manager for that AMD.

Solution :

Fixed in AppMon 7.0+

Workaround :

To resolve this issue, manually clear AppMon cache. The following procedure is based on AppMon 7.0 running on Windows:

Check if AppMon has a proper AMD configured:

  1. Log in to AppMon using remote desktop.
  2. Start Dynatrace Client.
  3. Go to System Profiles and edit it by RMB > Edit System Profile > Integration
  4. In the DCRUM Data Import section check entries for every AMD that should get data from AppMon (the green dot indicates that everything is fine with the communication, the red dot indicates connection problems)

Stop the AppMon service (Dynatrace Server 7.0).

Edit <AppMon install folder>/dtserver.ini and add the following line: -Dcleardcrum

Start the AppMon service and wait for the service to become available.

Stop the AppMon service.

Remove the added line.

Start the AppMon service again.

Check the AMD status in all required system profiles (the dot indicator for problem AMD should change color to green).

AMD nCipher SSL decryption not working after upgrade.


Workaround

OpenSSL

This issue DOES NOT impact any deployments using OpenSSL.

Reference : APMODCRUMM-9047

Applies to : AMD 17.0.0 with nCipher

Details :

Upgrade failing due to nCipher pieces missing.

This is a bug in the nCipher software, introduced in ncipher_pkcs11-12.10.00-2 (AMD 12.4.6).

The issue did not become immediately visible, instead it caused an issue with the next ncipher_pkcs11 package upgrade to ncipher_pkcs11-12.10.00-3 which also contains the same bug (AMD 12.4.13).

The bug is fixed in ncipher_pkcs11-12.30.00-0, (AMD 12.4.15.11) however, the newest ncipher package will not fix the issue if it has already been introduced by AMD 12.4.10/12.4.13.

If you are using AMD 12.4.10 release or greater (but less than 12.4.15.11), prior to moving further with the AMD installation manually remove currently installed ncipher_pkcs11 package (rpm --erase ncipher_pkcs11).

Solution :

Planned to be fixed in AMD 12.4.15.11, AMD 17.0.1 is not affected.

Workaround :

This will NOT remove the current ncipher configuration nor require card/security world reinitialization.

To summarize, there are four possible upgrade paths:

  • AMD 12.4.5 (HS or Classic) or older:

Upgrade directly to 12.4.15.11 or later

  • AMD 12.4.6 (HS or Classic) and all versions up to and including AMD 12.4.14:

Remove the ncipher_pkcs11 package (This may generate some error messages which can be ignored.).

[root@AMD /]# rpm --erase ncipher_pkcs11

Install AMD 12.4.15.11 or later.

  • AMD 12.4.15.11 or newer:

No action is needed, problem does not occur.

  • AMD 17.0.0:

Remove the ncipher_pkcs11 package (This may generate some error messages which can be ignored.).

[root@AMD /]# rpm --erase ncipher_pkcs11

Install AMD 17.0.1 or later

Icon

The issue also won't occur if you have never deployed AMD 12.4.5 or older. For example, you deployed a fresh installation of AMD 12.4.6 or later.