Consider changes to timeouts for asynchronous metrics

[kaylareopelle]

@wsmoak brought up some great points about the timeout behavior for asynchronous metrics in #1877.

Some things to ponder:

1. Currently, the asynchronous timeout is using Ruby's Timeout class, which operates in seconds. OTel exporter timeouts use milliseconds. Should we change the implementation to use milliseconds? Regardless, we should update the documentation to be clearer about the required unit.

2. Does the spec allow timeouts to be set for an asynchronous instrument on creation? Are any other implementations doing this? We should consider whether attributes could also be set on instrument creation.

From #1877:

I left a comment on https://github.com/wsmoak/opentelemetry-ruby/commit/309c129610166267055ce550c50c72826d67fba4#r164094574

I am confused by the need to set the timeout and attributes separately after creating the observable gauge.

And why you do that by calling observe on the just-created instrument. (Which does, actually, record an observation, in addition to setting the attributes for observations going forward.)

It seems like those could just be supplied when you create it.

[github-actions[bot]]

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.

[xuan-cao-swi]

1. Currently, the asynchronous timeout is using Ruby's Timeout class, which operates in seconds. OTel exporter timeouts use milliseconds. Should we change the implementation to use milliseconds? Regardless, we should update the documentation to be clearer about the required unit.

The @timeout in asynchronous_metric_stream actually is always nil since there is no way to initialize or modify it, so the callback timeout is always default timeout (which is 30 seconds). The only way to have different timeout effect is to use observe(timeout, attribute) methods but that is just one-time usage (e.g. won't change the value of @timeout in instance). Currently metric_reader doesn't timeout on collect, but periodical metric reader can force timeout to avoid infinite time of collecting.

2. Does the spec allow timeouts to be set for an asynchronous instrument on creation? Are any other implementations doing this? We should consider whether attributes could also be set on instrument creation.

Python doesn’t enforce the timeout for callbacks (link). JS has the timeout implementation that is based on the timeout of collection.

I am confused by the need to set the timeout and attributes separately after creating the observable gauge.

And why you do that by calling observe on the just-created instrument. (Which does, actually, record an observation, in addition to setting the attributes for observations going forward.)

Yes, it's confusing, need another PR to sort this out.

[github-actions[bot]]

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.