关于运维:AOps性能火焰图适用于云原生的全栈持续性能监测工具

2次阅读

共计 2291 个字符,预计需要花费 6 分钟才能阅读完成。

对于开发及运维人员来讲,火焰图是一个经典的定位性能问题的办法。利用火焰图能够可视化系统资源(cpu 占用、内存占用、调度、IO 等)的占用状况,从而帮忙技术人员疾速定位资源异样应用的代码级根因,或者察看潜在性能劣化趋势,进而优化零碎和利用的性能。然而,现有风行的火焰图工具往往存在一个或多个局限性,理论利用场景比拟无限。因而,openEuler 上的开源我的项目 A -Ops 中的 gala-ops 系列组件提供了实用于云原生的全栈继续性能监测火焰图。

传统火焰图在理论利用中的痛点

1. 传统火焰图工具绝对独立,难以对接第三方插件或集成到运维零碎,在利用中须要有教训的开发人员手动联合其余调试工具剖析定位。

2. 因为开销较大,火焰图大多仅仅作为工具在开发和调试阶段被应用,不能在生产环境中常态化部署。所以对于更常见的场景——即理论生产环境中的突发性的性能问题,火焰图并不是定位问题的无效伎俩。

3. 生产环境上中部署的利用类型盘根错节,语言纷纷多样,而且很多利用是会调用不同语言的模块。然而每种火焰图工具往往只针对繁多类型的语言。即便同时部署了不同语言的火焰图观测工具,所生成的火焰图数据又难以对立,从零碎角度难以观测不同语言利用的性能占比。

4. 传统火焰图往往只能观测过程,线程粒度,是 host 时代的工具。对于云原生零碎更关注的容器粒度,传统火焰图无奈直观辨别。

gala-ops 火焰图的四大个性

1. 易于部署和集成 gala-ops 是针对云基础设施灰度故障的利用级 / 零碎级在线诊断工具,火焰图探针 stackprobe 集成在其中的 gala-gopher 组件内。用户只需一键装置 gala-gopher 后,在配置文件中开启或敞开火焰图探针即可应用。具体的装置部署阐明可参考 gala-gopher 文档。

gala-ops 火焰图默认会在本地生成 svg 格局的火焰图。另外它也反对 pyroscope 和 grafana 等第三方运维平台,仅需在配置文件中填上第三方插件的地址,火焰图探针程序就会定期主动将火焰图数据上传到远端以不便后续剖析和实时监测。以下是 gala-ops cpu 火焰图对接 pyroscope 和 grafana 的示例。通过抉择特定时间段,能够查看到该时间段的火焰图,函数 cpu 占比排序,配合其余零碎或利用指标能够很不便地发现和定位问题。

2. 容器反对云原生零碎中,利用以容器模式部署。传统火焰图中在进行零碎级观测时,最多体现线程名称,若不同容器示例内线程名雷同,则调用栈会合并在一起无奈辨别,影响后续定位定界。gala-ops 火焰图探针可能自动识别本机中的 pod 和 container,并在图里减少工作负载,容器和过程号信息。若过程为工作负载 / 容器内过程,则别离以 [Pod] 和[Con]前缀标记 pod 和 container,过程以 [<pid>] 前缀标记。效果图参见下一段附图,可见通过查看调用栈底部第一层,能够显著辨别主机过程和容器过程。

3. 全栈反对 gala-ops 火焰图反对编译型和解释型语言的混合代码调用栈解析。目前已反对的语言包含 C,C++,GO,Rust,JAVA。不同语言的利用,同一调用栈中不同语言的函数 / 办法,用户态和内核态,均可在同一火焰图中对立显示。而且应用 gala-ops 火焰图前不须要针对不同的语言做额定配置或重新部署利用,即开即用。下图显示了一个实测生成的 gala-ops cpu 火焰图,以右侧的一个 tomcat 容器调用栈为例,从底层往顶层看调用关系:tomcat pod 内蕴含一个 container,containter 中有一个 pid 为 2434466 的 java 过程,过程内 cpu 占用最多的是名为 http-nio-8080- e 的 JVM 线程,JVM 调用了 C 库函数 thread_native_entry,再往上进入了 Java 办法 java.lang.Thread::run,而后通过一系列的 Java 办法调用,最终走到了 ksys_write 零碎调用,而后进入内核态函数。这样一个 Java 过程从 k8s 层 ->OS 层 ->JVM 底层实现 ->Java 办法 -> 内核态函数——残缺的调用过程就能够通过 gala-ops 火焰图追溯到。

4. 低开销 gala-ops 火焰图基于 ebpf 技术,精简堆栈采样逻辑,实现放弃采样精度(cpu 采样频率 10ms)的同时对被观测利用性能影响很小(个别在 1% 左右)。因而,大规模生产环境中也能够继续开启 gala-ops 火焰图以实时观测利用性能,这样即便呈现利用或系统故障,无需预先重现问题,通过 gala-ops 火焰图能够回溯以往任意时刻的零碎状态。咱们测试了开关 cpu 火焰图对不同利用的性能影响:对于自身性能中等,吞吐量中等的利用,例如 tomcat,tps 劣化在 1% 以下;对于自身性能较高,吞吐量大的利用,例如 kafka,tps 劣化在 2% 以下。后果如下:比照开关 cpu 火焰图探针对 tomcat 性能的影响:

比照开关 cpu 火焰图探针对 kafka 写入 MQ 音讯性能的影响:

gala-ops 火焰图具备易于部署和集成,容器反对,全栈反对,低开销等个性,使得开发者和维护者无论在开发环境还是生产环境均可通过火焰图的模式预测潜在问题和定位已产生问题。

性能的继续欠缺

目前 gala-ops 火焰图曾经反对 cpu 占用,内存透露两种类型火焰图,后续还会退出对其余系统资源的观测,例如调度、网络 IO、磁盘 IO 等。此外,对其余语言利用的反对也在继续开发中。欢送大家应用 gala-ops 火焰图,也欢送大家交换和反馈意见,点击​​https://forum.openeuler.org/t…​​,即可到 openEuler 论坛参加探讨!

正文完
 0