program will oom cause massive metrics in memory without expiring mechanism

[jingb]

there has a program and it consumes massive message from kafka. then it will trans the message to metrics format and use the vm metrics sdk to push to victoriametrics.
cause the vm metrics sdk holds global map to store the all the metrics in it and there has no expiring mechanism, the map will expand infinitely and finally the program oom. The process described above will be more obvious. Any solution to solve it?
and it seems there has a similar problem in https://github.com/prometheus/client_golang
prometheus/client_golang#920

// Set is a set of metrics.
//
// Metrics belonging to a set are exported separately from global metrics.
//
// Set.WritePrometheus must be called for exporting metrics from the set.
type Set struct {
	mu        sync.Mutex
	a         []*namedMetric
	m         map[string]*namedMetric
	summaries []*Summary
}

[f41gh7]

You can use metric Sets for this case and manage expiration at your code.
https://github.com/VictoriaMetrics/metrics/blob/master/set.go#L17
Pseudo code of Sets usage:

var  (
  ms  *metrics.Set
  expireTime  time.Time
)


func collectMetrics(srcMetrics []metricsWithValues){
  if ms == nil {
         ms = metrics.NewSet()
         metrics.RegisterSet(ms)
         expireTime = time.Now().Add(time.Minute)
  }
  if time.After(expireTime) {
      metrics.UnRegister(ms)
      ms =  metrics.NewSet()
      metrics.RegisterSet(ms)
       expireTime = time.Now().Add(time.Minute)
  }
  for _, mv := range srcMetrics{ 
     ms.GetOrCreateCounter(mv.name).Inc()
  } 
}

[valyala]

FYI, it isn't OK if the number of exposed metrics grows without bounds, since this may result in high cardinality issues and high churn rate issues at the monitoring system side.