Kindling项目目标利用eBPF技术带来的可观测性的上帝视角 ——关联内核可观测数据的trace_kindling trace

当前可观测性工具在云原生环境缺失了什么？

大家在使用可观测性产品当中，海量的数据一定会给排障带来障碍。稍微有点排障经验的技术人员都希望排障过程中能够追寻trace，并能沿着这个trace将各种可观测性的数据关联到这个trace上，这样最终就可以将问题根因找到。在eBPF技术出现之前，大家最常用的trace就是dapper论文中提到分布式追踪技术，但是在实际落地过程中会经常碰到以下痛点：

第一个痛点：探针自动化覆盖依赖人工：

APM探针安装需要人工安装，应用重启才能生效，所以很难做到自动化覆盖所有业务。导致云原生环境里某些节点并未安装APM探针或者人工插桩，所以无法顺着trace深入排查遇到阻碍。

第二个痛点：探针难以覆盖多语言的微服务业务：

微服务的设计哲学中强调，每个小团队可以使用擅长的语言并针对需求做出自认最佳的开发，这就意味着开发语言是多样的。trace也会由于多语言的难以统一追踪而断掉。

第三个痛点：APM trace缺少内核可观测数据：

DNS的性能导致业务抖动、Kmem 相关bug导致业务pod oom重启、业务pod出现请求另外一个pod请求不通、业务迭代产生网络消耗大引起业务性能下降问题、共享存储导致业务请求性能发生抖动、 kube-dns 配置出现异常导致业务异常等等问题都很难通过单一的APM trace数据进行排障。

另外一个常见的问题就是某段代码突然慢了，这段代码之前都是运行好的，单凭APM trace中采集的数据难以回答为什么突然慢了。这个时候多半需要人为介入，再从应用日志、系统日志找到内核可观测性数据去排查问题，比如找到当时srtt数据是否正常，某次文件读写时间和传输数据量、操作系统进程调度是否正常。

Metric数据全景图定义：

1. 1类型的Metric数据是