You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
As mentioned in the jaegerremotesampling extension's existing README, it would be nice to have optional (and configurable) collector-side caching behavior when the extension is used in conjunction with a remote gRPC endpoint implementing the JaegerRemoteSampler config API:
At this moment, the reload_interval option is only effective for the file source. In the future, this property will be used to control a local cache for a remote source.
Why is this nice? It would reduce collector -> remote endpoint volume within the configured caching window, for collector operators who care about things like egress or about the load on the remote backend endpoint. And it should be fully optional, so opting into the setting involves conscious acceptance of the eventual consistency implications for remote strategy updates (cached data is stale within TTL periods).
Describe the solution you'd like
I'd like to use the same language (and field even) for reload_interval, even if for the gRPC remote interaction it is slightly different (given that requests already specify a service name). I recommend TTL-based in-memory caching, where the TTL for each cached strategy item is just set to the reload_interval. That seems pretty intuitive for collector owners at a high level, and matches the language of the file mode of operation (which already supports reload_interval).
Describe alternatives you've considered
No response
Additional context
For what it's worth, I already have a branch that was based on #24414 and just needs some rebasing/cleanup. It has integration test coverage and unit testing of the cache, but I'll probably do quite a bit more to bring it up to par for code review. For now, I'm holding off on opening a PR with that branch because it's stacked on the branch of #24414 and I don't really know how to do stacked PRs with forks involved.
Component(s)
extension/jaegerremotesampling
Is your feature request related to a problem? Please describe.
As mentioned in the
jaegerremotesampling
extension's existing README, it would be nice to have optional (and configurable) collector-side caching behavior when the extension is used in conjunction with a remote gRPC endpoint implementing the JaegerRemoteSampler config API:Why is this nice? It would reduce collector -> remote endpoint volume within the configured caching window, for collector operators who care about things like egress or about the load on the remote backend endpoint. And it should be fully optional, so opting into the setting involves conscious acceptance of the eventual consistency implications for remote strategy updates (cached data is stale within TTL periods).
Describe the solution you'd like
I'd like to use the same language (and field even) for
reload_interval
, even if for the gRPC remote interaction it is slightly different (given that requests already specify a service name). I recommend TTL-based in-memory caching, where the TTL for each cached strategy item is just set to thereload_interval
. That seems pretty intuitive for collector owners at a high level, and matches the language of thefile
mode of operation (which already supportsreload_interval
).Describe alternatives you've considered
No response
Additional context
For what it's worth, I already have a branch that was based on #24414 and just needs some rebasing/cleanup. It has integration test coverage and unit testing of the cache, but I'll probably do quite a bit more to bring it up to par for code review. For now, I'm holding off on opening a PR with that branch because it's stacked on the branch of #24414 and I don't really know how to do stacked PRs with forks involved.
My work in progress and soon-to-come-via-PR branch: https://github.com/zcross/opentelemetry-collector-contrib/tree/origin/zcross/jaegerremotesampling/support-remote-policy-ttl-caching
The text was updated successfully, but these errors were encountered: