- 博客(47)
- 收藏
- 关注
RSS订阅原创 APO选择ClickHouse存储Trace的考量
自定义ClickHouse的表结构的好处在于，所有的内容完全能够自己掌控，但是坏处是其他生态产品很少会基于该自定义表结构进行演进，从而没有办法与其他生态集成。Span自身花的时间应该如何查找Span的tag应该如何才能查看这对于没有接触过Jaeger的用户而言是可行的，选择Signoz和Uptrace没有太多差别，但对于已经熟悉Jaeger的用户不大友好。
2024-08-28 14:58:04
974
原创 APO 新发版支持Skywalking Agent接入
自APO开源以来，社区成员询问APO是否支持Skywalking Agent，以避免已使用Skywalking的应用在测试发版过程中需要重新部署探针。APO利用OpenTelemetry生态，通过skywalkingreceiver实现Skywalking Trace到OTEL Trace的转换，为已经使用Skywalking的用户提供无缝体验。
2024-08-26 14:41:53
835
原创 APO 集成生态exporter一键完成指标采集
Metrics 作为可观测性领域的三大支柱之一，Metrics数据采集显得尤为重要。传统的prometheus工具采集指标，需要指定路径抓取，当指标越来越多配置会显得复杂。同时prometheus只能采集指定的指标，当用户需要节点系统相关、中间件等指标还需要引进额外组件。久而久之采集指标配置难以维护。
2024-08-21 16:17:31
980
原创 APO如何快速判断云环境网络质量是否有问题
使用ping来判断网络质量是大家常用的一个习惯，而对于ping的延时大家在实践中已经形成了一些认知，比如如果ping的延时超过100ms，那么在线网络游戏估计玩不成了。eBPF可以获取到网络rtt以及srtt等指标，这些指标确实能够反应网络质量，但是其实现是有局限性的，在当前绝大多数客户使用场景是不能反映网络质量的。虽然eBPF和ping包的方式都有一定局限性，但是eBPF的局限性受限于内核的实现，该局限没有办法突破的，而ping包的局限是可以突破的。最终效果图，展示srcip到dstip的ping值。
2024-08-16 10:19:37
766
原创 业界首个OpenTelemetry结合eBPF的向导式可观测性平台APO正式开源
APO 致力于提供一键安装、开箱即用的可观测性平台。APO 的 OneAgent 支持一键免配置安装 Tracing 探针，支持采集应用的故障现场日志、基础设施指标、应用和下游依赖的网络指标以及Kubernetes 事件，支持采集基于 eBPF 实现的等数据。支持使用 Jaeger UI 查询 Tracing 数据，使用 PromQL 从 VictoriaMetrics 中查询 Metrics 数据并展示在 Grafana 上。
2024-08-13 14:08:56
1014
原创 Kindling-OriginX 在快手 Staging 环境的异常诊断效果分享
Kindling-OriginX 并不直接提供 Trace 能力，而是采用接入 Trace 数据的形式，即通过接入目前成熟的 Trace 产品与提供标准接入 SDK 方 式，例如 Skywalking、OpenTelemetry、ARMS 等，利用 eBPF 能力将 Trace 数据进行扩展，将其与底层的系统调用相关联，进而实现整 的可观测性，消除程序执行与 Trace 数据中的盲区。假设极端情况，存在故障的实例的请求时延在 24h 内一直都很高，那么后续的请求也会被判断为正常请求，产生漏判。
2024-07-04 14:57:25
652
原创 Kubernetes集群中如何利用北极星因果指标设置正确的POD规格——CPU篇
在 Kubernetes 容量规划中，追求的是集群的稳定性和资源使用效率之间的平衡：资源分配过多会造成浪费。资源分配过少则会导致用户请求时延上升，影响集群的稳定性。公众号之前翻译了一篇 Sysdig 的文章，介绍了如何设置合理的资源参数。虽然按照那篇文章设置可以有一定的帮助，但仍然可能存在风险。本文将详细说明这些风险，并介绍如何通过北极星指标对 POD 的规格进行调整，以达到时延和资源的完美平衡。POD 启动时请求的 CPU 资源量。
2024-06-17 10:28:51
642
原创 Kindling-OriginX v1.4.0 发布：开箱即用，无需对接；自动关联故障节点的上下游关系，通过延时曲线辅助判断根因节点
在本次更新中，为了进一步加快排障速度，Kindling-OriginX优化了故障诊断页面，自动将故障节点的上下游关系关联起来，并展示了节点的响应耗时，使故障节点间的依赖关系和耗时相关性一览无余，在多节点发生故障时更容易找到根因；我们还在首页中将SLO状态与请求次数关联在一起，辅助用户判断SLO状态变化的原因。从该版本开始，OriginX安装后开箱即用，无需再对接外部 Tracing 系统，我们大大简化了安装过程，欢迎安装试用！
2024-06-13 09:41:31
805
原创 排障指标革命性新突破，北极星指标让故障无所遁形--北极星因果指标产品正式发布
指请求在CPU上消耗的时间。指请求在网络传输中消耗的时间。指请求在文件系统读写操作中消耗的时间。指请求在内存分配和管理中消耗的时间。指请求在等待锁资源中消耗的时间。指请求在垃圾回收过程中消耗的时间。指请求在执行过程中，由于CPU调度而产生的延时北极星因果指标的引入，彻底改变了故障排查的方式。通过提供因果关系和全面视图，它不仅提升了排障效率，还显著减少了排障过程中的盲目性和试错成本，真正实现了高效、精准的故障排查。永久免费多语言支持：Java、Python、Nodejs、一键安装标准PQL语句查询数据。
2024-06-11 13:39:21
680
原创 Originx创新解法——应用依赖故障篇
依赖故障指应用运行所依赖的环境包括网络、中间件、缓存故障导致应用出现故障。这部分故障的根因并不是应用代码的问题，但是其最终表现形式和应用代码故障表现形式类似，很难区分。本文重点呈现Originx如何针对应用环境所依赖的故障进行根因分析，之前的系列文章请参考：文章中对常见的全栈故障的传统定位方法进行了阐述。文章中呈现了如何利用Originx的功能对应用程序故障的根因定位。
2024-05-22 15:09:14
835
原创 Originx的创新解法之：应用程序故障篇
Originx并不期望做一个完整覆盖全栈的监控体系，而是利用北极星指标体系标准化找出故障方向，然后联动各种成熟的监控数据形成证据链条，并将各种数据融合在一个故障报告之中。更多信息请参考Originx的设计目标是力争实现全栈故障种类的定位，自身的eBPF探针采集北极星排障指标，然后北极星排障指标引导到故障根因，Originx的核心工作原理请参考下方网址，或者扫描下方二维码在已经识别出故障方向之后，利用各种成熟的开源监控作为数据来源，形成完整的证据链条，最终形成用户能够直接使用的故障根因报告。
2024-05-16 11:03:58
920
原创 在线业务的常见全栈故障种类与定位手段
在线系统的稳定性和可靠性是企业数字化转型成功的关键。然而，由于云环境和系统演进的复杂性，故障的发生几乎不可避免。本系列文章将对在线系统可能遇到的全栈故障进行分类，并结合网上的案例分析，对比常规分析诊断手段与Originx推理引擎是如何能够轻松找到全栈故障的根因。本文为该系列的第一篇，主要介绍常见故障以及全栈故障定位的难点，后续系列文章将重点介绍如何使用Orginx高效定位故障。
2024-05-13 09:24:05
475
原创 解密北极星指标体系如何实现根因分析
当前人为定位故障主要依赖于指标告警，但是现在绝大多数指标反映的程序执行结果，并未对程序执行过程提供更多的信息。举例说明，CPU利用率是程序执行完代码之后的CPU的被使用的反映，内存利用率是程序已经使用内存的执行结果，
2024-04-28 10:22:41
573
原创 Kindling-OriginX v1.3.0 发布：自动关联锁堆栈与锁时间，精准定位问题代码；新增代码火焰图，识别热点代码段
本次更新中，Kindling-OriginX 创新性地实现了慢故障 Trace 与代码堆栈的自动化关联。对于由于代码中锁问题导致的慢故障，可以快速通过“锁耗时分析”能力定位到相关代码堆栈，确定问题代码段。针对性能分析往往较复杂，无法快速定位的难题，新增热点代码火焰图功能，无需相关经验也能实现快速诊断性能问题。锁是开发高性能、高可靠程序的关键因子之一，同时也往往是导致性能问题和故障隐患的根源之一。很多系统在业务平峰期一切正常，高峰期间并发量增大就会出现各种性能问题，这往往都是由于锁问题导致。
2024-04-24 17:56:56
408
原创 Kubernetesr容量规划： 如何合理设置集群资源
本文介绍了超量使用资源带来的问题以及如何检测集群资源分配问题，并详细说明了如何调整容器的资源分配大小，并对优化效果进行简单的评估。目前 Kubernetes 容量规划在依靠各类工具获取相关指标后，仍然需要有较多相关经验，同时一些参数的设置仍主要参考经验值和历史值，这也对未来相关工具和技术的发展提出了新的要求和挑战。
2024-04-19 14:56:25
848
原创 最佳实践：高并发之扩容思路
扩容，通常指为了提高系统的处理能力，而采取的增加计算或其他资源的一系列措施，以此来提升系统的性能。传统意义上的扩容一般只单单针对硬件计算资源，策略上可以分为两种，一种是对单机整体扩容，也就是整机的CPU、内存、磁盘等等；另一种就是扩容对应的组件，例如提高CPU性能，升级读写性能更优秀的磁盘等。而在云原生、微服务等技术越来越普及后，扩容的概念也不再单单指计算资源，而是扩展到架构领域，例如流量高峰期针对某一中间件资源进行扩容，或针对某一核心服务进行扩容，这使得扩容能够更高效、更有目的性。
2024-04-17 15:44:12
830
原创 eBPF 主题分享：Kindling-OriginX 解密如何揭开可观测性盲区实现根因推导
不便参加会议的朋友，可以4月13日通过Bilibili/CSDN观看当天的直播。亦可扫码提前关注直播，4月13日下午 Kindling-OriginX 与您相约CSDN直播间。
2024-04-12 14:03:04
621
原创 Kindling-OriginX v1.2.0 发布：自动识别分类故障初因，排查效率加倍；推导过程关联自定义指标，适配个性化场景
通过与用户的不断沟通与交流，我们深挖如何通过技术和产品能力提升用户在生产环境中的排障效率和操作便捷性。目前使用中，当故障列表中存在大量慢故障时，用户需要分别打开多个故障报告进行查阅，需要花费大量时间来对故障进行初步的识别和归类。
2024-04-08 17:47:10
428
原创 最佳实践：深入理解线程池参数设置
在现代编程中，线程池已经成为了不可或缺的一部分，特别是在Java编程开发中，线程池更是绕不开技术点。然而，要想取得优秀的性能表现，需要对线程池的参数进行调优。本文将深入讲解 Java 线程池的调优方法和技巧，帮你提高编程技能和优化系统性能，并介绍如何使用 Kindling-OriginX 来深入理解线程池参数设置。
2024-03-29 14:50:48
1120
原创 标准化排障之路：内核行为可观测性应对标准化排障落地难题
在当今快速发展的互联网时代，企业对于IT系统的依赖程度越来越高，系统稳定性成为企业持续发展的关键因素。为了提高系统稳定性，企业纷纷寻求标准化排障的方法。然而，在实施标准化排障过程中，企业往往会遇到一些落地难题。本文将探讨如何应对这些难题，推动标准化排障的落地，并提出以实现内核行为可观测性的方式来应对标准化排障落地的难题。排障流程的标准化是指将故障处理的各个环节规范化、流程化，以确保在面对系统或服务故障时，团队能够快速、有效地采取行动。
2024-03-27 14:19:28
1087
原创 标准化故障根因定位应该怎么做
在现代软件开发和运维中，故障的及时响应和有效解决是确保服务稳定性的关键。然而，由于技术环境的复杂性和多样性，故障的根因定位往往是一项耗时且充满挑战的任务。为了提高故障处理的效率和准确性，标准化故障根因定位的方法和流程显得尤为重要。本文将探讨为什么需要标准化故障根因定位，以及标准化故障根因定位应该怎么做。标准化是提高工作效率和质量的基础。在故障根因定位中，标准化意味着建立一套统一的流程和方法，使得不同的人员在面对相同或类似问题时，能够按照既定的路径进行调查和分析。
2024-03-22 13:46:05
806
原创 可观测性体系建设后，该如何挖掘数据及工具价值？
在现代企业的运维管理中，构建高效且可靠的可观测性体系是保障系统稳定性和业务连续性的关键。然而，运维团队成员的技术能力参差不齐往往成为实现这一目标的障碍。尤其在处理复杂系统故障时，高度依赖专业知识和经验的可观测性工具很难被全员有效利用，进而影响到其建设价值的体现。
2024-03-21 14:11:56
839
原创 运维痛点深度解析：当前排障流程的挑战与局限
在当今互联网时代，运维工作的重要性日益凸显。然而，随着业务规模的不断扩大，运维面临的挑战和痛点也越来越多。本文将深度解析当前排障流程的挑战与局限，提出相应的解决思路，并对未来运维及可观测的发展趋势进行展望，以帮助企业和运维团队更好地应对复杂多变的运维环境，确保业务稳定、高效地运行。
2024-03-20 13:55:22
1192
原创 Kindling-OriginX v1.1.0 发布：有效预防P0故障发生、开源Tracing适配、多项性能与体验优化
我们也将这些错误场景添加到了故障注入平台中，大家可以通过在线Demo进行体验，亦可通过部署故障注入平台对自身可观测体系进行检验。现在Grafana支持将部署在集群内部的VictoriaMetrics作为 Datasource，配置方法见官网更新日志。支持超时错误场景的故障根因推导，清晰展示错误根因。支持超时错误场景的故障根因推导，清晰展示错误根因。SLO状态鼠标滑动自动选中，无需点击展示详细信息，支持单击锁定。故障列表页新增故障服务异常占比图及单个故障服务的筛选。错误故障列表新增“故障初因”列。
2024-03-18 16:58:27
397
原创 故障注入是检验可观测性建设成熟度的有效方法
混沌工程是一种方法论，而混沌工程的核心就是注入故障。通俗理解，以应用为出发点，在各种环境和条件下，给应用系统注入各种可预测的故障，以此来验证应用在面对各种故障发生的时候，它的服务质量和稳定性等能力。
2024-03-14 13:42:23
897
原创 Trace实践的常见挑战：客户端数据与服务器端时延不一致
另外如果从client角度来看，调用就是rpc封装的函数，这个函数的实现绝大多数是没有问题的，但是也可能出现以下这种情况：client端出现GC，或者DNS寻址出现问题，也就是问题出现在了认知盲区，不知道client可能会出现问题。因为RPC的函数调用被封装成了本地函数调用，有些开发可能都不知道自己调用的函数其实是远程RPC调用，所以他们印象中的程序执行是这样的：client端执行RPC之后，Server端立马响应。在一切正常的时候，图中紫色部分消耗的时间是非常少的，基本可以忽略。
2024-03-12 13:53:04
985
原创 AIOps实践中常见的挑战：故障根因与可观测性数据的割裂
在数字化时代，运维团队面临的挑战前所未有。他们不仅要确保系统的高可用性和高性能，还要快速响应并解决故障，以减少对业务的影响。在这种背景下，运维团队急需工具和技术，能够帮助他们提高效率，减轻负担。AIOps（人工智能运维）应运而生，旨在通过应用人工智能和机器学习技术来自动化监控、预测、优化和故障排除过程。
2024-03-05 14:18:49
921
原创 云原生团队如何实现加量不加价
在云原生团队承担更多责任和职能的情况下，如何保证工作效率和质量是一个目前亟待解决的问题。Kindling-OriginX 的思路是通过自动化分析每条 Trace，找出 Trace 中节点 Span 突变的根因，关联各种数据证明推理的准确性，让团队能够更加清晰地完成故障定界与根因分析，为业务方提供强有力的支撑，帮助团队实现加量不加价。相信随着技术的发展会有更多的工具和方法能够帮助到云原生团队来更好地应对各种挑战，也欢迎大家和我们一起讨论自己团队面临的挑战与解法。
2024-03-01 16:58:09
1162
1
原创 P0故障应对策略之：为什么P0故障难以排查
P0级故障，作为系统中最严重的故障，它们的发生往往带来灾难性的后果和巨大的损失。同时，这类故障的排查与修复也往往复杂而棘手，对整个团队的经验、综合能力、应急处置流程都是巨大的挑战。排查P0级故障的过程往往需要深入系统的各个层面，包括硬件、软件、网络等多个方面。这要求团队成员具备全面的技术知识和经验，能够快速定位问题并采取有效的解决措施。此外，团队还需要密切协作，共享信息，才能确保故障排查的效率和准确性。
2024-02-27 14:05:13
402
原创 如何让程序员过一个没有烦恼的假日
刚刚过去的春节假期是一个难得的休息和充电的机会，然而，由于程序员的工作性质，我们常常会面临一些不一样的挑战，常常由于线上业务稳定性要求和担心出现bug，很难真正度过一个没有烦恼的假日。还有一次，我们去内蒙古旅游，进沙漠他都背电脑，他说你不懂，带着电脑有安全感，长剑在手，谁与争锋！经常是好不容易到了假期，工作项目也暂时有所舒缓，想回趟家或者出去走走，一想还要带电脑回，临时都可能要处理报警，买票的欲望就会随理智渐渐消退，依旧选择原环境待上几天。说实话，这感觉我可太熟悉不过了，因为这状态困扰了我好几年……
2024-02-23 15:22:31
412
1
原创 内核视角下持续剖析 VS 代码视角下的持续剖析
持续剖析（Continuous Profiling）是一种软件性能优化技术，旨在实时收集程序运行时的性能数据，如CPU使用率、内存分配、线程锁等待时间等。这些数据通常通过在代码中嵌入剖析器（Profiler）来收集，剖析器能够监测和记录应用程序在执行过程中的各种性能指标。持续剖析的目标是帮助开发者理解应用程序在生产环境中的实际运行性能，从而发现性能瓶颈和优化机会。与传统的剖析（通常在开发或测试阶段进行）不同，持续剖析强调在应用程序的整个生命周期内，尤其是在生产环境中不断进行性能监控和优化。
2024-02-22 14:23:53
1286
1
原创 Kindling-OriginX 使用指南：更有效的进行代码质量优化
代码质量不仅影响着产品的稳定性和性能，而且在很大程度上决定了开发团队的工作效率和产品的成败。然而，由于现代软件交付快速迭代的要求和项目的长时间发展等因素，往往会使得代码质量难以得到长期有效的保证，需要不断对其质量进行优化，同时建立起可持续、可扩展且高效的流程。本指南将展示如何使用 Kindling-OriginX 更有效的发现并优化代码质量问题，尽早尽快发现代码缺陷，并与常用方法做一简单对比。
2024-02-02 15:08:37
938
原创 Kindling-OriginX 如何集成 DeepFlow 的数据增强网络故障的解释力
经过一系列的排查过程，最终用户是能够排查出故障的，但是对用户有以下要求：网络知识非常丰富深入理解网络火焰图熟练使用相关工具。
2024-02-01 14:10:17
1001
1
原创 Kindling-OriginX 使用指南：快速排查线上应用磁盘I/O过高
实际开发工作，在应用中常常需要对文件进行各种读写操作，不当的文件读写操作容易导致磁盘IO过高、文件读写慢、文件资源竞争等问题，这些都可能会对整个系统产生严重影响，甚至导致系统故障。本指南将展示如何使用 Kindling-OriginX 快速定位并排查应用因磁盘I/O导致故障的根因所在，同时与目前处理应用磁盘IO过高的常用方法做一简单对比。在实际生产环境中，应用磁盘IO过高往往都是以CPU过高，占用大量CPU资源或应用产生阻塞等故障形式表现出来，难以快速发现和定位，从而无法快速使其恢复。
2024-01-31 16:29:42
942
原创 Kindling-OriginX 使用指南：识别并解决Java垃圾回收问题
在 Java 开发中，开发人员是无需过度关注对象的回收与释放的，JVM 的垃圾回收机制可以减轻不少工作量。但完全交由 JVM 回收对象，也会增加回收性能的不确定性。在一些业务场景下，不合适的垃圾回收算法以及策略，都有可能导致系统性能下降甚至线上故障。本指南将展示如何使用Kindling-OriginX如何快速识别并解决Java中的垃圾回收造成的故障问题，并与目前处理垃圾回收问题的常用方法做一简单对比。
2024-01-30 14:19:57
904
1
原创 Kindling-OriginX 使用指南：快速定位业务代码性能问题
简单来说，它指的是你的应用在运行过程中出现的性能瓶颈点，也就是导致应用运行变慢的核心问题。解决这些性能问题可以让你的应用变得更快速、更高效。为了更高效地排查业务代码性能问题，需要有现代化的方法和工具，提供自动化和全局化的支持，帮助开发人员更快地定位和解决问题。通过大量Tracing、Log、Metrics数据，再结合JVM、系统日志、中间件日志等各类数据，人工汇总分析定位，工作量极大，难以快速完成。传统方式中主要通过各类 APM 工具，日志分析工具，性能压测等方法来发现业务代码中的性能问题。
2024-01-29 16:39:24
971
原创 Kindling-OriginX 使用指南：快速定位和解决接口延迟问题
排查接口响应慢的原因需要综合考虑网络、数据库、代码逻辑、依赖服务、并发和硬件资源等多个方面，并且需要使用合适的工具和方法进行监测和分析，定位到具体的问题所在。实际生产环境中受多种因素影响，更无法做到快速有效定位及查找故障根因，同时这类问题直接对用户体验造成巨大影响，更迫切需要有效的工具和方法能够进行应对。由于接口延迟问题可能受很多因素影响，很多故障都以这种形式出现在监控数据与用户体验侧，往往是最常见多发的业务问题，也是最难快速定位和处理的问题之一。检查接口的代码是否有性能瓶颈或潜在的问题。
2024-01-26 15:20:07
717
1
原创 依赖报错怎么办？
在开发过程中，经常会依赖各种库，可能是公共的、可能是公司内部的。常常会遇到通过日志发现底层依赖库抛出了异常，例如依赖的某个库中抛出了网路连接的错误，通过日志看到产生了Connection Refused或着响应发生了超时，但通过 APM 工具发现网络和其他依赖服务都没有问题，只能看着错误信息干着急。对于难以明确排查方向，无法定界的故障，Kindling-OriginX 快速组织和分析故障线索，通过自动化 Tracing 关联分析，以给出可解释的根因报告的方式，为这类故障提供可操作的排查方法。
2024-01-23 14:19:58
570
1
原创 Kindling-OriginX实战分享：级联故障该咋办？
通过对 Trace 数据的分析，大致定位问题原因是 ts-travel-service 或 ts-basic-service 出现故障，导致链路在 ts-route-plan-service 调用下游服务时候出现问题。单个服务发生故障，有可能导致故障沿着调用链路，扩散至多个上游服务，进而可能会导致多个服务均产生不同的故障现象，这就是典型的级联故障。之后受多种因素的影响，在 ts-route-service 的上游节点甚至旁路节点都出现不同的程度的故障现象，这就是典型的级联故障在实际系统中的现象。
2024-01-18 09:28:28
849
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人