检查日志是否可以被记录
当日志记录器收到一个日志记录请求时，如果请求的严重性级别低于记录器对象的实际有效级别，则该请求会被忽略。在日志记录方法的实现中会首先进行这样的检查。不过推荐的做法是在调用 API 进行记录之前，首先进行相应的检查，这样可以避免不必要的性能问题，如清单 7 所示。
清单 7. 检查日志是否可以被记录
if (LOGGER.isDebugEnabled()) { LOGGER.debug("This is a message."); }
清单 7 中的做法的作用在于避免了构造日志记录消息所带来的开销。日志消息中通常包含与当前上下文相关的信息。为了获取这些信息并构造相应的消息文本，不可避免会产生额外的开销。尤其对于 DEBUG 和 TRACE 级别的日志消息来说，它们所出现的频率很高，累加起来的开销比较大。因此在记录 INFO、DEBUG 和 TRACE 级别的日志时，首先进行相应的检查是一个好的实践。而 WARN 及其以上级别的日志则一般不需要进行检查。
日志中包含充分的信息
日志中所包含的信息应该是充分的。在记录日志消息时应该尽可能多的包含当前上下文中的各种信息，以方便在遇到问题时可以快速的获取到所需的信息。比如在网上支付功能中，与支付相关的日志应该完整的包含当前用户、订单以及支付方式等全部信息。一种比较常见的做法是把相关的日志记录分散在由不同日志记录器所记录的日志中。当出现问题之后，需要手工查找并匹配相关的日志来定位问题，所花费的时间和精力会更多。因此，应该尽可能在一条日志记录中包含足够多的信息。
使用合适的日志记录器名称
一般的日志记录实践是使用当前 Java 类的全名作为其使用的日志记录器的名称。这样做可以得到一个与 Java 类和包的层次结构相对应的日志记录器的层次结构。可以很方便的按照不同的模块来设置相应的日志记录级别。不过对于某些全局的或是横切的功能，如安全和性能等，则推荐使用功能相关的名称。比如程序中可能包含用来提供性能剖析信息的日志记录。对于这样的日志记录，应该使用同一名称的日志记录器，如类似“performance”或“performance.web”。这样当需要启用和禁用性能剖析时，只需要配置这些名称的记录器即可。
使用半结构化的日志消息
在介绍日志记录 API 中的格式化器时提到过，日志记录中除了基本的日志消息之外，还包括由日志框架提供的其他元数据。这些数据按照给定的格式出现在日志记录中。这些半结构化的格式使得可以通过工具提取日志记录中的相关信息进行分析。在使用日志 API 进行记录时，对于日志消息本身，也推荐使用半结构化的方式来组织。
比如一个电子商务的网站，当用户登录之后，该用户所产生的不同操作所对应的日志记录中都可以包含该用户的用户名，并以固定的格式出现在日志记录中，如清单 8 所示。
清单 8. 使用半结构化的日志消息
[user1] 用户登录成功。 [user1] 用户成功购买产品 A。 [user2] 订单 003 付款失败。
当需要通过日志记录来排查某个用户所遇到的问题时，只需要通过正则表达就可以很快地查询到用户相关的日志记录。
回页首
日志聚合与分析
在程序中正确的地方输出合适的日志消息，只是合理使用日志的第一步。日志记录的真正作用在于当有问题发生时，能够帮助开发人员很快的定位问题所在。不过一个实用的系统通常由很多个不同的部分组成。这其中包括所开发的程序本身，也包括所依赖的第三方应用程序。以一个典型的电子商务网站为例，除了程序本身，还包括所依赖的底层操作系统、应用服务器、数据库、HTTP 服务器和代理服务器和缓存等。当一个问题发生时，真正的原因可能来自程序本身，也可能来自所依赖的第三方程序。这就意味着开发人员可能需要检查不同服务器上不同应用程序的日志来确定真正的原因。
日志聚合的作用就在于可以把来自不同服务器上不同应用程序产生的日志聚合起来，存放在单一的服务器上，方便进行搜索和分析。在日志聚合方面，已经有不少成熟的开源软件可以很好的满足需求。本文中要介绍的是 logstash，一个流行的事件和日志管理开源软件。logstash 采用了一种简单的处理模式：输入 -> 过滤器 -> 输出。logstash 可以作为代理程序安装到每台需要收集日志的机器上。logstash 提供了非常多的插件来处理不同类型的数据输入。典型的包括控制台、文件和 syslog 等；对于输入的数据，可以使用过滤器来进行处理。典型的处理方式是把日志消息转换成结构化的字段；过滤之后的结果可以被输出到不同的目的地，比如
ElasticSearch、文件、电子邮件和数据库等。
Logstash 在使用起来很简单。从官方网站下载 jar 包并运行即可。在运行时需要指定一个配置文件。配置文件中定义了输入、过滤器和输出的相关配置。清单 9 给出了一个简单的 logstash 配置文件的示例。
清单 9. logstash 配置文件示例
input { file { path => [ "/var/log/*.log", "/var/log/messages", "/var/log/syslog" ] type => 'syslog' } } output { stdout { debug => true debug_format => "json" } }
清单 9 中定义了 logstash 收集日志时的输入（input）和输出（output）的相关配置。输入类型是文件（file）。每种类型输入都有相应的配置。对于文件来说，需要配置的是文件的路径。对每种类型的输入，都需要指定一个类型（type）。该类型用来区分来自不同输入的记录。代码中使用的输出是控制台。配置文件完成之后，通过“java -jar logstash-1.1.13-flatjar.jar agent -f logstash-simple.conf”就可以启动 logstash。
在日志分析中，比较重要的是结构化的信息。而日志信息通常只是一段文本，其中的不同字段表示不同的含义。不同的应用程序产生的日志的格式并不相同。在分析时需要关注的是其中包含的不同字段。比如 Apache 服务器会产生与用户访问请求相关的日志。在日志中包含了访问者的各种信息，包括 IP 地址、时间、HTTP 状态码、响应内容的长度和 User Agent 字符串等信息。在 logstash 收集到日志信息之后，可以根据一定的规则把日志信息中包含的数据提取出来并命名。logstash 提供了 grok 插件可以完成这样的功能。grok
基于正则表达式来工作，同时提供了非常多的常用类型数据的提取模式，如清单 10 所示。
清单 10. 使用 grok 提取日志记录中的内容
点击查看代码清单
在经过上面 grok 插件的提取之后，Apache 访问日志被转换成包含字段 client、method、request、status、bytes 和 useragent 的格式化数据。可以根据这些字段来进行搜索。这对于分析问题和进行统计都是很有帮助的。
当日志记录通过 logstash 进行收集和处理之后，通常会把这些日志记录保存到数据库中进行分析和处理。目前比较流行的方式是保存到 ElasticSearch 中，从而可以利用 ElasticSearch 提供的索引和搜索能力来分析日志。已经有不少的开源软件在 ElasticSearch 基础之上开发出相应的日志管理功能，可以很方便的进行搜索和分析。本文中介绍的是 Graylog2。
Graylog2 由服务器和 Web 界面两部分组成。服务器负责接收日志记录并保存到 ElasticSearch 之中。Web 界面则可以查看和搜索日志，并提供其他的辅助功能。logstash 提供了插件 gelf，可以把 logstash 收集和处理过的日志记录发送到 Graylog2 的服务器。这样就可以利用 Graylog2 的 Web 界面来进行查询和分析。只需要把清单 9 中的 logstash 的配置文件中的 output 部分改成清单 11 中所示即可。
清单 11. 配置 logstash 输出到 Graylog2
output { gelf { host => '127.0.0.1' } }
在安装 Graylog2 时需要注意，一定要安装与 Graylog2 的版本相对应的版本的 ElasticSearch，否则会出现日志记录无法保存到 ElasticSearch 的问题。本文中使用的是 Graylog2 服务器 0.11.0 版本和 ElasticSearch 0.20.4 版本。
除了 Graylog2 之外，另外一个开源软件 Kibana 也比较流行。Kibana 可以看成是 logstash 和 ElasticSearch 的 Web 界面。Kibana 提供了更加丰富的功能来显示和分析日志记录。与代码清单中的 logstash 的配置相似，只需要把输出改为 elasticsearch 就可以了。Kibana 可以自动读取 ElasticSearch 中包含的日志记录并显示。
http://www.ibm.com/developerworks/cn/java/j-lo-practicelog/
|
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理
