Go 应用的持续性分析

今天土拨鼠带来一篇官方更生动的实例文章。本篇文章翻译自 Continuous Profiling for Go Applications[1]。翻译不当之处烦请指出。

源码地址：https://github.com/pyroscope-io/pyroscope/tree/main/examples/golang-push。

使用Pyroscope — 一个开源的持续分析平台

img

使用Pyroscope分析Golang Rideshare应用程序

在这个例子中，展示了一个基本的用例，即如何使用Pyroscope^[2]（一个开源的分析库）来加速Golang应用程序使用持续分析。

我们模拟了一家"拼车"公司，该公司在 main.go 中有三个路径endpoint(这里endpoint翻译参考阮一峰^[3] 写的RESTful API 设计指南^[4]中的翻译):

/bike ：调用 OrderBike(searchRadius) 函数来订购一辆自行车
/car ：调用 OrderCar(searchRadius) 函数订购一辆汽车
/scooter ：调用 OrderScooter(searchRadius) 函数来订购一辆踏板车

我还模拟在3个不同的区域运行3个不同的服务器（通过docker-compose.yml^[5])

美国东部-1
美国西部-1
欧洲西部-1

Pyroscope 最有用的功能之一是能够以对你有意义的方式标记数据。在本例中，我们有两个自然划分，因此我们"标记"我们的数据来表示它们：

区域region：静态地标记运行代码的服务器的区域
车辆vehicle：动态地标记路径（类似于标记控制器轨道的方式）

对区域进行静态标记

标记静态内容（如region）可以在 main() 函数的初始化代码中完成：

pyroscope.Start(pyroscope.Config{ApplicationName: "ride-sharing-app",ServerAddress:   serverAddress,Logger:          pyroscope.StandardLogger,Tags:            map[string]string{"region": os.Getenv("REGION")},})

在函数内进行动态标记

像我们为车辆vehicle标记的那样，可以在我们的实用函数FindNearestVehicle()中使用pyroscope.TagWrapper() 来动态地标记一些东西。

func FindNearestVehicle(search_radius int64, vehicle string) {pyroscope.TagWrapper(context.Background(), pyroscope.Labels("vehicle", vehicle), func(ctx context.Context) {// 模拟找到一辆车 Mock "doing work" to find a vehicle var i int64 = 0start_time := time.Now().Unix()for (time.Now().Unix() - start_time) < search_radius {i++}})
}

这块的功能是：

它添加了标签pyroscope.Labels("vehicle", vehicle)
它执行 FindNearestVehicle() 函数
在块结束之前，它（在幕后）从应用程序中移除了pyroscope.Labels("vehicle", vehicle)，因为该块已经执行完成。

使用火焰图显示性能瓶颈

img

在分析应用程序的配置文件输出时，第一步是注意最大的节点，即应用程序消耗最多资源的地方。在本例中，它恰好是 OrderCar() 函数。

使用Pyroscope包的好处是，现在我们可以进一步研究为什么OrderCar()函数会有问题。标记region和vehicle使我们可以对两个很好的假设进行测试：

/car 路径的代码有问题
我们的某个地区region有问题

要对此进行分析，我们可以从"Select Tag"下拉列表中选择一个或多个标签：

img

使用标签缩小性能问题的范围

知道 OrderCar() 函数存在问题后，我们会自动选择该标签。然后，在检查多个region标签后，通过查看时间线可以清楚地看出 us-west-1 区域存在问题，它在高 CPU 时间和低 CPU 时间之间交替。

我们还可以看到，mutexLock() 函数消耗了近 70% 的 CPU 资源。

img

比较两个时间段

使用Pyroscope的"比较视图-comparison view"，我们可以从时间轴中选择两个不同的时间范围来比较生成的火焰图。左侧时间轴上的粉红色部分生成左侧火焰图，右侧的蓝色部分表示右侧火焰图。

当我们选择低 CPU 使用率周期和高 CPU 使用率周期时，我们可以看到 mutexLock() 函数中存在不同的行为 ，其中它在低 CPU 时间占用 33% 的 CPU，在高 CPU 时间占用 71% 的 CPU。

img

可视化两个火焰图之间约有 112% 的性能差异

虽然在这种情况下，差异是很显而易见的，但有时两个火焰图之间的差异最好通过相互叠加才能更好地可视化。无需更改任何参数，我们只需选择**(Diff View)差异视图选项卡**，即可查看颜色编码的差异火焰图中表示的差异。

img

未来路线图

如果你想尝试此示例，并查看如何将其调整到您的Go应用程序，请单击github上此示例^[6]的链接。持续分析已成为监视和调试性能问题（可以说是可观察性的第四个支柱）的日益流行的工具。

如果您对Pyroscope^[7]如何改进有想法，请随时在GitHub页面上提交你的问题！感谢您的阅读。

参考资料

[1]

Continuous Profiling for Go Applications: https://betterprogramming.pub/continuous-profiling-go-applications-8cdbdfdfc5ab

[2]

Pyroscope: https://github.com/pyroscope-io/pyroscope

[3]

阮一峰: https://www.ruanyifeng.com/

[4]

RESTful API 设计指南: https://www.ruanyifeng.com/blog/2014/05/restful_api.html

[5]

docker-compose.yml: https://github.com/pyroscope-io/pyroscope/blob/main/examples/golang-push/rideshare/docker-compose.yml

[6]

github上此示例: https://github.com/pyroscope-io/pyroscope/blob/main/examples/golang-push/README.md

[7]

Pyroscope: https://pyroscope.io/

欢迎关注Go招聘公众号，获取Go专题、大厂内推、面经、简历、股文等相关资料可回复和点击导航查阅。