> ## Documentation Index
> Fetch the complete documentation index at: https://otel.fyi/llms.txt
> Use this file to discover all available pages before exploring further.

# Metricstarttime

> OpenTelemetry processor for Metricstarttime

# Metricstarttime Processor

![Status](https://img.shields.io/badge/status-beta-yellow)

**Available in:** `contrib`

**Maintainers:** [@dashpole](https://github.com/dashpole), [@ridwanmsharif](https://github.com/ridwanmsharif)

**Source:** [opentelemetry-collector-contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/metricstarttimeprocessor)

## Supported Telemetry

![Metrics](https://img.shields.io/badge/metrics-beta-green)

## Overview

## Configuration

The processor will work without configuring any settings, but the following options are supported:

* `strategy` (default `true_reset_point`): Specifies which strategy to use. Valid values are
  `true_reset_point`, `subtract_initial_point`, and `start_time_metric`. See
  below for how each strategy works.
* `gc_interval` (default `10m`): Defines the interval to check if any resources
  have not emitted data since the last check. If a resource has not emitted any
  data, it is removed from the cache to free up memory. Any additional data from
  resources removed from the cache will be given a new start time.
* `start_time_metric_regex`: Allows specifying a regex for a metric name
  containing the start time for a resource. This option is only supported when
  the strategy is `start_time_metric`, and if unset, the `process_start_time`
  metric is used.

Example configurations:

```yaml theme={null}
processors:
  metric_start_time:
```

```yaml theme={null}
processors:
  metric_start_time:
    strategy: start_time_metric
    gc_interval: 1h
    start_time_metric_regex: "^.+_start_time$"
```

### Strategy: True Reset Point

The `true_reset_point` strategy handles missing start times for cumulative
points by producing a stream of points that starts with a
[True Reset Point](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/data-model.md#cumulative-streams-inserting-true-reset-points).
The true reset point has its start time set to its end timestamp. It is meant
to indicate the absolute value of the cumulative point when the collector first
observed it. Subsequent points re-use the start timestamp of the initial True
Reset point.

Pros:

* The absolute value of the cumulative metric is preserved.
* It is possible to calculate the correct rate between any two points since the timestamps and values are not modified.

Cons:

* This strategy is **stateful** because the initial True Reset point is necessary to properly calculate rates on subsequent points.
* The True Reset point doesn't make sense semantically. It has a zero duration, but non-zero values.
* Many backends reject points with equal start and end timestamps.
  * If the True Reset point is rejected, the next point will appear to have a very large rate.

### Strategy: Subtract Initial Point

The `subtract_initial_point` strategy handles missing start times for
cumulative points by dropping the first point in a cumulative series,
"subtracting" that point's value from subsequent points and using the initial
point's timestamp as the start timestamp for subsequent points.

Pros:

* Cumulative semantics are preserved. This means that for a point with a given `[start, end]` interval, the cumulative value occurred in that interval.
* Rates over resulting timeseries are correct, even if points are lost. This strategy is not stateful.

Cons:

* The absolute value of counters is modified. This is generally not an issue, since counters are usually used to compute rates.
* The initial point is dropped, which loses information.

### Strategy: Start Time Metric

The `start_time_metric` strategy handles missing start times by looking for the
`process_start_time` metric, which is commonly supported by Prometheus exporters.
If found, it uses the value of the `process_start_time` metric as the start time
for all other cumulative points in the batch of metrics.

Use the `start_time_metric_regex` configuration option to change the name of the
metric used for the start time.

If the start time metric is not found, it falls back to the time at which the
collector started.

This strategy should only be used in limited circumstances:

* When your application has a metric with the start time in Unix nanoseconds,
  such as `process_start_time`.
* The `metric_start_time` processor is used *before* any batching, so that the
  batch of metrics all originate from a single application.
* This strategy can be used when the collector is run as a sidecar to the
  application, where the collector's start time is a good approximation of the
  application's start time.

Cons:

* If the collector's start time is used as a fallback and the collector
  restarts, it can produce rates that are incorrect and higher than expected.
* The process' start time isn't the time at which individual instruments or
  timeseries are initialized. It may result in lower rates if the first
  observation is significantly later than the process' start time.

## Configuration

### Example Configuration

```yaml theme={null}
metric_start_time:

metric_start_time/subtract_initial_point:
  strategy: subtract_initial_point

metric_start_time/gc_interval:
  gc_interval: 1h

metric_start_time/negative_interval:
  gc_interval: -1h

metric_start_time/true_reset_point:
  strategy: true_reset_point

metric_start_time/start_time_metric:
  strategy: start_time_metric
  start_time_metric_regex: "^.+_process_start_time_seconds$"

metric_start_time/invalid_regex:
  strategy: start_time_metric
  start_time_metric_regex: "(((("

metric_start_time/invalid_strategy:
  strategy: bad

metric_start_time/regex_with_subtract_initial_point:
  strategy: subtract_initial_point
  start_time_metric_regex: "^.+_process_start_time_seconds$"
```

***

*Last generated: 2026-07-06*