【服务网格架构】Envoy架构概览(6):异常检测

简介: 【服务网格架构】Envoy架构概览(6):异常检测



【服务网格架构】服务网格:什么是Envoy(特使)

【服务网格架构】Envoy架构概览(1)术语,线程模型,监听器和网络(L3 / L4)过滤器和HTTP连接管理

【服务网格架构】Envoy架构概览(2):HTTP过滤器,HTTP路由,gRPC,WebSocket支持,集群管理器

【服务网格架构】Envoy架构概览(3):服务发现

【服务网格架构】Envoy架构概览(4):健康检查和连接池

【服务网格架构】Envoy架构概览(5):负载均衡


异常值检测和弹出是动态确定上游群集中的某些主机是否正在执行不同于其他主机的过程,并将其从正常负载平衡集中移除。性能可能沿着不同的轴线,例如连续的故障,时间成功率,时间延迟等。异常检测是被动健康检查的一种形式。特使还支持主动健康检查。被动和主动健康检查可以一起使用或独立使用,形成整体上游健康检查解决方案的基础。

弹射算法

取决于异常值检测的类型,弹出或者以行内(例如在连续5xx的情况下)或以指定的间隔(例如在定期成功率的情况下)运行。弹射算法的工作原理如下:


  1. 主机被确定为异常。
  2. 特使检查以确保弹出的主机数量低于允许的阈值(通过outlier_detection.max_ejection_percent设置指定)。如果弹出的主机数量超过阈值,主机不会被弹出。
  3. 主机被弹出几毫秒。弹出表示主机被标记为不健康,在负载平衡期间不会使用,除非负载平衡器处于紧急情况。毫秒数等于outlier_detection.base_ejection_time_ms值乘以主机被弹出的次数。这会导致主机如果继续失败,则会被弹出更长和更长的时间。
  4. 弹出的主机将在弹出时间满足后自动重新投入使用。一般而言,异常值检测与主动健康检查一起使用,用于全面的健康检查解决方案。

检测类型

Envoy支持以下异常检测类型:


连续5xx

如果上游主机返回一些连续的5xx,它将被弹出。请注意,在这种情况下,5xx意味着一个实际的5xx响应代码,或者一个会导致HTTP路由器代表上游返回的事件(复位,连接失败等)。弹出所需的连续5xx数量由outlier_detection.consecutive_5xx值控制。


连续的网关故障

如果上游主机返回一些连续的“网关错误”(502,503或504状态码),它将被弹出。请注意,这包括会导致HTTP路由器代表上游返回其中一个状态码的事件(重置,连接失败等)。弹出所需的连续网关故障的数量由outlier_detection.consecutive_gateway_failure值控制。


成功率

基于成功率的异常值弹出汇总来自群集中每个主机的成功率数据。然后以给定的时间间隔基于统计异常值检测来弹出主机。如果主机在聚合时间间隔内的请求量小于outlier_detection.success_rate_request_volume值,则无法为主机计算成功率异常值弹出。此外,如果一个时间间隔内请求量最小的主机数量小于outlier_detection.success_rate_minimum_hosts值,则不会对群集执行检测。


弹射事件记录

Envoy可以选择生成异常值弹出事件日志。这在日常操作中非常有用,因为全局统计数据不能提供有关哪些主机被弹出的信息以及原因。日志使用每行一个对象的JSON格式:

{
  "time": "...",
  "secs_since_last_action": "...",
  "cluster": "...",
  "upstream_url": "...",
  "action": "...",
  "type": "...",
  "num_ejections": "...",
  "enforced": "...",
  "host_success_rate": "...",
  "cluster_success_rate_average": "...",
  "cluster_success_rate_ejection_threshold": "..."}
time

事件发生的时间。

secs_since_last_action

自从上一次操作(弹出或未注射)发生以秒为单位的时间。由于在第一次喷射之前没有动作,所以该值将为-1。

cluster

拥有弹出主机的群集。

upstream_url

弹出的主机的URL。例如,tcp://1.2.3.4:80。

action

发生的行动。如果主机被弹出,则弹出;如果弹出主机,则弹出。

type

如果操作弹出,指定发生的弹出类型。当前类型可以是5xx,GatewayFailure或SuccessRate之一。

num_ejections

如果操作被弹出,则指定主机已被弹出的次数(对于该特使而言是本地的,并且如果主机由于任何原因从上游集群移除并且然后被重新添加)则被重置。

enforced

如果操作被弹出,则指定弹出是否被强制执行。真正意味着主机被弹出。假意味着事件被记录了,但是主机并没有被弹出。

host_success_rate

如果操作弹出,并且类型为SuccessRate,则指定喷射事件发生时在0-100范围内的主机成功率。

cluster_success_rate_average

如果操作弹出,并且类型为SuccessRate,则指定弹出事件时集群中主机在0-100范围内的平均成功率。

cluster_success_rate_ejection_threshold

如果操作弹出,类型为SuccessRate,则指定弹出事件时的成功率弹出阈值。

配置参考

  • 集群管理器全局配置
  • 每个群集配置
  • 运行时设置
  • 统计参考
相关文章
|
14天前
|
自然语言处理 监控 Cloud Native
探索微服务架构中的服务网格Service Mesh
【10月更文挑战第7天】服务网格(Service Mesh)是微服务架构中的关键组件,通过在每个服务实例旁部署Sidecar代理,实现服务间通信的管理、监控和安全增强。本文介绍了服务网格的基本概念、核心组件、优势及实施步骤,探讨了其在现代开发中的应用,并提供了实战技巧。
|
6月前
|
敏捷开发 运维 监控
探索微服务架构下的服务网格
【5月更文挑战第29天】 在现代软件开发的复杂多变环境中,微服务架构已成为构建分布式系统的热门选择。随着其应用的广泛化,服务网格(Service Mesh)这一概念应运而生并迅速崛起,它旨在提供一种透明且高效的方式来管理服务间的通信。本文将深入探讨服务网格的核心组件、运作机制以及如何通过服务网格优化微服务架构。我们还将讨论服务网格引入的挑战与克服这些挑战的策略,为采用微服务的企业提供指导和见解。
|
3月前
|
运维 负载均衡 监控
探索微服务架构下的服务网格(Service Mesh)实践之路
【8月更文挑战第30天】 在当今日益复杂的分布式系统中,微服务架构已成为众多企业解决系统扩展与维护难题的利器。然而,随着服务的不断增多和网络交互的复杂性提升,传统的微服务管理方式开始显得力不从心。服务网格(Service Mesh)作为一种新兴的解决方案,旨在通过提供应用层的网络基础设施来简化服务间通讯,并增强系统的可观察性和安全性。本文将分享我在采用服务网格技术过程中的经验与思考,探讨如何在现代云原生环境中有效地实施服务网格,以及它给开发和运维带来的变革。
|
4月前
|
存储 分布式计算 大数据
从零到一建设数据中台 - 架构概览
从零到一建设数据中台 - 架构概览
95 1
|
4月前
|
敏捷开发 运维 Cloud Native
云原生架构的演进之路:从容器化到服务网格
在数字化转型的浪潮中,云原生技术以其灵活性、可扩展性和弹性成为企业IT架构的新宠。本文将探讨云原生技术的演进路径,特别是容器化技术和服务网格的发展,以及它们如何共同推动现代应用的开发和部署。通过分析实际案例,我们揭示了云原生技术如何助力企业实现敏捷开发和高效运维,同时指出了未来云原生技术的发展趋势。
|
3月前
|
存储
软件设计与架构复杂度问题之throws new BizException("capacity over limit");”异常如何解决
软件设计与架构复杂度问题之throws new BizException("capacity over limit");”异常如何解决
|
3月前
|
Cloud Native 安全 云计算
云原生技术的未来:探索服务网格和无服务器架构
随着企业数字化转型的深入,云计算已成为推动业务创新的核心力量。本文将深入探讨云原生技术的最新发展趋势,重点分析服务网格和无服务器架构如何重塑云计算的未来。通过实际案例和技术解析,揭示这些前沿技术如何解决现代应用部署的复杂性,提高系统的可伸缩性和弹性。文章旨在为读者提供云原生领域的深度见解,并激发对云技术未来发展的思考。
93 0
|
4月前
|
Kubernetes Cloud Native 持续交付
云原生架构的核心组成部分通常包括容器化(如Docker)、容器编排(如Kubernetes)、微服务架构、服务网格、持续集成/持续部署(CI/CD)、自动化运维(如Prometheus监控和Grafana可视化)等。
云原生架构的核心组成部分通常包括容器化(如Docker)、容器编排(如Kubernetes)、微服务架构、服务网格、持续集成/持续部署(CI/CD)、自动化运维(如Prometheus监控和Grafana可视化)等。
|
4月前
|
Kubernetes Cloud Native Docker
云原生架构的演进:从容器化到服务网格
本文深入探讨了云原生技术从最初的容器化技术,如Docker和Kubernetes,发展到现代的服务网格架构,如Istio。文章将通过分析云原生技术的演进路径,揭示其在处理微服务复杂性、流量管理和安全性方面的优势。我们将通过具体案例展示服务网格如何优化分布式系统的性能,并预测未来云原生技术的发展趋势。
39 2
|
4月前
|
敏捷开发 设计模式 运维
探索微服务架构中的服务网格
【7月更文挑战第30天】在现代软件工程中,微服务架构因其灵活性和可扩展性而备受推崇。然而,随着系统规模的扩大,服务之间的通信和管理变得日益复杂。服务网格作为解决这一问题的新兴技术,提供了一种透明、可靠的服务到服务通信方式。本文将深入探讨服务网格的核心概念、实现原理以及其在微服务架构中的应用实践,为读者呈现一个关于如何利用服务网格优化微服务间通信的全景视图。
45 0