【阅读原文】戳：服务网格容灾系列场景（二）：使用服务网格应对可用区级故障容灾
可用区级故障是云上业务可能遭遇的一种较为极端的故障类型。当可用区故障发生时，发生故障的可用区内的工作负载都将面临不可用、不可访问或数据错误等风险，这包括用户自行部署的工作负载、云厂商托管的工作负载等。产生可用区级故障的原因包括但不限于：
• 电力供应问题：区域性电力中断影响整个可用区，这可能导致服务中断和工作负载不可用等问题。
• 基础设施故障：关键网络设备故障、或负载过高，或冷却系统故障等，这可能导致工作负载不可用、或处于降级状态（如延迟过高、持续返回5xx状态码等）。
• 资源问题：如文件系统写满等。这可能导致应用程序的逻辑错误、或处于降级状态。
• 人为原因：机房管理员或操作人员的误操作等。
• ……
当可用区发生故障时，我们主要需要考虑云服务基础设施的容灾和业务应用本身的容灾两种情况。服务网格ASM结合容器服务Kubernetes版可以完善地应对这两种情况：
1. 阿里云托管组件多可用区高可用
阿里云容器服务Kubernetes版ACK与阿里云服务网格ASM的所有托管组件均严格采用多副本、多可用区均衡打散的部署策略，确保在单个可用区发生故障时，集群和服务网格控制面仍然能够正常地提供服务。同时，集群内的WorkerNode、弹性容器实例也同样被打散在不同可用区。在发生可用区级别故障时（例如因不可控因素导致的机房断电、断网），健康的可用区仍然能够正常提供服务。
通过使用阿里云容器服务Kubernetes版与阿里云服务网格ASM，可以保证托管的基础设施在面临可用区级故障时的可用状态；接下来只需要考虑如何对应用本身设计故障预防方案。
2. 使用集群高可用配置和服务网格来应对应用的可用区级故障
为了应对可用区级别的故障，第一步需要将应用的工作负载均匀地部署在不同的可用区。
ACK支持多可用区（AZ）节点池。在节点池的创建和运行过程中，推荐您为节点池选择多个不同AZ的vSwitch，并在配置扩缩容策略时选择均衡分布策略，允许在伸缩组指定的多可用区（即指定多个专有网络交换机）之间均匀分配ECS实例。进一步，基于节点的弹性伸缩、部署集、多AZ分布等手段，结合K8s调度中的拓扑分布约束（Topology Spread Constraints），可以实现将工作负载均匀部署在不同的可用区。具体细节可参考ACK集群高可用架构推荐配置[1] 。
在应用实现多可用区部署后，需要能够在运行时及时有效地了解Kubernetes 应用程序和集群的健康状况，以发现可用区故障的情况，并能快速响应恢复。
• 服务网格技术可以帮助提高系统的网络可观测性，通过服务网格的数据平面代理可以暴露与网络请求和应用服务交互相关的关键指标，这些指标可以发出各种问题的信号，也包括了特定可用区的监控指标内容等。这些可观测性信息结合可以帮助发现可用区故障的情况。
• 在可用区级故障发生时，服务网格ASM还支持使用可用区流量转移能力结合负载均衡的可用区流量转移能力来进行容灾：当可用区处于不可用状态时，可以在收到相关告警信息后配置可用区转移，暂时将集群内网络流量从受影响的可用区重定向出去。当可用区恢复健康状态时，还可以恢复该可用区的流量管理。
容灾架构一览
当应对可用区级别的故障时，往往涉及到一系列上下相承的实践措施，包括：
• 在多个可用区中的均匀部署，并在每个可用区进行。
• 观测服务的相关指标并发现故障。
• 当可用区发生故障时，快速将流量从受影响可用区切走（通过手动或自动手段），以完成故障恢复，这主要涉及以下方面：
- 入口切流：确保作为流量入口的负载均衡不再向受影响可用区发送流量
- 集群内流量转移：确保集群内服务调用不会再将流量发送到受影响可用区
如下图，为应对多可用区级别的故障，需要准备一个具有多可用区worker节点的ACK集群，并在多可用区中均衡地部署工作负载。同时，可以将ACK集群和服务网格ASM实例的控制面日志、集群事件收集至日志服务SLS，并通过ACK集群和服务网格ASM将节点、容器和服务相关指标收集至阿里云可观测监控Prometheus版，以及时观测到不同级别的故障事件、并可以通过日志及Grafana仪表盘查看到集群内的服务状况。同时在使用集群流量入口时，建议使用具有多可用区多活机制的负载均衡作为入口流量承接（如NLB和ALB）。
当可用区中的应用发生故障时，取决于故障程度，可以通过不同的方式对故障进行处置：
从严重故障中恢复
严重故障是指可以通过集群事件或健康检查直接发现的故障模式。
当严重故障发生时，运行于Kubernetes集群中的工作负载会因为健康检查失败变成Unhealthy状态、或是由于可用区中的节点不可用直接变成Unknown状态。负载均衡对集群入口的网关工作负载的健康检查也将失败，负载均衡会将故障可用区内的工作负载移除出后端服务器组，达到故障恢复的目的。
于此同时，预先设置的告警联系人（可能是管理员角色）将会收到告警信息，可以从Kubernetes事件、云监控告警等渠道获知健康检查失败信息，以帮助确认可用区不可用的现状。
从灰色故障中恢复
健康检查对于明确可检测到的硬件故障或软件问题是快速有效的，可以发现如网络硬件故障、应用停止监听、机房故障等问题。
但即使进行了深入的健康检查，仍然可能出现一些模糊或间歇性的灰色故障模式，这些故障模式难以检测。例如，在区域部署之后，副本可能会响应探测并显示为健康状态，但实际上存在影响客户的功能缺陷。又或者，可用区内的库存缺乏某种特定机型、导致该可用区内的工作负载无法很好地承接实际业务逻辑。也可能在可用区中产生了微妙的基础架构问题，如数据包丢失或间歇性的依赖失败，也可能导致响应变慢但仍通过健康检查的情况。
当灰色故障发生时，可以通过NLB、ALB的DNS摘除能力与服务网格ASM的可用区转移能力，暂时将集群内网络流量从受影响的可用区重定向出去，并在业务仍然保持可用的情况下对受影响可用区中的应用展开详细调查，确认故障原因。当可用区恢复健康状态时，还可以恢复该可用区的流量管理。
容灾配置实践
步骤一：准备跨可用区集群、服务网格实例和部署示例应用
在示例中，我们通过创建一个包含多个可用区的集群来演练可用区级别故障的容灾动作。在最佳实践中，推荐在多个地域中创建多个包含多可用区的ACK集群、以应对更大的地域级别的故障、并在最小的。在本示例中我们主要聚焦在多可用区的单集群视角。
1. 创建多可用区集群
首先创建一个ACK托管集群。在创建集群时，选择来自多个可用区的交换机以支持集群的多可用区。其它配置均保持默认即可，节点池将默认使用均衡分布的扩缩容策略。
创建集群后，可以发现扩容出的节点将均匀分布在所选的两个可用区：
2. 创建多可用区的服务网格ASM实例，并添加集群到ASM实例
在服务网格控制台[2]创建服务网格ASM实例。创建时，在Kubernetes集群选项中选择添加刚刚创建的集群。在交换机处，同样选择两个不同可用区的交换机。
选择好后，点击创建服务网格并等待服务网格创建完成。
3. 部署网关及示例应用
1）参考在ASM入口网关中使用网络型负载均衡NLB[3] ，在ASM实例中ASM网关、并绑定一个网络型负载均衡NLB。NLB可用区选择和ASM实例与ACK集群同样的两个可用区（本例中是cn-hangzhou-k和cn-hangzhou-h）。
本例中采用关联网络型负载均衡NLB的ASM网关作为流量入口。您也可以使用应用型负载均衡ALB作为应用的流量入口，ALB同样具备多可用区容灾以及DNS摘除能力。
在创建网络型负载均衡NLB后，还需要关闭NLB的跨AZ转发能力，从而使得每个可用区的NLB都只向自身可用区内的后端进行转发。通过这样的配置，可以实现当可用区级故障发生时、从流量入口进行快速切流。同理，ALB也支持同样的同AZ转发能力。
2）在ASM实例中，为命名空间default开启Sidecar自动注入。具体操作参考启用自动注入[4] 。
3）使用kubectl连接到ACK集群（参考获取集群KubeConfig并通过kubectl工具连接集群[5] ），并执行以下命令来部署示例应用。
kubectl apply -f- <<EOF apiVersion: v1 kind: Service metadata: name: mocka labels: app: mocka service: mocka spec: ports: - port: 8000 name: http selector: app: mocka --- apiVersion: apps/v1 kind: Deployment metadata: name: mocka-cn-hangzhou-h labels: app: mocka spec: replicas: 1 selector: matchLabels: app: mocka template: metadata: labels: app: mocka locality: cn-hangzhou-h spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-h containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-h - name: app value: mocka - name: upstream_url value: "http://mockb:8000/" ports: - containerPort: 8000 --- apiVersion: apps/v1 kind: Deployment metadata: name: mocka-cn-hangzhou-k labels: app: mocka spec: replicas: 1 selector: matchLabels: app: mocka template: metadata: labels: app: mocka locality: cn-hangzhou-k spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-k containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-k - name: app value: mocka - name: upstream_url value: "http://mockb:8000/" ports: - containerPort: 8000 --- apiVersion: v1 kind: Service metadata: name: mockb labels: app: mockb service: mockb spec: ports: - port: 8000 name: http selector: app: mockb --- apiVersion: apps/v1 kind: Deployment metadata: name: mockb-cn-hangzhou-h labels: app: mockb spec: replicas: 1 selector: matchLabels: app: mockb template: metadata: labels: app: mockb locality: cn-hangzhou-h spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-h containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-h - name: app value: mockb - name: upstream_url value: "http://mockc:8000/" ports: - containerPort: 8000 --- apiVersion: apps/v1 kind: Deployment metadata: name: mockb-cn-hangzhou-k labels: app: mockb spec: replicas: 1 selector: matchLabels: app: mockb template: metadata: labels: app: mockb locality: cn-hangzhou-k spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-k containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-k - name: app value: mockb - name: upstream_url value: "http://mockc:8000/" ports: - containerPort: 8000 --- apiVersion: v1 kind: Service metadata: name: mockc labels: app: mockc service: mockc spec: ports: - port: 8000 name: http selector: app: mockc --- apiVersion: apps/v1 kind: Deployment metadata: name: mockc-cn-hangzhou-h labels: app: mockc spec: replicas: 1 selector: matchLabels: app: mockc template: metadata: labels: app: mockc locality: cn-hangzhou-h spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-h containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-h - name: app value: mockc ports: - containerPort: 8000 --- apiVersion: apps/v1 kind: Deployment metadata: name: mockc-cn-hangzhou-k labels: app: mockc spec: replicas: 1 selector: matchLabels: app: mockc template: metadata: labels: app: mockc locality: cn-hangzhou-k spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-k containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-k - name: app value: mockc ports: - containerPort: 8000 --- apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: mocka namespace: default spec: selector: istio: ingressgateway servers: - hosts: - '*' port: name: test number: 80 protocol: HTTP --- apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: demoapp-vs namespace: default spec: gateways: - mocka hosts: - '*' http: - name: test route: - destination: host: mocka port: number: 8000 EOF
该指令部署了一个包含名为mocka、mockb、mockc的服务的应用，每个服务下包含两个只有1副本的无状态部署，分别通过不同的nodeSelector分布到不同可用区的节点上，并通过配置环境变量来返回自己所在的可用区。
本示例中直接使用pod的nodeSelector字段来手动选择pod所在的可用区，这是出于示例演示直观的目的。在实际高可用环境的构建中，您应该配置拓扑分布约束，来保证pod尽可能分布在不同的可用区中。
具体配置方法请参考工作负载高可用配置[6] 。
步骤二：观测来自不同可用区的服务指标
完善的观测体系是容灾不可缺失的重要一环。当故障发生时，与工作负载相关的日志及指标等可观测信息以及相关的告警可以帮助我们尽快发现故障事件、确定故障范围以及初步了解故障影响或理解故障成因。
服务网格支持对运行于集群中的服务所发出以及接受的所有之请求进行访问日志以及请求指标的持续上报，能够汇总请求相关的响应码、延迟、请求尺寸等等相关信息，当可用区中发生灰色故障模式的故障时，服务网格提供的请求相关指标以及相关告警配置对确定故障范围以及故障表现可以形成有意义的参考。本示例中主要介绍如何查看服务网格上报的服务流量相关指标，有关集群工作负载相关指标及相关告警配置，可以进一步参考基于阿里云Prometheus监控配置监控告警并查看性能指标[7] 、容器服务报警管理[8] 、事件监控[9] 。
1. 为请求指标添加可用区维度
服务网格的网格代理可以自动检测工作负载部署的可用区，并存储在代理元数据中。我们可以通过编辑指标维度的方法，为服务网格指标添加locality维度、并将取值设置为xds.node.locality.zone，即工作负载所在可用区。
通过这种方式，在服务网格上报给Prometheus的指标中、将新增代表可用区的locality维度，而无需应用的额外配置。具体的指标维度编辑方式可参考监控指标设置说明[10] 。
2. 向示例应用持续发送请求，产生请求指标
通过curl工具，向示例应用持续发送请求。其中将nlb-xxxxxxxxxxxxx.cn-xxxxxxx.nlb.aliyuncsslb.com替换为步骤一种创建的网关绑定的NLB的域名。
watch -n 0.1 curl nlb-xxxxxxxxxxxxx.cn-xxxxxxx.nlb.aliyuncsslb.com/mock -v
预期输出：
> GET /mock HTTP/1.1 > Host: nlb-85h289ly4hz9qhaz58.cn-hangzhou.nlb.aliyuncsslb.com > User-Agent: curl/8.7.1 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK < date: Sun, 08 Dec 2024 11:53:26 GMT < content-length: 150 < content-type: text/plain; charset=utf-8 < x-envoy-upstream-service-time: 5 < server: istio-envoy < * Connection #0 to host nlb-85h289ly4hz9qhaz58.cn-hangzhou.nlb.aliyuncsslb.com left intact -> mocka(version: cn-hangzhou-h, ip: 192.168.122.66)-> mockb(version: cn-hangzhou-k, ip: 192.168.0.47)-> mockc(version: cn-hangzhou-h, ip: 192.168.122.44)%
由预期输出可以看到，请求的Pod会随机到两个不同的可用区，此时意味着两个可用区中的工作负载都处于可用状态。
3. 查看请求指标
服务网格所产生的指标可以被采集到各种可观测系统中，和集群监控一同为可用区中潜在发生的各种问题提供直观的观测能力。本例中我们通过将指标采集到阿里云可观测监控Prometheus版，即可通过各项指标来观测可用区内工作负载接收请求的一些关键信息（具体操作，参考将监控指标采集到可观测监控Prometheus版[11] ）。
持续发送请求一段时间后，我们可以在可观测监控Prometheus版中进行指标探索，具体操作，参考指标探索[12] 。
3.1. 示例一：查看不同可用区的工作负载请求状态码信息
在Prometheus实例中，通过如下PromQL，可以查询到指定可用区内的工作负载接收请求的速率，并按照服务名和响应码分组：
sum by(app, response_code) (rate(istio_requests_total{locality="cn-hangzhou-h", reporter="destination"}[$__rate_interval]))
通过以下指标探索，可以看到cn-hangzhou-h可用区内，三个服务接收的请求速率相差不大、同时绝大部分请求响应码都是200。
同理，可以将筛选条件变更为locality="cn-hangzhou-k"查看cn-hangzhou-k可用区下的请求速率及状态码信息。
sum by(app, response_code) (rate(istio_requests_total{locality="cn-hangzhou-k", reporter="destination"}[$__rate_interval]))
可以看到在均匀部署的情况下，两个可用区接收到的请求速率基本一致。
3.2. 示例二：查看不同可用区的工作负载请求延迟信息
在Prometheus实例中，通过如下PromQL，可以查询到指定可用区内的工作负载接收请求的平均延迟，并按照服务名和响应码分组：
sum by(app, response_code) (rate(istio_request_duration_milliseconds_sum{locality="cn-hangzhou-h", reporter="destination"}[$__rate_interval]))
同理，可以将筛选条件变更为locality="cn-hangzhou-k"查看cn-hangzhou-k可用区下的平均延迟信息。
4. 基于指标信息配置告警规则
基于服务网格上报的Prometheus指标，可以通过自定义PromQL的方式配置告警信息。当业务的延迟或状态码大于设定值时，为指定联系人发送告警信息。具体操作方式可参考创建Prometheus告警规则[13] 。
4.1. 示例一：基于应用延迟设置告警规则
对于实际业务应用的延迟来说、无法像容器CPU内存用量等指标一样设定静态阈值告警，往往需要结合实际的业务期望对不同的应用进行调整：例如，上文中mocka、mockb、mockc三个服务形成mocka -> mockb -> mockc的调用链路，因此延迟上固定会有mocka > mockb > mockc的关系。可以针对业务中的关键服务分析其期望延迟、并针对该服务设定基于延迟的告警规则、帮助发现可用区中的灰色故障信息。
示例中，通过如下的PromQL来实现针对mockb服务的告警：
sum by(response_code, locality) (rate(istio_request_duration_milliseconds_sum{app="mockb",reporter= "destination"}[1m])) > 3
该PromQL表示当mockb服务1m之内的平均延迟在3ms以上时进行告警，告警针对状态码和可用区信息进行分组。
4.2. 示例二：基于服务响应状态码设置告警规则
对于响应码来说、告警规则的设置同理，需要针对具体服务的业务设置异常状态码、并在异常状态码的速率大于一定阈值时发出告警。
示例中，通过如下的PromQL来实现针对mocka服务的告警：
sum by (locality, response_code) (rate(istio_requests_total{app="mocka",reporter="destination",response_code!="200"}[1m])) >= 0
该PromQL表示当mocka服务1m之内出现响应码不为200的请求时就进行告警，告警针对状态码和可用区信息进行分组。
步骤三：故障发生时，隔离受影响可用区
当ACK集群中的一个可用区不健康或受损时，在收到告警后，我们可以将该可用区内部署的服务工作负载与其它可用区进行隔离，在保持业务依然正常运行的情况下对故障原因进行详细调查、并在故障恢复时让流量返回到拥有完整容量的可用区。
具体来说，我们可以通过以下操作将可用区内的工作负载与其他可用区进行隔离。
1. 隔离受影响可用区中的节点
可以通过污点更改受影响可用区中的节点调度设置，禁止新的Pod向可用区内的节点进行调度。设置后，节点将进入不可调度状态，已有Pod仍将留存在节点上、但新的Pod不会在该可用区内再进行调度。具体操作，参考将节点设置为不可调度[14] 。
示例以隔离cn-hangzhou-h可用区为例，将cn-hangzhou-h可用区中的节点都标识为不可调度。
2. 转移南北向入口流量
在步骤一中，由于配置了NLB的同可用区转发，当故障发生时，只需要使用NLB（或ALB）的DNS摘除能力、就可以快速在入口南北向流量层级切走流量，防止外部流量继续流入故障可用区。
1）进入NLB控制台[15] ，单击ASM网关绑定的NLB实例。
2）在NLB的实例详情页面，可用区页签下，找到受影响可用区，在右侧操作列中单击DNS摘除，并在弹框中单击确定（示例中摘除cn-hangzhou-h可用区）。进行DNS摘除后，受影响可用区的NLB公网ip将不再出现在域名解析记录中、防止流量进一步流入受影响可用区。
3. 转移东西向流量
通过使用阿里云服务网格ASM的可用区转移能力，可以快速转移集群中的东西向流量走向，防止流量发送到指定可用区的端点。
1）进入服务网格控制台[16] ，单击管理集群的服务网格实例。
2）在网格详情页面，单击服务发现范围配置。找到高级选项，填写Pod所在的地域和可用区信息，并单击确定。
服务网格会进入短暂的更新状态，更新完成后将会将指定可用区内的端点排除出服务发现范围，这会使得该可用区的流量被快速切走。
4. 观察可用区隔离效果
继续持续访问示例应用，可以发现响应的服务均来自cn-hangzhou-k的服务，说明流量已经完全从cn-hangzhou-h可用区切走。
curl nlb-xxxxxxxxxxxxxxxxxxx8.cn-hangzhou.nlb.aliyuncsslb.com/mock -v % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Host nlb-xxxxxxxxxxxxxxxxxxx8.cn-hangzhou.nlb.aliyuncsslb.com:80 was resolved. * IPv6: (none) * IPv4: 121.41.175.51 * Trying 121.41.175.51:80... * Connected to nlb-xxxxxxxxxxxxxxxxxxx8.cn-hangzhou.nlb.aliyuncsslb.com (121.41.175.51) port 80 > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0> GET /mock HTTP/1.1 > Host: nlb-xxxxxxxxxxxxxxxxxxx8.cn-hangzhou.nlb.aliyuncsslb.com > User-Agent: curl/8.7.1q > Accept: */* > A * Request completely sent off < HTTP/1.1 200 OKe < date: Tue, 10 Dec 2024 04:03:26 GMT < content-length: 1500 < content-type: text/plain; charset=utf-8 < x-envoy-upstream-service-time: 30 < server: istio-envoyr < s { [150 bytes data] {100 150 100 150 0 0 2262 0 --:--:-- --:--:-- --:--:-- 2238 * Connection #0 to host nlb-xxxxxxxxxxxxxxxxxxx8.cn-hangzhou.nlb.aliyuncsslb.com left intact -> mocka(version: cn-hangzhou-k, ip: 192.168.0.44)-> mockb(version: cn-hangzhou-k, ip: 192.168.0.47)-> mockc(version: cn-hangzhou-k, ip: 192.168.0.46)
参照步骤二，在Prometheus实例中，通过以下的PromQL查询到集群内的工作负载接收请求的速率，并按照可用区、服务名和响应码分组：
sum by(app, response_code, locality) (rate(istio_requests_total{reporter="destination"}[$__rate_interval]))
可以观察到，在转移可用区流量后、cn-hangzhou-h可用区内所有服务接收的流量都迅速跌至0。此时，cn-hangzhou-h已经处于流量隔离环境下，可以安全地进行故障检查等操作。
当需要从故障状态恢复时，则需要解除集群中节点的不可调度状态（消除污点）、删除配置的服务发现范围、并恢复NLB的DNS解析。
相关链接：
[1] ACK集群高可用架构推荐配置
[2] 服务网格控制台
[3] 在ASM入口网关中使用网络型负载均衡NLB
[4] 启用自动注入
https://help.aliyun.com/zh/asm/user-guide/manage-global-namespaces#title-2ff-57z-yk9
[5] 获取集群KubeConfig并通过kubectl工具连接集群
[6] 工作负载高可用配置
[7] 基于阿里云Prometheus监控配置监控告警并查看性能指标
[8] 容器服务报警管理
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/alert-management
[9] 事件监控
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/event-monitoring
[10] 监控指标设置说明
https://help.aliyun.com/zh/asm/user-guide/observability-settings
[11] 将监控指标采集到可观测监控Prometheus版
[12] 指标探索
https://help.aliyun.com/zh/arms/prometheus-monitoring/index-exploration
[13] 创建Prometheus告警规则
https://help.aliyun.com/zh/arms/prometheus-monitoring/create-alert-rules-for-prometheus-instances
[14] 将节点设置为不可调度
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/set-node-schedulability
[15] NLB控制台
[16] 服务网格控制台
我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。
获取关于我们的更多信息~
