最近涌现出各种各样能帮助你理解日志的新工具，有类似 Scribe、Logstash 这样的开源项目，也有类似 Splunk 的预付费工具，还有托管服务如 SumoLogic 和 PaperTrail。这些工具的共同点是对日志数据进行清洗，在大量日志中提取一些更有价值的文件。
但有一件事这些工具却爱莫能助，因为它们完全依赖你实际投入的日志数据，而如何保证数据的质量和数量则需要用户自行完成。因此，在关键时刻，如果你需要基于部分或者遗漏日志做代码调试时，事情可能会变得非常棘手。
为了减少这种情况发生，在这里分享五个建议，在你记录日志时最好能铭记于心：
1. 你好，我的（线程）名字是
正如 Ringo，线程名称这个属性是 Java 中最被低估的方法之一。其原因是线程名称大部分是描述性的。然而问题同样出现在这里，类似人们自己，起名时通常会被赋予一定的意义。而在多线程日志中，线程名同样挥着关键作用。通常情况下，大多数日志框架会记录当前所调用的线程名称。可悲的是，我们通常会看到 http-nio-8080-exec-3 这种名字，简单地由线程池或容器进行分配。
出于某种原因，我们曾不止一次地听过这种误解——线程名称是不可变的。与之相反，在日志中，线程名称占据基本主要地位，你应该确保能正确使用。比如将它与具体情境结合起来，例如 Servlet 的名字、任务相关，或者一些动态语境如用户或消息 ID。
这样的话，代码接口应该是这样：
Thread.currentThread().setName(ProcessTask.class.getName() + “: “+ message.getID);
更先进的版本将被加载到当前线程的线程局部变量，配置 log appender，并自动将其添加到日志条目。
当多个线程写入服务器日志，但你需要集中在单一线程上时，这将会非常有用。如果你在一个分布式 /SOA 环境下运行，更能看到它得天独厚的优势。
2. 分布式的标识符
在 SOA 或消息驱动的架构，任务执行很可能跨多台机器。当处理这种环境下的故障时，连接相关机器和它们的状态将是了解具体情况的关键。大多数日志分析器会将这些日志信息分组，假设你为它们提供了唯一标识，它们便可以作为实际日志消息的一部分。
从设计的角度出发，这意味着，从进入系统到操作完成，每一个入站操作应该有其唯一的 ID 对应。请注意，一个持久的标识符，如用户 ID 可能不是一个好容器。在记录日志文件的过程中，用户可能有多个操作，这将使得隔离特定流更加困难。UUIDs 可能是个不错的选择。它的值可以被加载到实际线程名称或者作为 TLS-thread 的局部储存器。
3. 不要使用文本+驱动器，不要日志+循环
很多时候，你会看到一段代码在紧密的循环中运行，并执行相应的日志操作。基本假设是，该代码运行的次数是有限的。
很可能运行情况非常良好。但是当代码得到意外输入时，循环可能并不会中断。在这种情况下，你不只是处理一个无限循环「虽然这样已经很糟糕了」，你正在处理的代码正将无限量的数据写到磁盘或网络。
在单机场景中它可能会造成一台服务器崩溃，而在分布式场景中，被影响的则是整个集群。因此如果可能，不要在紧密循环中记录日志。捕获错误时，这一点尤其如此。
