以后可观测性工具在云原生环境缺失了什么？
大家在应用可观测性产品当中，海量的数据肯定会给排障带来阻碍。略微有点排障教训的技术人员都心愿排障过程中可能追寻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类型的Metric数据是Linux /proc下数据，Promethues和Zabbix等支流监控数据就来自于/proc 下的统计数据，APM探针也会有局部统计数据如TPS、均匀时延、错误率等。
- 2类型的数据以后是APM产品次要采集的数据，该类型数据大量通过APM trace进行展现，并不是以惯例指标模式展现，少部分数据以惯例指标模式展现。
- 3类型的数据，以后该类型数据采集工具缺失，如BCC等工具是作为小工具长期应用，业界并未有监控工具将该局部数据作为可观测性数据7X24小时运行保留展现。
- 4类型的数据，以后次要还是专家型技术人员通过BCC、Bftrace、Ftrace等工具去获取内核函数执行状况。
Kindling基于eBPF技术构建的上帝视角带来了解决方案——关联内核可观测数据的trace
针对痛点一：以后解决方案 VS Kindling解决方案
以后业界的次要解决思路：
有些公司推出了OneAgent概念，实质上利用脚本做自动化检测，自动化装置脚本，从而保障节点可能做到探针全笼罩。然而此种形式依然须要人工干预决定业务何时能力重启，探针采集数据能力失效。
Kindling的解决思路：
Kindling利用eBPF技术或者内核模块技术构建的探针，以DeamonSet工作在Node所在的Linux操作系统上，即可笼罩所有环境，不会呈现没有探针笼罩的状况。另外十分重要的一点是利用无需重启，探针即可采集内核层的数据，对业务无烦扰。为了可能反对以后国内支流的CentOS7系列（eBPF运行在该类型操作系统默认内核上有技术局限性），Kindling通过构建内核模块的技术获取了同样数据，保障用户在高版本内核上与低版本内核取得同样的体验。
针对痛点二：以后解决方案 VS Kindling解决方案
以后业界的次要解决思路：
针对不同语言推出不同的APM agent，然而有些语言如Go和C语言很难做到自动化插裝，只能提供SDK包以便人工插裝。另外每个语言个性不统一，导致不同语言探针采集的数据集很难统一，对后端的整合剖析带来更大的压力，用户体验也不统一。会呈现某种语言有某些指标，而另外语言可能就缺失了这部分的指标。
Kindling的解决思路：
eBPF代码或者内核模块代码工作在内核层与语言无关，所以程序无需做任何插裝或改变，也不必重启即可被观测，所有程序采集指标完全一致，用户了解不会有偏差。
针对痛点三：以后解决方案 VS Kindling解决方案
以后业界的次要解决思路：
以后比拟常见的做法是将prometheus的数据和APM trace进行关联，这种计划能解决应用层导致的问题，然而针对云原生环境很多问题如DNS的性能导致业务抖动，共享存储导致业务申请性能产生抖动，代码忽然执行慢了等问题排障帮忙无限。
针对3与4类型的metric数据，以后支流做法是利用BCC、BFTRACE、Ftrace、Systamp等与内核交互的工具采集数据并输入至console中展现，以后并未有能提供7x24小时运行的可观测计划。次要起因是3与4类型中很多品种数据的数据量是十分大的，而7x24小时运行过程中，绝大多数状况是数据是失常的，保留这些大量失常的数据是节约存储资源。
Kindling的解决思路：
Kindling构建全局拓扑图和排障trace来排查问题，排障trace有别与APM trace，eBPF排障trace只是APM trace中的一个如A->B调用环节。Kindling重点做的事件就是将3与4类型的数据关联至排障trace当中，通过判断排障trace是否异样，决定该trace的存储，从而实现存储敌对的7x24小时运行云原生可观测性工具。
● Kindling应用和BCC、Bftrace同样的原理从而失去利用运行环境中3类型与4类型数据，为了可能反对以后国内支流的CentOS7系列（eBPF运行在该类型操作系统默认内核上有技术局限性），Kindling通过构建内核模块的技术获取了同样数据，保障用户在高版本内核上与低版本内核取得同样的体验。
● Kindling 通过剖析在同一个socket fd上的read零碎调用和wrtie零碎调用即可失去利用在解决该socket上申请耗时，并将该次申请与返回封装成排障trace。通过耗时、返回码等业务层语义可能确定每次eBPF排障trace是否异样。在一个socket fd上的read零碎调用总工夫，能够失去一个申请上的网络request工夫，剖析一个socket fd上的write零碎调用总工夫，能够失去一个申请上的网络response工夫。将一个socket fd上的最初一个read和第一个write时间差即是程序处理的总工夫。将同一个socket fd上三者工夫关联在一起看，即可看到申请的耗时的残缺散布，失去相似chrome外面下图
● Kindling 获取到的3类型数据与4类型数据通过各种关联伎俩关联至排障trace，在确定排障trace异样之时能存储该排障trace，同时也存储了3类型数据与4类型数据。该种形式确保了Kindling是能够运行在云原生环境的7X24小时存储敌对的可观测性工具。
Kindling将来的倒退思路与Roadmap
kindling将来心愿在有全局拓扑图和排障trace的概念之上，不断丰富第3与第4类型的数据，可能帮忙用户排障云原生上所有故障。
在丰盛指标方面，次要遵循以下两个思路：
● 心愿社区用户可能奉献更多的故障场景至太空舱我的项目https://github.com/Kindling-p...，该我的项目致力于收集云原生上不同品种的故障，并通过混沌工程进行在一个demo中模仿各种品种故障。在探针端，针对每种故障，剖析内核源代码，明确内核层面要害指标，给出排障方向。依据以后的场景，曾经在Kindling 演进思维导图中“探针指标能力加强”中列出来了一些的指标。
● 将会一直借鉴其它排障工具的原理、提炼eBPF技术可能获取到的3类型与4类型数据，并找到应用3类型与4类型数据的故障场景，也欢送社区用户一起奉献工具、场景和思路。
以下的思维导图是Kindling近一年想做的事件。其中云原生故障场景和业务场景，欢送各位用户继续一直奉献。
次要工夫节点如下：
这里在多花点工夫介绍下咱们认为对用户十分有帮忙的OnCPU和OffCPU指标性能：
程序OnCPU火焰图是解决线上CPU耗费较高时的排障利器，OffCPU火焰图是解决程序期待资源较长的排障利器。OnCPU的火焰图曾经有很多开源我的项目正在演进了，Kindling无心反复造轮子或者集成某一个OnCPU火焰图工具。Kindling正在做的是借鉴了OnCPU和OffCPU火焰图的思路，利用eBPF技术剖析排障trace异样时间段内，不同线程的体现，最终可能帮忙用户剖析异样产生时间段，哪些线程可能是问题首恶、再进一步剖析哪些函数或者资源导致了异样，并且要可能实现7X24小时常并存储敌对。
在云可观测性方面有任何疑难欢送与咱们分割：
微信
公众号