共计 3220 个字符，预计需要花费 9 分钟才能阅读完成。
可观测性是从零碎内部去察看零碎外部程序的的运行时状态和资源应用状况。掂量可观测性的次要伎俩包含：Metrics、Logging 和 Tracing，下图是 Metrics、Logging 和 Tracing 之间的关系。
举个例子，Tracing 和 Logging 重合的局部代表的是 Tracing 在 request 级别产生的日志，并通过 Tracing ID 将 Tracing 和 Logging 关联起来。对这份日志进行肯定的聚合运算之后，可能失去一些 Metrics。Tracing 本身也会产生一些 Metrics，例如调用量之间的关系。
Apache APISIX 的可观测性能力
Apache APISIX 领有欠缺的可观测性能力：反对 Tracing 和 Metrics、领有丰盛的 Logging 插件生态、反对查问节点状态。
Tracing
Apache APISIX 反对多种 Tracing 插件，包含：Zipkin、OpenTracing 和 SkyWalking。须要留神是：Tracing 插件默认处于敞开状态，应用前须要手动开启 Tracing 插件；Tracing 插件须要与路由或全局规定绑定，如果没有采样率的要求，倡议与全局规定绑定，这样能够防止脱漏。
Metrics
在 Apache APISIX 中，Metrics 的相干信息通过 Prometheus Exporter 上报，兼容 Prometheus 的数据格式。在 Apache APISIX 中应用 Prometheus Plugin 有两件事件须要留神。
第一，请尽量进步路由、服务和上游这三者名称的可读性。
Prometheus Plugin 中有一个名为 prefer_name 的参数，将这个参数的值设置为 true 时，即：prefer_name: true，如果路由、服务和上游这三者的名称可读性比拟强，这会带来一些益处：后续通过 Grafana 监控大屏展现参数的时候，不仅可能分明地展现出所有的数据，还可能清晰地通晓这些数据的起源。如果 prefer_name 参数的值为 false，则只会展现资源的 ID 作为数据起源，例如 路由 ID、上游 ID，进而造成监控大屏的可读性较低的问题。
第二，Prometheus Plugin 必须与路由或者全局规定绑定，而后才能够查看到指定资源的 Metrics。
实现上述设置当前，Metrics 的数据会存储在 Prometheus 外面。因为 Prometheus 的存储性能很好，但展现性能欠佳，所以咱们须要借助 Grafana Dashboard 展现数据。咱们能够看到 Nginx 实例的 Metrics、网络带宽的 Metrics、路由和上游的 Metrics 等，详情如下图所示：
Logging
Apache APISIX 反对多种日志插件，能够与其余内部的平台间接分享日志数据。Error Log 插件反对 HTTP 与 TCP 协定，并且兼容 SkyWalking 的日志格局。也能够通过 FluentBit 等日志收集组件，将日志同步到日志平台进行解决。
Access Log 插件目前还不反对在日志格局外面进行嵌套。因为 Access Log 插件是路由级别的，所以须要跟路由进行绑定，才能够收集到路由的拜访日志。然而日志的格局是全局的，而全局只能有一份日志格局。
反对查问节点状态
Apache APISIX 的反对查问节点状态，启用之后，能够通过 /apisix/status 收集到节点的信息，包含节点数、期待链接数、解决连接数等。
美中不足
上文讲到，Apache APISIX 的可观测性能力十分欠缺，可能收集 Metrics、Logging 和 Tracing 等信息。尽管借助 Apache APISIX 的内置插件配合 Grafana Dashboard，可能解决监控数据收集和指标可视化问题，然而各种数据扩散在各个平台。冀望有一个可观测性剖析平台能集成 Metrics、Logging、Tracing 信息，可能将所有数据联动起来。
应用 Apache SkyWalking 加强 Apache APISIX 的观测能力
Apache SkyWalking 是一个针对分布式系统的利用性能监控（APM）和可观测性剖析平台。它提供了多维度利用性能剖析伎俩，从分布式拓扑图到利用性能指标、Trace、日志的关联剖析与告警。
一站式数据处理
Apache SkyWalking 反对对接 Metrics、Logging、Tracing 等多种监控数据，兼容 Prometheus 数据模型，还能够通过 Log Analysis Language 进行二次聚合，产生新的 Metrics。
更具体的数据展现
Apache SkyWalking 的 Dashboard 分为高低两个区域。上部是性能抉择区域，下部是面板内容。Dashboard 提供全局、服务、示例、Endpoint 等多个实体维度的 Metrics 相干信息，反对以不同的视图展现可观测性。以全局视图为例，展现的 Metrics 包含：服务负载、慢服务数量、不衰弱的服务数量等，如下图所示。
另外值得一说的是 SkyWalking Dashboard 的 Trace 视图。SkyWalking 提供了 3 种展示模式：列表、树状图和表格。Trace 视图是分布式追踪的典型视图，这些视图容许用户从不同角度查看追踪数据，特地是 Span 间的耗时关系。
SkyWalking Dashboard 也反对拓扑图。拓扑图是依据探针上行数据分析出的整体拓扑构造。拓扑图反对点击展示和下钻单个服务的性能统计、Tracing、告警，也能够点击拓扑图中的关系线，展现服务之间、服务示例间的性能 Metrics。
反对容器化部署
Kubernetes 是一个开源的云原生容器化集群治理平台，指标是让部署容器化的利用简略且高效。Apache SkyWalking 后盾能够部署在 Kubernetes 之中，而且得益于 Kubernetes 的高效率治理，能够保障 UI 组件的高可用性。
如果在集群上部署了 Apache APISIX，Apache SkyWalking 反对以 sidecar 或服务发现的模式部署 SkyWalking Satellite，监控集群中的 Apache APISIX。
将来打算
Apache APISIX 在将来仍会继续加强可观测性相干的性能反对，例如：
- 解决 SkyWalking Nginx-Lua 插件的 peer 缺失问题
- 反对在日志中打印 trace id
- 接入拜访日志
- 反对网关元数据
结语
本文介绍了 Apache APISIX 的可观测性能力以及如何通过 Apache SkyWalking 晋升 Apache APISIX 的可观测性能力。将来两个社区还会持续深度单干，进一步加强 Apache APISIX 的可观测性能力。心愿大家可能多多地参加到 Apache APISIX 和 Apache SkyWalking 我的项目中来。如果你对这两个开源我的项目很感兴趣，却不相熟代码，写文章、做视频、对外分享、积极参与社区和邮件列表探讨都是很不错形式。
流动预报
Apache APISIX 大咖面对面第一期举办后，小伙伴们在评论区直呼播种满满、不过瘾、期待下期！
11 月 30 日 19:30 第二期大咖面对面如约而至，本期嘉宾邀请到了融云联结创始人兼 CTO – 杨攀、Kyligence 联结创始人兼首席架构师 – 史少锋、KubeSphere 创始人 – 周小四、Apache APISIX Committer – 王晔倞，众咖齐聚一起畅谈面对职场变动和转型分岔路，技术人投身 To B 畛域的问题与挑战。
- 中国的 To B 企业为什么倒退很难？
- 技术人投身 To B 畛域胜利的起因有哪些、转型失败的起因又有哪些？
- “年纪轻了做技术，年纪大了转治理”这是不是惟一的路径？职业倒退还有哪些路径？
- 开源根底软件 To B 商业化和传统根底软件 To B 商业化，经营形式有哪些不同？
11 月 30 日 19:30 锁定「Apache APISIX 视频号 」，来和嘉宾互动发问，直播间还有精美礼品等你哦。
入群交换
扫描下方二维码，或在公众号后盾回复【直播交换群】，退出 Apache APISIX 线上直播交换群，理解更多社区动静！
