以后可观测性工具在云原生环境缺失了什么？
大家在应用可观测性产品当中，海量的数据肯定会给排障带来阻碍。略微有点排障教训的技术人员都心愿排障过程中可能追寻 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 中展现，以后并未有能提供 7 ×24 小时运行的可观测计划。次要起因是 3 与 4 类型中很多品种数据的数据量是十分大的，而 7 ×24 小时运行过程中，绝大多数状况是数据是失常的，保留这些大量失常的数据是节约存储资源。
Kindling 的解决思路：
Kindling 构建全局拓扑图和排障 trace 来排查问题，排障 trace 有别与 APM trace，eBPF 排障 trace 只是 APM trace 中的一个如 A ->B 调用环节。Kindling 重点做的事件就是将 3 与 4 类型的数据关联至排障 trace 当中，通过判断排障 trace 是否异样，决定该 trace 的存储，从而实现存储敌对的 7 ×24 小时运行云原生可观测性工具。
● 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 小时常并存储敌对。
在云可观测性方面有任何疑难欢送与咱们分割：
微信
公众号