eBPF技术正以令人难以置信的速度发展，作为一项新兴技术，它具备改变容器网络、安全、可观测性生态的潜力。eBPF作为更加现代化的内核技术，相较于内核模块，它的编写难度已经有了较大的降低，但是不可否认对于普通开发者还是有一定门槛。
当前可观测性技术采用之后，运维&开发普遍面临的问题：
² 指标太多：不知何时看何种指标；
² 依赖经验和百度：根据经验采用排除法去排查各种可能的异常指标。控制台、日志、trace追踪、数据库管理平台等，各种工具来回切换，需要运维和开发协作，将数据和信息有效组织起来，解决问题时间周期不可控；
² 依赖复现、日志埋点：生产环境是黑盒子，通常靠推理根据现象反推系统行为，但是对于很多非必现问题无从下手；
² 排障门槛：专业apm等工具存在一定的学习门槛，排查方向的准确性和经验能力成正比，而生产故障需要快速响应；
本期我们有幸采访了Kindling创始人苌程老师，一起探讨Kindling程序摄像头如何能在分钟级内定位全资源故障根因及Kindling的未来发展计划。
问题1：苌程老师，您好！请简单介绍一下您的技术背景、目前所负责的领域。
2010浙江大学研究生毕业留校成为SEL实验室的带队老师，SEL实验室的研究方向是paas云计算的方向，从代paas Cloudfoundry到如今的云原声Kubernetes，我们一直在这个方向探索，寻找其中的应用难点。在2016年作为技术联合创始人创办了一家云原生技术服务公司，主要的产品方向是为客户提供私有化的云原生kubernetes平台，在推广云原生平台的时候，我们发现可观测性是用户能否用好云原生平台，业务敢不敢于大范围推广上云原生平台的关键技术难点，而之前传统可观测性技术APM等技术并不能很好帮助用户解决此难点，所以我们在2022年推出了开源的Kindling项目，目标就是利用eBPF技术结合传统可观测性技术，打造一个可以帮助用户理解一次trace执行的完整细节可观测性产品，帮助用户以标准化方式定位所有云原生环境所有可能出现的问题，主力其落地1-5-10。
问题2：：Kindling探针的架构基于什么理念？探针架构包含哪几个部分？
Kindling探针的核心目标就是尽可能的在边缘端完成数据的采集和处理，这个边缘端指的是云原生Node节点，中心端采集的数据要尽可能少。可观性数据是符合低价值，大数据量的特点，所以这就要求我们需要在边缘端完成数据的采集和初步分析，筛选出有价值的数据。
目前Kindling的探针包含以下几个部分：
Kindling-probe：这部分是完全基本上从falco-libs迁移过来，核心逻辑就是拦截内核点位，获取各种内核数据。
Kindling-driver：这部分代码的核心是处理从C端内核采集出来的数据，对从内核采集的数据进行初步处理。
Kindling-Collector：这部分主要使用Go语言，核心逻辑是分析所有的数据，高效的筛选出有价值的数据。
Kindling-Java：这部分代码主要用来和各种APM工具对接，比如Skywalking、pinpoint、opentelmentry等工具。
问题3：当前采用可观测技术之后仍然面临的问题有哪些？如何通过Kindling解决的呢？
当前可观测性技术核心的思想是从系统、运行程序、各种日志中采集海量数据，通过界面将低价值的海量数据给用户使用，用户要能够很好使用这些数据达到高效排障是有比较高技术门槛的，经常需要通过各种表象指标，在不同指标之间跳转去找到线索，这对人员的对程序的运行机理要有深入的掌握才行，但是实际深入掌握程序运行机理的技术人员毕竟是少数，所以现状就是终要落地1-5-10是非常困难的。
Kindling利用eBPF技术从内核中获取关键指标，这些指标是能够取代很多表征指标，直接给出线索。Kindling进一步将关键指标和trace集成，从而帮助用户很好的理解一次请求的完整执行过程。在这两个能力的加持下，我们认为用户可以借助Kindling以标准化的方式去排障，不依赖于技术人员个人水平高低就能的落地1-5-10。
问题4：Kindling是如何实现实时可用的协议解析功能？涉及哪些功能？
Kindling目前协议解析式比较通用的，经历过几次迭代，开始只支持request response模型，而且要求模型必须是一一对应的。目前仍然支持的是request response模型，但是resposne与request不要求在同一个上下文中，可以通过id来标识不同的匹配request与response对。
通过解析协议能够获取到黄金指标：吞吐量，时延与错误率。这三个黄金指标能够直接确定业务是否健康，所以是很关键的。
问题5：当前可观测性工具在云原生环境缺失了什么？
从“术”来讲很多可观测性工具缺乏K8s的集成，感知pod漂移等，但这只是“术”的问题，做好K8s对接其实也就能完成。
从道与法来看，国外的datadog能够做到年收入十几亿美金，国内可观测性工具和厂商差距非常之大，这里面很重要的原因就是国内外的IT人员经验和技术的不同，导致了对工具要求的不同。如果大家真的研究过datadog，会发现datadog本质上来讲是一个可观测性数据的搜索引擎，提供了非常方便的工具，让用户可以不断过滤不重要的数据，持续深入到问题的根因。这些工具对使用者的技术水平要求是非常高的，要求技术人员对于程序运行原理，网络原理，操作系统原理有深入的理解才能利用好这些工具。国内的IT从业者水平很难达到美国IT从业的水平，所以这就对可观测性工具能够在国内的广泛适用提出了更高的要求，要求能够以标准化的方式提供并组织好数据，有效引导，只有完成了这些工作才能满足国内用户对可观测性工具在云原生落地的要求。如果数据能够能被组织好提供有效引导，技术水平比较高的国内外用户当然也会欢迎这种工具。
问题6：为什么Kindling选择了falco-libs作为了eBPF基础设施呢？Kindling大的优势是什么呢？
为什么选择falco-libs作为eBPF基础设施，有以下的原因：
l falco-libs非常成熟，背后有大公司Sysdig站台
l 我们期望Kindling能作为7X24运行的可观测性工具，所以底层要求能够支持，BCC是脚本化的工具，aqua开源tracee其实也是个不错的选择。
l 我们期望一些功能都能够覆盖所有操作系统，目前国内操作系统非常多的不适用eBPF版本，falco-libs能够支持内核模块，能够与eBPF有着相同体验，这是我们终选择falco-libs而不选择tracee的原因
Kindling大优势是率先在全球首创提出了trace-profiling程序摄像头功能，能够指导用户整合trace、metrics，logs等能力，以标准化方式落地1-5-10。
问题7：Kindling程序摄像头如何能在分钟级内定位全资源故障根因？排障时效性目标是怎么设置的？
当用户的trace、log、metrics体系建立之后，仍然有非常多的指标等使用者去发现关联、理解，之后再针对性的给出故障根因。当前排障流程都是以非标准化的方式记录在牛人的脑子里的，牛人排障的问题越多，那么他的经验也就越丰富。这样容易形成每个牛人都有自己的方法论，每个人可能有自己擅长处理的问题。
Kindling trace-profiling程序摄像头深入Linux内核理解程序依赖内核的工作机制，并完整的还原了程序的执行过程，就像光学摄像头一样。这样使用者完全可以利用程序执行过程数据，按照标准化步骤：
l 步，借助trace找到有问题的进程
l 第二步，对比哪个部分的数据有异常（CPU、网络、存储、内存）等
l 第三步，那部分资源开销和预期不符合，重点研究该资源相关的指标，找到异常
根据我们实际经验，这部分操作下来，实际花费时间不操作3分钟。当然现在我们不能因为针对常见的一些故障做到分钟级定位，就能推而广之覆盖所有的故障。这方面我们接下来会开展两方面的工作
l 从理论上论证我们提供的数据是否能够做到分钟级，现在理论的结果是按照我们的步骤是可行的。
l 利用开源的太空舱项目，目标就是广泛的制造出各种故障，并对故障进行实验，验证理论的可行。同时我们也在学术圈调研。国内学术界目前复旦大学软工实验室做得应该梯队的，在TSE国际权威的软工期刊发表了*佳论文，他们开放了一个全球发复杂的微服务应用demo TrainTicket，我们的太空舱项目接下来会利用TrainTicket结合我们之前的积累来论证我们程序摄像头确实可以做到分钟级定位故障根因。
问题8：您创立Kindling的初衷是什么呢？Kindling未来的未来发展思路是怎么计划的？
之前介绍了我们的背景，高校背景结合产业背景使得我们具有不一样的视野。
l 我们想利用Kindling做成一个技术发声的社区，将原来在实验室的想法通过开源社区公开传递给更多用户，大家利用社区协作机制碰撞出符合未来潮流，适用于中国技术土壤的技术方案。
l Kindling可以成为未来可观测性的标准化基础设施的一部分，所以这就注定我们会注重和可观测生态的协作，形成可观测性生态方案，不会重复造轮子。
Kindling的未来发展思路主要是以下几个方面：
1. 优化Kindling探针的性能，使之适用于更加严苛的环境，占用更小的资源
2. 重点在于可观测性的实验环境打造，给社区提供一个擂台，我们认为未来可观测性技术与aiops算法的会结合碰撞出更多的想法，那就需要这样的一个擂台来校验这个想法的可行性与效果。
3. 在擂台之上，不断地完善Kindling的功能，目标就是期望做出能让国内使用者方便实用的，能够真的用起来的可观测性产品。
问题9：您认为好的云原生可观测性开源工具应具备哪些条件？您怎么看待国内的开源环境？有什么关于开源方向的意见和建议吗？
好的云原生可观测性开源工具应该具备的条件，我认为有以下几点：
l 不要重复造轮子，故障根因定位是个很复杂的系统问题，各种技术都应该被系统性采用。这个过程中应注意开源生态的协作，能为我所用的，就去适配使用，重复造轮子反而给使用者造成了更多的选择困惑。
l 解决用户在现有可观测性工具当中解决不了的问题，而且是实际需要的，只有解决实际问题，开源项目才会有生命力。
l 贴近用户的运营，再好的技术与产品，都需要能够清晰的表达，使得目标用户群体能够理解。目前这块kindling做得还不够，当前我们还主要是研发阶段，等到核心功能完善之后，我们会针对用户述求，做更多的文档，场景的撰写
国内开源环境应该是越来越好了，随着国内技术水平与国际技术水平越来越接近，我认为未来中国会出一些有着全球影响力的项目。个人观点，目前国内开源相比国外开源还是处于很大的宣传劣势的，所以国内开源只有做技术和场景都领先的项目，才有可能在众多开源项目之中杀出来，这样的项目长期会得到国内外的认可。
专家照片：
