Expose Metric details

[AlekSi]

Right now we use the following code in our exporter tests:

type metricResult struct {
	name       string
	labels     prometheus.Labels
	value      float64
	metricType dto.MetricType
}

func readMetric(m prometheus.Metric) *metricResult {
	pb := &dto.Metric{}
	err := m.Write(pb)
	if err != nil {
		panic(err)
	}

	name := getName(m.Desc())
	labels := make(prometheus.Labels, len(pb.Label))
	for _, v := range pb.Label {
		labels[v.GetName()] = v.GetValue()
	}
	if pb.Gauge != nil {
		return &metricResult{name, labels, pb.GetGauge().GetValue(), dto.MetricType_GAUGE}
	}
	if pb.Counter != nil {
		return &metricResult{name, labels, pb.GetCounter().GetValue(), dto.MetricType_COUNTER}
	}
	if pb.Untyped != nil {
		return &metricResult{name, labels, pb.GetUntyped().GetValue(), dto.MetricType_UNTYPED}
	}
	panic("Unsupported metric type")
}

(getName is a hack from #322)

I would like to have something like that in that package, not to copy&paste it across several exporters.

Alternatively, I would like to add methods to Metric interface. That feels like a more natural solution to me – type exposes information about itself directly, not via serializing and deserializing. What do you think?

That's a subtask of #58, but I want to discuss (and possibly implement) it separately if it is fine with you.

[AlekSi]

@beorn7 What do you think?

[beorn7]

This is one of the tasks that would require more work to review than to implement it myself.

I acknowledge that it is bad that it takes so long to get done. I blame a very exhausting situation in both my professional and private life. Expectations are that I will have more time for client_golang soon(tm), so that's the only promise I can give.

About changing the Metric or other interfaces to allow direct access to the value: This was discussed multiple times already with the conclusion of not allowing it, for various reasons.

[beorn7]

Since this is exactly what #58 is about, I close it as a dupe.

[brian-brazil]

@AlekSi You might want to look at what we're doing over in the blackbox exporter for testing for inspiration: https://github.com/prometheus/blackbox_exporter/blob/master/utils_test.go (though this doesn't support labels, and we're checking for every single metric due to the unusual nature of this exporter.)

[AlekSi]

Thanks. I think I will move that common code to our shared repo for exporters (https://github.com/percona/exporter_shared). Feel free to ping me if I can help with anything client_golang-related.

[beorn7]

Thanks for the offer. I'm planning to flag some issues as "suitable for new contributors" or something. Many of the existing issues are quite loaded with years of context hidden behind them. Others are pretty straightforward.