摘取自 云原生网关的可观测性体系实践
可观测性一词来源于控制理论，指系统可以由其外部输出推断其其内部状态的程度，随着 IT 行业几十年的发展，IT 系统的监控、告警、问题排查等领域的逐渐成熟，IT 行业也将其抽象形成了一整套可观测性工程体系。目前可观测性已不仅仅是一种具体的工具或者技术，它更偏向是一种理念，已成为复杂分布式系统成功管理的关键组成部分，并对系统在运行时提供对其理解、探查以及调度的能力。
当前业界在可观测性能力建设方面通用的三大支柱：日志事件(Logging)，分布式链路追踪(Tracing)以及指标监控(Metrics)。
1) 指标(Metrics)，是一段时间内记录的各个维度的量化信息，用来观察系统的某些状态和趋势
2) 日志(Logs)，是对程序运行过程中产生的一些离散事件的记录
3) 链路追踪(Traces)，是对一次请求从接收到处理完毕整个生命周期内的调用链路的记录
可观测性难点
云原生网关是阿里云微服务引擎(MSE)下的一款托管类型网关产品，其将传统的流量网关与微服务网关进行了整合，本文将讲述如何基于云原生网关去搭建网关场景的可观测性体系。
网关作为业务流量的入口，其可观测性建设与整体业务的稳定性息息相关，同时由于网关的用户使用场景与功能较多，且网络环境也较为复杂，这对网关可观测性建设也带来了很多的难点。下面就针对其中的主要难点分别加以说明。
1) 关注网关可观测性的角色众多
可观测性的核心在于 通过观测数据、满足不同角色、对于系统状态的理解需求，网关作为流量入口，业务，研发，SRE 等角色都会关注网关的状态，需要在深入理解不同角色需求的前提下才能够完善网关的可观测性体系。
2) 埋点不够精确，统计消耗大
点位不够准。埋点不难，难的是如何判断哪些数据是符合使用场景的。这就需要设计者有丰富的从业经验，或者在上线的过程中，不断迭代打磨。
统计采集代价高。可观测性的实现，很多时候往往是时间、空间、颗粒度三者之间的权衡。统计的时间粒度太密会造成存储容量的膨胀，统计的时间粒度太粗则不利于定位问题。这都为可观测性的实现带来了难题。
3) 网络环境复杂, 问题排查难度大
在流量网关场景下，由于公网网络环境复杂，网关流量巨大，偶发问题排查难度巨大。
可观测性实践
基于业界可观测性实践的三大支柱，建设了云原生网关基础的可观测性能力。
1) 确定网关核心指标，构建可观测性基础
核心指标即能准确描述系统内部运行状况的指标，在云原生网关场景，核心指标即为 qps，rt，成功率等能够准确描述网关此时运行状况的指标。云原生网关同时集成了 prometheus 与 sls，用户既可以通过网关的访问日志的 etl 处理获取更加精细准确的数据，也可以通过 prometheus 获取网关的实时监控。
针对统计采集消耗大的问题，云原生网关将部分采集消耗大的指标使用 etl 处理访问日志来减少采集消耗，将更需要实时性的统计指标采用程序内埋点的方式来保证实时性。
针对不同角色对网关可观测性的不同需求，云原生网关提供了不同维度的数据表现，对于需要进一步精细分析的企业用户，也可以通过 sls 进一步进行数据加工。
2. 划分系统边界，快速定位问题
网关通常请求量庞大，同时在微服务场景下，调用链路错综复杂，在这样的条件下想确认某一条请求的失败原因是一件困难的事情，针对这一场景，云原生网关对接了开箱即用的 ARMS 分布式链路追踪服务，同时也支持将 trace 数据投递到用户自建的 skywalking，避免云产品锁定。
对于未接入链路追踪的用户，云原生网关提供日志明细的详细解释，将请求失败的原因可视化为具体的图表，帮助用户确认问题边界，减少问题排查时的时间。
3. 风险管理定时巡查风险
云原生网关综合用户实例，规格，性能等数据，会给出目前实例存在的风险，并给出改善建议，极大程度上提高了允原生网关实例维护的自动化程度，降低客户使用成本。
