开发小白的高光逆袭：竟然能一眼断定生产环境接口响应时间慢是磁盘性能问题引起的 就像犯罪现场的监控视频能让警察一眼看到真正的凶手是谁一样，有一个机智的开发同学借助Kindling程序摄像头精准还原接口执行现场的能力，一眼定位根因。
生产环境10分钟黄金时间快速排障：CPU不定时飙高怎么排查？ 1分钟发现-5分钟响应-10分钟恢复，是定义故障处理的时效性目标。在阿里巴巴内部经过多年的实践，这也早已成为各个业务稳定性、基础设施稳定性以及大促保障的重要牵引指标。对于故障，最难的往往不是排查解决，而是保证上述1-5-10时效性。程序摄像头Trace Profiling直击排障痛点，期望帮助用户在分钟级以标准化步骤定位全资源种类的故障根因
90%开发都会忽略的性能调优点：针对返回大数据量的接口，10分钟内找到提升带宽瓶颈的突破口 我们可能从来没有注意到一个事情：在实际生产环境访问大数据量的接口时，我们自然而然地认为响应速度相对慢些是正常的，但真的完全是因为返回报文太大的缘故吗？现在的带宽大都是百兆，服务器之间的带宽更是上千兆，而往往查询十几M的数据也要几秒钟，这里面还有没有可调优的缺口？我们突然意识到，如果能排查出该慢请求背后的根因，找到调优方法，这可能会对众多开发者提升生产环境接口的性能产生很大的价值和参考意义。
程序摄像头Trace Profiling：生产环境10分钟黄金时间快速排障手册 程序摄像头Trace Profiling能够覆盖CPU、内存、网络、存储等当前常见的资源维度，未来也许我们也可以去支持GPU的资源维度。业内的排障目标是1分钟发现，5分钟响应，10分钟解决问题，而通过使用程序摄像头，按标准化步骤，我们期望辅助开发和运维能在10分钟黄金时间内解决问题。2.2 程序摄像头Trace Profiling的排障效率：1-5-10分钟级定位。2.3 程序摄像头Trace Profiling的排障目标：定位全资源种类故障根因。
一名曾因线上P0故障导致月工资扣了10%的码农心得：如何在故障10分钟黄金时间快速排障 作者曾因一次愚蠢的操作引发了线上P0故障，导致月工资扣了10%，年底绩效-1，连带上级leader也被扣钱，全公司邮件通报批评，大型社死现场。作者想通过自己这次悲催的经历，告诉普通开发同学如何实现在10分钟黄金时间内快速排障
可观测性项目对 uprobe 的需求理解与实现 uprobe是一种用户空间探针，uprobe探针允许在用户空间程序中动态插桩，插桩位置包括：函数入口、特定偏移处，以及函数返回处。当我们定义uprobe时，内核会在附加的指令上创建快速断点指令（x86机器上为int3指令），当程序执行到该指令时，内核将触发事件，程序陷入到内核态，并以回调函数的方式调用探针函数，执行完探针函数再返回到用户态继续执行后序的指令。
关于程序摄像头Trace Profiling的十大热门问题 很多同学对程序摄像头Trace Profiling这个“不明觉厉”的工具有很多问题，小编特意邀请了我们eBPF可观测项目kindling的创始人——苌程老师为大家解答
眼见为实：关于微服务熔断这几个知识点，你可能理解错了 可视化微服务熔断实验，当在应用A某接口上加了熔断器：1. 熔断超时时间指的是接口的执行时间，还是仅接口调用下游服务的时间？2. A接口超时、和抛Exception这两种场景都会触发降级熔断，底层逻辑有什么不同？看似同步的请求竟然是通过异步线程实现的？3. 当A的熔断器触发开启，它是否还能成功调用下游服务？总不能让用户一直失败吧？
eBPF程序摄像头——力争解决可观测性领域未来最有价值且最有挑战的难题 eBPF程序摄像头期望帮你定位Trace追踪工具无法排查的问题；生产环境无法复现的问题；需要打日志紧急发布的问题；系统内核无法观测的问题......
ForkJoin的“分而治之”竟然有隐藏的坑？ 子任务的计算量拆分到多少才算合理吗？为什么你用了ForkJoin反而降低性能？大量线程并行，如何规避线程阻塞？虽知“先fork再join”，但谁负责join？有什么坑需要注意？ForkJoinPool的invoke和submit启动方式竟然还有隐藏的坑你知道吗？
眼见为实：被误导的Tomcat工作原理 眼见为实：用页面可视化的方式带你看到Tomcat工作原理，它里面有哪些线程，在每次请求过来的时候做了什么工作？纠正部分网友对于Tomcat工作原理理解的误区，明确Tomcat里到底是哪个线程在做socket读写？
基于eBPF的云原生可观测性开源项目Kindling之慢系统调用 Kindling通过eBPF技术和内核提供的系统调用tracepoint捕获了所有的系统调用数据，然后把系统调用与线程信息做了关联，并在用户空间对系统调用的enter和exit进行了latency的计算以判断是否为慢系统调用。...
基于eBPF的开源工具Kindling之page-fault事件可观测性实现机制 在Linux内核中，每一个进程都有一个独立的虚拟地址空间，而进程本身感知不到真正的物理内存的存在（比如某进程感知到的内存是连续的，但是实际上它被分配的内存是物理内存中分散的空间）。MMU（内存管理单元）负责完成对于这种虚拟地址-物理内存地址的转换工作。Linux为每一个进程维护了一张页表，用于记录虚拟地址和物理内存地址之间的关系，并在进程运行时实时进行地址转换从而使得进程访问到真正的物理内存。...
Kindling参加首届CCF GitLink开源编程夏令营啦~快来报名吧 Kindling社区参加首届CCF GitLink 编程夏令营，目前报名正在火热进行中，欢迎学生们报名，有丰厚奖金等你来拿哦！
各路大咖云集探讨eBPF技术在可观测性领域的落地现状和未来可能 在本周进行的Kindling研讨会上，Kindling团队的小伙伴给大家分享了多语言微服务环境下的监控问题以及解决对策，并对相关指标进行了解读。本次研讨会也云集了云可观测领域的各路大神：观测云的CEO蒋总、云杉的向阳总以及其他可观测领域的大佬。在后面的交流环节，就当前用户在使用Kindling过程中存在的一些问题，Kindling团队的小伙伴做了回答。如有用户问：Kindling如何解决内存占用的问题？答：目前引起内存占用的原因包括URL发散、慢trace、系统调用的事件源多等，解决方案是尽量减少事件源的数
基于eBPF的云原生可观测性开源项目Kindling之eBPF基础设施库技术选型 eBPF技术正以令人难以置信的速度发展，作为一项新兴技术，它具备改变容器网络、安全、可观测性生态的潜力。eBPF作为更加现代化的内核技术，相较于内核模块，它的编写难度已经有了较大的降低，但是不可否认对于普通开发者还是有一定门槛。因此，很多云原生软件会在eBPF系统调用(函数)和libbpf之上封装一层更加简单易用的api，比如falco的libs、bcc的libbcc、cilium的cilium-ebpf。笔者将这些依赖库称之为eBPF的基础设施。Kindling专注于云可观测性领域，致力于排查各种复杂故障
关注
