例如，我为什么要用基于web server的agent呢，我干嘛不用tcp长连接到服务端，这样执行的结果可以流式传输到调用方，他那边显示起来比较平滑，不用每个命令执行完等结果。但是我这样搞的话，中控端流量和日志存储就成了问题了啊。如果我的业务都在云上，如果不同机房...

如果还有其他的OS，那SSH可能就不好使了，而agent可以一定程度上屏蔽掉OS之间的差异。比如puppet这类解决方案，实际下发的操作指令并不是实实在在在机器上执行的指令，而是一种中间代码，由agent将中间代码翻译成当前OS实际该执行的本地命令。

预估并发量假设这1w+pv 80%的请求集中在5小时内(夜里很少人上网)，那么每秒 0.44 次请求，双11为1.32次。极端一点，请求全部集中在1小时内，那么每秒 2.77次请求，双11为 8.31 次。（这点并发量我觉得单机没什么压力吧）

String 是不可变的，所以你在函数体内部做的改变不可能修改这个变量本身地址的值，而是在另一个地址新建了一个String 类型的变量，而你获取不到这个新建的变量的地址，函数执行完毕这个变量就可能会被回收。

这个问题我深有体会.原来项目有做过基于 winston 的 log 系统.首先一定要明确日志的功能. 调试功能，可以方便快速定位和解决问题 记录功能,保存系统运行状态 分析功能,基于记录的数据进行挖掘,实现系统的优化和升级 首先调试功能,这个需要结合业务逻辑.原则是能够利...

写了篇博客，可以来看看——小谈日志与其实践

1、对外部的调用封装2、状态变化3、重要方法的输入和输出4、业务异常5、非预期执行（比如删除一条数据，可能成功可能数据本省不存在）6、很少出现的else情况7、程序运行时间8、大批量数据的执行进度

定时任务开始, 结束 调用接口 执行到哪个功能 打印入参, 等关键参数

1.接口出错,抛出异常的时候. 2.邮箱,消息发送失败的时候

你考虑的确是的，我增加几点吧! 错误异常处理。try{}catch(Exception $e){}。 crontab定时任务的输出。 整个请求的链路上。 关键接口的定制。

打印哪些log，楼上已经有很多回答了。还有两点建议： log严格分level，这样方便在debug的时候查询信息，平时log也不至于过大。 log最好按照日期或者size自动切分

日志宜多不宜少，控制好日志级别就行。说一下我的一个体会吧：如果一个业务的处理流程会经过多个处理节点，那么在每个节点的出口和入口都要打印包含该条业务id的日志，业务处理出现异常时，grep一把这条业务的id，就可以定位是哪个节点处理出现异常。

我是这样想的..一起讨论...看项目的架构设计打日志的系统..打在客户端,打在服务端,还是打到分布式系统中.. 对日志进行分类,方便快速定位.(可能会出现错误异常并且需要的分析的地方都可以打日志) 如果日志打得比较散,如何把这些日志收集起来.(本地日志,还是构建日志服...

嗯，楼上已经说的比较全面了。补充一些1.支付的时候，打log是很有必要的，因为直接涉及到收益，另外，提现一类操作也要打log。2.对接其他接口的时候，如socket之类3.对接一些第三方接口的时候，如极光推送等，要确认推送状态等等吧

后台运行异步任务之前记录时间和运行结束之后的时间 并且记录消耗的内存 建议使用try/catch运行 这样可以准确监控到是否报错 及报错信息.

其实个人认为日志的打印是一门学问的,打的位置关键不关键,输出的内容必要不必要见过很多系统的日志,打的很多,看似很全.但是到出现问题的时候,排查错误很难靠日志快速定位.