可观测性
可观测性（Observability）是指零碎、应用程序或服务的运行状态、性能和行为可能被无效地监测、了解和调试的能力。
随着零碎架构从单体架构到集群架构再到微服务架构的演进，业务越来越宏大，也越来越简单。云原生时代背景下，随着微服务、Service Mesh、Serverless 等新技术的呈现，业务的复杂度很快就超过了集体的极限，可观测性在古代分布式系统的设计和运维中变得越来越重要。传统的监控和告警办法往往只关注零碎的一些根本指标，而疏忽了更细粒度的信息和上下文。可观测性的指标是通过全面的数据收集和剖析，提供更深刻和全面的洞察力，使运维和开发人员可能更好地了解零碎的行为、排查问题、预测性能瓶颈和应答故障。
日志、指标和分布式追踪被称为可观测性的三大支柱：
- 日志（Logging）：日志是记录零碎运行过程中产生的事件和信息的记录。通过记录应用程序的日志，能够理解零碎的运行状态、谬误和异样信息，不便故障排查和系统分析。常见的日志零碎包含 ELK（Elasticsearch、Logstash、Kibana）和 Splunk 等。
- 指标（Metrics）：指标是用于掂量零碎各个方面性能的度量规范。通过采集和记录指标数据，能够实时监控零碎的运行状况，包含 CPU 使用率、内存占用、申请响应工夫等。罕用的指标零碎有 Prometheus 和 InfluxDB 等。
- 分布式追踪（Distributed Tracing）：分布式追踪是用于跟踪和监控分布式系统中申请的门路和性能的技术。通过将申请在零碎中的不同组件之间传递一个惟一标识符，能够追踪申请的流程和耗时，帮忙剖析和优化零碎性能。常见的分布式追踪零碎有 Zipkin 和 Apache Skywalking 等。
通过提供全面且准确的可观测性，零碎的开发和运维人员能够更疾速地发现问题、了解零碎行为，并做出相应的优化和决策，从而进步零碎的性能、稳定性和可靠性。
云原生网关可观测体系
MSE 云原生网关依靠阿里云现有的云产品（日志服务 SLS、利用实时监控服务 ARMS）以及对开源软件的良好反对构建了丰盛的可观测体系，为用户提供了弱小的日志、监控、链路追踪以及告警性能，性能大图如下所示：
网关的可观测性能力致力于帮忙客户构建产品的可靠性体验，为客户提供故障发现与故障定位的能力，缩小故障的产生以及升高故障的影响面。基于网关的监控与告警治理性能，实现故障的及时发现与告诉到客户；基于监控与日志，实现故障的疾速定位；基于链路追踪，实现申请调用的全链路故障根因排查。
云原生网关可观测实际
过程概览
本文将根据下图中标注的功能模块登程，帮忙读者体验网关可观测性在故障发现与故障定位中的能力。
整体流程如下图所示：
- 用户收到网关收回的告警
- 用户查看 prometheus 监控找到出问题的路由、服务
- 用户查看 SLS 日志获取更具体的报错信息
- 用户通过链路追踪排故障的根因
测试环境架构概览
本文在 ACK 集群中部署了一系列 Springboot 的服务，调用关系如上图所示，其中 Spring SVC 4-2 产生了 crash。通过网关接入 ACK 集群，创立路由如下：
测试过程中会通过以下三种申请去拜访网关：
- 失常的申请，网关路由到 httpbin
- 在网关处就返回谬误的申请，本文应用无奈命中路由的申请
- 在上游服务返回谬误的申请，网关路由到 Spring SVC 1
此时网关的错误率会呈现显著回升。
故障发现与定位过程
通过告警策略及时发现故障
首先配置网关的告警策略，从网关实例粒度设置告警规定与告诉策略，本文中采纳了邮件告诉的形式，除此之外还有电话、短信等形式。配置告警策略的示例如下图所示：
通过以下邮件信息能够得悉网关呈现了故障：
通过 Arms Prometheus 监控初步定位问题
接下来，查看网关观测剖析 -> 业务监控 -> 全局看板的错误信息概览板块，以后监控信息如下：
依据图中内容，能够失去以下信息：
- “网关粒度失败率”看板中，网关整体失败率是大于上游服务失败率的，这意味着一部分申请在网关处返回了错误码，一部分申请在上游服务处返回了错误码
- “路由粒度失败率”看板中，可能看到只有路由名称为“spring”的路由失败率不是 0
- “上游服务粒度失败率”看板中，可能看到只有服务名称为“springboot-svc-1.app-system.svc.cluster.local”的服务失败率不是 0
点击图中“路由失败申请数排行”或者“上游服务失败申请数排行”中的路由名或者服务名能够查看路由或者服务的详细信息。
路由名为“spring”的路由监控信息如下图所示：
服务名为“springboot-svc-1.app-system.svc.cluster.local”的服务监控信息如下图所示：
上图中显示呈现谬误的路由和服务返回的错误码为 5xx，至此，曾经初步定位到问题所在：路由“spring”指向的上游服务“springboot-svc-1.app-system.svc.cluster.local”呈现了问题。
然而，目前还有两个问题须要解决：
- 在网关处返回谬误的申请是什么起因？
- 服务“springboot-svc-1.app-system.svc.cluster.local”的谬误是什么起因造成的？
通过 SLS 网关日志获取详细信息
接下来通过网关日志核心的 SLS 日志获取更具体的信息。
首先点击 response_code，此时会主动生成查问申请，能够看到这段时间内网关的响应码只有三种：200，404，500。在网关问题排查页面，输出响应码，能够查看错误码可能的起因：
能够看到返回 404 响应码的起因是没有命中路由导致。相似的，当选择响应码为 500 时，能够看到相应的路由名以及服务名，如下图所示：
通过问题排查工具能够看到，谬误是后端服务造成的：
到当初为止，只剩下一个问题：服务“springboot-svc-1.app-system.svc.cluster.local”的谬误根因是什么？
通过 Arms xtrace 链路追踪剖析调用链
借助于链路追踪技术，能够获取更细粒度的错误信息。只须要简略的配置，网关即可接入 Arms xtrace：
ACK 集群上的 Java 利用依照以下文档进行配置：为容器服务 Kubernetes 版 Java 利用装置探针 [1]。
在 SLS 日志中找到一条谬误申请的 traceid，依据 traceid 在链路追踪页面搜寻相应的调用链路剖析调用链路谬误的根因：
从链路追踪后果看，故障根因是 springboot-svc-4-2 服务谬误，至此，一次残缺的故障发现与故障定位曾经实现。
总结
本次通过云原生网关可观测性进行故障发现和故障定位的实际过程中，首先通过网关的告警策略将故障告诉到用户，而后通过 arms 提供的 prometheus 监控服务初步定位到呈现故障的路由以及服务，之后通过 SLS 日志服务提供的网关的结构化日志进行查问剖析，排查出局部谬误是客户端申请门路谬误导致，最初通过链路追踪对服务调用链路进行剖析，最终胜利对故障根因进行定位。
相干链接：
[1] 为容器服务 Kubernetes 版 Java 利用装置探针
https://help.aliyun.com/zh/arms/application-monitoring/gettin…
作者：钰诚
点击立刻收费试用云产品 开启云上实际之旅！
原文链接
本文为阿里云原创内容，未经容许不得转载。