Skip to content

Comments

Add interface for metric instantiation#654

Merged
daviddrysdale merged 10 commits intogoogle:masterfrom
daviddrysdale:wrapped-metrics
Jun 2, 2017
Merged

Add interface for metric instantiation#654
daviddrysdale merged 10 commits intogoogle:masterfrom
daviddrysdale:wrapped-metrics

Conversation

@daviddrysdale
Copy link
Contributor

No description provided.


// MetricFactory allows the creation of different types of metric.
type MetricFactory interface {
NewCounter(name, help string, labelNames []string) Counter
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not use labelNames ...string here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

// Counter is a wrapper around a Prometheus Counter or CounterVec object.
type Counter struct {
labelNames []string
single prometheus.Counter
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this be by reference? Or it's not needed because prometheus.Counter is an interface (and they're always references)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, it's an interface


func (m *memoryLogStorage) beginInternal(ctx context.Context, treeID int64, readonly bool) (storage.LogTreeTX, error) {
once.Do(func() {
createMetrics(prometheus.MetricFactory{})
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't that come from the registry, rather than have prometheus hardcoded?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ideally, yes -- I'll add a TODO.


func (m *mySQLLogStorage) beginInternal(ctx context.Context, treeID int64, readonly bool) (storage.LogTreeTX, error) {
once.Do(func() {
createMetrics(prometheus.MetricFactory{})
Copy link
Contributor

Choose a reason for hiding this comment

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

Same question here, shouldn't that use the registry?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ideally, yes, although in practice I don't think we'll ever use the MySQL storage layer with anything other than the Prometheus metric layer.

I'll add a TODO

return nil, fmt.Errorf("Unsequenced: %v", err)
}
}
queuedCounter.Add(float64(len(leaves)), labelForTX(t))
Copy link
Contributor

Choose a reason for hiding this comment

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

I'll trust you know what you're doing with the changes here and below... 😃

r.handlerRequestErrorCountMap.Add(method, 1)
r.handlerRequestFailedLatencyMap.Add(method, latency.Nanoseconds()/nanosToMillisDivisor)
r.ReqErrorCount.Inc(labels...)
r.ReqErrorLatency.Observe(float64(latency.Nanoseconds()/int64(time.Millisecond)), labels...)
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't latency.Nanoseconds() divide by time.Millisecond without the need for casts? And then cast back to float64 once? I admit there's the semantic ickiness of momentarily having a time.Duration that's "incorrect" (containing a value in the wrong unit)...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

latency.Nanoseconds() is an int64, but you're right, it can be simplified to float64(latency/time.Millisecond) - done.

New interface to create different sorts of metric, each of which
is an interface.

Add a testonly/ package with tests that should pass regardless of
the implementation of the interface.
Add an in-memory, unexported implementation of the MetricFactory
interfaces.  This is only useful for tests.
Add the MetricFactory interface to the extension registry, and
use the Prometheus-based implementation in the logsigner and
logserver.
Use the monitoring.MetricFactory interface instead.

Move the RPC interceptor test into the monitoring_test package
as it needs a concrete implementation (and only needs public
entrypoints from the monitoring package anyway).
If so configured, announce HTTP endpoints for the logserver and the
logsigner to etcd.  This allows monitoring systems to discover those
endpoints.
@daviddrysdale daviddrysdale merged commit f2607ef into google:master Jun 2, 2017
@daviddrysdale daviddrysdale deleted the wrapped-metrics branch June 2, 2017 15:43
liamsi added a commit to liamsi/trillian that referenced this pull request Jun 7, 2017
- catch-up with google#654 (where the flag was removed)
- needed for google/keytransparency#578
daviddrysdale pushed a commit that referenced this pull request Jun 7, 2017
- catch-up with #654 (where the flag was removed)
- needed for google/keytransparency#578
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants