除了废开发外，就全剩收益了呀，定位方便，跟踪方便~

这都是开发要做的事，默认是加的，还没见过没有日志的项目

不知道日志监控具体是指啥，是指类似 ELK 的日志统一采集和查找，还是日志错误数达到一定程度自动预警，还是别的。

楼主先明确说下？

日志加了， 如果是和产线一套模板/服务， 也不怎么费开发。
日志留存个 1 天/周（ 根据你们测试场景），也没有很大开销， 按需测试也没那么多的流量。
好处就是， 容易朔源， 也方便定位问题。

监控的好处就不用说了，测试环境不加监控，挂了你都不知道。后面就各种项目来了临时救火修环境。
最简单就是把现有的自动化测试， 在测试环境每天跑一版，能定期回归，又能保证测试环境可用性。
利远大于弊

是指日志中出现异常时的报警通知

这个要看你这报警的阈值是怎么设置的。

如果是抛个异常就预警，估计会很多（很可能出个 bug 就异常了，或者是历史原因系统存在很多其实不用关注的异常）很快就疲了，加了等于没加

如果是能限制为影响环境主流程才预警，那会比较有效，但会比较难，因为从日志其实很难区分，比较有效的是 4 楼所说的，在测试环境里跑已有的自动化用例（特别是流程类的），不通过的时候预警。我们之前是加了主流程自动化的失败监控，30 分钟跑一次并且自带重试机制（有可能刚好某个服务在部署，引起失败），如果重试还是失败就预警。

个人看法，只要不是过度监控，就是有做得必要。
收益：

1. 尽早发现问题，尽早做出响应，争取更多时间，不用多解释
2. 排查定位问题，如某特定类型的 error 日志开始暴涨，很容易知道是谁的变更引入问题

但是在具体实施时要考虑一些因素：

1. 监控触达率，不要搞低效的监控通知机制，比如群里甩个没啥信息量的报警，除非有明确的奖惩机制，否则一般没人管
2. 监控误报率，监控不是做了就完事，是需要持续运营跟进的，不然后面监控准确性越来越低会直接影响正常工作，监控变成了垃圾
3. 监控覆盖率，如果当成是一个正儿八经的事情来做，就需要考虑这个点，否则可以不管

感谢回答，有收获！

实施过程中确实会遇到您说的这些问题，感谢分享！

有些明确的 Exception，如果可以 trace 到 file，然后就可以追踪到 MR，直接给到代码负责人就行了，通知还是要的