接上篇：
https://developer.aliyun.com/article/1222967?spm=a2c6h.13148508.setting.17.4f394f0em1x0Jq
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大盘。它符合关联分析逻辑，无论是全局还是特定实体都有总览，能够发现问题细节，能够排查问题；它包含日志、事件、指标等多数据源，以告警异常阈值为驱动，整个大盘可以交互、点击跳转，可以定位根因，涵盖了K8s集群最核心的资源类型。
我们也推出了统一的拓扑大图，它具备拓扑感知、依赖分析、流量监控、上下文关联等特性，可以按维度筛选节点和边，构建业务语义化的视图。
