【发布时间】:2023-03-08 16:35:02
【问题描述】:
我对@987654321@ 工具有点陌生,我想知道是否可以继续在生产环境中运行它。从我看到的文章来看,这似乎是好的和标准的,但是我很困惑这不会影响性能,因为它每秒会采样N 次,为什么这不会导致性能下降性能。
【问题讨论】:
-
如果你想监控使用监控系统而不是pprof; pprof 适用于需要跟踪一些问题并进行调试的情况
我对@987654321@ 工具有点陌生,我想知道是否可以继续在生产环境中运行它。从我看到的文章来看,这似乎是好的和标准的,但是我很困惑这不会影响性能,因为它每秒会采样N 次,为什么这不会导致性能下降性能。
【问题讨论】:
Jaana Dogan 确实在她的文章中说“Continuous Profiling of Go programs”
生产中的分析
pprof 在生产环境中使用是安全的。
我们的目标是为 CPU 和堆分配分析额外增加 5% 的开销。收集从单个实例每分钟发生 10 秒。如果您有 Kubernetes pod 的多个副本,我们会确保进行摊销收集。
例如,如果您有 10 个 pod 副本,则开销将为 0.5%。这使得用户可以始终保持分析。我们目前支持 Go 程序的 CPU、堆、互斥锁和线程配置文件。
为什么?
在解释如何在生产中使用分析器之前,先解释一下为什么要在生产中进行分析会有所帮助。一些非常常见的情况是:
- 调试性能问题仅在生产中可见。
- 了解 CPU 使用情况以减少计费。
- 了解争用在何处累积和优化。
- 了解新版本的影响,例如看到金丝雀和生产之间的区别。
- 通过将分布式跟踪与分析样本相关联来丰富您的分布式跟踪,以了解延迟的根本原因。
因此,如果您出于正确的原因使用 pprof,是的,您可以将其保留在生产环境中。
但是对于基本监控,正如评论的那样,该系统就足够了。
正如Vladimir Varankin在“Continuous Profiling and Go”中所述
根据公司基础架构的状态,应用程序进程中的“意外”HTTP 服务器可能会引起您的系统运营部门的质疑;)
同时,根据公司的特殊性质,访问生产应用程序中与应用程序的业务逻辑没有直接关系的某些内容的能力可能会引起安全部门的质疑 ;)) 我
因此,在启用此类功能时,开销并不是唯一要考虑的标准。
【讨论】: