Derived metrics allow you to run a query and ingest it back into Wavefront. All users can then use the result of the query, that is, the derived metric, in their queries.
Derived metrics created and metrics points scanned apply to your data ingestion and data scan rates.
The minimum reporting interval for a derived metric is 1 minute. If the query that is used in the derived metric reports data points more than once within a minute, Wavefront summarizes it using the
mean()aggregation and aligns it to 1 minute time buckets.
- Starting with release 2020-26.x, metrics that are not reported for 4 weeks or more (obsolete metrics) are removed from derived metrics.
Our customers wanted to register and ingest a query so they can have instantly available metrics (derived metrics). Here are some use cases.
Simplify User Experience
Many queries are complex and intimidating for non-expert users. If you create a derived metric, the corresponding query runs in the background. All users can then use the result of the complex query – the derived metric – in other queries.
The screenshot below shows how you can create a derived metric from a complex query. This query tracks employees who are required to perform onboarding. You use
aliasMetric and can call the metric by that metric name in a new query. In this example, we can use
employee-onboarding-time-left the next time we need the result of the query.
Other examples might include:
- Creating new metrics from
ts()expressions that do transformations such as collapsing multiple series into one, retagging series using
taggify(), or doing joins to create new synthetic series.
- Creating new metrics from
ts()expressions that do complex filtering of data using joins and other techniques.
Improve performance by pre-processing expensive queries and saving the results as a new metric. Expensive might mean a large volume of data is accessed, many calculations are done, many metrics are use, and so on. Derived metrics are especially useful if the query result is needed by several other queries or even by several users. The expensive operation is performed once a minute (or less frequently) and the new derived metric is accessible.
Example 1: Idle CPU
The following example shows how you can save a metric that sums all
telegraph.cpu.usage.idle metrics with status
dev as the metric
The example uses
aliasSource to ensure that you don’t mix up a synthetic metric with the original source.
Example 2: Report Points
Suppose you have the following query:
You create a derived metric that outputs
saved.dataingester.report-points. The next time you need the report points information, you query
ts(saved.dataingester.report-points) and you get instant results. The server does not have to compute the
rate, and 60-day moving average.
You can reduce the data scan rate in a similar way using derived metrics.
Derived Metrics Basics
You can customize how often the derived metric executes, and how many minutes of results we include.
Execute the query every N minutes: By default, Wavefront executes the derived metric query every 1 minute. Use this setting to adjust the execution interval.
Include results in the last N minutes: By default, Wavefront uses the last 5 minutes as the time window for the derived metrics query to account for possible delays in the upstream metric pipeline. The results of the query are ingested back into Wavefront and overwrite existing data in the last N minutes for the derived metric. You can adjust the time window of the query with this setting.
Creating and Managing Derived Metrics
To create a derived metric:
- Select Browse > Derived Metrics.
- Click Create Derived Metric.
- Specify the query and make sure you include an
aliasMetric– you later use that name for the derived metric.
- If you want, change the times for results inclusion and for query execution. If your environment might have queueing problems, increase the results inclusion time.
aliasSourceto have a different name for the metric (and optional source).