envoyproxy/envoy

observability: allow "event sink" services to update configuration in-band

Open

#10,968 创建于 2020年4月27日

在 GitHub 查看
 (2 评论) (0 反应) (0 负责人)C++ (5,373 fork)batch import
area/observabilityhelp wanted

仓库指标

Star
 (27,997 star)
PR 合并指标
 (平均合并 8天) (30 天内合并 378 个 PR)

描述

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.

  1. 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 2 below. As pointed out by Harvey in this comment.
  2. 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.
  3. 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)

贡献者指南