Learn about the most common AppMon concepts and features. For the full definition, click the term name in the list below.
*NIX is used to refer to all Unix-like systems. Here, they typically include Linux, Solaris, AIX, HP-UX and Mac OS X.
An active visit is a visit in progress, which means that the representative user is actively using your application. If the user has left your application or is inactive for a certain time, the visit is finished.
An Agent is a software that is either running on the host or injected into the application process. It gathers performance data and sends it to the AppMon Collector.
Use Agent Groups to logically group certain Agents for common configuration and easier maintenance. Examples are separate groups for front-end and back-end servers. See Using Agent Groups for more information.
Auto Sensors (aka extended PurePath information) automatically retrieve information (transactional snapshots) provided by PurePath technology without explicitly instrumenting methods. It includes class and method names, parameter and return types, access modifiers, and call hierarchy information. Auto Sensors complement AppMon out-of-the-box Sensors which explicitly instrument methods to capture context information for web requests, database statements or exceptions, and other information. See Auto Sensors on the Sensors page for more information.
AppMon provides automatic, smart baselines. The smart alerting mechanism reduces alerts on false positives, which can occur with traditional statistical approaches that look only at averages and violations based on standard deviation.
A business transaction is a set of automated interactions between IT systems that execute a business task or business process. In AppMon, a business transaction is a categorization of PurePaths defined by filter or grouping parameters. When a PurePath matches those parameters, one or more evaluation metrics are calculated to create the result set of the business transaction.
The AppMon Collector performs bytecode modifications when instrumented applications start up. Agents therefore need to send the bytecode of your applications to the AppMon Collector. To keep start-up times low, it is necessary to deploy at least one AppMon Collector in every location/data center that is connected to an AppMon Server.
A conversion goal is a criterion to count visits as converted. The following options are available:
- Web request
- Method invocation
- Custom measure
The discovery run is the first run of an application after the agent injection that covers all or most of the application functions. AppMon requires it to be aware of all classes that the application uses, for further analysis and instrumentation. No special configuration needed, just run your application.
DT_HOME refers to the AppMon installation directory. It could be referenced as %DT_HOME% on Windows or $DT_HOME on *NIX or generically <DT_HOME>
It originally refereed to the environment variable that is optional now and can be used for convenience and then should point to the AppMon installation root, for example
C:\Program Files\dynaTrace\dynaTrace 7.2 for a default 64-bit AppMon installation on Windows.
Dynamic measures are measures that can either appear or not appear on a chart based on whether the measure's splitting creates data within the chart's selected time frame. A Measure is split by Agent, application or a business transaction criterion. If a splitting value occurs for the Measure within the selected time frame, AppMon creates an entry for this Measure in the chart. Depending on the chart type, the entry can be either a line in a chart table or a series in a chart.
The starting point of a PurePath is its entry point. It is the start of the method call chain that makes up the PurePath.
An error in AppMon can be any kind of unexpected event that happens while a user interacts with a system. Some examples of errors that can occur are resources that cannot be found on a web server, HTTP 500 response codes sent by a web service, or exceptions that occur within an application.
The Garbage Collection size (GC size) of an instance is the amount of memory that is freed if the corresponding instance is garbage collected.
A host in AppMon is a system under analysis. A host is instrumented so that that measures can be monitored and reported on when thresholds ae exceeded.
Hot Sensor Placement is a technology used to commit changes to an application's instrumentation during run time without the need to restart the application or application server.
An incident rule in AppMon is a mapping between measured thresholds and the actions to be taken when such thresholds are violated. If all the thresholds defined in the incident rule are violated, this is an incident, even if no actions have been configured for the incident rule.
Instrumentation in AppMon is when AppMon injects bytecode into applications to make it possible to monitor a PurePath from end to end.
In the Transaction Flow visualization, Inter Tier Time is the time between the last measure point in a PurePath on one agent and the first measure point in the same PurePath on another agent. This measurement may include the following factors:
- Network latency if the agents are physically separated.
- Time added by other tiers that are between the measure points but are not instrumented.
- Messaging queues.
See mobile agent
The Keep Alive graph shows how an instance is kept alive on the heap.
The Keep Alive Set dashlet is the set of instances that are held by an object instance. If the corresponding instance is garbage-collected, all instances held by this object can also be garbage-collected.
A (logical) application lets you manage more than one application within a single System Profile.
Monitor and manage transaction performance for separate applications, or make a logical separation automatically by host / web application ID, or manually by using entities such as URI pattern or PurePath entry point.
AppMon 2018 April and later A lost and found transaction is an executed SubPath of a Transaction, which is not linked to its parent SubPath.
Measures in AppMon are metrics, or data points, collected and recorded in the AppMon Performance Warehouse either periodically or based on transactions. Measures are used for long-term charting, trend analysis, and as the basis for configuring incidents.
Agent based measures (such as host agent and monitor measures) provide insight into your environment and infrastructure. These measures give accurate environment data points related to hardware, operating systems, servers, and databases.
Transaction based measures give insight into your applications and transactions using PurePath information.
PurePath based measures are calculated from PurePath-extracted data such as Response Time, the number of SQL executions, or the number of exceptions. PurePath based measures can also be calculated from any visit data, including visit durations, visit counts, or conversion rates
Measures can be used to define criteria in a business transaction by extracting pieces of specific information and so they can be broken up into categories of information
Memory snapshot post-processing extracts optimization classes, instances, and references from the raw data and performs calculations on the raw data to produce data for analysis.
AppMon UEM's mobile app support lets you track visitors, actions, and PurePaths triggered by your iOS and Android application. See Supported platforms for information on which mobile platforms can use AppMon's mobile UEM support.
To trace UEM activity, you must integrate the Mobile Agent into your mobile app by adding mobile agent method calls to the app's source code. When integrated into the mobile app, user experience data can be collected and analyzed in the same way as for users browsing your UEM enabled web application. The following shows the steps needed to generate and analyze mobile app UEM data.
The AppMon "Mobile agent" is synonymous with Dynatrace "OneAgent for Android" and "OneAgent for iOS". See the topics on enabling user experience monitoring for Android apps and iOS apps for more information.
A Monitor is scheduled for repetitive execution on a Collector to deliver additional performance metrics to the AppMon Server.
Typical examples are windows performance counters that are not specific to a process but host-wide, and SNMP data sources.
Data retrieved by Monitors are stored as Measures, which can then be combined and correlated to metrics captured from within the application. For example, transaction response times, number of exceptions and executed database statements.
PureLytics is the AppMon big data analytics engine that streamlines data analysis by pulling relevant information from millions of PurePath and PureStack data points in real time to enable multi-dimensional analytics.
PureModel Technology® combines the PurePath and PureStack views to provide the complete context of business application performance and end-user impact.
PurePath Technology® is a complete multi-dimensional trace of every transaction in a monitored application providing comprehensive visibility across web browsers, web apps, mobile apps, web servers, Java, .NET, PHP, databases, middleware, and mainframe apps.
PureStack Technology® directly correlates system infrastructure health data from every transaction tier in a monitored application environment with individual transactions and affected end users in real-time. PureStack is the vertical view of infrastructure in a monitored application environment and is the basis for bottom up analysis, which is defined by analyzing problems in the infrastructure and assessing and correlating their impact on application performance and end-user experience.
A Sensor is a small piece of code that instruments the monitored applications at certain points to extract relevant data. For example, a Sensor can transport tagging information from one host to another when a web service call executes. The AppMon installation includes a set of built-in Knowledge Sensor Packs for a wide set of application servers and frameworks. AppMon maintains these Knowledge Sensor Packs, and you can activate/deactivate them as needed.
A session is a set of diagnosis data related to a specific System Profile.
Examples of a session are:
- PurePath Session: Combined information about PurePaths and Time Series within a given time period.
- Memory Dump: Analysis data about the number, size, and class of allocated objects and their references.
- Thread Dump: Collection of data for thread analysis, including CPU time information.
- Sampling: Statistical data for all threads, which can help to find Rules and entry points.
The shallow size of an object is the flat size, without children. The shallow size is defined by the sizes of all fields defined within the corresponding class and all fields defined in super-classes. It does not include the size of referenced children objects.
A System Profile is a container for all configuration settings that belong to a certain set of Agents, representing the system under diagnoses (SUD). When a new Agent connects to the AppMon Server, it is matched to exactly one System Profile. As a result, AppMon applies all configuration settings within the System Profile to the Agent.
A System Profile Template is the same container for all configuration settings, as a System Profile. The only difference is that template can not contain Agent Mapping settings.
When you need to create several System Profiles with same settings, but for different Agents, you can create System Profile Template once, make all configuration here, and then create System Profiles, basing on it. These System Profile will inherit all properties from the Template, and you will only have to map Agents to them.
The System under Diagnosis is the application where you inserted the AppMon Agent.
AppMon provides built-in tasks to automate repeating tasks such as generating reports or storing sessions.
The Transaction Flow dashlet graphically represents the tiers and backends of a monitored application environment as it is modeled by Agent Groups and Agent mappings defined in a System Profile.
Splitting can be used to segment business transactions according to splitting criteria. By default, all newly created business transactions are split by one criterion: application.
onload handler, which in turn might perform XHR requests, or other actions.
A user action's duration is called response time. It represents the time the user waits until it is possible to continue with the use case. A low response time indicates better performance than a high one.
A visit is a group of user actions performed by the same user within a certain time period. It is created with the first user action and ends after the user is inactive for a specified period of time. See System Profile > User Experience for more information. This user inactivity time setting defaults to 30 minutes. You can define it on an application-level (System Profile - Applications). A visit represents the user's click-path and helps to analyze problems. A visit duration is calculated from the start of the first user action to the end of the last user action.
A visit tag is a specially configured measure, which you can use to mark a certain visit. When the threshold of the measure triggers, the measure value is assigned to the visit.