New component: timestamp processor

[atoulme]

The purpose and use-cases of the new component

The purpose of this processor is to change the timestamp of all data that it processes (logs, traces, metrics) by adding or removing a static time duration.

Example configuration for the component

processors:
  timestamp:
    offset: "0h"

  timestamp/add2h:
    offset: "2h"

  timestamp/remove3h:
    offset: "-3h"

receivers:
  nop:

exporters:
  nop:

service:
  pipelines:
    metrics:
      receivers: [nop]
      processors: [timestamp, timestamp/add2h, timestamp/remove3h]
      exporters: [nop]

Telemetry data types supported

all

Is this a vendor-specific component?

• This is a vendor-specific component
• If this is a vendor-specific component, I am proposing to contribute this as a representative of the vendor.

Sponsor (optional)

No response

Additional context

This was needed at one point as a stop gap solution for one of our PoCs and it's possible the transformprocessor and ottl is a better solution long term. See original discussion #14142

If others find this processor has merit, I can help contribute it to contrib and help maintain it.

The name of the processor might be instead better named "clockskew" - please suggest.

[fatsheep9146]

@TylerHelmuth can this feature be implemented by transformprocessor?

[TylerHelmuth]

I am mostly tracking the timestamp work via this issue: #16067. I think that with a change to returning time.Time we'll gain flexibility to handle situations like these.

[github-actions]

Pinging code owners for processor/transform: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[atoulme]

I have built this code here: https://github.com/signalfx/splunk-otel-collector/tree/main/pkg/processor/timestamp so the work would consist of taking the code and migrating it upstream.
From a bit of lessons learned building this one-off, there is a bit going into changing timestamps across different metrics, metric types, logs, traces.

A good example is: https://github.com/signalfx/splunk-otel-collector/blob/main/pkg/processor/timestamp/metric_processor.go#L58

I think the transformprocessor is the right tool to change one timestamp field, but this solution is a bit more generic as it tries to applies to any timestamp reported by any data record.

[atoulme]

Another example:

span := ss.Spans().At(k)
					span.SetStartTimestamp(offsetFn(span.StartTimestamp()))
					span.SetEndTimestamp(offsetFn(span.EndTimestamp()))
					for l := 0; l < span.Events().Len(); l++ {
						e := span.Events().At(l)
						e.SetTimestamp(offsetFn(e.Timestamp()))
					}

For each span, we need to change timestamps of start, end, and event timestamps. I think this approach cannot easily be taken with the transform processor. WDYT?

[atoulme]

Discussed SIG meeting 1/25:

• should have an ottl condition
• Not sure if it's a common problem
• Might be useful for browsers, reset to now
• Useful if instead of fixed adjustment, use an offset from now
• at least 2 companies have their own timestamp processors. Need more flexibility.
• adjusting for timezone or truncating duration, or setting a field to a new value "now"
• still a feeling that the transform processor is a better solution, rather than a new processor.
• https://github.com/honeycombio/opentelemetry-collector-configs/tree/main/timestampprocessor exists as well, different use case
• templatize config source functionality for the transform processor - apply config that is used, use a function.

[atoulme]

Closing as there is no path forward and the timestamp processor we use is too narrow for the types of use cases considered.