Golang 问题排查指南

文｜三藏(唐智坚)

当我们收到线上服务的报警，如何正确的处理？当遇到莫名的性能问题，如何定位到 RootCase ?线上问题诊断总是困难重重，但是我们可以通过成熟的方法论和工具链来帮助我们迅速定位问题。这里根据我们内部的实践和大家做一个分享。

1. 报警排查

报警是一个客观事实，即使是误报也说明了出现了一些没有预期的 case，我们无法穷尽所有的问题，但是我们可以建立标准的流程和 SOP手册，去拆分问题的颗粒度，简化难度，更加容易的去定位问题。

1.1 流程

• don't panic，胸有激雷而面如平湖者，可拜上将军！深吸一口气不要慌张，在紧张和压力面前越是慌张越会犯错，反而忽略了正确的线索。
• 然后在群里同步你已开始介入，让大家放心的把后背交给你。

• 80% 的事故都是当日上线的变更。
• 对于事故，止损是第一要务，即使会破坏现场，事后我们总是可以靠着蛛丝马迹找出线索。不能降级就重启，重启无效就回滚。

• 从资源利用率到延迟建立不同的 SOP。遇到问题时我们只需要按图索骥，足矣解决90% 的问题。对于解决不了，要呼叫队友和大佬进行支援，语音是最有效的沟通。

1.2 建立 SOP 手册

建立好 SOP , 培养组织的战斗力，不能只是一个人的单打独斗。有幸我们建立了完善的 SOP，即使一个新人也能迅速投入战场，参与到线上排查。我们内部的文档如下：

• 服务调用异常排查SOP
• 响应延迟增长问题排查SOP
• 熔断问题排查SOP
• Mysql响应RT升高排查 SOP
• Redis响应RT升高排查SOP
• ES响应RT、错误率升高SOP
• goroutine异常升高排查SOP
• 实例CPU、内存异常排查SOP
• 流量环比上涨排查SOP
• 业务常见问题排查

限于内部的敏感性，这里基于上述资料做一个总结，处理手册应该做好以下几点：

• 涵盖各种工具的链接，有服务的Owner，基建的负责人，要做到不靠搜，不靠问。

• Grafana 等工具做好 Dashboard ，一个好的 Dashboard 能够直观的定位到有问题的 API ，可以看到 P99, 95, 90 等延迟, QPS、流量等监控。错误率是重点监控的值，延迟只是表象，错误能帮我们接近真相。
• 查看对应的服务是否存活？是否存在资源瓶颈（CPU 打满等）？Goroutine 是否飙升？全家桶炸了？

这种就直接重启，大概率是资源连接申请了没有释放。重启无效就止血。

• 基建（Redis，Mysql 等）的延迟，查看当前的连接数，慢请求数，硬件资源等。性能之巅里的 USE（utilization、saturation、erros）是个很好的切入点，对于所有的资源，查看它的使用率、饱和度和错误。

• 部分接口慢，直接限流防止雪崩，抓一条请求看看 tracing ，看看链路的耗时。

一个合格的处理手册交给新人也能够定位到问题点，并能解决一部分的问题。

2. 性能排查

业务逻辑的 BUG 最终可以通过日志和监控定位到 Root Case。但是不可捉摸的性能问题，才让我们头秃，这里重点讲下这我们如何排查性能问题：

2.1 工具箱

2.1.1 pprof

这是 Go 最常规也是最好用的性能排查工具，如果你还没有用过那么强烈建议阅读下官方教程 和 这篇。

在时间窗口内，CPU Profiler 会向程序注册一个定时执行的 hook（有多种手段，譬如 SIGPROF 信号），在这个 hook 内我们每次会获取业务线程此刻的 stack trace。
然后将 hook 的执行频率控制在特定的数值，在 Golang 中 是100hz(可调整)，也就是每 100 个 CPU 指令采集一个业务代码的调用栈样本。当时间窗口结束后，我们将采集到的所有样本进行聚合，最终得到每个函数被采集到的次数，相较于总样本数也就得到了每个函数的相对占比。