A Machine Agent running on Windows OS shows gaps on the Controller due to collector script timeout  This article describes an issue where the Machine Agent on Windows OS shows gaps on the Controller, presents the likely cause, and provides steps for troubleshooting as well as two test scripts. The scripts can be found below the text portion of this article. In this article...  Machine Agent functionality Machine Agent on Windows OS Observed gaps in the Machine Agent   Troubleshooting steps  Observations    Machine Agent functionality  By default, the Machine Agent invokes collector scripts to gather hardware stats once every 30 seconds (this limit can be increased to a maximum of 60 seconds). At the end of every minute, the Machine Agent aggregates the data received and publishes it to the Controller. Hence, the Controller expects data every minute, and if not received, it will show a gap for that respective minute.     Machine Agent on Windows OS  The Machine Agent uses open source OSHI libraries and collector scripts to gather hardware statistics. CPU, Memory and Process statistics are collected via OSHI libraries, and the rest of the metrics are gathered via collector script. The collector script Machine Agent executes on Windows OS is sim-collector.vbs (added to this article as an attachment). The collector scripts get the data directly via Windows WMI calls and OSHI, as well relying internally on similar Windows WMI java APIs to get the data. This Machine Agent functionality is also applicable for Windows OS.   Back to top Observed gaps in the Machine Agent  The administrator observes intermittent gaps from a Machine Agent installed on Windows OS. This can happen across single or multiple servers.   Gaps appear as follows:   Back to top Troubleshooting steps we performed  We created collect-sample.vbs to mimic the functionality of the Machine Agent.   NOTE | You can find the collect-sample.vbs and sim-collector.vbs scripts below the text of this article, just above and to the left of the comment buttons.   The collect-sample.vbs script ensures that sim-collector.vbs is invoked once every 30 seconds. Before invoking the sim-collector.vbs script, collect-sample.vbs writes a time stamp in the log file as shown below:  objFile.WriteLine("Script Start Time") objFile.WriteLine(Now()) Immediately after writing the above time stamp, collect-sample.vbs file invokes the sim-collector.vbs script.  Set WshShellExec = objShell.Exec("cscript sim-collector.vbs") The first module invoked as part of the sim-collector.vbs script is "runCollector".  Function runCollector() The very first operation performed as part of the "runCollector" module is writing the time stamp onto the same log file again.  Wscript.Echo "runCollector start", Now()   The sample output of the collector script is attached here in the ticket. Here are the first few lines from the collector script sample output: Explanation of the collector script’s sample output : SCRIPT  LINES CAPTURED  collect-sample.vbs  Script Start Time  2023-05-17 12:34:37 PM  sim-collector.vbs  Microsoft (R) Windows Script Host Version 5.8  Copyright (C) Microsoft Corporation. All rights reserved.    runCollector start 2023-05-17 12:34:38 PM  {  The expected difference in the two timestamps described above should be a few seconds—ideally less than 5 - 10 seconds— since it is just a timestamp print operation happening on both sides, and no other operations that would consume more time are taking place between them.  Observations after performing troubleshooting In general, the scripts run fine with an expected delay of less than 5 seconds. During this time, metrics are also published to the Controller as expected.    During other times, the delay between both the time stamps explained above goes beyond 2-3 minutes. The Controller also shows gaps during the same period of time as the delay.    Here is a sample output snippet from this scenario:  Script Start Time 2023-05-17 12:39:01 PM Microsoft (R) Windows Script Host Version 5.8 Copyright (C) Microsoft Corporation. All rights reserved. runCollector start 2023-05-17 12:43:31 PM The gap in the snippet above shows that the script is getting stuck during this time, and that something on the OS is blocking the sim-collector.vbs script invoked by collect-sample.vbs.   A number of things could block this call from the OS. The specifics must be determined by a Windows administrator. In our experience with similar issues in the past, customers’ Windows administrators were able to identify the OS tasks blocking the vbs scripts, and to fix the issue.   Back to top ... View more

Suppose your application is throwing an exception that contains some confidential or secret data exposed in the exception message and you don't want to display that information on the Controller. You could add a block like below in <AgentHomeDir>/ver.x.x.x/conf/app-agent-config.xml <sensitive-message-filters> <sensitive-message-filter message-type="throwable" match-type="CONTAINS" match-pattern="<Exception Message Static Text>" redaction-regex="<Regular Expression>"/> </sensitive-message-filters>   Example Suppose there is an exception thrown like the one below: com.TestException("AccountNumber1111111111") If you don't want to expose the actual account number on the Controller, use below block: <sensitive-message-filters> <sensitive-message-filter message-type="throwable" match-type="CONTAINS" match-pattern="AccountNumber" redaction-regex="[0-9]+"/> </sensitive-message-filters> Agent restart is required for the changes to take effect. After the changes and restart, this is what it should look like on the Controller:  Attached a sample app-agent-config.xml ... View more

Microservices are available for AppDynamics version 4.3+ Controller and Agents. For more information, see AppDynamics and microservices. To allocate purchased licenses for microservices, create a new license rule. Licenses screen 1. Create a new license rule for all 250 Any Language Micro Services licenses: Enter 250 of 280 licenses for microservices 2. Select default options for Application and Server scope and save the rule. 3. Copy the access key corresponding to microservices, and use it as an access key for the agent. ... View more

How do I change the Controller HTTP port, depending on whether or not it is discovered in the Enterprise Console? This article includes the different steps for changing a Controller’s port, whether it is discovered in the Enterprise Console, or it isn’t. In this article...  How do I change the Controller’s port when not discovered in the Enterprise Console?  How do I change the Controller’s port when discovered in the Enterprise Console? How do I change the Controller’s port when not discovered in the Enterprise Console? To change the Controller from default port 8090 to an open HTTP port, make the following changes to file <controller>\appserver\glassfish\domains\domain1\config\domain.xml. Search for the following: <network-listener port="8090" protocol="http-listener-1" enabled="true" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener> Edit it, replacing the former port=”8090” with the new port details, as shown below, where <new-port> contains the new port details.  <network-listener port="<new-port>" protocol="http-listener-1" enabled="true" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener>  In the same file— <controller>\appserver\glassfish\domains\domain1\config\domain.xml  —replace all occurrences of 8090 with the new port number. Restart the Controller app server using the relevant commands, from the steps below: Windows <Controller_Home>/bin/controller.bat stop-appserver  <Controller_Home>/bin/controller.bat start-appserver  Linux <Controller_Home>/bin/controller.sh stop-appserver  <Controller_Home>/bin/controller.sh start-appserver  After restarting the app server, access the Controller using the new port in the URL.  Example: http://<controller_hostname>:<new_port>/controller  Replace <controller_hostname> with the hostname of the controller and <new_port> with the new port number.  How do I change the Controller’s port when it is discovered in the Enterprise Console?  If the Controller is discovered in the Enterprise Console, change the Controller ports by following the steps outlined in the Documentation: Update platform configurations, "Controller Settings".  ... View more

Table of Contents Issue Scenario 1 Scenario 2 Solution Issue Specific Business Transactions (BTs) are registered in both the main BT list and all other traffic under the same tier. This happens for two reasons: Scenario 1 Scenario 2 Scenario 1 There are multiple nodes under a tier. BT - X is registered under node-1 of a tier. You have selected "Enable Business Transaction lock down" in the following screenshot. This is selected by choosing Configuration > Instrumentation > Select App.    After performing the aforementioned actions, the transactions that are already selected are frozen, and any BTs attempting to register will be moved to "All other traffic." Suppose the same transaction BT - X is trying to register from node-2 of same tier. Though there is the same BT from another node of the same tier, this would be pushed into "All other traffic." The BT will appear in both places (BT list and All other traffic). Conclusion/Solution: If you still want to register the same BT from second node again, disable the lock down on the BT. Ref doc: https://docs.appdynamics.com/display/LATEST/Organize+Business+Transactions#OrganizeBusinessTransactions-LockDownBusinessTransactions Scenario 2 Similar to the aforementioned example, there are multiple nodes under a tier. BT - X is registered under node-1 of the tier. node-2 has similar jvm instance and it hasn't detected the same BT yet. node-2 has met the BT limit, which is in excess of 50. After the limit has been reached, the BT - X attempts to register from node-2. BT - X would be moved into "All other traffic", which results the same BT appearing in both the BT list and All other traffic. BT - X of node-1 is showing in BT list and BT - X of node-2 will display in "All other traffic". Solution Figure out the node from which the BT is appearing in "All other traffic," as we aren't sure it is from node-2. Open transaction snapshots of all other traffic and figure out in which node BT - X is registered. Exclude some business transactions from the aforementioned node. On "All other traffic" select BT - X, then click Register so that it appears in the main BT list. ... View more