Historical and Live Entity Data
Historical and Live Entity Data
The Controller has an entity liveness module that tracks the "live" or "historical" status of the the four entity types: application, tier, node, and business transaction for 365+ days.
- Historical: Oldest time (a year before the latest Controller restart) to the latest Controller restart time
- Live: Latest Controller restart time until the current time
Anchor Metrics for Entities
The entities have special metrics called anchor metrics that are used to determine the liveness of the entity. This table lists the anchor metrics for each of the entities.
| Entity | Anchor Metrics |
|---|---|
| Application | Agent | App | Availability |
| Tier | Agent | App | Availability |
| Node | Agent | App | Availability |
| Business Transactions (BTs) |
BTM | BTs | BT: %d | Component: %d | Calls per Minute |
Liveness Status
The liveness of an entity affects the associated entities as the liveness is rolled up the hierarchy. If the entity type in the table is live, you can determine the liveness of the associated entities in the right column.
| Live Entity | Liveness Status |
|---|---|
| Application | An app is alive if any tiers in this app are alive |
| Tier | A tier is alive if any nodes in this tier are alive |
| Node | Any metrics from the particular node |
| Business Transactions (BTs) | BT metrics, Calls per Minute |
How the Controller Displays Live Entities
Based on entity liveness status of the selected time range, the Controller determines whether to count and display entities in these places:
- Flowmap
- Tier and Node list pages. This is also determined by the Performance Data checkboxes. See Live Entity Data in Flowmaps.
- Metric tree of the Metric Browser
- Custom dashboards
- Splunk AppDynamics REST APIs related to topology such as the Application Model API.