diff --git a/images/change_ephemerality.png b/images/change_ephemerality.png new file mode 100644 index 000000000..399d48207 Binary files /dev/null and b/images/change_ephemerality.png differ diff --git a/images/metrics_browser.png b/images/metrics_browser.png index cced3f2b0..e9f2776c6 100644 Binary files a/images/metrics_browser.png and b/images/metrics_browser.png differ diff --git a/images/metrics_browser_RNs.png b/images/metrics_browser_RNs.png new file mode 100644 index 000000000..ca19b23fc Binary files /dev/null and b/images/metrics_browser_RNs.png differ diff --git a/pages/doc/authorization_faq.md b/pages/doc/authorization_faq.md index b891fc4c3..9870dea18 100644 --- a/pages/doc/authorization_faq.md +++ b/pages/doc/authorization_faq.md @@ -30,6 +30,7 @@ When a Super Admin user [enables Super Admin mode](users_account_managing.html#e * Can [restore orphan dashboards and alerts](access.html#make-orphan-dashboards-or-alerts-visible). * Can invite other Super Admin users. * Can [sign out a user](user-accounts.html#sign-out-a-user). +* Can [convert metrics](metrics_managing.html#change-the-retention-period-of-metrics) from persistent to ephemeral and the reverse. * Can purchase more PPS. To invite other Super Admin users: diff --git a/pages/doc/cardinality.md b/pages/doc/cardinality.md index a8184c368..ce046f6eb 100644 --- a/pages/doc/cardinality.md +++ b/pages/doc/cardinality.md @@ -101,7 +101,7 @@ Although Operations for Applications supports high cardinality for time series d 1. Ensure that the metric names are stable and do not change. 2. Keep source names stable. Source names change over time, but make sure that they don't change frequently. - 3. Use point tags for data that are ephemeral. + 3. Use point tags and [ephemeral metrics](metric_types.html#metric-types-per-retention-period) for data that is ephemeral. 4. In Kubernetes, where point tags are usually called labels, add only the point tags that you really need. For information about metric, source, and point tag names, see [Operations for Applications Data Format Best Practices](wavefront_data_format.html#operations-for-applications-data-format-best-practices). You can also understand more about the metrics structure, sources and the sources browser, and tags, by exploring [Metrics and the Metrics Browser](metrics_managing.html), [Sources](sources_managing.html), and [Organizing with Tags](tags_overview.html). diff --git a/pages/doc/metric_types.md b/pages/doc/metric_types.md index 43821cbd6..02a484e9c 100644 --- a/pages/doc/metric_types.md +++ b/pages/doc/metric_types.md @@ -18,12 +18,14 @@ summary: Learn about gauges, counters, delta counters, histograms, and spans. ## Summary of Metric Types +### Metric Types per Data Type + The following table gives an overview of metric types. We introduce each type in more detail below. - + @@ -32,7 +34,7 @@ The following table gives an overview of metric types. We introduce each type in - + @@ -55,7 +57,28 @@ The following table gives an overview of metric types. We introduce each type in + +
MetricDescriptionExample
Metric TypeDescriptionExample
Gauge
CounterShows values as they increase (and decrease).Shows values as they increase. Counters only accumulate or reset to zero (do not decrease). Number of failed connections, registered users.
Spans are the fundamental units of trace data. Each span corresponds to a distinct invocation of an operation that executes as part of the request. For example, in our BeachShirts sample application, we have the beachshirts.shopping operation, which includes many invocations of the Printing.getAvailableColors span.
+ +### Metric Types per Retention Period +With the 2024-07 release, we introduce **ephemeral** metrics, which have a short [retention period](terms_of_service.html#data-retention). + + + + + + + + + + + + + +
Metric TypeDescription
Persistent18 months of data retention. By default, all metrics and counters are persistent. Metrics are convertible to ephemeral.
Ephemeral28 days of data retention. Suitable for metrics that are relevant for a short time and that have high cardinality, such as the Kubernetes metrics (kubernetes.). +

Converting metrics from persistent to ephemeral improves the query performance and reduces the cardinality.

+
diff --git a/pages/doc/metrics_managing.md b/pages/doc/metrics_managing.md index 7f47dfa87..fcdb766ea 100644 --- a/pages/doc/metrics_managing.md +++ b/pages/doc/metrics_managing.md @@ -97,41 +97,26 @@ In the Metrics browser and Query Editor, obsolete metrics are no longer shown in Select **Browse > Metrics** to display the Metrics Browser. Use the Metrics Browser to find metrics that are actively sending data points. -{% include note.html content="The Metrics browser filters out the obsolete metrics." %} +{% include note.html content="The Metrics Browser filters out the obsolete metrics." %} -To make search easier, you can -* Drill down and go up the hierarchy. -* Filter by source. -* Hide and redisplay metrics or groups of metrics to unclutter your page. - -{% include tip.html content="If you select **Browse > Delta Counters** you can use the same browser to examine [delta counters](delta_counters.html)." %} - -![metrics browser with pointers to folder & chart icon for selection, source filter, and info button which displays sources and point tags for a metric](images/metrics_browser.png) - -### Examine Metrics +![An annotated screenshot of the Metrics Browser. The information is listed below.](images/metrics_browser.png) - - - - - - - -
-To examine metrics -
    -
  1. Select Browse > Metrics
    2. -
  2. Select folder icons to drill down to individual metrics.
    3. -
  3. With a metric selected, click Expand Info to show sources and point tags for that metric.
    4. -
  4. Click the metric name to show a chart with that metric.
    5. -
browse metrics
+On the Metrics Browser, you can: +* Drill down and go up the hierarchy. +* Filter by name or source. +* Hide and redisplay individual metrics or metrics namespaces to unclutter your page. +* View the metric type in terms of retention period - persistent or ephemeral. +* Convert persistent metrics to ephemeral and the reverse. +* Create a chart or dashboard for an individual metric or for the current set of metrics. +* View the sources and point tags for an individual metric. +{% include tip.html content="If you select **Browse > Delta Counters** you can use the same browser to examine [delta counters](delta_counters.html). The only difference is that counters are persistent and not convertible to ephemeral." %} -## Hide and Redisplay Metrics +### Hide and Redisplay Metrics -While obsolete metrics are automatically hidden, you can manually hide metrics from the Metrics browser. Manually hiding metrics does not permanently delete a metric or metric namespace. +While [obsolete metrics](metrics_managing.html#obsolete-metrics) are automatically hidden, you can manually hide metrics from the Metrics browser. Manually hiding metrics does not permanently delete a metric or metric namespace. -{% include shared/permissions.html entity="metrics" entitymgmt="Metric" %} +{% include shared/permissions.html entity="metrics" entitymgmt="Metrics" %} {% include note.html content="Hidden metrics are removed from the autocomplete drop-down lists, but you can still use these metrics in queries as long as data points exist." %} @@ -141,14 +126,13 @@ While obsolete metrics are automatically hidden, you can manually hide metrics f To hide one or more metrics:
    -
  1. Select Browse > Metrics
    2. -
  2. Click the Manage Hidden Metrics button
    3. -
  3. In the dialog type a complete metrics name (e.g. requests.latency) or a metric prefix (e.g. requests., cpu.loadavg.). +
  4. Select Browse > Metrics.
    5. +
  5. Click the Manage Hidden Metrics button.
    6. +
  6. In the dialog box, type a complete metric name (e.g. requests.latency) or a metric prefix (e.g. requests., cpu.loadavg.).
  7. Press Enter to add the metric(s) to the list and click Save.
@@ -163,7 +147,7 @@ While obsolete metrics are automatically hidden, you can manually hide metrics f To view hidden metrics:
    -
  1. Select Browse > Metrics
    2. +
  2. Select Browse > Metrics.
  3. Click the Manage Hidden Metrics button.
  4. Click the Unhide button to the right of the metric or metric prefix to unhide and click Save.
@@ -174,6 +158,37 @@ The selected metrics and metric prefixes appear again as long as they are not ob +### Change the Retention Period of Metrics + +With the 2024-07 release, we introduce **ephemeral** metrics, which have short [retention period](terms_of_service.html#data-retention). By default, all ingested metrics are persistent but are convertible to ephemeral. + +Converting persistent metrics to ephemeral can significantly improve the [query performance](query_language_performance.html) and reduce the [cardinality](cardinality.html). + +{% include note.html content="To change the retention period of a metric or metrics namespace, you must be a Super Admin user with [enabled Super Admin mode](users_account_managing.html#enable-or-disable-super-admin-mode)." %} + +{% include important.html content="Converting a persistent metric to ephemeral **permanently deletes** the data points of this metric that are older than 28 days." %} + + + + + + + + +
+
    +
  1. Select Browse > Metrics.
    2. +
  2. Click the Change Ephemerality button.
    3. +
  3. To convert a persistent metric or metrics namespace to ephemeral, in the Select Metric Prefix text box, enter the target metric name or namespace prefix, and press Enter. +

    The metric name or namespace prefix appears in the Ephemeral Metrics table below. You can repeat this step for multiple metrics and metrics namespaces.

    4. +
  4. To convert an ephemeral metric or metrics namespace to persistent, in the Ephemeral Metrics table, locate the target metric or namespace prefix and click the corresponding Convert to Persistent Metric action.

    The metric name or namespace prefix disappears from the Ephemeral Metrics table. You can repeat this step for multiple metrics and metrics namespaces.

    5. +
  5. Click Save.
    6. +
A screenshot of the Change Ephemerality dialog box.
+ +Changing the retention period of a metric or metrics namespace creates a [System event](events.html): +* Converting a persistent metric to ephemeral creates a System event with the name `Ephemeral Prefix: Added `. +* Converting an ephemeral metric to persistent creates a System event with the name `Ephemeral Prefix: Removed `. + ## Learn More! * [Optimizing the Data Shape to Improve Performance](optimize_data_shape.html) diff --git a/pages/doc/missing_data_troubleshooting.md b/pages/doc/missing_data_troubleshooting.md index 36584684f..eb6f277ea 100644 --- a/pages/doc/missing_data_troubleshooting.md +++ b/pages/doc/missing_data_troubleshooting.md @@ -7,7 +7,7 @@ permalink: missing_data_troubleshooting.html summary: Learn how to troubleshoot when you expect to see data but it doesn't appear in charts. --- -Sometimes you expect to see certain data in VMware Aria Operations for Applications (formerly known as Tanzu Observability by Wavefront) but, for some reason, it doesn't show up! This can be a frustrating and confusing experience, especially when you urgently need the data. Operations for Applications does not delete data, and retains [metric data for 18 months](terms_of_service.html#data-retention). What could be the problem? +Sometimes you expect to see certain data in VMware Aria Operations for Applications (formerly known as Tanzu Observability by Wavefront) but, for some reason, it doesn't show up! This can be a frustrating and confusing experience, especially when you urgently need the data. Operations for Applications does not delete data - the [retention period](terms_of_service.html#data-retention) is 18 months for persistent metrics and 28 days for ephemeral metrics. What could be the problem? This doc page, based on the extensive experience of our customer success team, helps you investigate, understand, and remedy possible causes. In addition to manually investigating and troubleshooting your issues, you can use the [Query Analyzer](query_language_performance.html#use-the-query-analyzer) which helps you identify where exactly the problem is. diff --git a/pages/doc/proxies_configuring.md b/pages/doc/proxies_configuring.md index f793efcb6..5a8bd1b7b 100644 --- a/pages/doc/proxies_configuring.md +++ b/pages/doc/proxies_configuring.md @@ -145,7 +145,7 @@ This section gives details on the proxy configuration properties. All properties agentMetricsPointTags -Point tags and their values to be passed along with ~agent.* metrics.
Default: none +Point tags and their values to be passed along with ~proxy.* metrics.
Default: none Comma-separated list of key-value pairs.
Ex: dc=west,env=prod 3.24 diff --git a/pages/doc/query_language_performance.md b/pages/doc/query_language_performance.md index 5065ac8c6..dd156ab40 100644 --- a/pages/doc/query_language_performance.md +++ b/pages/doc/query_language_performance.md @@ -40,7 +40,10 @@ Watch this video to learn how to optimize dashboard and query performance. Note ## Use Performance Statistics You can see performance statistics for the whole chart and for each query of the chart. For the performance statistics, we measure the following characteristics: -- **Cardinality**: Number of unique time series. A unique time series has unique metric name, source name and point tags (key and value). For example, you might receive `networks_bytes_received` from multiple sources and with multiple point tags (e.g. `availability_zone`). You can lower cardinality for each query (and the chart) by filtering, for example, limiting the query to certain sources, certain availability zones, etc. +- **Cardinality**: Number of unique time series. A unique time series has unique metric name, source name and point tags (key and value). For example, you might receive `networks_bytes_received` from multiple sources and with multiple point tags (e.g. `availability_zone`). You can lower cardinality for each query (and the chart) by: + + - Filtering, for example, limiting the query to certain sources, certain availability zones, etc. + - Using [ephemeral metrics](metric_types.html#metric-types-per-retention-period), which have a shorter retention period. - **Points Scanned**: Number of data points that were queried to show the chart on the screen. You can affect this number by including the time window in the query or by changing the time window interactively. - **Duration**: Time between query start and return of result. diff --git a/pages/doc/query_language_series_matching.md b/pages/doc/query_language_series_matching.md index 8d6aed476..36a383478 100644 --- a/pages/doc/query_language_series_matching.md +++ b/pages/doc/query_language_series_matching.md @@ -289,7 +289,7 @@ You can use `groupRight` and `groupLeft` operators to achieve many-to-one and on For example, when we use the `groupRight` operator in the query below, we see results with the `processId` tag which is on the right side of the operator. ``` -sum(ts(~agent.listeners.connections.*), port, processId) + by(processId) groupRight sum(ts(~agent.points.2878.blocked), processId) +sum(ts(~proxy.listeners.connections.*), port, processId) + by(processId) groupRight sum(ts(~proxy.points.2878.blocked), processId) ``` ![A chart created with the above query with one dimension shown in the pinned legend - processId.](images/groupRight.png) @@ -297,7 +297,7 @@ sum(ts(~agent.listeners.connections.*), port, processId) + by(processId) groupRi In the example below, we use the `groupLeft` operator. Therefore, we see results with the `port` and `processId` tags, which are on the left side of the operator. ``` -sum(ts(~agent.listeners.connections.*), port, processId) + by (processId) groupLeft sum(ts(~agent.points.2878.blocked), processId) +sum(ts(~proxy.listeners.connections.*), port, processId) + by (processId) groupLeft sum(ts(~proxy.points.2878.blocked), processId) ``` ![A chart created with the above query with two dimensions shown in the pinned legend - port and processId.](images/groupLeft.png) diff --git a/pages/doc/terms_of_service.md b/pages/doc/terms_of_service.md index 766ee0437..d1fc2d9a9 100644 --- a/pages/doc/terms_of_service.md +++ b/pages/doc/terms_of_service.md @@ -12,19 +12,24 @@ The terms of service and data retention for VMware Aria Operations for Applicati ## Data Retention -A production instance retains different types data for different amounts of time. While this is subject to change, here are the default settings: +A production instance retains different types of data for different amounts of time. While this is subject to change, here are the default settings: - - + + + + - + - +
Type of DataRetention
metrics and counters18 months of full-resolution (no downsampling)
metrics
  • For persistent (default) metrics, 18 months of full-resolution (no downsampling).
    • +
  • For ephemeral metrics, 28 days of data detention.
+See Metric Types per Retention Period.
counters18 months of data retention. +
histograms6 months of data retention
6 months of data retention.
spans7 days retention. With spans, we use Intelligent Sampling. Use trace sampling policies explicitly exclude certain spans.
7 days of retention. With spans, we use Intelligent Sampling. Use trace sampling policies explicitly exclude certain spans.
@@ -32,7 +37,7 @@ A production instance retains different types data for different amounts of time Your Terms of Service are different depending on when you became a customer. -Production clusters currently offer 18 months of full-resolution (no downsampling) data retention for metrics, 6 months for histograms, and 7 days for spans. We also have an uptime guarantee, as well as High Availability (HA) and Disaster Recovery (DR) options. +Production clusters currently offer 18 months of full-resolution (no downsampling) data retention for persistent metrics, 28 days for ephemeral metrics, 6 months for histograms, and 7 days for spans. We also have an uptime guarantee, as well as High Availability (HA) and Disaster Recovery (DR) options. If you became a customer on or after August 17, 2017: diff --git a/pages/doc/wavefront_internal_metrics.md b/pages/doc/wavefront_internal_metrics.md index 62c011760..96089a780 100644 --- a/pages/doc/wavefront_internal_metrics.md +++ b/pages/doc/wavefront_internal_metrics.md @@ -12,7 +12,6 @@ You can: * Clone and modify one of the Operations for Applications Usage integration dashboards. * Create your own dashboard, query these metrics in charts, and create alerts for some of these metrics. - ## Internal Metrics Overview We collect the following sets of metrics. diff --git a/pages/doc/wavefront_kubernetes.md b/pages/doc/wavefront_kubernetes.md index 379f053d5..272ea590a 100644 --- a/pages/doc/wavefront_kubernetes.md +++ b/pages/doc/wavefront_kubernetes.md @@ -89,11 +89,11 @@ To use our Kubernetes Metrics Collector, you must set up our Kubernetes integrat ## Monitor Kubernetes -Our Kubernetes Metrics Collector supports monitoring for your Kubernetes infrastructure at all levels of the stack. +Our Kubernetes Metrics Collector supports monitoring for your Kubernetes infrastructure at all levels of the stack. See the [list of metrics collected by the Kubernetes Metrics Collector](kubernetes.html#metrics). * Set up the Kubernetes Collector to have much of the monitoring happen automatically. * Fine-tune and customize the solution with configuration options available in the Operations for Applications Kubernetes Metrics Collector. -{% include note.html content="See the [list of metrics collected by the Kubernetes Metrics Collector](kubernetes.html#metrics)." %} +{% include tip.html content="To avoid [high-cardinality](cardinality.html) and ensure optimal [query performance](query_language_performance.html), consider reducing the retention period of the Kubernetes metrics from 18 months (default) to 28 days. For that purpose, convert the `kubernetes.` metrics namespace from persistent to ephemeral. For details, see [Change the Retention Period of Metrics](metrics_managing.html#change-the-retention-period-of-metrics)." %} ### Infrastructure Monitoring diff --git a/pages/doc/wavefront_monitoring.md b/pages/doc/wavefront_monitoring.md index 852605eb1..17ce16864 100644 --- a/pages/doc/wavefront_monitoring.md +++ b/pages/doc/wavefront_monitoring.md @@ -91,10 +91,10 @@ The **Logs Stats** section contains charts that track the amount of logs that ar These charts use the following metrics: -- `~agent.logs.*.delivered` -- Number of log bytes successfully delivered. +- `~proxy.logs.*.delivered` -- Number of log bytes successfully delivered. - `~wavefront.logservice.api.bytesQueried.total.bytes` -- Number of log bytes successfully queried. - `~proxy.logs.*.received.bytes` -- Number of log bytes received by the proxy. -- `~agent.logs.*.received.max-burst-rate` -- Maximum burst rate of incoming logs. +- `~proxy.logs.*.received.max-burst-rate` -- Maximum burst rate of incoming logs. - `~proxy.buffer.logs-count` -- Number of delayed log bytes stored on disk. Logs can be queued for the following reasons: - Intermittent failures in communication with the backend. - A surge of incoming data in excess of thread buffer size. diff --git a/pages/doc/wavefront_obsolescence_policy.md b/pages/doc/wavefront_obsolescence_policy.md index 75310e045..c0b383040 100644 --- a/pages/doc/wavefront_obsolescence_policy.md +++ b/pages/doc/wavefront_obsolescence_policy.md @@ -167,6 +167,20 @@ For the above example if the data measured across 3 minutes had been a total of: Starting with release 2020.26, a new data type for storing delta counters is part of the product. Data ingestion of delta counters remains unchanged, and a delta (∆) is still required to indicate a delta counter, but the data is now queried via `cs()` instead of `ts()`. The original delta counters still report minutely, but instead of maintaining a monotonically increasing count they report the total number of increments that occurred within each minute. In our example, `cs(errors.count)` displays values of 10, 15, and 5. See [Counters and Delta Counters](delta_counters.html#counters-and-delta-counters-basics) for details and examples. + +## Replace all `~agent.` metrics with `~proxy.` + +The `~agent.` metrics were deprecated a few years ago. With release 2024-05.x, our service no longer supports the `~agent.` metrics. You must replace all the `~agent.` metrics with `~proxy.` to ensure that your charts don’t break. +For example: + +``` +# Deprecated metric: +rawsum(align(1m, mean, ts(\"~agent.buffer.task-count\"))) + +# Replace with: +rawsum(align(1m, mean, ts(\"~proxy.buffer.task-count\"))) +``` + ## Operations for Applications Authentication and Authorization Starting July 3, 2023, VMware Aria Operations for Applications is a service on the VMware Cloud services platform. VMware Cloud services provides centralized authentication and authorization to your entire VMware Cloud services portfolio across hybrid and native public clouds, including Operations for Applications. See [Advantages of VMware Cloud Services Subscriptions Over Original Subscriptions](subscriptions-differences.html#advantages-of-vmware-cloud-services-subscriptions-over-original-subscriptions). diff --git a/pages/doc/wavefront_pricing.md b/pages/doc/wavefront_pricing.md index 4d8a24b84..4509b1b62 100644 --- a/pages/doc/wavefront_pricing.md +++ b/pages/doc/wavefront_pricing.md @@ -30,7 +30,8 @@ For spans, the pricing structure is as follows: ## Data Retention Default data retention is: -* 18 months for metrics and derived metrics. +* 18 months for persistent metrics, counters, and derived metrics. +* 28 days for ephemeral metrics. * 6 months for histograms and derived histograms. * 7 days for traces, spans, and span logs. diff --git a/pages/doc/wavefront_release_notes.md b/pages/doc/wavefront_release_notes.md index 108aec3d6..d8da457a2 100644 --- a/pages/doc/wavefront_release_notes.md +++ b/pages/doc/wavefront_release_notes.md @@ -38,6 +38,33 @@ In October, 2023, we start to incrementally [**onboard**](csp_migration.html) al ## 2024-05.x Release Notes +* **New Ephemeral Metric Type**: With this release, we introduce ephemeral metrics, which have a short retention period. Ephemeral metrics are retained for 28 days, whereas persistent (default) metrics are retained for 18 months. For details, see [Metric Types per Retention Period](metric_types.html#metric-types-per-retention-period). + + {% include note.html content="By default, all ingested metrics are persistent but are now convertible to ephemeral."%} + + On the Metrics Browser: + + * All users can view the type of each metric - persistent or ephemeral. + * Super Admin users can convert metrics from persistent to ephemeral and the reverse. For details, see [Change the Retention Period of Metrics](metrics_managing.html#change-the-retention-period-of-metrics). + + ![A screenshot of the Metrics Browser with highlighted the new Type column and the new Change Ephemerality button.](images/metrics_browser_RNs.png) + + {% include note.html content="Converting persistent metrics to ephemeral improves the [query performance](query_language_performance.html) and reduces the [cardinality](cardinality.html). Consider converting metrics that are relevant for a short time and that have high cardinality, such as the Kubernetes metrics (`kubernetes.`). "%} + +* **Replace all `~agent.` metrics with `~proxy.`**: The `~agent.` metrics were deprecated a few years ago. With this release, our service no longer supports the `~agent.` metrics. You must replace all the `~agent.` metrics with `~proxy.` to ensure that your charts don’t break. + + For example: + + ``` + # Deprecated metric: + rawsum(align(1m, mean, ts(\"~agent.buffer.task-count\"))) + + # Replace with: + rawsum(align(1m, mean, ts(\"~proxy.buffer.task-count\"))) + `````` + +## 2024-03.x Release Notes + * **Updated Support Link**: The link for contacting our Technical Support team from within the Operations for Applications user interface is now updated. To open a support ticket, click the gear icon on the toolbar and select **Support**. * **Derived Metrics Browser Improvements**: We improved the user experience of the **Derived Metrics Browser**. To navigate to this page, select **Browse > Derived Metrics**. diff --git a/pages/doc/wavefront_spring_boot_faq.md b/pages/doc/wavefront_spring_boot_faq.md index 93f4e5b6c..c3dbeb0a5 100644 --- a/pages/doc/wavefront_spring_boot_faq.md +++ b/pages/doc/wavefront_spring_boot_faq.md @@ -36,7 +36,7 @@ Follow these steps: While this is subject to changes at any time, we currently retain 5 days of data and offer no SLA on our free cluster. Freemium accounts that are are inactive for 3 days are automatically deleted. -Production clusters currently offer 18 months of full-resolution (no downsampling) data retention for metrics, 6 months for histograms, and 7 days for spans. We also have a 99.95% uptime guarantee, as well as High Availability (HA) and Disaster Recovery (DR) options. +Production clusters currently offer 18 months of full-resolution (no downsampling) data retention for persistent metrics, 28 days for ephemeral metrics, 6 months for histograms, and 7 days for spans. We also have a 99.95% uptime guarantee, as well as High Availability (HA) and Disaster Recovery (DR) options. ## Why Do I Not See a Link to Access the Free Service on Start-Up?