This page describes how to create analytics metrics from scheduled queries.
If you want to execute an analytics search repeatedly to monitor its value, you can create a metric from the search. The search will execute once per minute and report the results as a metric. You can create alerts on the metric in the usual way using Health Rules to trigger Policies and Actions. The analytics metric list is searchable.
You can create metrics for all Analytics event types - Browser, Mobile, Transaction, Log, and Custom.
Although the metrics calculated by scheduled queries may have decimal point precision, we only save and report whole numbers.
You can create a metric from an analytics search for the functions shown in this table. See Metric Data Resolution over Time.
|Metric Rollup Type
count(* | field_name)
SELECT count(activeMacUsers) FROM dummyTransactions
SELECT distinctcount(activeMacUsers) FROM dummyTransactions
SELECT sum(responseTime)where userExperience = "NORMAL" FROM transactions
SELECT avg(responseTime) FROM transactions
SELECT min(responseTime) FROM transactions
SELECT max(responseTime) FROM transactions
Create an Analytics Metric
- Working in the Analytics > Search editor, set the search criteria to select the appropriate data.
- Click Actions > Create Metric in the search action toolbar.
- In the pop-up window, give your metric a name and a description.
The name determines how the metric appears in the Metrics panel and the Metric Browser. Keep in mind:
- Metrics are truncated to whole values. So values less than one are truncated to zero. To work around this, you can multiply a numeric_field_name by a factor of 10, 100, 1000, and so on, depending on the level of decimal accuracy you need. We recommend that you add this factor into the metric display name so other users can understand what the metric represents, for example, Display Name = Metric (Factor 1000). In cases where the value is a percentage, and you convert by multiplying by 100, you probably don't need to put the factor in the metric name because it would be implicit (Metric %).
- Math operations are only supported inside the aggregation function. For example,
count(numeric_field_name * 10) from transactions.
Timestamp metrics always aggregate events from the current minute because metrics are created for events published in the last minute.
If you have specified a value for the
eventTimestamp field, the timestamp value in the new metric uses an aggregation of events from the pickupTimestamp field.
For example, you set an
eventTimestamp for an event on a previous day. You then create a metric for the event today. The metric does not use your explicit
eventTimestamp because it is no longer from the current minute. The metric aggregates events using
pickupTimestamp. This ensures that the metric timestamp is based on the current minute because
pickupTimestamp cannot be explicitly changed.
See Analytics Events API.
Correlate Metrics from Multiple Events
When you create a query, AppDynamics produces a holistic metric. Because the queried data comes from different events, the Events Service has to retrieve this segmented data and stitch it together to produce a single metric. The Events Service waits for correlated events to arrive, where the maximum wait time depends on the event type:
- Mobile and Browser Session Events - two minutes.
- Transaction Events - ten seconds.
The wait time resets when the Events Service finds a correlated event.
If an event arrives after the maximum wait time, the event is not stitched together correctly in your query. For example in the following query
fieldB are separate but correlated events:
select count(*) from transactions where fieldA = "foo" and fieldB = "bar"
The Events Service finds
fieldA and waits 10 seconds for a correlated event. If
fieldB arrives 15 seconds after
fieldA, the Events Services does not correlate both events. The count metric is now inaccurate because the events are not connected.
Monitor Analytics Metrics
For performance reasons, the scheduled queries used in analytics metrics can be disabled as follows:
- Queries are deactivated if calling the Events Service results in any errors ten consecutive times.
- Queries are not deactivated if the Events Service is not reachable from the controller, such as during maintenance and upgrade windows.
- When the Controller is restarted, the queries which were previously disabled by the system due to consecutive failures are re-enabled.
- User-deactivated queries remain inactive even after the system is restarted.
To monitor the metric:
- Click Metrics in the left navigation bar.
Search, edit, enable, disable, or delete metrics from the Metrics list.
You can edit only the description of the selected metric.
To activate or deactivate metrics in a batch, select the corresponding rows in the grid and click the Enable or Disable button in the toolbar. Use Shift+ click or Command + click rows to select multiple rows.
If you see a status that says "Disabled due to repetitive failures", you can re-enable it by clicking Enable.
To see the metric in the Metric Browser, click the Metric Browser. For more details, see the section "Metric Data Point Details" in Metric Browser.