Discovering Objectives before real metrics are produced

[brettimus]

Related to: https://github.com/orgs/autometrics-dev/discussions/31

We've discussed how to discover function names before any metrics are produced, and thus far the implementations in libraries have settled on initializing counters at zero.

This allows us to know which functions have been "autometricized". It also gives us insight into which Success rate objectives have been defined.

However, we cannot initialize histograms with zero values, because this would affect latency calculations.

This means we have a situation where, before any metrics are produced, we can detect success-rate-related SLO definitions, but we cannot detect latency-related SLO definitions.

I'm wondering if we can add a gauge, similar to the build_info gauge, which would track which objectives are enabled.

I can add sample queries later if this idea seems viable (I'm about to log off)

[gagbo]

I wonder if we could manually create the {histogram_name}_count counter, and then add the 0 value there. Will client libraries accept this hack though? (and overwrite the metric later when actual calls happen)

[emschwartz]

I think the easiest way to make this work would be to just observe zero-latency values for each of the histograms and make it apply this behavior only in debug mode or debug builds.

Specifically, I think the problem with using a separate metric to show the names of the SLOs is that it wouldn't tell you which functions are part of which SLO.

[emschwartz]

I tried one another possibility: observing a NaN value. Unfortunately that seems to permanently mess up the function_calls_duration_seconds_sum so I don't think that's a good approach. The counts and buckets are correct, but still.