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

metrics: refactor metrics (part II) #28035

Merged
merged 26 commits into from
Sep 13, 2023
Merged

Conversation

holiman
Copy link
Contributor

@holiman holiman commented Aug 31, 2023

This is a follow-up to #28031

Split up interfaces, write vs read

The changes look large, but they're not actually that invasive. The interfaces have been split up into one write-interface and one read-interface, with Snapshot being the gateway from write to read. This simplifies the semantics a lot.

Example of splitting up an interface into one readonly 'snapshot' part, and one updatable writeonly part:

type MeterSnapshot interface {
	Count() int64
	Rate1() float64
	Rate5() float64
	Rate15() float64
	RateMean() float64
}

// Meters count events to produce exponentially-weighted moving average rates
// at one-, five-, and fifteen-minutes and a mean rate.
type Meter interface {
	Mark(int64)
	Snapshot() MeterSnapshot
	Stop()
}

A note about concurrency

This PR makes the concurrency model clearer. We have actual meters and snapshot of meters. The meter is the thing which can be accessed from the registry, and updates can be made to it.

  • For all meters, (Gauge, Timer etc), it is assumed that they are accessed by different threads, making updates. Therefore, all meters update-methods (Inc, Add, Update, Clear etc) need to be concurrency-safe.
  • All meters have a Snapshot() method. This method is usually called from one thread, a backend-exporter. But it's fully possible to have several exporters simultaneously: therefore this method should also be concurrency-safe.

TLDR: meters are accessible via registry, all their methods must be concurrency-safe.

For all Snapshots, it is assumed that an individual exporter-thread has obtained a meter from the registry, and called the Snapshot method to obtain a readonly snapshot. This snapshot is not guaranteed to be concurrency-safe. There's no need for a snapshot to be concurrency-safe, since exporters should not share snapshots.

Note, though: that by happenstance a lot of the snapshots are concurrency-safe, being unmutable minimal representations of a value. Only the more complex ones are not threadsafe, those that lazily calculate things like Variance(), Mean().

Example of how a background exporter typically works, obtaining the snapshot and sequentially accessing the non-threadsafe methods in it:

		ms := metric.Snapshot()
                ...
		fields := map[string]interface{}{
			"count":    ms.Count(),
			"max":      ms.Max(),
			"mean":     ms.Mean(),
			"min":      ms.Min(),
			"stddev":   ms.StdDev(),
			"variance": ms.Variance(),

TLDR: snapshots are not guaranteed to be concurrency-safe (but often are).

Sample changes

I also changed the Sample type: previously, it iterated the samples fully every time Mean(),Sum(), Min() or Max() was invoked. Since we now have readonly base data, we can just iterate it once, in the constructor, and set all four values at once.

The same thing has been done for runtimehistogram.

ResettingTimer API

Back when ResettingTImer was implemented, as part of #15910, Anton implemented a Percentiles on the new type. However, the method did not conform to the other existing types which also had a Percentiles.

  1. The existing ones, on input, took 0.5 to mean 50%. Anton used 50 to mean 50%.
  2. The existing ones returned float64 outputs, thus interpolating between values. A value-set of 0, 10, at 50% would return 5, whereas Anton's would return either 0 or 10.

This PR removes the 'new' version, and uses only the 'legacy' percentiles, also for the ResettingTimer type.

The resetting timer snapshot was also defined so that it would expose the internal values. This has been removed, and getters for Max, Min, Mean have been added instead.

Unexport types

A lot of types were exported, but do not need to be. This PR unexports quite a lot of them.

@holiman holiman changed the title Metrics refator (part II) Metrics refactor (part II) Aug 31, 2023
@holiman
Copy link
Contributor Author

holiman commented Sep 2, 2023

This is now running on 05/06

Sep 01 19:45:02 bench05.ethdevops.io geth INFO [09-01|17:45:02.776] Starting peer-to-peer node instance=Geth/v1.13.0-unstable-40f291b0-20230901/linux-amd64/go1.21.0
Sep 01 19:45:11 bench06.ethdevops.io geth INFO [09-01|17:45:11.310] Starting peer-to-peer node instance=Geth/v1.13.0-unstable-28857080-20230831/linux-amd64/go1.21.0

So this PR on bench05, master on bench06.
I had to revert the type-change resetting timer, not because it was wrong, but because the earlier code has used the i-format (non-default integer format), making it not possible to switch to using the default (float) format:

Sep 01 19:43:18 bench05.ethdevops.io geth WARN [09-01|17:43:18.263] Unable to send to InfluxDB err="{\"error\":\"partial write: field type conflict: input field \\\"p50\\\" on measurement \\\"geth.hashdb/memcache/gc/time.span\\\" is type float, already exists as type integer dropped=2\"}\n"

This does look a bit odd; here's a 12-hour chart, master:
Screenshot 2023-09-02 at 12-54-42 Single Geth - Grafana
vs this PR:
Screenshot 2023-09-02 at 12-55-32 Single Geth - Grafana
The latter is very empty. Needs to be investigated.

@holiman
Copy link
Contributor Author

holiman commented Sep 3, 2023

I made a little custom binary which sent in fake traffic metrics. The master reported GetBlockHeadersMsg stats, the "this PR" code reported GetBlockBodiesMsg stats. Then I ran them at the same time, reporting against the same host.

The faked metrics were more or less similar distribution, but there's randomness so they aren't identical.

Screenshot 2023-09-03 at 20-10-48 Single Geth - Grafana

So left is master, right is this PR.

As far as I can tell, this PR does not modify the behaviour of the traffic tracker histogram charts.

@holiman holiman marked this pull request as ready for review September 3, 2023 18:14
@holiman
Copy link
Contributor Author

holiman commented Sep 3, 2023

Some time later

Screenshot 2023-09-03 at 20-41-36 Single Geth - Grafana

@holiman
Copy link
Contributor Author

holiman commented Sep 5, 2023

This does look a bit odd; here's a 12-hour chart, master:

I think I know the reason for this now: those charts only take into account traffic on eth/66, not 67 or 68. So if the bulk of the peers are 67/68 the charts won't have a lot of content. So it varies from time to time

(@karalabe how about changing it so that all meters like geth.p2p/wait/eth/66/0x05.histogram becomes geth.p2p/wait/eth/0x05.histogram, disregarding version? )

@holiman holiman changed the title Metrics refactor (part II) metrics: refactor metrics (part II) Sep 5, 2023
Copy link
Member

@lightclient lightclient left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks really nice. Great simplification of the interfaces!

metrics/sample.go Outdated Show resolved Hide resolved
metrics/sample.go Show resolved Hide resolved
metrics/sample.go Outdated Show resolved Hide resolved
metrics/sample_test.go Show resolved Hide resolved
metrics/testdata/opentsb.want Show resolved Hide resolved
metrics/counter.go Outdated Show resolved Hide resolved
metrics/ewma.go Outdated Show resolved Hide resolved
metrics/gauge.go Outdated Show resolved Hide resolved
metrics/gauge_float64.go Show resolved Hide resolved
metrics/influxdb/testdata/influxdbv1.want Show resolved Hide resolved
Copy link
Member

@MariusVanDerWijden MariusVanDerWijden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, big improvement over the old one, also -2000 lines is pretty cool!

@holiman holiman added this to the 1.13.1 milestone Sep 13, 2023
@holiman holiman merged commit 8b6cf12 into ethereum:master Sep 13, 2023
1 check passed
@holiman holiman deleted the refactor_metrics branch October 11, 2023 07:25
devopsbo3 pushed a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 2023
This change includes a lot of things, listed below. 

### Split up interfaces, write vs read

The interfaces have been split up into one write-interface and one read-interface, with `Snapshot` being the gateway from write to read. This simplifies the semantics _a lot_. 

Example of splitting up an interface into one readonly 'snapshot' part, and one updatable writeonly part: 

```golang
type MeterSnapshot interface {
	Count() int64
	Rate1() float64
	Rate5() float64
	Rate15() float64
	RateMean() float64
}

// Meters count events to produce exponentially-weighted moving average rates
// at one-, five-, and fifteen-minutes and a mean rate.
type Meter interface {
	Mark(int64)
	Snapshot() MeterSnapshot
	Stop()
}
```

### A note about concurrency

This PR makes the concurrency model clearer. We have actual meters and snapshot of meters. The `meter` is the thing which can be accessed from the registry, and updates can be made to it. 

- For all `meters`, (`Gauge`, `Timer` etc), it is assumed that they are accessed by different threads, making updates. Therefore, all `meters` update-methods (`Inc`, `Add`, `Update`, `Clear` etc) need to be concurrency-safe. 
- All `meters` have a `Snapshot()` method. This method is _usually_ called from one thread, a backend-exporter. But it's fully possible to have several exporters simultaneously: therefore this method should also be concurrency-safe. 

TLDR: `meter`s are accessible via registry, all their methods must be concurrency-safe. 

For all `Snapshot`s, it is assumed that an individual exporter-thread has obtained a `meter` from the registry, and called the `Snapshot` method to obtain a readonly snapshot. This snapshot is _not_ guaranteed to be concurrency-safe. There's no need for a snapshot to be concurrency-safe, since exporters should not share snapshots. 

Note, though: that by happenstance a lot of the snapshots _are_ concurrency-safe, being unmutable minimal representations of a value. Only the more complex ones are _not_ threadsafe, those that lazily calculate things like `Variance()`, `Mean()`.

Example of how a background exporter typically works, obtaining the snapshot and sequentially accessing the non-threadsafe methods in it: 
```golang
		ms := metric.Snapshot()
                ...
		fields := map[string]interface{}{
			"count":    ms.Count(),
			"max":      ms.Max(),
			"mean":     ms.Mean(),
			"min":      ms.Min(),
			"stddev":   ms.StdDev(),
			"variance": ms.Variance(),
```

TLDR: `snapshots` are not guaranteed to be concurrency-safe (but often are).

### Sample changes

I also changed the `Sample` type: previously, it iterated the samples fully every time `Mean()`,`Sum()`, `Min()` or `Max()` was invoked. Since we now have readonly base data, we can just iterate it once, in the constructor, and set all four values at once. 

The same thing has been done for runtimehistogram. 

### ResettingTimer API

Back when ResettingTImer was implemented, as part of ethereum#15910, Anton implemented a `Percentiles` on the new type. However, the method did not conform to the other existing types which also had a `Percentiles`. 

1. The existing ones, on input, took `0.5` to mean `50%`. Anton used `50` to mean `50%`. 
2. The existing ones returned `float64` outputs, thus interpolating between values. A value-set of `0, 10`, at `50%` would return `5`, whereas Anton's would return either `0` or `10`. 

This PR removes the 'new' version, and uses only the 'legacy' percentiles, also for the ResettingTimer type. 

The resetting timer snapshot was also defined so that it would expose the internal values. This has been removed, and getters for `Max, Min, Mean` have been added instead. 

### Unexport types

A lot of types were exported, but do not need to be. This PR unexports quite a lot of them.
devopsbo3 added a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 2023
devopsbo3 added a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants