Fix invalid start/end params in series api

[yeya24]

Signed-off-by: yeya24 yb532204897@gmail.com

• I added CHANGELOG entry for this change.
• Change is not relevant to the end user.

Changes

Fixes #2011

cc @IKSIN @GiedriusS

Verification

I have already tested both in Grafana and local API request.

curl -g 'http://localhost:10908/api/v1/series?' -d 'match[]={__name__="up"}'
{"status":"success","data":[{"__name__":"up","instance":"localhost:9090","job":"prometheus","replica":"test"},{"__name__":"up","instance":"localhost:9091","job":"prometheus","replica":"test"}]}

curl -g 'http://localhost:10908/api/v1/series?' -d 'match[]={__name__="up"}' -d 'start=1579551916'   
{"status":"success","data":[{"__name__":"up","instance":"localhost:9091","job":"prometheus","replica":"test"}]}

[yeya24]

I am not sure if there is a better way to format the timestamp from int64 directly? I am not quite familiar with this

[bwplotka]

Looks like time.RFC3339Nano is supported so maybe startTime.Format(time.RFC3339Nano)?

[yeya24]

I have tried several times but still doesn't work, the generated timestamp is not valid in Prometheus side. Are you OK with the current implementation? @bwplotka
I think there is no big difference between the two ways.

[bwplotka]

It would be super nice to make it valid, I can't see reason why it would not work:

The code is literally this:

func parseTime(s string) (time.Time, error) {
	if t, err := strconv.ParseFloat(s, 64); err == nil {
		s, ns := math.Modf(t)
		ns = math.Round(ns*1000) / 1000
		return time.Unix(int64(s), int64(ns*float64(time.Second))), nil
	}
	if t, err := time.Parse(time.RFC3339Nano, s); err == nil {

		return t, nil
	}

	// Stdlib's time parser can only handle 4 digit years. As a workaround until
	// that is fixed we want to at least support our own boundary times.
	// Context: https://github.com/prometheus/client_golang/issues/614
	// Upstream issue: https://github.com/golang/go/issues/20555
	switch s {
	case minTimeFormatted:
		return minTime, nil
	case maxTimeFormatted:
		return maxTime, nil
	}
	return time.Time{}, errors.Errorf("cannot parse %q to a valid timestamp", s)
}

so you can test even locally for that.

[bwplotka]

https://github.com/prometheus/prometheus/blob/9d9bc524e5e893287cfeeab9995252f54b0624a8/web/api/v1/api.go#L1400

[yeya24]

Hi, I think that may bring this more complicated. What about just using the current implementation in this PR and maybe add a TODO for changing to RFC3339 format? The current way works, and I think we need to fix #2011 ASAP

Or could you reproduce the error I met in your setup @bwplotka

[GiedriusS]

@yeya24 maybe let's add another test-case which would test this out so that we would know for sure if this is reproducible?

[yeya24]

@GiedriusS Added one. From that testcase, using timestamp.Time(startTime).Format(time.RFC3339Nano) will fail. I think it is OK to use the current one.

[GiedriusS]

It is unfortunate that Golang's stdlib cannot parse all of the values that one can format in time.RFC3339Nano: golang/go#20555. However, I'd vote for @bwplotka's suggestion here: maybe lets just not add these parameters if they haven't been specified? Prometheus then handles all of this accordingly. I think we'd avoid more problems down the line. WDYT?

[yeya24]

Thanks for pointing this out! However, I am still not sure about how to handle all the cases.

Currently the minTime of sidecar can be configured via a flag. But its default value "0000-01-01T00:00:00Z" is invalid at the Prometheus side. How to avoid this case? And what if users set some other time that cannot be parsed as well? @GiedriusS

[bwplotka]

Thanks!

One suggestion and LGTM! Thanks for fixing 👍

[bwplotka]

Looks like time.RFC3339Nano is supported so maybe startTime.Format(time.RFC3339Nano)?

[sylr]

I've built this PR and unfortunately it did not fix the problem for me.

Grafana queries that populate variables returned more items that they should have.

[yeya24]

I've built this PR and unfortunately it did not fix the problem for me.

Grafana queries that populate variables returned more items that they should have.

Hi, @sylr
Could you please share with me how you test this?
I am not quite familiar with Grafana and I only found the variables page calls the series API.

Recent 30 min of label_values(up, instance)

Several days ago data of label_values(up, instance). The result is different from the previous one.

[bwplotka]

After some digging I believe we should merge and release this version. @yeya24 is right, formatting to float actually makes more sense. See: prometheus/client_golang#614

[bwplotka]

Thank you @yeya24 for quick reaction!

[sylr]

Ok so I'd like to correct my previous comment as I thought the problem was located only on the querier, it was not according to my new observations:

0.10.0 on the sidecar and 0.10.0 on the querier -> NOT OK
0.10.0 on the sidecar and 0.8.1 on the querier -> OK
master+this on the sidecar and 0.10.0 on the querier -> NOT OK
master+this on the sidecar and master+this on the querier -> OK
0.10.0 on the sidecar and master+this on the querier -> NOT OK