关于日志的一些考虑
前几天晚上，又对这个问题产生了一些思考，然后做了一些记录，最近博客弄好了，整理一下发出来。
在很早前，我有一次感觉需要日志了，然后就找日志框架(log4j2)，看文档怎么回事。当时很痛苦，总觉得差了一些东西，后来就放下了。
最近重新思考了下，日志这个东西，某种意义上和代码注释差不多，要写的话，就只记录核心的东西就可以了。
我之前看这个就麻爪的原因一个是因为我没有使用过，再一个就是当时感到恐怖的核心问题是*日志到底该输入什么样子pattern*，而非*应该输出什么内容*。
不过就目前的阅读+自己的思考来看想要一次性的实现日志整体的内容是不可能的，可能需要多次的迭代修改。即便我对自己的智力与能力非常自信，我能做的扩展只是针对现阶段的自己的眼界，这和大公司的某些人的视角是比不了的。
下面就按照自己现有的经历做一下梳理吧。
目标
首先要明确目标：我用日志来做什么？
- 记录出现的bug（1.系统报错，2.应用行为异常，如某些特别缓慢）
- 行为某些用户行为（用户的主要操作）
- 业务需求记录的东西？
谁来用
有运维的公司可能是运维来用，没有的可能是开发在用。（我现在）
日志该记录什么
我有了这样的目标，那么日志应该记录什么东西呢？
- 能够定位bug的东西，即谁登录（如果有的话），哪个代码，什么错误，时间。
- 想监控的东西，比方说方法执行了多长时间
- 哪个id的用户，做了什么东西
如何处理日志的等级？
- 自己随便打桩的自测，用
debug info就是正常的输出，比方说某些游戏可以自动执行，然后就会不停地刷新输出日志，某些日志就是必须要输出的，即便是不需要任何人做操作。- 某些危险的行为
warn，如登录验证错误，————本来写的登录验证错误 - 系统出问题，需要人干预的，那就需要
error级别了。
大公司的分级
看了别人的日志分级文章，有了不同的想法，像我这种是一种分级思路，这种分级对没运维项目来说是恰当的。因为我们这个项目，即便是我设置为error的问题也不需要马上看。
而别人说的分级思路是这样的，是否紧急到需要别人操作，或者是是否紧急到需要修复。比方说某些错误必须要马上通知运维操作，这种日志就需要error，而且要极力避免狼来了的反复情况。
总结下能做的东西
- 使用aop统计每个接口的执行时间，记录缓慢的行为（）
- 每一个手动抛出异常的位置，记录下异常原因和位置。
- 一些自认为不可能的东西，如if的另一半，要打日志记录下。
- 尽量把日志写成可定为问题的样子，即把自己假定为刚看这个日志的人，从这个日志中能知道问题是啥。就像类的命名那种，不要模糊
总结
坦诚讲，我这边就是按照自己的业务需求设计的log部分。后来查到了一些文章，发现别人写的真是好。大公司员工做的事和我们这种真的不一样，不但要考虑部门之间的协作，而且实际遇到的问题也多，总结也到位。
后记
本篇内容原记于2019.02.11，放了好久也没有发出来。现在整理一下，发出来。
重新看了下，其实当时困扰我的问题在新公司依然做的不是很好。不过考虑下java原生啊、很多java写的框架啊、包括apt、git之类的工具。在我们初次使用这些东西的时候，它们即便把错误原因输出出来，我也不知道怎么办。我只能去查，然后才能懂怎么回事。查的过程本身就是了解apt、git的过程。换句话说，如果不懂这个软件在干嘛怎么干，日志输出啥都没用。换句话说，能看懂日志的前提是知道软件怎么做事。换句话说，让运维看懂日志很难，最后出问题还是写代码的人来查。在换句话说，日志只需要记录到能让程序员自己看懂就行了。换句话说，以上考虑的点都没啥意义，有意义的是被真实场景推动的改变。
之后有可能会结合架构是最低成本写一篇文章，这篇先这样。