Calculate DESK monitoring consumption

When OneAgent is integrated using Universal injection, operation of OneAgent is based on the application level (i.e, application-only monitoring). In such cases, where OneAgent isn't installed on the host level (physical or virtualized), the memory detection for host unit calculation is done per operating system instance (for example, container, Azure AppService instance, Solaris Zone) that the application runs on, with consideration of the memory limits that are set on this layer (for example, container memory limits).

If no memory limit is set, higher host-unit requirements may result as the reported available memory is typically the underlying host memory.

Example

A Docker host with 16 GB RAM running 2 containers, monitored with application-only:

Variant-1: Without a memory limit set, 2 host units will be consumed in total as 16 GB RAM per container are reported.

Variant-2: With a memory limit set to 4 GB per container, 0.5 host units will be consumed in total as 4 GB RAM per container are reported.

Monitoring the Docker host in full-stack monitoring mode would consume 1 host unit because the memory reported from the Docker host is used for licensing (1x 16 GB RAM).

If you've arranged for an allotment of host units to monitor your hosts and you're entitled to exceed this number (i.e., overages are allowed for your account), the overages will be calculated in host unit hours. For example, if you've arranged to monitor up to 10 host units (a maximum of 160 GB total RAM) and your account allows for overages, if you connect another host that equates to 2 host units you'll have 12 host units in total and will, therefore, have exceeded your quota by 2 host units. If you continue to monitor your hosts using 12 host units for a full week, you'll accrue an overage of 336 host unit hours.
2 (host units) x 24 (hours a day) x 7 (days) = 336 (overage host unit hours)
To add or remove overages from your account, contact DESK Sales.

For example, say you have 1,000 host unit hours available and you want to monitor a host that has 64 GB RAM (which equates to 4 host units). If you keep the host running for a full day, it will consume 96 host unit hours.
4 (host units) x 24 (hours a day) = 96 (host unit hours)

The 1,000 host unit hours will be consumed in slightly more than 10 days.
4 (host units) x 24 (hours) x 10 (days) = 960 host unit hours

Each minute, DESK calculates host unit consumption based on true concurrency. This means that two hosts running within the same hour will only count as 2 hosts units if both hosts run at the same time.

If a host runs for less than 5 minutes, it doesn't count against your host unit hour quota. A host running for 5 minutes or longer is rounded up to 1 host unit hour.

Example 1

You have a host with 16 GB RAM (which equals 1 host unit) running from 10:00-10:30 AM. At 10:30 you spin up another host of the same size. DESK considers this a single host unit because the hosts don't run concurrently.

Example 2

If you start the first host at 10:00 AM and launch another host at 10:30 AM. Both hosts run for 30 minutes and are then shut down at the same time. DESK considers this to be 2 host units because both hosts run at the same time.

Example 3

One host of size 16 GB RAM is started and stopped three times within an hour:

12:10 - Server start
12:20 - Server stop

12:30 - Server start
12:40 - Server stop

12:50 - Start
13:00 - Stop

Such a scenario equates to 1 host unit hour because true concurrency is taken into account.

Host unit hours are used for DESK free trials. When you sign up for a DESK free trial, you receive a certain number of host unit hours to evaluate DESK.

If you know in advance that your base quota of host units will be exceeded due to holiday demand or a short-lived project (for example, on Black Friday or during a one-time testing initiative), you can use host unit hours rather than host units to manage variable traffic spikes. For example, if you have a pool of 9,000 host unit hours and 100 host units, during Black Friday, you'll need more hosts to scale up for the increased traffic on your site. In such a case, you have the option of using all 9,000 host unit hours in a single day. This would enable you to connect an additional 375 host units (475 total maximum) to DESK for one day.
9,000 (host unit hours) / 24 (hours) + 100 (base quota of host units) = 475 (max. host units)

If your account has multiple monitoring environments, e.g., one for development and the other one for production, then overages are calculated per account and not per environment. Only when the account quota is exceeded, then overages are incurred.

For example, you licensed 100 host units and you have two environments, one for production and one for testing. You assign 80 host units to the production environment and 20 host units to the testing environment. Your license entitles you for overages (you can see this in the account overview below the host units circle). If production uses 70 host units but testing uses 30 host units, the total account quota of 100 host units is not exceeded thus no overages are incurred. Only if both environments use more than 100 host units overages are incurred.

A single Real User Monitoring session (i.e., a "user session") is defined as a sequence of interactions between a user with a browser-based web application or a native iOS or Android mobile app within an interval and with at least two user actions. A user action is a button click or app start that triggers a web request (for example, a page load or a page-view navigation). Interactions that include only one user action are considered “bounced” and aren't counted. A user who interacts with more than one web application or app at the same time consumes one session for each web application or app, except when the interaction is considered “bounced”. A session ends when a) the browser running a web application is closed or has been inactive for more than 30 minutes, b) the mobile app is closed or the client is inactive for more than 30 minutes, or c) after 60 minutes of continuous interaction with the web application or app.

If you've set up an annual RUM sessions quota, your usage will reset annually.

A browser monitor or browser clickpath “synthetic action” is an interaction with a synthetic browser that triggers a web request that includes a page load, navigation event, or action that triggers an XHR or Fetch request. Browser monitors perform a single synthetic interaction (for example, measuring the performance and availability of a single URL) and consume one synthetic action per execution. Clickpath monitors are sequences of pre-recorded synthetic actions. Clickpaths consume one action per each interaction that triggers a web request. Scroll downs, keystrokes, or clicks that don't trigger web requests aren't counted as actions.

An HTTP monitor consists of one or multiple HTTP(S) requests (for example, GET, POST, HEAD requests). Each request executed by an HTTP monitor equates to one synthetic request.

# Synthetic actions/requests consumed per monitor = (# Synthetic actions included in monitor) x (# Executions per hour) x (# Locations) x # Hours

XHR or Fetch requests that are made by a synthetic browser as the result of a user action like a page load, which isn't directly triggered by user input, don't result in user actions and therefore aren't counted. Such XHR and Fetch calls are considered child requests of synthetic actions.

Synthetic actions/requests calculation example

For example, a recorded browser clickpath that navigates through 2 pages and clicks 1 button that triggers an XHR or Fetch request consumes 3 synthetic actions. If such a synthetic monitor runs every 15 minutes from 2 locations for 1 day, the browser clickpath will consume 576 synthetic actions per day.
3 (synthetic actions) x 4 (monitor executions per hour) x 2 (locations) x 24 (hours per day) = 576 (synthetic actions)

For more details, see synthetic monitoring.

If you've arranged for Digital Experience Monitoring overages (i.e., your account allows you to exceed the maximum limit of DEM units), the units you consume as overage are counted just as with regular DEM unit consumption; each additional overage session or synthetic test increases the amount of DEM units consumed by your account. To add or remove overages from your account, contact DESK Sales.

Log Monitoring consumption is based on anticipated GiB of annual average log storage size, which is calculated as the average annual daily ingestion of uncompressed log data multiplied by the number of days. Once this limit is reached, you need to contact DESK Sales to arrange for additional capacity.
Annual average daily log storage = Actual annual storage / (# of days)

Log storage calculation example

Say, for example, that your Log Monitoring agreement is configured for 90 days and you've arranged for 450 GiB of annual daily average storage. The anticipated average daily ingestion of log data in this case would be 5 GiB.
450 (GiB; base quota of annual average storage) / 90 (days) = 5 (GiB; anticipated average daily ingestion)

Once the annual equivalent of 1,825 GiB is ingested and exceeded, the annual average storage size of 450 GiB is also reached.
5 (GiB; anticipated average daily ingestion) x 365 (days) = 1,825 (GiB; anticipated average annual ingestion)

Continuing with the example above, if after six months your actual log ingestion is only 912.5 GiB (50% of the anticipated 1,825 GiB), then you might decide to re-configure your Log Monitoring allotment down to 45 days while leaving the annual average storage capacity unchanged at 450 GiB. In this case, the anticipated average daily ingestion of log data for the subsequent six months would be 10 GiB.
450 (GiB; average annual capacity) / 45 (days) = 10 (GiB; anticipated average daily ingestion)

Once the annual equivalent of 2,737.5 GiB is ingested, the annual average storage size of 450 GiB is also reached.
(5 x 182.5) + (10 x 182.5) = 2,737.5

If you've arranged for annual log storage capacity, your usage will reset annually (DESK SaaS only).

Log Monitoring overages (optional) - SaaS deployments

If you've arranged for Log Monitoring overages so that you can exceed your agreed upon maximum limit of anticipated annual average storage size, your overages will be calculated based on the difference between your storage size limit and your actual storage size. For example, if you have an agreed upon storage limit of 450 GiB and your actual consumption is 500 GiB, you'll have 50 GiB in overages.
500 (GiB; actual average storage size) - 450 (GiB; average storage size limit) = 50 (GiB; overages)
To add or remove overages from your account, contact DESK Sales.

Log Monitoring consumption is based on anticipated GiB of annual average log storage size, which is calculated as the average annual daily ingestion of uncompressed log data. Once this limit is reached, you need to contact DESK Sales to arrange for additional capacity.

For example, if during an annual period the total log data sent to your DESK Managed Cluster is 730 GiB, then the "per day" rate of annual average ingestion would be 2 GiB.
730 (GiB; actual annual ingestion) / 365 (days) = 2 (GiB; annual average daily ingestion)

If you've arranged for annual log storage capacity, your usage will reset annually.

Log Monitoring overages (optional) - Managed deployments

If you've arranged for Log Monitoring overages so that you can exceed your agreed upon maximum limit of daily log storage, your overages will be calculated based on the difference between your daily storage limit and your actual daily storage size. For example, if you have an agreed upon storage limit of 10 GiB/day and your actual consumption is 12 GiB/day, you'll have 2 GiB/day in overages.
12 (GiB; actual daily log storage) - 10 (GiB; daily log storage limit) = 2 (GiB; daily overage)
To add or remove overages from your account, contact DESK Sales.

Each DESK environment (SaaS or Managed) comes with 5 GB of log data storage, per year at no cost to you.

Custom metrics are consumed per component and per collected dimensional value. Here are some examples:

1. A File count metric actively collected for 2 hosts equates to 2 custom metrics.
2. A File count metric actively collected for 5 different folders across 10 hosts equates to 50 custom metrics.
   5 * 10 = 50 (custom metrics)
3. A File count metric actively collected for 5 different folders (with each folder representing a separate dimensional value) equates to 5 custom metrics.
   5 * 1 = 5 (custom metrics)

"Actively collected" means that at least one data point is reported for the custom metric within a sliding window of 24 hours. Custom metrics aren't factored into your consumption when no data is written to them for 24 hours or more.

Note that for DESK versions earlier than 1.168, the sliding window was defined at 28 days.

If your agreement specifies a maximum limit of 10K custom metrics ingested during any 24-hour period, and there's a risk that you'll exceed this amount during periods of peak traffic, consider setting up overages for custom metrics. With overages enabled, at peak times you can go beyond the maximum limit.

Say, for example, that you have an agreement for a limit of 100 custom metrics during any 24 hour period, you have overages enabled for custom metrics, and for the first 15 days of DESK usage, your environment ingests 90 custom metrics that are reported by custom OneAgent plugins. If on day 16 your team enables a custom plugin that collects an additional 30 custom metrics (now 120 total custom metrics), you'll have 20 in custom metrics overages.
120 (actual custom metrics usage) - 100 (custom metrics limit) = 20 (custom metrics overages)

Each DESK environment (SaaS or Managed) comes with 100 free custom metrics. Additionally, 10 free custom metrics are provided for each of your allotted host units. For example, if you have 100 host units, you will be provided with 1,100 custom metrics.
100 + 10 * 100 = 1,100 (custom metrics)

There's a maximum free tier limit of 10,000 custom metrics.