On this page:

Your Rating:
Results:
PatheticBadOKGoodOutstanding!
2 rates
The following notes describe 4.5.x updates to Server Visibility.

If an artifact has been updated, the version number of the updated artifact and its availability date are listed below. The version number corresponds to that shown on the download portal (http://download.appdynamics.com).

The most recent releases appear at the top of the page.

4.5.4 Updates

October 25, 2018

Enhancements
Resolved Issues
Key
Summary
SERVER-4821Reduce resource utilization for Windows process collection by removing effective user of a process

4.5.2 Updates

October 15, 2018

Resolved Issues
Key
Summary
SERVER‑4467Machine Agent not collecting data when collector script contains non-ASCII characters
SERVER-4720HardwareMonitor (OS Specific) reports incorrect memory metrics on RHEL 7.x when REPORT_MEMORY_FREE_AS_MEMORY_AVAILABLE is enabled
SERVER-4892Machine agent looks for custom trust store relative to machine_agent_home rather than machine_agent_home/conf

4.5.1 Updates

Version 4.5.1.1245 – September 5, 2018

Resolved Issues
KeySummary
SERVER‑4744Application Infrastructure Performance|root takes a long time to load

4.5.0 Updates

July 11, 2018

Enhancements
  • This release supports monitoring of applications deployed in OpenShift v3. See Monitoring Red Hat OpenShift Clusters.
  • Dynamic Monitoring Mode enhancements:
    • Dynamic Monitoring Mode (DMM) is now supported for all Docker Visibility metrics. See Dynamic Monitoring Mode and Docker Visibility.
    • The Controller now has three different DMM defaults for all agents reporting to that Controller. Each setting applies to a different set of metrics. 
      • sim.machines.dmm.physical.defaultMode
        Default for Hardware Resources Metrics on servers without Docker Visibility
      • sim.machines.dmm.containerAware.defaultMode
        Default for Hardware Resources Metrics on servers with Docker Visibility enabled
      • sim.machines.dmm.container.defaultMode
        Default for Docker Container Metrics on containers running apps monitored by App Agents
    • The default for all three settings is KPI, the lowest setting: collect Key Performance Indicator metrics only. 
    • AppDynamics recommends that you leave these global settings at their defaults and increase the DMM on individual servers or containers on an "as-needed" basis: 
      • When you need to troubleshoot a specific server or container, increase the DMM on that object only. 
      • When you finish troubleshooting that object, set the DMM on that object back to KPI.
    • When a container monitored by a Java App Agent shuts down and restarts, any overridden DMM specified for the shut-down container is lost. The DMM for the restarted container automatically resets to the global default specified by sim.machines.dmm.container.defaultMode.
  • Docker Visibility enhancements:
    • The Container Details window includes a new Network tab. This tab is available only if the Dynamic Monitoring Mode for the container is Diagnostic or Advanced Diagnostic. This tab shows:
      • Network KB – Total traffic (KB)
      • Network Rate – Rate of traffic (KB/s) 
      • Network Errors
        • Packet Drops – Rate of incoming/outgoing packets dropped by the network. A high rate of packet drops might indicate congestion or other network issues.
        • Errors – Rate of incoming/outgoing packets with errors. 
    • The following new metrics are available in the Metric Browser:
      • CPU %Busy Scaled – If the -cpus=<value> option is set in the container, this metric measures the scaled value of the CPUs property. If this value is not set, this metric measures the scaled value of the Logical CPUs property.
        You must enable CPU Scaling on the Controller to collect this metric.

      • Network metrics
        • Incoming KB
        • Outgoing KB
        • Incoming KB/sec
        • Outgoing KB/sec
        • Incoming packets
        • Outgoing packets
        • Incoming packets dropped
        • Outgoing packets dropped
      • Disks – these metrics might not be available on all platforms:
        • Average IO Utilization (%) – Average disk utilization for read/write operations.
        • Queue size – Average number of container requests queued during the time bucket. Consistently high queue sizes indicate that the container is not getting enough IO resources.
Resolved Issues
KeySummary
SERVER‑2059Controller UI stops working intermittently due to threadpool saturation

SERVER-2183

Service Availability Event should display events related to that service only

SERVER-2277

Node Dashboard > Server tab should show the same information as Server Dashboard

SERVER-2418

Server page shows data for 13 hours, not selected time range of 1 day (observed on SaaS Controller)

SERVER-2698

Disk usage percentage on Linux needs to reflect "df -P -m" command

SERVER-4412Service Availability configurations on agent host get deleted when the machine is considered stale and marked for deletion 

SERVER-4588

License > Account Usage does not show Service Availability license usage

Server Visibility Known Issues
  • Dynamic Monitoring Mode (DMM) is enabled by default on the Controller starting in release 4.5. When DMM is enabled, the Servers tab does not show data for machines that are currently inactive but are not yet deleted. (An inactive machine will re-appear in the Controller if it becomes active again and resumes reporting data to the Controller.)
    To see data for inactive machines, disable DMM on the Controller; view data for the machines of interest, and then re-enable DMM. 
  • If a metric name contains colons (:), the Metric Browser interprets the name as hierarchically separated.
  • If the machine that a Machine Agent is monitoring goes to sleep, monitored processes might be duplicated on the Controller. Because the process has a new start time, the Controller interprets it as a new process. When the configured process count is reached, the Controller marks the duplicated processes as terminated and purges them.
  • (Windows only) You must have .NET Compatibility Mode enabled for Server Visibility to work correctly on a server with a .NET APM agent installed.
  • Server Visibility does not support the following on Solaris:
    • Solaris zones
    • Unicode characters
  • The following Health Rule is disabled by default in this release: 
         Disk Usage is too high on at least one partition. 
    This wildcard health rule can result in high resource consumption and health rule evaluation times on the Controller. If this rule is critical for your environment, the recommended practice is to create your own custom Health Rules and apply specific rules for specific volumes on specific servers. For more information, see the following Support Advisory: 
    https://community.appdynamics.com/t5/FEZ-Knowledge-Base/Server-Visibility-Support-Advisory/ta-p/22408
Docker Visibility Known Issues
  • The Standalone Machine Agent running inside the container sometimes reports a few extra volumes for the host machine. This can result in a higher total volume for the aggregate volume metrics.
  • There might be gaps in the container network I/O metrics. This happens because the Docker API resets the accumulated network I/O metric data for every 4.2 GB of data sent or received. When the data is reset, the Standalone Machine Agent calculates negative I/O values and does not report a data point for that time window.
  • If the agent started monitoring the current container after the beginning of the selected time range in the Controller, the Controller might show metric data prior to the container start time. This metric data will include metrics from a previously monitored container. This behavior occurs when the Controller flag "sim.machines.reuse.enabled" is enabled. 
  • If the agent started monitoring the current container before the beginning of the selected time range in the Controller, the data is correct for the current container.
  • If a container stops running while it is being monitored, the Tiers & Nodes Dashboard > Server tab will show data for the stopped container rather than for the underlying server.
  • In some cases, container monitoring is suspended when some containers that are currently being monitored are stopped. This issue has been observed on Docker API version 1.24. The suggested workarounds, in this case, are to
    • Restart the Standalone Machine Agent (Docker Visibility will start monitoring the containers), or 
    • Upgrade to Docker CC/EE v17.03 or Docker Engine v1.13.
  • cgroup data collection is not supported in Kubernetes deployments. If the Standalone Machine Agent is monitoring containers deployed as Kubernetes pods, do not enable the cgroup Enabled setting.
  • The Container Details > Network tab does not display IP or MAC addresses for monitored containers.