envoyproxy/envoy
Auf GitHub ansehenobservability: allow "event sink" services to update configuration in-band
Open
#10.968 geöffnet am 27. Apr. 2020
area/observabilityhelp wanted
Repository-Metriken
- Stars
- (27.997 Stars)
- PR-Merge-Metriken
- (Durchschn. Merge 8T) (378 gemergte PRs in 30 T)
Beschreibung
In #10889 @htuch suggested allowing in-band config updates for the metrics service stats sink. This is a pretty powerful idea. This issue details some of the complexities of implementing this, and the tradeoffs involved.
- The current service definition is not bi-di streaming. It is only streaming on the request side. So we can't support in-band config updates for the life of the stream. Although only allowing one response would make the protocol easier, as it would obviate difficulty
2below. As pointed out by Harvey in this comment. - If we want to support continuous, in-band config changes that affect the shape of the data (counters as absolute values vs. deltas) we need a way for the message envoy sends to encode the "version" of config that was used to generate the data. This is the base case of what I was talking about above where the data sent prior to config might not be in the shape the service expects. In general, we have to have a way for the service to know if the data was generated with the version of the config (and hence the shape of data) the service expects. I believe this wasn't a problem with #10407 and LRS, because there the in-band updates are just filters, not changing the shape of the data itself.
- I'd like to have the logic of in-band config changes implemented in a base class that "event reporting" services can use, as I think that logic can be abstracted. I created an issue about this (https://github.com/envoyproxy/envoy/issues/10966)