changefeedccl: add scoping support for max_behind_nanos

[aerfrei]

Currently, changefeed.max_behind_nanos is a measurement of the
lag of the furthest behind changefeed. We'd like to be able to
support scoping/grouping changefeeds. This applies scoping to
that metric similar to the scoping on changefeed.aggregator_progress.

Epic: none
Fixes: #132281

Release note (ops change): the changefeed.max_behind_nanos metric
now supports scoping with metric labels.

[blathers-crl]

It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR?

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroach-teamcity]

This change is 

[andyyang890]

Reviewed 1 of 3 files at r1, 2 of 3 files at r2, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @aa-joshi, @aerfrei, @arjunmahishi, @asg0451, @rharding6373, and @xinhaoz)

---

-- commits line 9 at r2:
FYI it's not necessary to put an Epic if you've already linked an issue (linking an issue is preferred per https://cockroachlabs.atlassian.net/wiki/spaces/CRDB/pages/2009039063/Issue+and+Epic+Refs+in+Commits+and+PRs)

---

pkg/ccl/changefeedccl/metrics.go line 1003 at r2 (raw file):

		var max int64
		for _, val := range childValues {
			if val != 0 && val > max {

Do you need the val != 0 clause? Another thing you could do is leverage go's new max function: return max(0, childValues...)

[andyyang890]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @aa-joshi, @aerfrei, @arjunmahishi, @asg0451, @rharding6373, and @xinhaoz)

---

pkg/ccl/changefeedccl/metrics.go line 1208 at r2 (raw file):

				return 0
			}
			return timeutil.Now().UnixNano() - minTs

Is there a reason you chose to do a raw subtraction instead of using the Sub method? From skimming the code, it seems like we usually convert the hlc.Timestamp to a go time and then use Sub.

[aerfrei]

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @aa-joshi, @andyyang890, @arjunmahishi, @asg0451, @rharding6373, and @xinhaoz)

---

-- commits line 9 at r2:

Previously, andyyang890 (Andy Yang) wrote…

FYI it's not necessary to put an Epic if you've already linked an issue (linking an issue is preferred per https://cockroachlabs.atlassian.net/wiki/spaces/CRDB/pages/2009039063/Issue+and+Epic+Refs+in+Commits+and+PRs)

I'll change this, thanks for the tip!

---

pkg/ccl/changefeedccl/metrics.go line 1003 at r2 (raw file):

Previously, andyyang890 (Andy Yang) wrote…

Do you need the val != 0 clause? Another thing you could do is leverage go's new max function: return max(0, childValues...)

Good point on the val check, I'll remove that. I get a compilation error on using max that way, seems like max doesn't support it. https://stackoverflow.com/questions/78778577/a-compilation-error-while-using-builtin-func-max-with-go-1-22-1-invalid-ope

---

pkg/ccl/changefeedccl/metrics.go line 1208 at r2 (raw file):

Previously, andyyang890 (Andy Yang) wrote…

Is there a reason you chose to do a raw subtraction instead of using the Sub method? From skimming the code, it seems like we usually convert the hlc.Timestamp to a go time and then use Sub.

The reason I did it this way is because I chose to reuse the minTimestampGetter, which returns an int64. If I still wanted to use it, I considered converting back into a timestamp to do the subtraction and then back into nanoseconds like this: "timeutil.Now().Sub(time.Unix(0, minTs)).Nanoseconds()" which seems less readable and I didn't see a strong argument the other way. Thoughts?

[andyyang890]

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @aa-joshi, @aerfrei, @arjunmahishi, @asg0451, @rharding6373, and @xinhaoz)

---

pkg/ccl/changefeedccl/metrics.go line 1003 at r2 (raw file):

Previously, aerfrei (Aerin Freilich) wrote…

Good point on the val check, I'll remove that. I get a compilation error on using max that way, seems like max doesn't support it. https://stackoverflow.com/questions/78778577/a-compilation-error-while-using-builtin-func-max-with-go-1-22-1-invalid-ope

Ah ok. In that case, maybe you could use slices.Max like the StackOverflow answer says instead?

---

pkg/ccl/changefeedccl/metrics.go line 1208 at r2 (raw file):

Previously, aerfrei (Aerin Freilich) wrote…

The reason I did it this way is because I chose to reuse the minTimestampGetter, which returns an int64. If I still wanted to use it, I considered converting back into a timestamp to do the subtraction and then back into nanoseconds like this: "timeutil.Now().Sub(time.Unix(0, minTs)).Nanoseconds()" which seems less readable and I didn't see a strong argument the other way. Thoughts?

Ah ok, that makes sense to me.

[aerfrei]

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @aa-joshi, @andyyang890, @arjunmahishi, @asg0451, @rharding6373, and @xinhaoz)

---

pkg/ccl/changefeedccl/metrics.go line 1003 at r2 (raw file):

Previously, andyyang890 (Andy Yang) wrote…

Ah ok. In that case, maybe you could use slices.Max like the StackOverflow answer says instead?

Great, done!

[asg0451]

😂

[asg0451]

maybe remove the deprecation notice, now that we've improved it

[aerfrei]

Done.

[aerfrei]

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @aa-joshi, @andyyang890, @arjunmahishi, @asg0451, @rharding6373, and @xinhaoz)

[aerfrei]

Done.

[aerfrei]

bors r=andyyang890,asg0451

[craig]

Build succeeded:

• windows_build
• examples_orms
• linux_amd64_fips_build
• macos_amd64_build
• acceptance
• lint
• linux_arm64_build
• local_roachtest_fips
• docker_image_amd64
• unit_tests
• check_generated_code
• macos_arm64_build
• linux_amd64_build
• local_roachtest