Mismatch in reported data on Timestamp and StartTimestamp

[frzifus]

Component(s)

receiver/hostmetrics

What happened?

Description

As far as I understand there seems to be an issue when recording the Timestamp and StartTimestamp.

Every OTLP metric data point has two associated timestamps. The first, mandatory timestamp is the one associated with the observation, the moment when the measurement became current or took effect, and is referred to as TimeUnixNano. The second, optional timestamp is used to indicate when a sequence of points is unbroken, and is referred to as StartTimeUnixNano.

Short:

• StartTimestamp - Represents the time when a metric's collection period began
• Timestamp - Represents the time when the metric data point was recorded

Steps to Reproduce

I am using a machine in CET+02 ($ date; Fr 22. Nov 17:41:57 CET 2024).
There I used this config shown below with a collector (./bin/otelcontribcol_linux_amd64 --config=config.yaml):

Expected Result

An almost equal TS in StartTimestamp and Timestamp.

Actual Result

I see 1h mismatch between both timestamps, while both claim to be UTC.

Collector version

v0.113.0

Environment information

Environment

OS: Fedora 41 Silverblue
Compiler(if manually compiled): go 1.23

OpenTelemetry Collector configuration

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      cpu:
      memory:

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    metrics:
      receivers: [hostmetrics]
      exporters: [debug]

Log output

Data point attributes:
     -> state: Str(slab_unreclaimable)
StartTimestamp: 2024-11-22 15:44:12 +0000 UTC
Timestamp: 2024-11-22 16:41:53.73050196 +0000 UTC
Value: 238321664

Additional context

No response

[github-actions]

Pinging code owners:

• receiver/hostmetrics: @dmitryax @braydonk

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[dehaansa]

The Host Metrics Receiver uses the boot time of the instance as the StartTimestamp

https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/memoryscraper/memory_scraper.go#L47

[braydonk]

Yes @dehaansa is right. The StartTimestamp for metrics produced by the hostmetrics receiver is either the instance start time, or the in the case of the process scraper each process' create time. This is done because the metrics produced are nominally associated with the resource they are under, thus the StartTimestamp of the metric is more useful when it is the time the resource started vs the time the first point was recorded. This also gives automatic resiliency against Collector crashes; even if a collector crashes while collecting metrics for an instance, when it comes back it will continue to produce the same StartTimestamp without erroneously indicating a timeseries restart.

I think this issue can be closed unless you have any objections to the reasoning.