VMware Aria Operations for Applications (formerly known as Tanzu Observability by Wavefront) product features and APIs move to end-of-life as part of the normal software development lifecycle, security improvements, and other factors. To support planning for upgrades, this document provides information on upcoming lifecycle changes. While every effort is made to provide sufficient notice of changes, security issues or other factors may occasionally lead to accelerated end-of-life dates.
To help you plan for end-of-life dates, this page uses the following terms:
- Deprecated. Feature, component, platform, or functionality that may no longer be efficient or safe. Deprecated features are supported but no longer recommended. We eventually remove deprecated features. We usually do not fix a bug in a deprecated feature and request that you start using the replacement feature. Deprecated features are identified in the release notes for the release in which the feature is deprecated. For Wavefront proxy, the table below lists deprecated versions.
- End-of-life. No longer supported. Feature, component, platform, or functionality is no longer supported and may be removed from the product at any time.
Upgrade to the latest GA release of the Wavefront proxy to get the latest bug fixes and performance enhancements.
The following proxy versions are deprecated or moved to end-of-life.
|Version||Current Stage||End-of-Life Date|
|11.x||Deprecated since Oct 19, 2022||TBD|
|10.x||End-of-life||Oct 19, 2022|
|9.x||End-of-life||Mar 18, 2022|
|8.x and earlier||End-of-Life||Jul 1, 2021 and earlier|
|Version||Current Stage||End-of-Life Date|
|1||End-of-Life||Dec 31, 2017|
Delta counter behavior changed with Release 2020.26. The original delta counter implementation was Deprecated with Release 2020.26. We changed delta counter queries to use
cs() in the Operations for Applications Usage integration and tracing RED metrics. The original delta counter implementation is End of Life March 31, 2021.
Automatic Updates and Required Changes
We update system dashboard and integration content to use the new version of delta counters. However, you might have to update custom delta counters.
- Automatic Updates. Tracing RED metrics and in certain internal
~metrics collected by the service, such as
~collector.points.reported, use delta counters. All out-of-the-box dashboards that use these data will be updated for you.
- User Updates. If you have cloned any out-of-the-box dashboards that use delta counters or have created any custom dashboards, charts, or alerts, you are responsible for updating the queries in related charts and alerts yourself.
How to Find Queries that Might Need Modification
- Find delta counters from the UI or using Spy.
- Log in to your product instance, click Browse > Delta Counters and examine your data.
- From your Web browser, use Delta Counter Spy to view live delta counter ingestion.
- Search for those named counters in alerts and dashboards.
- Search on the Alerts page to find alerts that use the counter metric.
- Search on the All Dashboards page for dashboards. You might have to select Metrics to get the relevant result.
How to Modify the Queries
cs()if the query targets delta counter data. Filtering works as before, so nothing within the parentheses needs to change.
ratediff()functions from your delta counter queries.
cs()query tracks the total increments per minute, so
cs()data is already a 1-minute rate and doesn’t require the
rate()function. If you do want to know the per-second rate of change, divide the result by 60.
You do not need to do anything differently if you are using a
timeWindowparameter in your
rate()function. The purpose of that parameter is to account for cumulative counter resets, but delta counters do not have resets.
align()from your delta counter queries unless you picked an
align()time window that’s larger than 1 minute.
cs()data is always minutely aligned and raw or standard aggregations give the same results.
In the following examples,
errors.count is a delta counter:
|Original Query||New Query||Explanation|
||In the simplest case, just change
||To produce per-second rate of change like the
Background: Original and New Delta Counter Implementation
Delta counters allow you to measure the number of times something occurred over time without needing to keep track of the number of occurrences to date yourself.
At ingestion time, a delta counter must have a ∆ character at the beginning. Just like any other measurement data in a delta counter series is uniquely identified by its name, source, and any point tags.
For example, imagine we are trying to track the total number of errors that occur across lambda functions running in a given AWS region. Each invocation of the function would measure how many errors occurred during that run and would emit that to the service.
If 5 errors were encountered during a given run, a Lambda running in the
us-west-2 region would send:
∆errors.count 5 source=lambda region=us-west-2. We automatically aggregate any increments received for that same counter, allowing you to know the total number of errors that occurred over time, across any number of lambda invocations without any function needing to keep track of that overall state!
Before release 2020.26, delta values were stored internally as regular metrics emitted every minutes.
For the above example if the data measured across 3 minutes had been a total of: 10 errors in minute 1, 15 errors in minute 2, and 5 errors in minute 3 then if you queried
ts(errors.count) for that time range you would see a monotonically increasing count showing 10, 25, 30 across those 3 minutes.
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 for details and examples.
Starting with the 2022-48.x release, we introduce a new Observability for Kubernetes Operator, which helps simplifying the management and configuration of the Kubernetes integration and the deployed components (such as our Kubernetes Metrics Collector, Wavefront proxy, Logs (Beta), and so on). The Observability for Kubernetes Operator replaces the deprecated Helm or manual installation of the Kubernetes Metrics Collector and Wavefront proxy for all Kubernetes distributions, except for OpenShift Container Platform.
If you are currently leveraging the Helm or manually-installed Kubernetes Metrics Collector and Wavefront proxy, the deprecation will NOT affect you and you won’t experience any disruptions. However, support (including bug fixes, security vulnerabilities, new functionality, etc.) will be discontinued on Feb 28, 2023, for the legacy collector and proxy installation methods.