Bogdan Drutu

@codeboten the time in my comment was to give us time to address my concerns, so I do believe someone (who is working full time, not like me until Sept)...

One thing that we need to agree on, is that we should suffix everything with Config probably (instead of Settings) as discussed in one of the issues.

Another thing is to make sure we pass "context" everywhere. Maybe TelemetrySettings as well

@gravelg we no longer have a "main" file, we do rely on the builder tool to generate that file. Is that solution acceptable to you?

I think we should remove the custom runtime metrics from the service, and use one of the way we do allow collecting of runtime metrics for any go lang binary....

@Vemmy124 alternative is to rely on opentelemetry-go library to produce these metrics

@Vemmy124 look into opentelemetry-go-contrib, already support for more runtime metrics. We should use that instead of OpenCensus for recording internal metrics and install the runtime plugin from there

Java has a nice way to "close" an observe instrument, still specification compliant because it is permanently associated with the instrument. See https://javadoc.io/doc/io.opentelemetry/opentelemetry-api/latest/io/opentelemetry/api/metrics/ObservableLongCounter.html **Update:** By offering this, it allows me...

> I'm interested to hear what others think about adding it in the future. Wouldn't be backwards incompatible? And if you make the dev checking if implementing a Closer interface...

@Aneurysm9 > The API MUST support creation of asynchronous instruments by passing zero or more callback functions to be permanently registered to the newly created instrument. To the "newly" created...