在Service Mesh中,不同的服务可能需要采集不同的可观测性数据,因此需要支持针对网格Waypoint与网关Pod分别定义采集配置规则,并统一标准化采集配置规则,以便更好地支持云原生应用的可观测性。可观测性在云原生应用中扮演着非常重要的角色,它可以帮助我们实时监控服务的运行情况和性能指标,发现并解决服务故障和瓶颈,从而提高应用的可靠性和性能。阿里云服务网格ASM提供了统一标准化方式,为您提供一种收敛后的可观测数据生成与采集配置模式,以更好地支持云原生应用的可观测性。本文介绍可观测的概念及相关功能。
可观测介绍
随着应用系统的复杂度越来越高,就越来越难保证所有的系统都一直处于稳健状态,有可能某些部分会因问题而处于降级状态。因此不仅需要将应用程序构建得更可靠且更具弹性,还需要通过可观测性工具了解应用服务和基础设施在运行时发生的情况。如果能够了解实际发生的情况,就可以学会检测故障并在观察到某些意外情况时进行深入调试。这将有助于降低平均恢复时间,快速恢复对业务的影响。
可观测性是一个包含各种级别的系统特征,必须结合应用程序的指标采集、网络的指标采集、以及基础设施(例如数据库存储等)来筛选存储大量的数据,以便在发生不可预测的情况时拼凑出一个完整的视图。Service Mesh在可观测性方面可以有效提升应用程序级别的网络指标采集。从实际应用的角度来看,在系统中需要重视其稳定性,需要理解什么时候系统运行良好或出现问题,从而可以更快地识别错误,并实施正确的自动化及手动控制来维护系统的可用性。
Service Mesh的Waypoint工作负载位于服务之间的网络请求路径中,通过捕获Waypoint的可观测性数据可以在运行时了解应用程序网络和网格的运行情况。
在Service Mesh中实现可观测性,涉及了日志、监控指标、链路追踪这些可观测性数据的生成规则配置和采集配置,以及如何将这些可观测数据采集到云托管服务或者自建服务中。同时,还需要考虑如何支持针对网格代理与网关Pod分别定义采集配置,以支持不同的场景诉求。ASM提供了统一标准化方式,为您提供一种收敛后的可观测数据生成与采集配置模式,以更好地支持云原生应用的可观测性。
日志
在Service Mesh中,日志的采集是实现可观测性的重要手段之一,使用访问日志,您可以获取请求的响应码,请求路径,请求主机,虚拟服务路由名称等信息。一条请求日志如下所示。
{
"authority_for": "httpbin:8000",
"bytes_received": "0",
"bytes_sent": "0",
"downstream_local_address": "192.168.73.109:8000",
"downstream_remote_address": "10.22.115.101:35004",
"duration": "0",
"istio_policy_status": "-",
"method": "GET",
"path": "/delay/60",
"protocol": "HTTP/1.1",
"request_id": "fa4a0646-f873-9561-9b1f-eb58e439866c",
"requested_server_name": "-",
"response_code": "429",
"response_flags": "UAEX",
"route_name": "default",
"start_time": "2025-06-17T01:36:06.687Z",
"trace_id": "-",
"upstream_cluster": "outbound|8000||httpbin.default.svc.cluster.local;",
"upstream_host": "-",
"upstream_local_address": "-",
"upstream_response_time": "-",
"upstream_service_time": "-",
"upstream_transport_failure_reason": "-",
"user_agent": "curl/8.1.2",
"x_forwarded_for": "-"
}
日志格式规则配置
在实际应用中,不同服务的日志格式可能不同,因此需要设置生成规则来控制日志的生成方式。ASM支持自定义数据面输出的访问日志内容。具体操作,请参见自定义数据面访问日志。
当前日志格式规则配置只能生效于Evnoy代理(Sidecar,Waypoint,网关),对于Ztunnel来说,该配置无法生效。
数据面日志采集设置
将数据面日志采集到阿里云日志服务SLS时,需要设置采集规则来控制日志的采集方式和储存有效期。容器服务ACK集成了日志服务功能,可对服务网格数据面集群的AccessLog进行采集。具体操作,请参见使用日志服务采集数据面集群AccessLog。
采集控制平面日志及设置告警
ASM支持采集控制平面日志和日志告警,例如采集ASM控制平面向数据平面Envoy代理推送配置的相关日志。ASM控制面组件的主要功能之一是推送网格的规则配置到数据面的Envoy代理中。如果您配置的网格规则内容存在一些冲突导致推送失败,Envoy代理将接收不到最新的配置内容。虽然Envoy代理在不重启的情况下,可以使用已经接收到的配置继续运行,但是一旦这些Pod重启,很有可能导致Envoy代理失败。在很多实际场景中,经常出现用户误配置引发的网关或代理不可用的问题,因此启用控制面的日志告警,及时发现并解决问题十分必要。具体操作,请参见启用控制平面日志采集和日志告警(旧版)或启用控制平面日志采集和日志告警(新版)。
监控指标
监控指标是Service Mesh中的另一个重要可观测性维度,用于描述请求的处理情况、服务之间的通信状况等。Istio采用Prometheus进行监控指标的采集和存储,每个Envoy代理(Waypoint,Sidecar,网关等)以及 Ztunnel 会生成大量的监控指标。这些指标可以用于实时监控服务的运行情况和性能指标,还可以用于异常检测和自动伸缩等场景。
监控指标注意事项
第一次开启:阿里云可观测监控Prometheus版是收费服务,请您根据实际情况自行决定指标生成范围,以免指标量过大,产生过高费用。例如,若需要针对网关进行监控,则需要开启CLIENT侧指标。对于已开启过的指标,重新开启之后的指标设置将保留使用上一次的设置规则。
ASM网格拓扑功能相关的指标设置:ASM网格拓扑功能依赖于Sidecar上报的监控指标,若您开启了网格拓扑,关闭部分监控指标会对网格拓扑功能造成影响甚至不可用。
如果不启用REQUEST_COUNT的SERVER侧指标,将无法生成HTTP或gRPC服务的拓扑图。
如果不启用TCP_SENT_BYTES的SERVER侧指标,将无法生成TCP服务的拓扑图。
关闭REQUEST_SIZE和REQUEST_DURATION的SERVER侧,REQUEST_SIZE的CLIENT侧指标会导致部分拓扑图节点的监控信息无法展示。
启用指标采集
开启Prometheus的统计数据收集功能,将采集到的监控指标发送到Prometheus中,以便进行存储和分析。ASM集成了ARMS Prometheus功能,可以实现对服务网格的监控。您也可以使用自建的 Prometheus 进行采集。具体操作,请参见:
指标数据生成规则配置
启用服务网格数据面监控指标可以使服务网格数据面生成与其运行状态相关的指标数据。您可以启用或停用特定的监控指标(例如 TCP 连接时间,请求大小等),只保留您关心的监控指标,从而降低指标所带来的性能消耗,计费等。具体操作,请参见在ASM中自定义监控指标。
指标采集间隔
Prometheus采集间隔会对指标收集开销产生重大影响。间隔越长,抓取的数据点就越少,从而可以减少处理、存储和计算开销。经过我们的实践,推荐您配置采集间隔为 30 秒,以在保证数据不会漏采集的情况下,降低采集的开销。
当您使用 ARMS 进行采集时,采集间隔为 30 秒,并且为了 ASM 提供的大盘能够正常使用,此间隔不支持修改。
指标废弃配置
直方图关联的指标(包括istio_request_duration_milliseconds_bucket
、istio_request_bytes_bucket
、istio_response_bytes_bucket
)通常比较密集,开销较大。为了避免这些自定义指标持续产生费用,您可以废弃这些自定义指标。
如果使用的是ARMS Prometheus,我们默认对这些指标进行了收敛,只有当 bucket 发生变化时才会进行采集,您可以在 ARMS 控制台通过查询指标istio_request_duration_milliseconds_bucket_delta
是否存在来确认。
如果您的指标并未收敛,您可以升级 ARMS 采集配置来获取最新的收敛采集配置,具体操作,请参见ASM监控指标与大盘升级。
您可以请通过ARMS控制台进行配置对指标进行废弃。具体操作,请参见配置废弃指标。
合并Istio与应用的监控指标
已有Prometheus监控端点的应用服务,通过启用合并Istio与应用的监控指标功能,可以借助网格代理输出原有业务指标。启用合并Istio与应用的监控指标功能后,ASM会将应用程序指标合并到Istio指标中,相对应的prometheus.io
注解会被加入到所有数据面Pod上,以启用Prometheus的指标抓取能力。如果这些注解已经存在,就会被覆盖。网格代理将应用指标和Istio指标进行合并,Prometheus可以从:15020/stats/prometheus
端点拉取合并后的指标。具体操作,请参见合并Istio与应用的监控指标。
网格拓扑配置
网格拓扑是一个服务网格可观测性工具,提供查看相关服务与配置的可视化界面。如下图所示,ASM支持内置网格拓扑。具体操作,请参见开启网格拓扑提高可观测性。
分布式追踪
分布式追踪是Service Mesh中实现可观测性的重要组成部分之一,是一种用于对应用程序进行概要分析和监视的方法,尤其是针对使用微服务架构构建的应用程序。在微服务架构中,服务之间的通信通过网络进行,因此需要采用分布式追踪技术来对服务之间的调用关系进行跟踪和监控。通过分布式追踪技术,您可以:
加速故障排查:链路追踪能够准确地显示请求在各个微服务之间的流转路径,便于开发和运维团队快速定位和解决故障。同时,链路追踪记录不仅包括时间延迟,还包括错误信息和上下文,使得问题诊断更加准确。
性能监测:通过分析每个服务的延迟和响应时间,链路追踪能够帮助识别系统中的性能瓶颈。通过对不同服务间的调用延迟进行比较,可以发现潜在的优化机会,以提高整体系统性能。
获得调用链路:能够展示服务调用链路,有助于理解复杂的服务间依赖关系。
在 Ambient 模式下,链路追踪数据的上报由 Waypoint 完成。因此,当一个服务未启用 Waypoint 流量代理时,即使其加入了服务网格,其链路追踪数据也不会上报,这会导致该服务链路追踪数据的缺失。
同时,对于 OpenTelemetry 以外的链路追踪 provider 来说,由于不同服务上报的客户端可能是相同的 Waypoint,因此链路追踪数据无法完整展示应用的拓扑,如果您需要查看应用的拓扑,推荐您使用 OpenTelemtry 进行采集,或开启网格拓扑进行查看。
启用链路追踪
您可以将链路追踪数据上报到自建的链路追踪系统,或是阿里云链路追踪中。具体操作,请参见配置上报ASM链路追踪数据。
链路追踪请求头透传
虽然 ASM 能够为代理的流量自动添加链路追踪相关的请求头,但应用程序仍然需要透传特定的请求头,来保证链路追踪采集点能够构建出完整的调用链路。所有应用都需要透传以下请求头:
x-request-id
traceparent
tracestate
如果您的采集点为 Zipkin,您还需要透传以下请求头:
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
相关文档
您可以通过ASM控制台为全局、命名空间或指定工作负载自定义相关配置,例如日志输出的格式、指标的维度、是否启用特定监控指标、设置链路追踪的采样率等。具体操作,请参见可观测配置。