这是一个创建于 1604 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们日常生产环境反馈有问题的做法一般都是直接在线上 debug，比如直接在线上修改代码打日志等。。 因为我们使用的是 PHP，其优点在这里就可以凸显出，那就是可以随时修改代码随时看效果，所以我们都是在线上改代码打日志。。。但我觉得这样子不是正常的做法。。
不知道有没有什么样的系统性方案。。来应对这么些问题：
- 该问题只在生产环境中出现，若要复现只能在线上做调试，因此本地或测试环境无法复现和排查。
- 当我们应用从单机部署变成了集群部署，在线上修改代码就不止修改一份代码了。
- 我们无法有充分的预见性在代码中各个点埋好日志记录，因此只有等问题出现了，然后再去加日志埋点？
- 即使我们做足了日志收集，但日常 90%的时间以上都是没有问题的，日志照样输出并采集，积累的大量日志太占磁盘了，而出问题时，我们仅仅需要那一小部分的日志信息。
所以不知道大家都是怎么做的？难道是应用中日志埋点做满，但平常不输出和采集，只有出问题时，通过修改日志采集配置再进行日志采集？比较困惑
 |
1
superrichman 2020-06-22 16:03:49 +08:00 via iPhone
生产环境 debug ？居然没有被运维打死？
|
 |
2
evill 2020-06-22 16:04:27 +08:00
日志级别 + 日志调用链路 + requestID
|
 |
3
yukinomiu 2020-06-22 16:07:25 +08:00
生成环境 debug 这个需求本身已经不优雅了.
|
 |
4
Vegetable 2020-06-22 16:09:52 +08:00
只在生产环境出现的问题真的有这么多吗？标准操作就是日志拉满，非生产环境复现问题。
日志是定时切分压缩或清理的，叫 rotation，应用层系统层都可以实现，占不了多少地方。你分布式之后会涉及到日志收集。 你欠缺可能是一个 stage 环境 |
 |
5
xhcnb 2020-06-22 16:10:55 +08:00
哈哈, 没有经历过生活的毒打
|
 |
6
lff0305 2020-06-22 16:21:00 +08:00
把 PROD 的 request 镜像到你的调试机上
需要 IT 配合 |
 |
7
vitoliu 2020-06-22 16:28:09 +08:00
核心功能打好 request 和 response，公司如果有流量回放的中间件可以用上，如果没有可以用 arthas 或者去哪儿的 bistoury
|
 |
8
lower 2020-06-22 16:30:00 +08:00
果然 PHP 才是世界上最好的编程语言
|
 |
9
asanelder 2020-06-22 16:34:50 +08:00
俺说下自己的看法
1. 首先这个问题只能在生产环境复现，那么，这种问题就应该是一种少有的情况（如果你的项目大部分问题都是在生产环境复现，你应该考虑是不是项目本身出什么问题了）。既然是一种少有的情况，就特殊对待即可，而看样子，楼主想使用一种通用的方案，俺觉得企图使用通用优雅的方案来解决少有的情况是不合适的。 2. 即然楼主可以在生产环境复现，那么将服务部署到一台生产环境的机器，让它不对接上流的流量，然后楼主不是能复现么，直接在这台机器上复现，debug 即可。 3. 当然，在生产环境 debug 时，要留意这个过程中产生的数据，是不是进入了生产环境。避免数据污染。 4. 最后说一句，以上仅仅是下下策，只有在其它环境实在搞不定的情况下，才使用，使用的时候要万分小心，考虑周到（主要是数据污染问题）！！！ |
 |
10
opengps 2020-06-22 16:39:38 +08:00
业务规模小的时候都是生产直接调试，我就不像那些大公司的大佬们那样打击楼主了
我从零到一，从一到百万负载，确实是意识到了这个过程的重要性，小公司刚起步就那么规范的话，估计活不过几年，所以在线 debug 几乎属于必然，但是我建议楼主千万注意备份，我也经历过数据库误操作丢失一个备注列的情况，以至于客服部门不敢再使用我提供的备注列寸信息了 |
 |
11
guanhui07 2020-06-22 16:54:17 +08:00
测试环境 复现是最好，生产环境日志
|
 |
12
luxinfl 2020-06-22 17:29:32 +08:00
改生产环境代码 debug ？想都不敢想
|
 |
13
useben 2020-06-22 18:14:04 +08:00
elk 日志系统+p 指标监控系统...
|
 |
14
smallpython 2020-06-22 18:23:51 +08:00
gdb 是不是可以调试 php
|
 |
15
kop1989 2020-06-22 18:25:48 +08:00
如果是一个未知原因的小概率出现的问题，也就是加日志了，然后通过日志去揣测问题本质，然后再在测试环境尝试复现。
|
 |
16
hankai17 2020-06-22 19:21:28 +08:00
gdb -p 加一堆断点
|
 |
17
JuSH 2020-06-22 19:24:52 +08:00
我们公司产品测试环节等同于无，客户遇到问题后，研发直接远程到客户服务器替换组件上生成日志分析原因。后面嫌临时替换文件太麻烦，直接做成产品功能。
|
 |
18
zhuzhibin 2020-06-22 19:53:47 +08:00 via iPhone
Yii debug
|
 |
19
ben1024 2020-06-22 19:54:15 +08:00
|
 |
20
darknoll 2020-06-22 20:07:41 +08:00 via Android
生产环境 de 啥 bug
|
 |
21
fhsan 2020-06-22 20:17:46 +08:00
elk 吧，别搞了
|
 |
22
oneoy 2020-06-22 22:30:10 +08:00 via Android
idea 支持的 谷歌下就可以 我目前在用
|
 |
23
sadfQED2 2020-06-23 09:18:20 +08:00 via Android
哈哈哈，我也经常在生产环境 debug 啊，在我个人博客项目里面
|
 |
24
ifconfig 2020-06-23 09:21:50 +08:00
1 、该问题只在生产环境中出现，若要复现只能在线上做调试：
你说的应该就是 Sentry，可以在 Sentry 配置各种环境， 报错会提示相关环境、第几行代码 2 、在线上修改代码就不止修改一份代码了 这些不是都可以通过 Git 分支加 webhook 解决么 |
 |
25
avenger 2020-06-23 10:11:03 +08:00
多打日志吧，再加一个预发布 staging 环境，日志记录推荐一下 papertrailapp
带尾巴链接 URL: https://papertrailapp.com/?thank=48e610 |
 |
26
dandankele OP @Vegetable 好吧，就是觉得一些地方做日志，平时基本没啥问题，但日志大量被产生，收集的贼多，感觉像是在浪费磁盘。。
|
|
27
dandankele OP @useben 这些都有，但日志没做满，一些问题出现在没做日志的地方，但不出问题的话感觉这些日志太占空间了。。
|
|
28
dandankele OP @ben1024 看起来不错，回头我研究一下
|
 |
29
weixiangzhe 2020-06-23 17:59:14 +08:00
本地开个 http 代理，whistle 挺好用的，代理到本地也可以
|
Select Language