【问题标题】:Filter request logs in the istio sidecar proxy在 istio sidecar 代理中过滤请求日志
【发布时间】:2021-08-13 23:53:57
【问题描述】:

我有一个 azure 前门,位于 aks 集群的前面,每个 pod 都注入了​​ istio 和代理边车。

由于 Azure 前门终结点的数量,Azure 前门的运行状况探测每秒至少会命中一次请求。应用程序收到的请求数量非常多,以至于我想减慢间隔它的影响是失去前门的好处。

Microsoft 建议在 dotnet 中编写遥测初始化程序以将请求标记为合成,但这似乎是一个大问题,我需要让多个团队参与进来。以及复制到多种语言。

相反,我想使用特使过滤器来查看请求的标头,如果它与前门代理“Edge Health Probe”匹配,我想完全忽略它。

这意味着我可以控制将哪些日志发送到应用洞察,可以推出适合所有人的解决方案,并且不需要开发人员参与。

我看过 envoy 过滤器,但不能真正理解它是如何工作的。

特使过滤器可以做到这一点还是有人知道更好的方法?

谢谢 凯文

【问题讨论】:

  • 替代方案您可以在虚拟服务中设置一个路由,将所有带有标头的请求路由到某个虚拟 nginx 应用程序。通过这种方式,请求与您的工作负载完全分离。不知道我是否完全理解你的问题。
  • 所以基本上我在集群中的每个服务前面都使用frontdoor,frontdoor由于端点的数量而对每个服务发出的请求数量如此之多,以至于我们的日志空间在中午用完.这些请求带有一个特定的代理标头,如果我可以过滤掉它,因为我并不真正关心被记录的请求,它确实会减少这种情况。当您查看 istio 代理日志时,您可以看到请求日志,它们只是作为 HEAD 请求发送到已设置的健康探测页面。我只想做一个“如果代理标头== X:则不记录请求结束”
  • docs.microsoft.com/en-us/azure/azure-monitor/app/… 这是微软推荐的,但显然这是一种编码方法,我们需要为不同的语言复制并推广到众多应用程序。

标签: kubernetes istio envoyproxy azure-front-door


【解决方案1】:

您可以使用EnvoyFilter 来做到这一点。此示例识别入口网关上的标头并简单地发送 200 响应而不将其发送到工作负载:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: custom-ms-header
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
    - applyTo: NETWORK_FILTER
      match:
        context: GATEWAY
        listener:
          filterChain:
            filter:
              name: envoy.filters.network.http_connection_manager
              subFilter:
                name: envoy.filters.network.http_connection_manager
      patch:
        operation: INSERT_BEFORE
        value:
          name: custom.ms-header
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
            inlineCode: |
               function envoy_on_request(request_handle)
                 val = request_handle:headers():get("some-header")
                 if (val and val ~= "some-value") then
                   request_handle:respond({[":status"] = "200"}, "ok")                        
                 end
               end

或者,您可以将其应用于匹配某些工作负载

[...]
    namespace: my-namespace
spec:
  workloadSelector:
    labels:
      istio: my-worklload
  configPatches:
    - applyTo: NETWORK_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          filterChain:
[...]

这要求您将其应用于每个工作负载。

【讨论】:

  • 抱歉,如果缩进不正确,我是在智能手机上写的。
  • 如果您还有其他问题,请在 cmets 中提问,我可以扩展我的答案。
  • 这听起来很棒,是的,正是我想做的。我需要在每个命名空间或 istio 系统命名空间中应用此过滤器吗?这将是全面的,我希望它到位。
  • 带有入口网关的版本只需要应用于 istio-ingressgateway pod 运行的命名空间,通常是 istio-system 命名空间。该逻辑将应用于每个传入的请求。
  • 我会在下周再试一次,看看我会得到什么,我会回复评论
【解决方案2】:

我是否误解了这一点,但如果您想忽略该请求,为什么不简单地关闭运行状况探测?

或者将探测的间隔从默认的 30 秒更改为 255 以减少请求,当然默认的健康探测是 HEAD 请求,因此您可以轻松地将它们过滤掉。

【讨论】:

  • 我需要 heatlh 探针,因为它会让前门知道根据运行状况探针发送到任一集群,因此禁用它们会变得毫无意义,也会增加间隔,尽管考虑会使 failovwr 真的慢的。我想停止实际记录在应用程序洞察力中的日志,因为这就是问题发生的地方。特使过滤器需要检查运行状况探测是否有效并将 200 返回到前门但没有实际的日志行 - 如果 poss
猜你喜欢
  • 2021-06-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-04-03
  • 1970-01-01
  • 1970-01-01
  • 2021-04-20
  • 2016-01-19
相关资源
最近更新 更多