1885380 - Can the object metric type be used to gifft to keyed histograms?

Status: RESOLVED DUPLICATE of bug 1907945

(Toolkit :: Telemetry, enhancement)

Description

[Perry McManis [:perry.mcmanis]]

With the object metric type landing, there may be opportunities to cover some gaps in GIFFT mapping, especially to legacy's keyed histograms.

Questions:

• Do we want to do this?
• What is the size of the effort?
• Are there any complications to doing this?
• How would this impact recommendations on which telemetry system to use?

Comment 1

[Chris H-C :chutten]

I don't think we want to do this for a couple of reasons

1. So far, we only map Glean metric types to Legacy Telemetry probe types that can represent (even clumsily) the entire representable domain of the Glean metric. (modulo weird values in the corners). For example, counter can be a Scalar with kind: uint because they both can represent the same values. object metrics cannot be entirely represented by anything in Legacy Telemetry that doesn't require writing a custom schema, so it doesn't fit the pattern.
2. This is a matter of "How can these Glean things be mirrored to Telemetry" not "How can these Telemetry things be mirrored to Glean". "keyed histograms" are a Telemetry thing that Glean doesn't have.
3. We still need labeled distributions for [telemetry-parity] and so many uses within platform. We should be wary of tasks that pull us away from that.

What do you think?

Comment 2

[Perry McManis [:perry.mcmanis]]

So, I don't want to speak too too much for Wil on this as he floated the idea originally, so I've tagged him so he can comment too even if it's to just affirm.

My feeling, hence my enthusiasm to at least get a bug on the books, is that part of doing this would be in support of moving policy from "use the telemetry that chameleons into the component youre already in, unless one system has some capability the other lacks" to potentially "all new metrics must be instrumented via Glean, if you need a Legacy version use GIFFT"

1. and 3. are compelling to me (2. less so because I am willing to compromise on ideological purity in the short run until which time such things are no longer necessary). 3. Is a matter of prioritization and not one I'd push other things out of the way for in H1, H2 hmm more open for discussion.

Re 1, I'm not fully bought in one way or the other. Most users of FOG I've personally interacted with would be OK with us making an abstract FOG only type, well I mean in the sense that beyond its usefulness that they would not insist on using internal bits where one could run into problems with the fact that the giffted type is technically only supporting a subset of what the glean type could represent. IE we wouldnt have folks define an object and gifft it, we would instead offer a FOG type. I think if we took this approach, we could also decommission this adapter a bit more easily? Im sure there are other ways to approach though.

@Wil, if you wouldn't mind tagging chutten back after you've commented to your satisfaction, I'd appreciate it!

Comment 3

[Wil Stuckey]

Now that labeled distributions has landed, I think we can close this out.