The Experience View is based on Slow and Fail patterns. We categorize the transactions into Problems (left most impacting) and Anomalies (non-left most impacting).
Experience Cards show summary information and identify the problem and the problem origin. Cards are defined based on a universe. These cards must be created manually.
Important Note: If an Experience Card is blank, this indicates that there are no transactions. To appear in an Experience Card, there must be some application level or business level component, which would consist of a frontend, a business transaction, or an application entry point.
When looking at an Experience Card, what do all the parts of it mean and where does the information come from?
Below is an experience card. These cards are based on the Left Most component (User Experience) of the Map, which you can get to by clicking on the Map menu item or opening an Analysis Notebook. It gives a quick overview of the Health on the Experience Card (based on how each card was set up).
Below is a breakdown of the components. Starting from top and going clockwise:
1. Problems and Anomalies - This is probably the most misunderstood part of the card. Where do problems and anomalies come from? Is a problem an anomaly? Is an anomaly a problem? Using the below map, you can see there are 3 red icons on the right and 2 red icons on the left (separated by ActionServlet|service in the middle). The map is drawn from transaction traces. If no transaction traces exist, then no map is drawn.
In summary, Problems are those that have critical user impacts and Anomalies do not at that point in time.
A.) Problem - The items on the left are considered the left most component. They can be a business transaction coming from CEM or Browser Agent, or an Application Entry Point. Any component that exhibits a red icon is a Problem and will be noted in the number in the image above. A Problem is anything that impacts the user directly is the most critical. A Problem takes higher precedence over an Anomaly. In the above example, we see there are 2 problems.
B.) Anomaly - The items on the right are considered the right most component. An anomaly can become a problem. For example, if you have a database where one instance goes down of a multi instance DB, not a load balancer, it is an anomaly and you have to fix it at some point, but it is not affecting everything as other instances can take the load. But if all instances go down of the DB go down, then the impact on left most component, classified as problem. In the above example, we see there are 3 anomalies.
2. Experience View Alert Status icon (top right hand corner of Experience Card) - This icon is based on the alert on the left most side of the map above (aka Problem). Indicates any user experience tile exceeding danger or caution threshold, which is happening at the current point in time.
3. Fail Bucket - Based on any alert that is not from Differential Analysis, not from Average Response Time, and error count on left most component.
4. Slow Bucket - Based on any alert from Differential Analysis or Average Response Time on the left most component. If Differential Analysis is not configured, then it will be all based on Average Response Time. If you have an alert set on DA or ART and it goes into caution/danger, then it will be put into the slow bucket.
5. Poor transaction - The first number represents the transactions that fall into the slow and fail buckets (slow + fail = poor transaction). The second number represents the total number of transactions. In the example above, there are 30 poor transactions that had issues (non Average Response Time and non Differential Analysis) out of 593 total transactions that were impacting the user experience.
6. Health Score - This is the quality of all transactions. To obtain this value, we calculate (Total Transactions - Poor Transactions) / Total Transactions to get the percentage. In the example it would be (593 - 30) / 593 = 95%