Write cache metrcis #378
No reviewers
Labels
No labels
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#378
Loading…
Reference in a new issue
No description provided.
Delete branch "dstepanov-yadro/frostfs-node:feat/write-cache-metrics"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Metrics added:
put, get/head, delete duration & counters. Duration implemented with histogram vector metric labeled with shard id, success flag and storage type. Counters implemented with counter vectors labeled with shard id, success flag and storage type
flush and evict counters labeled with shard id, storage type and success flag (for flush only)
actual object count in write cache labeled with shard id and storage type
estimated cache size (object count x max allowed object size). Estimated size used by put objects.
writecache mode metric.
91f6a694e9
to914a37b99c
914a37b99c
to8a7ffacf4b
8a7ffacf4b
to4f6e05e208
4f6e05e208
to9aaaf9a367
9aaaf9a367
to38f95af11d
WIP: Write cache metrcisto Write cache metrcisLGTM
@ -0,0 +32,4 @@
type metricsStub struct{}
func (s *metricsStub) Get(_ time.Duration, _ bool, _ StorageType) {}
you can just delete all placeholders, since none is used, e.g.
Same elsewhere.
fixed
@ -166,1 +168,4 @@
}
// WithMetrics sets metrics implementation.
func WithMetrics(metrics metrics) Option {
this interface should be exported if it's used as part of the public API of this package?
Fixed. I don't think someone will mock it:)
@ -34,2 +35,4 @@
defer span.End()
startedAt := time.Now()
added := false
hmm, is it really better having these two vars assigned than just calling the
c.metrics.Put
where they are assigned? Following the flow seems a bit messier this way, IMHO.It seems to me that it's easier this way: negative case by default, but for success way we need to change vars.
@ -33,12 +34,16 @@ func NewNodeMetrics() *NodeMetrics {
})
mustRegister(epoch)
wcMetrcis := newWCMetrics()
s/
wcMetrcis
/wcMetrics
fixed
@ -0,0 +39,4 @@
modeMetrics map[shardIDMode]metric[prometheus.GaugeFunc]
modeValues map[string]string
modeMtx *sync.RWMutex
no need for pointer
fixed
@ -0,0 +177,4 @@
mustRegister(m.evictCounter)
}
func setWCDuration(m *metric[*prometheus.HistogramVec], shardID string, success bool, d time.Duration) {
I'm not sure, but do we actually need to pass these (i.e.
m
) using pointers?replaced with value pointer
daf63fad63
tod067817895
d067817895
to9366e26de3
9366e26de3
toce714c9c89
ce714c9c89
to180c33a101
180c33a101
tof3763c1f40
@ -33,12 +34,16 @@ func NewNodeMetrics() *NodeMetrics {
})
mustRegister(epoch)
wcMetrics := newWCMetrics()
I would personally avoid this sort of abbreviation in type names.
writeCacheMetrics
is not that long, and autocomplete helps.fixed
@ -0,0 +60,4 @@
}
}
func (m *wcMetrics) WriteCacheGetDurationAdd(shardID string, success bool, d time.Duration) {
eventually we will probably want to think about better structuring this (not specific to this PR). I suspect namespacing the metrics with prefixes in method names won't scale :))
Maybe we can try it here already? Like
nodeMetrics.WriteCache()
if @dstepanov-yadro doesn't mind, that would be ideal.
done
f3763c1f40
to70fa1403f2
@ -27,0 +29,4 @@
}
type WriteCacheMetrics interface {
WriteCacheGetDurationAdd(shardID string, success bool, d time.Duration)
We already have
AddXDuration
pattern for names in this package, why not follow?fixed
@ -241,2 +241,3 @@
// flushObject is used to write object directly to the main storage.
func (c *cache) flushObject(ctx context.Context, obj *object.Object, data []byte) error {
func (c *cache) flushObject(ctx context.Context, obj *object.Object, data []byte, st StorageType) error {
success := true
What about declaring
err
here instead?done
@ -0,0 +13,4 @@
}
const (
StorageTypeUndefined StorageType = ""
Does it have any specific meaning for the person who views metrics?
This value is used when success = false, so replaced with
null
valueHm, so we can have failed counter increasing both for "any fail" and "fail specific to some storage type"?
I mean may be it's better to have 1 total for everything and specific counters which could increase together with the total one?
Why it is better?
Now this case can be resolved with selector {success=false}.
@ -0,0 +14,4 @@
const (
StorageTypeUndefined StorageType = ""
StorageTypeDB StorageType = "db"
Why are they exported?
they are used in
engine
pkg70fa1403f2
tob438f55e7d
b438f55e7d
toa3ecf15929
a3ecf15929
to639168b74f
639168b74f
toc81d44a06d