Skip to end of metadata
Go to start of metadata

On this page:

Related pages:

Experience Level Management (XLM) enables you to configure and monitor compliance targets that impact your business and users. It also lets you service level agreements (SLAs) through application performance monitoring. 

How it Works

Whether you speak of an experience level or a service level depends on whether your focus is user experience or SLAs, but you configure both through the same XLM UI. What this section says about experience levels applies equally to service levels. 

You can define experience levels for any kind of data that meets the following criteria:

  1. The data must be numerical.

  2. The data must be individual (per event) values, not aggregates.

Since data collectors provide individual values, they are a good basis for experience levels as long as the values are numeric. By contrast, metrics and information points cannot be used as the basis for experience levels, because they provide aggregate values.

The follow are all good bases for defining experience levels:

  • Sales in dollars per week during the time an ad campaign is running

  • Application response times calculated from business transaction events

  • End user response times calculated from RUM and synthetic events

  • Custom analytics such as login times for platinum customers or item checkout response times for London customers

Compliance against the configured thresholds is calculated at midnight and noon UTC, beginning on the start date you specify. Thus, two reporting jobs run every twenty-four hours.

XLM aggregates the results of reporting jobs into weekly or monthly periods, according to your choice of Compliance Period settings, including Time Zone.

When viewing XLM data for a week or month, you can drill down into daily granularity. XLM also allows you to

  • Create XLM reports in the time zone of your choice 
  • Export reports of however many reporting periods you choose, in CSV format
  • Add your XLM report to a custom dashboard for periodic generation and delivery

You can export XLM configurations, and migrate them from one environment to another. You can also view and export the XLM Audit Trail, which automatically records XLM configurations and changes to them. 

If you revise the configuration, the new configuration takes effect the next time the XLM reporting job runs. Past data is immutable and configuration changes do not affect the values.

To see which configuration was in effect at a particular moment in a reporting period, view the XLM Audit Trail.

XLM Monitoring

Compliance against the configured thresholds is calculated in daily intervals from the specified start date. The local time zone start for each day is converted to midnight of the equivalent UTC date. For example, 07/30 means UTC 12:00 am on 07/30. The reporting job that calculates the XLM data runs every day at midnight and noon UTC. The results are updated the next time the reporting job runs.

If you revise the configuration during a compliance period, the next time the job runs, compliance is computed with the configuration that is in effect at that time. Once time has passed over a compliance period, the past data is immutable and configuration changes do not affect the values.

Note that XLM data is calculated using UTC time zone for time-based calculations.

XLM Exclusion Periods

The XLM queries executed against your Analytics event data observe configured exclusion periods. Exclusion periods cover the UTC equivalent of the Controller's local time zone because exclusion periods are always resolved to UTC time, even though you configure the exclusion period as local time in the Controller UI. This means that some events may fall on a certain day in your local time zone, but a different day in UTC time.

For example, if you specify an exclusion period for Friday 1am to 11pm and you are in the Pacific time zone (which is GMT -7), the exclusion period is resolved to Friday 8AM - midnight and Saturday midnight - 6am.

XLM does not automatically recognize controller-level exclusion and maintenance periods. In such cases, you need to explicitly add those exclusion periods in XLM.

XLM Auditing

All changes to XLM configurations produce an immutable audit record.  The XLM audit reporting is completely separate and distinct from other reports available in the AppDynamics Controller UI, such as the Controller Audit Report.

The XLM audit records contain information about the operation that was performed and the fields that were changed. In the UI, the audit records are presented as a sequential timeline:

Audit History Size Constraints  

There islimit of 1000 updates to each XLM configuration. If that limit is reached, the oldest audit records are dropped as new ones are added.

Watch the Video

For full-screen viewing, click Experience Level Management.