Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mismatch in reported data on Timestamp and StartTimestamp #36504

Open
frzifus opened this issue Nov 22, 2024 · 2 comments
Open

Mismatch in reported data on Timestamp and StartTimestamp #36504

frzifus opened this issue Nov 22, 2024 · 2 comments
Labels
bug Something isn't working needs triage New item requiring triage receiver/hostmetrics

Comments

@frzifus
Copy link
Member

frzifus commented Nov 22, 2024

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

@frzifus frzifus added bug Something isn't working needs triage New item requiring triage labels Nov 22, 2024
Copy link
Contributor

Pinging code owners:

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

@dehaansa
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs triage New item requiring triage receiver/hostmetrics
Projects
None yet
Development

No branches or pull requests

2 participants