首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
宝塔
V2EX  ›  程序员

日志的粒度请教?

  •  
  •   chaleaochexist · 105 天前 · 1237 次点击
    这是一个创建于 105 天前的主题,其中的信息可能已经有所发展或是发生改变。
    不会打 log.
    不知道哪些地方需要打 log.

    目前的情况是总是丢 log.
    线上的一些随机问题不知道是哪些地方引起的.

    但是 log 太细,又觉得不太合适吧?

    请教最佳实践.谢谢.
    12 回复  |  直到 2019-08-08 12:15:49 +08:00
        1
    VANHOR   105 天前
    看看楼下怎么说
        2
    maemual   105 天前
    当遇到问题的时候你想知道哪些信息有助于你解决问题
        3
    lihongjie0209   105 天前
    遇到问题就加上, 加多了就有经验了
        4
    jsjscool   105 天前
    第三方的接口调用要打,服务的输入输出要打,其他的能不打就不打。写日志是帮助自己用最少的字符得到最有用的结论。
        5
    arrow8899   105 天前
    只在关键的地方记日志,服务调用请求和响应记日志,这样出现问题可以根据代码一步一步复现。
        6
    mushishi   105 天前
    ## 场景 1. 判断程序中关键方法是否进入与正常退出。
    3. 固定:类名+方法名+start+关键参数用于过虑日志

    ## 场景 2:判断关键方法内部逻辑是否正常进入和退出。
    2. 固定:类名+方法名+逻辑主要功能名+start/end+关键参数用于过虑日志

    ## 场景 3:判断程序异常执行关键日志,及异常输出,如果是符合预期的异常捕获可以使用 wran 级别代替 error。
    1. 固定:类名+方法名+[逻辑主要功能名]+got exception error+[关键参数用于过虑日志]+e.getMessage []中括号中的信息代码位置视情况需不需要加
        7
    mushishi   105 天前
    @mushishi 我们团队内部暂时使用的日志规范
        8
    pkookp8   105 天前 via Android
    用等级区分,不重要的或只是协助看流程的 debug 或 trace
    出了问题用于快速定位问题区间的 info
    意料外的但是能处理的 warn
    无法恢复或不能简单处理的,error 或 critical
    外部封装,内部 if 或 switchcase,一句判断条件语句不影响性能(影响的地方用 flag 或 count 记录,别的线程定时输出)
        9
    stevenkang   105 天前
    总结了以下几点:

    1、API 的 I/O 日志,也就是请求参数和响应内容记录日志,这相当于整个系统的大门了,访问日志在排错、性能分析等方面非常有用;

    2、第三方 API 的 I/O 日志,也就是请求第三方 API 发送了哪些参数,第三方 API 又响应了哪些参数,这有利于分析传递的数据是否正确;

    3、异常块,所有捕获异常的位置均应当记录异常内容,除非一些用于业务逻辑判断的异常块(例如:利用异常来判断某个字符串是否能转换等);

    4、非正常请求,例如请求某个 API 报了 403,应当记录 >= WARN 级别的日志,这里和 #1 的区别是,#1 无论正常还是异常均记录请求、响应内容,这里的应当记录更加详细的内容,例如为什么会产生 403 响应,并且日志级别应当更高,方便分析、优化;

    5、应用启停日志,在启动应用进行初始化时,应当记录各个参数的情况,便于在启动时遇到问题进行定位。同理,在应用停止的时候(特别是异常停止),应当记录详细的运行状况、运行参数等日志;

    6、其他日志,根据实际业务情况需要,应当记录其他日志,例如调用短信接口时记录短信用量、剩余量等,这样可以通过编写日志报警规则来实现短信余额不足预警功能;
        10
    jatsz   105 天前   ♥ 2
    这个是个好问题,我在自己的一篇博客中总结过: https://www.imzjy.com/blog/2018-07-06-writing-good-log

    通常下面的情况可以考虑加一行日志:

    - 程序的参数检查一下,函数输入决定输出,输入都不对,输出怎么可能对呢?
    - 第三方回传的时候检查一下,返回数据了么,返回大小是多少,调用时间用了多少?
    - 关键业务点,留下点脚印,打一些 Info 类的日志。
    - 有副作用的函数,比如操作网络,操作磁盘,数据库操作,有时候越是难的 bug,越是这些觉得不可能出错的地方出错。
    - 应用程序启动相关的,比如加载的模块,影响行为的配置文件,环境变量,等等。
    - 数据驱动着应用,常常 bug 在数据中。加一些日志在已有的数据上,即使不记录具体内容,也要记一下大小。
    - 别在同一个地方跌倒两次。抓到一个 bug,或者业务漏洞修复,写个测试区覆盖或许很难,但是记一行日志不费多少电。
        11
    bulbzz   105 天前
    你觉得有问题的地方加上就可以了 粒度是可以准确定位出问题所在。
        12
    bravoer   103 天前
    打日志,一定要注意要形成一个完整的链,从开始到结束,让别人从你的日志中就可以整天程序运行的整个流程,完整清晰的流程一般是一个流程图,分支进入什么的都要考虑到,整个流程一般使用 info,异常使用 error,用于调式什么的,使用 trace 或者 debug。

    你需要明确一点就是,打日志的作用在哪。你就知道怎么打了。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1269 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 24ms · UTC 23:29 · PVG 07:29 · LAX 15:29 · JFK 18:29
    ♥ Do have faith in what you're doing.