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 the following table. For a discussion of metric rollup types see Metric Data Resolution over Time.
|Function||Metric Rollup Type||Example|
|count(* | field_name)||sum||SELECT count( activeMacUsers) FROM dummyTransactions|
|average||SELECT distinctcount(activeMacUsers) FROM dummyTransactions|
|sum||SELECT sum(responseTime)where userExperience = "NORMAL" FROM transactions|
|SELECT avg(responseTime) FROM transactions|
|SELECT min(responseTime) FROM transactions|
|SELECT max(responseTime) FROM transactions|
SELECT (count(activeMacUsers)) / (avg(activeWindowsUsers)) FROM dummyTransactions
Each side of the expression must be enclosed in parenthesis.
To create metrics from analytics searches, you need the following permissions:
- Manage Metrics permission
- View access to the default Analytics Application
For more information, see:
Creating 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 screen 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 explicity changed.
Learn more about timestamps in 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 - 2 minutes
- Transaction Events - 10 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:
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.
Monitoring Analytics Metrics
For performance reasons, the scheduled queries used in analytics metrics can be disabled as follows:
- Queries are disabled if calling the Events Service results in any errors for ten consecutive times.
- Queries are not disabled 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-disabled queries remain disabled even after the system is restarted.
To monitor the metric:
- Click Metrics in the left navigation bar.
The Metrics list appears.
- Search, edit, enable, disable, or delete metrics from here.
You can edit only the description of the selected metric.
To enable or disable 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.