共计 4383 个字符，预计需要花费 11 分钟才能阅读完成。
作者：刘洋（炎寻）
可观测是为了解决问题，所以在聊可观测之前，应先对问题排查的普适准则进行理解。
背景介绍
问题排查的准则
以排查零碎问题为例，要了解零碎，要先关注基础知识，了解编程语言根本的计算机科学常识，关注零碎大图比方架构部署和重大流程，要关注运行细节，要对外围性能的算法和数据结构了然于心，还要关注零碎的运维工具，可能理解公布、回滚和监控。
在了解的根底上，还要可能复现问题，次要关注问题产生的触发条件以及问题产生时数据现场的保留，蕴含指标、链路、日志、事件等。
有了现场再加之对于零碎的，才能够定位问题。通过现场保留的数据，进行关联剖析；基于了解，能够疾速用二分定位到根因。在定位的过程中，尤其要关注变更，因为有大量的零碎问题是由变更导致的。
确定根因后再进行修复，既要治本也要治标，并且要充沛验证，确保不引入新的问题。
以上为问题排查的普适准则，它不仅实用于零碎问题的排查，也能够利用到生存的方方面面。
而可观测使得问题排查的过程更加高效、稳固、低成本。它可能帮忙咱们了解零碎，呈现问题的时候可能留下足够多的现场，可能使数据之间很不便地进行关联，帮忙咱们做二分的关联剖析，最终还能够验证修复是否正确。
Kubernetes 可观测挑战
复杂度是恒定的，它不会隐没，只会转移。咱们构建的编程语言、编程框架、容器操作系统都只是将复杂度关在适合的中央。如果所有运行失常，大快人心；而一旦呈现问题，就是劫难。复杂度一直下沉的趋势使得可观测面临了很大的压力。Kubernetes 的风行使得微服务架构非常遍及，多语言、多通信协议成为常态，这也在另一方面带来了挑战。
挑战 1：端到端观测复杂度回升，埋点老本居高不下。然而这只是冰山一角，有大量能力下沉到 Kubernetes 管控层、容器运行层、网络和操作系统层面，这些基础设施能力的下沉带来了很大挑战。
挑战 2：因为关注点的拆散，使得利用问题与底层问题无奈自顶向下造成关联。
挑战 3：尽管有很多工具，然而上下文缺失、数据散落，导致无奈通过这些数据很好地了解利用，因为现场的缺失无奈关联，而使问题排查效率低下。
可观测须要有对立的技术来解决本身的复杂度。
基于 eBPF 的可观测实际分享
eBPF 介绍
从一开始，内核就是可观测的绝佳地位，然而因为效率和平安问题始终无奈实现。通过多年倒退，eBPF 技术为可观测关上了新的大门。
eBPF 是一项能够平安地在内核中运行沙盒程序的技术，无需批改代码即可在内核用户态程序事件产生时运行。它具备以下个性：
无侵入个性 ：观测老本极低，利用无需批改任何代码，也无需重启过程。
动静可编程性 ：无需重启探针，动静下发 eBPF 脚本即可批改探针侧的逻辑。
高性能 ：自带 JIT 编译，使探针可能取得内核本地运行的效率。
平安 ：verifier 机制限度了 eBPF 脚本可能拜访的内核函数，保障内核运行的稳固。
除了这些令人振奋的个性外，eBPF 的应用流程也十分不便。以监控、利用、性能为例，只须要加载编译 eBPF 程序监听网络的内核事件，解析网络协议，而后聚合成指标，输入 Trace 即可。
eBPF 失去了很多大公司的反对，倒退非常迅猛。过来一年，阿里云可观测团队基于 eBPF 技术构建了对立可观测平台。其架构如下图：
基于 eBPF 的对立可观测平台架构
最底层是数据采集层，次要采纳 Tracepoints、Kprobre、eBPF 函数抓取相干零碎调用，关联过程容器信息，造成原始事件，并通过 eBPF 和 sysdig 的联合反对多内核版本。同时为了解决事件爆炸的问题，引入了事件过滤和高性能事件传输机制。
往上是数据处理层。用户态获取到原始事件后，首先进行协定的解析，生成指标、链路、日志等数据，过程中也会对信息做收敛。而后填充元信息，比方 K8s 信息填充或自定义利用信息填充，最初监控数据会通过 OpenTelemetry Collector 输入。引入 OpenTelemetry Collector 次要为了反对多种数据类型以及多数据传输通道，反对将监控数据写入用户指定的存储。
再往上是数据存储层，默认状况下，指标会应用 influxDB 存储在 Prometheus，链路和日志应用 SLS 存储在 Trace。
最上是数据服务层，通过 ARMS 的前端以及 Grafana 最终出现给用户多种多样的可观测服务。
如何进行无侵入式多语言的协定解析
ARMS 可观测团队关注 eBPF 在应用层的利用，通过监听网络内核调用，构建连贯跟踪，将传输的网络包进行协定剖析，失去利用层面的申请响应，最终得以无侵入式地反对多语言场景下申请数、响应工夫、谬误数、黄金指标的监控。
目前咱们反对 HTTP、Redis、DNS、Kafka、MySQL、gRPC、http2 等协定，反对的协定列表也在一直裁减中。
线上问题与解决办法
通过一年多的生产实践，遇到最多的问题次要有以下四个：
第一， 内核版本适配问题 。eBPF 在内核版本 4.14 以上才有较为成熟的反对。然而线上仍然存在很多老的内核版本，这部分须要应用 sysdig 进行反对。高版本在 core 不成熟的状况下，应用动静下载内核图文件以及动静编译的形式进行反对。
第二， 内核事件爆炸 。传统的监听 Tracepoints、Kprobre 会产生微小的事件，给探针的性能造成微小压力。为了解决这个问题，咱们引入了事件过滤机制，只解决网络调用事件，同时优化事件传输序列化，达到高性能事件传输的目标。
第三，在事件的生产侧， 协定解析效率低下 。为此咱们优化了高性能解析算法，比方能够缩小剖析的字节数，优化更多的匹配算法晋升解析的效率。同时还应用了多线程内存复用等工程伎俩晋升协定解析效率。
第四， 指标工夫线爆炸 。所有事件最终都会聚合为指标、链路和日志，其中指标方面因为个别维度发散，会对存储的稳定性造成极大的影响。因而，咱们反对在写指标的时候进行维度收敛，比方每个维度的基数不得超过 100，超过后将收敛成星号，代表通用的收敛标记。此外，还在查问侧进行了优化，次要做了精度的降级。
对立可观测交互界面
对立告警
eBPF 技术的无侵入性以及多语言反对的个性使得开箱即用成为了可能。基于此，阿里云可观测团队开始构建对立可观测界面。
首先是对立告警。接入阿里云 eBPF 监控，咱们设计了一套默认的告警模板，涵盖了应用层、K8s 管控层、基础设施层和云服务层，提供了开箱即用的帮忙用户发现问题的能力。
对立的关联剖析逻辑
有了 eBPF 保留现场数据，加上告警零碎告知存在问题，后续应如何对立进行关联剖析，找到根因？
咱们认为须要有一个界面来承载关联剖析逻辑。它该当指标明确，比方要解决容量布局问题、老本耗费问题还是利用性能问题；它该当内容丰盛，蕴含解决问题须要的所有内容，比方指标、链路、日志、事件、问题的影响面、关联关系等；它该当具备十分清晰的应用门路，可能答复以后是否有问题，将来是否有问题、问题的影响是什么、问题的根因是什么、用户能做什么等，以此一步步疏导用户解决问题。
对立 Grafana 大盘
基于以上构想，咱们推出了对立的 Grafana 大盘。它合乎关联剖析逻辑，无论是全局还是特定实体都有总览，可能发现问题细节，可能排查问题；它蕴含日志、事件、指标等多数据源，以告警异样阈值为驱动，整个大盘能够交互、点击跳转，能够定位根因，涵盖了 K8s 集群最外围的资源类型。
对立拓扑图
咱们也推出了对立的拓扑大图，它具备拓扑感知、依赖剖析、流量监控、上下文关联等个性，能够按维度筛选节点和边，构建业务语义化的视图。
Demo 演示：基于 eBPF 的对立交互页面
在容器服务 ACK 进入一个集群后，点击运维治理，进入集群拓扑性能页面。如果没有装置 eBPF 探针则会提醒装置，装置实现后开箱即用，能够取得整个集群的流量拓扑。
页面蕴含了 deployment、deamonset、和 statfulset 之间的流量关系。点击节点能够看到它对外提供的利用性能，也能够查看节点的上下游。通过上下游的查看，能够疾速查看它是否依照预约的架构运行。
此外，也能够点击边进行查看，比方能够看到 MySQL 的 QPS 以及响应工夫等。
除了查看指标，还能够查看详情，比方查看 SQL 语句以及网络耗时，比方申请发到对端用了多久、对端解决用了多久、响应的内容下载耗时多久等，能够疾速定位问题所在。同时还提供了节点过滤的能力，能够疾速过滤出用户感兴趣的节点，同时也能够搜寻对应的节点。
Grafana 对立的大盘为 1+N 的模式。1 是指集群的全局大盘提供了整个集群最外围的资源总览，蕴含事件，能够疾速查看各类事件的个数及详情，能够查看节点是否衰弱、无状态利用 deployment 是否衰弱以及有状态利用、deamonset 等。
每一个特定资源总览的构造也是统一的，蕴含“总”和“分”。“总”是对整个集群进行概括的总结，能够疾速通过阈值确认是否有问题，有问题的阈值会用娇艳的色彩标出。比方上图能够看出有 1 个节点的 CPU 申请率过高，而具体哪一个节点的申请率过高，则由“分”负责查找，通过申请率排序，疾速找到问题节点。
上图显示集群级别有两个 Pod 不是 ready 状态。通过对 phase 进行排序疾速获取两个处于 pending 状态的 Pod。也能够看到有 15 个 Pod 在过来 24 小时存在重启行为，进行排序后即可疾速找到这些 Pod。
能够点击具体节点，查看其 CPU 申请率的 top 10，点击查看详情后可在系统资源里进行查看，以判断申请量是否正当，并进行修改。
由此可见，Grafana 大盘具备很强的交互能力和逻辑。
前端利用的每一个 deployment 或资源详情页也具备排查逻辑。概览中展现了管控层、CPU、网络、内存等状况，一眼便能通晓零碎是否存在问题，能够疾速查看问题所在。
与此同时，大盘还集成了日志以及 7 层的应用性。
以上能力全副是基于 eBPF 的无侵入性提供的开箱即用的能力。
总结与瞻望
总结
阿里云可观测团队构建了 kubernetes 对立监控，无侵入式地提供多语言、利用性能黄金指标，反对多种协定，联合 Kubernetes 管控层与网络系统层监控，提供全栈一体式的可观测体验。通过流量拓扑、链路、资源的关系，可进行关联剖析，进一步晋升在 Kubernetes 环境下排查问题的效率。
瞻望
将来，阿里云可观测团队将进一步开掘 eBPF 全笼罩、无侵入、可编程的个性，在以下三个方面继续发力：
第一，可扩大 APM，简称 eAPM。围绕 APM 一直扩大边界，解决其侵入每种语言都须要独自埋点的问题，解决在利用层面看不到的底层黑盒问题，包含以下几个方面：
- 无侵入式的多语言性能监控。
- 无侵入式的分布式链路追踪。
- 利用申请粒度的零碎与网络分析。
第二，提供工具，针对包含 tracing、profiling、动静网络包跟踪以及内核事件在用户态进行解决的开发框架进行优化。
第三，实现 eBPF 加强的内置指标、链路和日志，次要包含对利用协定更多的反对以及高阶的零碎指标和网络指标。