Info 日志和 Debug 日志的界限在哪?
对于排查问题来说 Info 的信息似乎不够多,基本都是看 Debug 了。
如此以来就感觉 Info 级基本没什么作用了。
有什么指导性建议吗?
你 debug info 分这么细,别人又会问你 debug trace 的区别,说一千道一万做业务就是 info (非 error )和 error 两种层级有意义。
debug 是详细的 info
warn 也有吧。。
实际开发,其实就 error 和非 error 两种。一般就是 info 和 error 两种。
debug 一般上生产 debug 就关了,所以可以随意打印一些出入参数,调试信息info 一般记录系统模块启停运行,重要步骤出入口,系统内部各种重要状态变化等
一把梭,全打
关键业务信息用 info细节信息,开启之后很快会把磁盘打满的用 debug
正常运行用 info ,复现 bug 的时候打开开关切换到 debug
隐私信息,密码,ip 什么的,info 打不合适,但是 debug 时要看,就是 debug 日志
单元测试期间用 debug ,提交给测试部以后就应当提升到 info ,上生产之后就必须不得低于 info 。debug 、trace 级别対标的是断点 debug 操作,相当于断点调试的替代工具。另外对于自动化单元测试,往往也需要用 debug 日志来辅助校验。info 、warn 、error 属于常规日志,后面俩都是报警用的,而 info 则是用于报警之后的问题定位和复现。
一段业务一个 info ,一个算法一个 debug 。info 可以线上打,debug 不能现上打,意味着 info 不能含有用户隐私的数据,脱敏处理
看情况,个人喜欢 info 是给非研发人员看的,尽量让非研发人员能看懂,debug 是给研发看的。比如 log 需要同时输出到界面上和 log.txt ,那可以设置界面的 log level 为 info ,log.txt 的 level 为 debug ,这样界面的 log 用户能看懂,log.txt 同时包含 info 和 debug 也方便研发排错
我喜欢把用户的操作、其他服务发送的消息用 info 来输出,程序自身的逻辑用 debug ,区分行为者,而且生产环境也不会关 debug ,很多时候客户遇到问题光靠 info 完全不足以分析原因,所以我宁愿占用多些磁盘和 CPU ,也要让 log 完整记录
xxx 插入了一条记录 info打开数据库数据库加锁写入数据库数据库解锁函数返回 这些都是 debug
大公司有严格的信息安全要求的,可能不能打印一些用户信息,小公司全打印出来,方便问题定位
你可以这么理解,info 日志是给运营人员看的,他们不需要知道你的软件细节是怎么运作的,但是他们希望能追踪到一个用户是如何使用软件的。例如积分是如何变更的,变更的结果是否符合期望debug 是给开发运维的人看的,他们希望在运营人员对某些数据的变更有异议的时候根据 debug 确认是逻辑错误还是业务本就如此。同时在用户反馈有错误时用户到底提交了什么数据,触发了什么东西引起了用户认为的错误(也可能软件就是这般设计,并不是错误)
感觉一些关键业务运行的参数打到 info 里,这样可以直接通过看日志,便于发生错误的时候能够快速定位运行问题和预测进哪个逻辑分支。debug 可能更偏底层一些,我用的相对少
log.warn("你这是违法行为");log.info("走, 跟我去自首");log.info("没想到, 捅了老窝");log.warn("任何邪恶, 终将绳之于法");log.error("不是白象我不吃");
建议看看这个 : www.cnblogs.com/zh94/p/16109603.html
debug 开发的时候用,info 上线用。事实是,线上出问题的时候恨不得把所有打印都打出来
一般不用 info只有 debug 和 error
对性能的影响程度
其实很好理解debug 就是开发阶段调试用的,上线肯定要关掉info 就是你需要分析线上环境的问题时所需要的所有信息warn 就是没有达到预期逻辑分支时的场景日志error 就是异常报错信息
有时候做 presentation 需要有一些 live coding ,如果用 Google Meet 分享屏幕的话有延迟不说,画质还经常被压缩到的。目前的想法是收集一下同事…
作为一个老 Python 开发,看了这篇 3.13 的类型注解新特性解读之后,头有点冷: medium.com/techtofreedom/7-new-typing-feat…
如题,怎么样能将其利用起来? 数据还在持续更新,不过后续的难度不小 刑 细说 你这是把谁家裤子给脱了 合法数据的话和 SFT 一个 llama 呗 依我看就一个用…