五个改善你服务器日志的技术

原文链接译文链接,译者:梁海舰,校对:方腾飞

 

 

最近我们看到各种各样新的工具,能够帮助你搞定日志。开源的项目如Scribe和LogStash,在线的工具如Splunk,托管的服务如Sumologic和PaperTrail。这些工具可以帮你减少大量日志数据。

但是有一个东西它们都无法帮到你,它们都依赖你实际放入日志中的数据。获得更多、更高质量数据的任务就落在你身上了。所以,在关键时刻你需要调试部分代码和丢失的日志数据,你可能要取消晚饭了。

为了减少以上情况发生的次数,我要给你分享5件事情,当你在生产环境使用日志的时候你必须紧记在心:

1. 你好,我(线程)的名字是

和Ringo一样,线程的名称是java中最被低估的方法之一。原因是它主要是描述性的属性。那又怎么样呢?我们让它们的名称变得有意义。

线程的名称在多线程日志记录中扮演重要角色。许多日志框架会记录当前调用日志记录的线程名称。可悲的是,它们大部分类似 “http-nio-8080-exec-3″,这个是线程池或者容器给它们取的。

出于某种原因,我不止一次听到对线程名称是不可变的误解。它们是可变的。线程名称是你日志中主要标记,你必须确保正确地使用它。这就意味着给线程取的名称必须结合上下文,例如servlet的名称或者任务此刻的意义,还有一些动态的上下文环境,例如一个用户或消息ID。

因此,代码的入口处应该像下面这样:

1 Thread.currentThread().setName(ProcessTask.class.getName() + “: “+ message.getID);

一个更高级的写法是加载一个线程本地变量到当前线程中,并且配置一个自定义日志(appender),自动把这个变量加入到每一条日志记录中。

当多线程写服务器日志时,并且你需要关注某一个线程的时候,这是非常有用的。如果你的程序是分布式/面向服务的环境,你等会看到它的另一个好处。

 2. 分布式标示

在面向服务或者消息驱动的架构中,一个任务的执行很可能要跨越多个机器。当这样的任务执行失败的时候,机器之间的连接点和它们的状态是搞明白到底发生了什么的关键。很多日志分析工具可以帮你进行日志归类,前提是你日志中带有它们可以用来做分类的唯一ID。(校对注:当A应用调用B应用接口时,而B应用的接口实现又需要调用应用C的接口时,一旦报错很难定位这个请求到底是在调用哪个应用时报错的?所以就使用一个唯一ID把这个请求链路串起来。)

从设计的角度来看,这意味着每一个操作进入到你的系统中都应该有一个唯一的ID,用这个ID直到它执行完成。注意,那些持久化标示符,例如用户的ID在这里可能不是很好的选择,因为一个用户可能有多个操作发生在同一个日志中,这会使得隔离出一个特定的操作流变得更难。UUID在这边是一个很好的选择,这个值可以被作为线程的名称或者作为一个TLS-线程本地存储。

 3. 不要在循环中记录日志

你经常会看到一小段代码运行在一个紧凑的循环中,并且执行一个日志操作。潜在的假设是这段代码运行的次数是有限的。

当一切执行顺利的话这样写是可以的。但是当这段代码获得一个意外的输入,循环可能无法跳出,在那种情况下你处理的不仅是一个无限循环(那已经够糟了),你正在处理的代码是无限地写入大量数据到磁盘中或者网络上。

任由其一直写日志,这会使得服务器宕机,在分布式环境中,一整个集群都会挂了。所以可能的话,不要在循环中记录日志。尤其是在捕获错误的时候。让我们来看一个例子,我们在一个while循环中记录异常日志:

01 void read() {
02     while (hasNext()) {
03         try {
04             readData();
05         } catch {Exception e) {
06             // this isn’t recommend
07             logger.error(“error reading data“, e);
08         }
09     }
10 }

如果readData抛异常,并且hasNext方法返回true,最终我们无限记录日志。解决它的一个方法是确保我们不记录所有东西:

01 void read() {
02     int exceptionsThrown = 0;
03     while (hasNext()) {
04         try {
05             readData();
06         } catch {Exception e) {
07             if (exceptionsThrown < THRESHOLD) {
08                 logger.error(“error reading data", e);
09                 exceptionsThrown++;
10             } else {
11                 // Now the error won’t choke the system.
12             }
13         }
14     }
15 }

另一个方式是把日志从循环中完全移除,并且保存第一个或最后一个异常对象到其他地方记录。

4. 未捕获异常处理者

维斯特洛有绝境长城作为最后防线,你有 Thread.uncaughtExceptionHandler。所以,一定要确保你有使用它们。如果你没有设置这些处理器,你有可能会把异常抛到“野外”,如果发生这样的情况,很难控制日志记录下它们来。

找出你代码中曾经出现过大量错误,并且未被记录的,或者有关它们的记录是少量非状态日志,这是一个极大的错误。

注意,即使有未捕获异常处理器,从表面上看,你不能获得任何抛出异常线程(线程已经终止)中的变量,即便你可以获得线程对象的引用。如果你坚持第一步(给线程命名),你仍然可以通过调用 thread.getName() 方法记录一个有意义的值。

5. 捕获外部调用

无论什么时候你调用一个JDK之外的API,产生异常的几率都会大大增加。包括web service,HTTP,DB,文件系统和其他JNI调用。对待每一个调用都应该认为它会产生异常(很有可能在某一个点会抛异常)。

很多情况下,外部API调用失败的原因是提供的入参是未预知的。把那些输入参数现成的记录在日志中是你修复代码的关键。

这个点上你可能会选择不记录错误日志,但是必须记录抛出的异常,这是对的。在这种情况下,只需要尽可能多的收集传递给调用的相关参数,并且把他们格式化到异常错误信息中。

只需要却表异常被捕获,并且和调用栈一起被高日志级别记录。

1 try {
2     return s3client.generatePresignedUrl(request);
3 } catch (Exception e) {
4     String err = String.format(“Error generating request: %s bucket: %s key: %s. method: %s", request, bucket, path, method);
5     log.error(err, e); //you can also throw a nested exception here with err instead.
6 }
时间: 2016-04-06

五个改善你服务器日志的技术的相关文章

一起谈.NET技术,服务器日志法网站分析的原理及优缺点

     [前言] 应朋友们的要求,我还是写一篇关于服务器日志法进行网站分析的原理以及它的优缺点是什么.请朋友们注意,网站服务器日志法并不容易进行,初学者,以及在绝大多数情况下,进行以用户行为分析为核心的网站分析,用不到服务器日志法.不过,作为网站分析历史不可分割的一部分以及重要的基础篇章,服务器日志法仍然值得一书.下面的这篇文章也是我要撰写的书中截取的内容(我要快马加鞭快快写了,已经辜负了太多朋友的重托,抱歉抱歉!).      [正文] 网站分析收集数据的方式其实有五.六种之多,我们最常见的

Web服务器日志统计分析完全解决方案_服务器

  文章相关软件: webalizer http://www.mrunix.net/webalizer/ cronolog http://www.cronolog.org/ Apache http://www.apache.org/ 一. 前言 随着Internet上Web服务的发展,几乎各个政府部门.公司.大专院校.科研院所等都在构建或正在建设自己的网站.而与此同时,在构建网站建设中各个单位都会遇到各种各样的问题,那么对web服务器的运行和访问情况进行详细和周全的分析对于了解网站运行情况,发现

服务器日志法网站分析的原理及优缺点

[前言] 应朋友们的要求,我还是写一篇关于服务器日志法进行网站分析的原理以及它的优缺点是什么.请朋友们注意,网站服务器日志法并不容易进行,初学者,以及在绝大多数情况下,进行以用户行为分析为核心的网站分析,用不到服务器日志法.不过,作为网站分析历史不可分割的一部分以及重要的基础篇章,服务器日志法仍然值得一书.下面的这篇文章也是我要撰写的书中截取的内容(我要快马加鞭快快写了,已经辜负了太多朋友的重托,抱歉抱歉!). [正文] 网站分析收集数据的方式其实有五.六种之多,我们最常见的有三种,分别是:服务

Web 服务器日志工具点评

查看记录文件是很乏味的.记录文件令人厌恶,包含了太多的信息,经常使人非常头疼.幸运的是,这些枯燥的工作有代劳者,利用一些日志分析工具,不仅可以利用日志信息进行调试而且可以提供更多的内容.利用它们可以制作出有意义的各种报告.有很多用来分析服务器日志的工具.本文将重点介绍这些工具的和它们的发展方向. 在评估这些软件包之前,先确定你希望用它们来分析的日志类型.虽然大多数日志分析软件不仅仅支持Web服务器日志,但是,本文仅讨论web服务器的日志记录.记录分析软件能够显示从连接到服务器的IP地址到以饼图表

微软Exchange Server 2007五个集成的服务器角色

Exchange Server 2007新性能传递了你企业所要求的先进保护,在任何地方找到你的机构想要找到的人,并且能够给与你所需要的操作效率. Exchange Server 2007 Beta 2可以通过下载或者订购 DVD 来获取.通过下载或者订购这个工具包,你将会自动被注册到 TechNet 测试中心,在那里,你可以找到更多帮助你对于工具包评估的资源和信息. Exchange 2007的五个集成的服务器角色: 邮箱服务器角色 经过扩展的存储角色:它需要的 I/O 吞吐量比Exchange

深入了解 Dojo 的服务器推送技术

服务器推送技术和 Bayeux 协议简介 服务器推送技术的基础思想是将浏览器主动查询信息改为服务器主动发送信息.服务器发送一批数据,浏览器显示这些数据,同时保证与服务器的连接.当服务器需要再次发送一批数据时,浏览器显示数据并保持连接.以后,服务器仍然可以发送批量数据,浏览器继续显示数据,依次类推.基于这种思想,这里我们要引出 Bayeux 协议. Bayeux 是一套基于 Publish / Subscribe 模式,以 JSON 格式在浏览器与服务器之间传输事件的通信协议.该协议规定了浏览器与

实例解析如何分析服务器日志

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 网站服务器日志分析对于一个网站具有比较重要的作用,通过分析该日志,我们可以知道搜索引擎爬行记录,这有利于我们针对搜索引擎的习惯进行交换.那么,今天我们便以SEO教程网为例,告诉大家怎么来分析网站日志吧: 1,我们到哪去找服务器日志? 一般我们使用的虚拟机都会有服务器日志,大都在logs文件夹下,如果你的空间没有,那么请联系你的空间服务商,他会

获取远程服务器日志文本

问题描述 多年不编码,别说思路了连基础语法都较劲--现因工作需要,要做一个WinForm工具来获取一组远程服务器中的多个应用站点的多个日志文本(.txt或.log),场景和要求如下:1.服务器信息.应用站点路径信息都配置在XML中来读取:2.各个应用站点中的日志文件生成周期和文件名都不同,无规律:3.设置手动选取的控件(如Datetimepicker)来设置要筛选的日志文件生成的时间范围:4.日志有两种,一种是错误日志,可直接获取:另一种是完整日志,需要判断日志文件中有没有关键字"Error&q

10方法改善虚拟服务器的存储性能

    企业级虚拟基础架构通常都会使用共享存储.这是个不争的事实,即如果你想使用VMware vSphere和Microsoft Hyper-V的高级特性,所有的主机都需要访问虚拟机(VM)的各种文件.虽然VMware VMotion和Microsoft Live Migration的最新版本并不强制要求使用共享存储,但绝大多数的特性就需要使用,比如VMware vSphere高可用性和微软故障切换集群,可能以后也会是这样. 为了使虚拟基础架构(以及你的关键应用)运行良好,其必须配置虚拟CPU.