如何在生产环境优雅的 debug?

我们日常生产环境反馈有问题的做法一般都是直接在线上 debug,比如直接在线上修改代码打日志等。。
因为我们使用的是 PHP,其优点在这里就可以凸显出,那就是可以随时修改代码随时看效果,所以我们都是在线上改代码打日志。。。但我觉得这样子不是正常的做法。。

不知道有没有什么样的系统性方案。。来应对这么些问题:

  1. 该问题只在生产环境中出现,若要复现只能在线上做调试,因此本地或测试环境无法复现和排查。
  2. 当我们应用从单机部署变成了集群部署,在线上修改代码就不止修改一份代码了。
  3. 我们无法有充分的预见性在代码中各个点埋好日志记录,因此只有等问题出现了,然后再去加日志埋点?
  4. 即使我们做足了日志收集,但日常 90%的时间以上都是没有问题的,日志照样输出并采集,积累的大量日志太占磁盘了,而出问题时,我们仅仅需要那一小部分的日志信息。

所以不知道大家都是怎么做的?难道是应用中日志埋点做满,但平常不输出和采集,只有出问题时,通过修改日志采集配置再进行日志采集?比较困惑

Click to rate this post!
[Total: 0 Average: 0]

相关文章

28 thoughts on “如何在生产环境优雅的 debug?

  1. 只在生产环境出现的问题真的有这么多吗?标准操作就是日志拉满,非生产环境复现问题。

    日志是定时切分压缩或清理的,叫 rotation,应用层系统层都可以实现,占不了多少地方。你分布式之后会涉及到日志收集。
    你欠缺可能是一个 stage 环境

  2. 核心功能打好 request 和 response,公司如果有流量回放的中间件可以用上,如果没有可以用 arthas 或者去哪儿的 bistoury

  3. 俺说下自己的看法

    1. 首先这个问题只能在生产环境复现,那么,这种问题就应该是一种少有的情况(如果你的项目大部分问题都是在生产环境复现,你应该考虑是不是项目本身出什么问题了)。既然是一种少有的情况,就特殊对待即可,而看样子,楼主想使用一种通用的方案,俺觉得企图使用通用优雅的方案来解决少有的情况是不合适的。

    2. 即然楼主可以在生产环境复现,那么将服务部署到一台生产环境的机器,让它不对接上流的流量,然后楼主不是能复现么,直接在这台机器上复现,debug 即可。

    3. 当然,在生产环境 debug 时,要留意这个过程中产生的数据,是不是进入了生产环境。避免数据污染。

    4. 最后说一句,以上仅仅是下下策,只有在其它环境实在搞不定的情况下,才使用,使用的时候要万分小心,考虑周到(主要是数据污染问题)!!!

  4. 业务规模小的时候都是生产直接调试,我就不像那些大公司的大佬们那样打击楼主了

    我从零到一,从一到百万负载,确实是意识到了这个过程的重要性,小公司刚起步就那么规范的话,估计活不过几年,所以在线 debug 几乎属于必然,但是我建议楼主千万注意备份,我也经历过数据库误操作丢失一个备注列的情况,以至于客服部门不敢再使用我提供的备注列寸信息了

  5. 如果是一个未知原因的小概率出现的问题,也就是加日志了,然后通过日志去揣测问题本质,然后再在测试环境尝试复现。

  6. 我们公司产品测试环节等同于无,客户遇到问题后,研发直接远程到客户服务器替换组件上生成日志分析原因。后面嫌临时替换文件太麻烦,直接做成产品功能。

  7. 1 、该问题只在生产环境中出现,若要复现只能在线上做调试:
    你说的应该就是 Sentry,可以在 Sentry 配置各种环境, 报错会提示相关环境、第几行代码

    2 、在线上修改代码就不止修改一份代码了
    这些不是都可以通过 Git 分支加 webhook 解决么

  8. @Vegetable 好吧,就是觉得一些地方做日志,平时基本没啥问题,但日志大量被产生,收集的贼多,感觉像是在浪费磁盘。。

  9. @useben 这些都有,但日志没做满,一些问题出现在没做日志的地方,但不出问题的话感觉这些日志太占空间了。。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注