Envoy架构概览(8):统计,运行时配置,追踪和TCP代理

简介: Envoy架构概览(8):统计,运行时配置,追踪和TCP代理

统计


特使的主要目标之一是使网络可以理解。特使根据配置如何发出大量的统计数据。一般来说,统计分为两类:


  • 下游:下游统计涉及传入的连接/请求。它们由侦听器,HTTP连接管理器,TCP代理过滤器等发出
  • 上游:上游统计涉及传出连接/请求。它们由连接池,路由器过滤器,TCP代理过滤器等发出

单个代理场景通常涉及下游和上游统计信息。这两种类型可以用来获得特定网络跳跃的详细图片。来自整个网格的统计数据给出了每一跳和整体网络健康状况的非常详细的图片。所发出的统计数据在操作指南中详细记录。


特使使用statsd作为统计输出格式,虽然插入不同的统计数据汇并不难。支持TCP和UDP statsd。在内部,计数器和计量器被分批并定期冲洗以提高性能。直方图会在收到时写入。注意:以前称为定时器的东西已经成为直方图,因为两个表示法之间的唯一区别就是单位。


  • v1 API参考。
  • v2 API参考。


运行时配置

Envoy支持“运行时”配置(也称为“功能标志”和“决策者”)。 可以更改配置设置,这将影响操作,而无需重启Envoy或更改主配置。 当前支持的实现使用文件系统文件树。 Envoy监视配置目录中的符号链接交换,并在发生这种情况时重新加载树。 这种类型的系统通常在大型分布式系统中部署。 其他实现并不难实现。 受支持的运行时配置设置记录在操作指南的相关部分。 特使将使用默认运行时值和“空”提供程序正确运行,因此不需要运行Envoy这样的系统。


追踪


概览

分布式跟踪使开发人员可以在大型面向服务的体系结构中获得调用流的可视化。在理解序列化,并行性和延迟来源方面,这是非常宝贵的。 Envoy支持与系统范围跟踪相关的三个功能:


  • 请求ID生成:Envoy将在需要时生成UUID并填充x-request-id HTTP头。应用程序可以转发x-request-id头以进行统一日志记录以及跟踪。
  • 外部跟踪服务集成:Envoy支持可插入的外部跟踪可视化提供程序。目前,Envoy支持LightStep,Zipkin或Zipkin兼容后端(例如Jaeger)。但是,对其他跟踪提供者的支持并不难添加。
  • 客户端跟踪ID加入:x-client-trace-id头可用于将不可信的请求ID连接到可信的内部x-request-id。

如何启动跟踪

处理请求的HTTP连接管理器必须设置跟踪对象。有几种方法可以启动跟踪:


  • 由外部客户端通过x-client-trace-id头部。
  • 通过x-envoy-force-trace头部的内部服务。
  • 通过随机采样运行时间设置随机采样。

路由器过滤器还可以通过start_child_span选项为出口呼叫创建子范围。


跟踪上下文传播

Envoy提供报告有关网格中服务之间通信的跟踪信息的功能。但是,为了能够关联呼叫流内各个代理生成的跟踪信息,服务必须在入站和出站请求之间传播特定的跟踪上下文。


无论使用哪个跟踪提供者,该服务都应该传播x-request-id,以便使被调用服务的日志记录相关。


跟踪提供者还需要额外的上下文,以便能够理解跨度(逻辑工作单元)之间的父/子关系。这可以通过在服务本身内直接使用LightStep(通过OpenTracing API)或Zipkin tracer来实现,以从入站请求中提取跟踪上下文,并将其注入到任何后续的出站请求中。这种方法还可以使服务创建额外的跨度,描述在服务内部完成的工作,这在检查端到端跟踪时可能是有用的。


或者,跟踪上下文可以由服务手动传播:


  • 当使用LightStep跟踪器时,Envoy依靠该服务传播x-ot-span-context HTTP头,同时向其他服务发送HTTP请求。
  • 当使用Zipkin示踪器时,Envoy依靠该服务传播官方的B3 HTTP报头(x-b3-traceid,x-b3-spanid,x-b3-parentspanid,x-b3-sampled和x-b3-flags )或为了方便起见,也可以传播x-ot-span-context HTTP头。

注意:分布式跟踪社区中正在进行工作以定义跟踪上下文传播的标准。一旦采用了合适的方法,用于传播Zipkin跟踪上下文的非标准单头x-ot-span-context的使用将被替换。


每个跟踪包含哪些数据

端到端跟踪由一个或多个跨度组成。跨度表示具有开始时间和持续时间的逻辑工作单元,并且可以包含与其关联的元数据。 Envoy生成的每个跨度包含以下数据:


  • 通过--service-cluster设置始发服务集群。
  • 开始时间和请求的持续时间。
  • 始发主机通过--service-node设置。
  • 通过x-envoy-downstream-service-cluster头设置下游集群。
  • HTTP网址。
  • HTTP方法。
  • HTTP响应代码。
  • 跟踪系统特定的元数据。

范围还包括一个名称(或操作),默认情况下被定义为被调用的服务的主机。但是,这可以使用路线上的装饰器进行定制。该名称也可以使用x-envoy-decorator-operation标头覆盖。


特使自动发送跨度追踪收藏家。根据跟踪收集器的不同,使用通用信息(如全局唯一请求标识x-request-id(LightStep)或跟踪标识配置(Zipkin))将多个跨度拼接在一起。看到


  • v1 API参考
  • v2 API参考

有关如何在Envoy中设置跟踪的更多信息。


TCP代理

由于Envoy基本上是作为L3 / L4服务器编写的,因此基本的L3 / L4代理很容易实现。 TCP代理筛选器在下游客户端和上游群集之间执行基本的1:1网络连接代理。 它本身可以用作替代通道,或者与其他过滤器(如MongoDB过滤器或速率限制过滤器)结合使用。


TCP代理过滤器将遵守每个上游集群的全局资源管理器施加的连接限制。 TCP代理过滤器检查上游集群的资源管理器是否可以创建连接,而不会超过该集群的最大连接数,如果它不能通过TCP代理进行连接。

相关文章
|
1月前
|
前端开发 Java 应用服务中间件
21张图解析Tomcat运行原理与架构全貌
【10月更文挑战第2天】本文通过21张图详细解析了Tomcat的运行原理与架构。Tomcat作为Java Web开发中最流行的Web服务器之一,其架构设计精妙。文章首先介绍了Tomcat的基本组件:Connector(连接器)负责网络通信,Container(容器)处理业务逻辑。连接器内部包括EndPoint、Processor和Adapter等组件,分别处理通信、协议解析和请求封装。容器采用多级结构(Engine、Host、Context、Wrapper),并通过Mapper组件进行请求路由。文章还探讨了Tomcat的生命周期管理、启动与停止机制,并通过源码分析展示了请求处理流程。
|
1月前
|
消息中间件 监控 Java
大数据-109 Flink 体系结构 运行架构 ResourceManager JobManager 组件关系与原理剖析
大数据-109 Flink 体系结构 运行架构 ResourceManager JobManager 组件关系与原理剖析
64 1
|
24天前
|
缓存 前端开发 JavaScript
前端架构思考:代码复用带来的隐形耦合,可能让大模型造轮子是更好的选择-从 CDN 依赖包被删导致个站打不开到数年前因11 行代码导致上千项目崩溃谈谈npm黑洞 - 统计下你的项目有多少个依赖吧!
最近,我的个人网站因免费CDN上的Vue.js包路径变更导致无法访问,引发了我对前端依赖管理的深刻反思。文章探讨了NPM依赖陷阱、开源库所有权与维护压力、NPM生态问题,并提出减少不必要的依赖、重视模块设计等建议,以提升前端项目的稳定性和可控性。通过“left_pad”事件及个人经历,强调了依赖管理的重要性和让大模型代替人造轮子的潜在收益
|
1月前
|
存储 SQL 消息中间件
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
47 0
|
4月前
|
NoSQL Redis
Redis 主从复制架构配置及原理
Redis 主从复制架构配置及原理
62 5
|
4月前
|
存储 分布式计算 大数据
从零到一建设数据中台 - 架构概览
从零到一建设数据中台 - 架构概览
108 1
|
4月前
|
NoSQL Redis 开发工具
Redis性能优化问题之检查 Redis 实例是否启用了透明大页机制,如何解决
Redis性能优化问题之检查 Redis 实例是否启用了透明大页机制,如何解决
|
3月前
|
监控 安全 API
Android项目架构设计问题之保证线上用户不会进入到本地配置页面如何解决
Android项目架构设计问题之保证线上用户不会进入到本地配置页面如何解决
30 0
|
3月前
|
JSON Android开发 数据格式
Android项目架构设计问题之在远端动态配置中添加相应配置如何解决
Android项目架构设计问题之在远端动态配置中添加相应配置如何解决
28 0
|
4月前
|
负载均衡 监控 Kubernetes
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。