错误处理司空见惯，你认为这是理所当然的。事务处理和跟踪日志也一样——这些问题是如此明显。在简单的虚拟化云（例如，MySQL服务器）中，在软件栈的几层中你可以认为低级别的错误日志记录是理所当然的。 但是这并不意味着你可以认为日志记录的持久性是理所当然的。如果你没有正确配置虚拟机，或者你没有付费给云提供商保存这些日志，如果虚拟机宕机，日志可能被彻底摧毁。没有这些服务器端日志，你的故障处理将推迟数天，最少也要几个小时。无人监视系统中，缺少持久的日志记录成为了一个严重的问题，而且为什么你会希望长期归档日志有一些很好的取证方面的原因。所以不要吝啬记录日志。
基于云应用的情景甚至更加有趣。一些基于云的应用在服务器端根本没有任何日志记录，即使是最好的应用也只是暂时进行了全面的日志记录—关闭日志记录并没有任何明确的通知。最好的应用都经历过调试过程。但是重现几个小时前发生的出错状况....哦，如果你是幸运的，将收到一封错误堆栈跟踪的邮件。好极了！
因此，在云中(尤其是跨越云)，事实上你不能指望服务器端或服务端的错误日志记录。你猜会怎么样：如果你想知道服务器进行事务处理时究竟发生了什么，你必须自己写下服务器端错误抛出代码。通常来讲，你打算调用像Splunk，Exceptional或基于SysLog这样的集中错误日志服务，补充服务器云本地的错误日志。和不捕获错误相比，这些服务很便宜。
更进一步说，你需要制定关注请求端也就是客户端的云日志策略记录持续的错误。为什么需要开发这些错误日志代码呢？
只有在客户端你可以知道错误发生时应用级的上下文。在服务器端，所有的服务确切知道请求者的URL或IP地址，调用参数以及时间戳。当然对于每一个服务器调用，可能包括客户端线程标识符，但是为什么不在两端同时记录日志呢?
只有请求者可以记录“服务器没有响应”的错误。当然，如果服务器已经没有响应，只有请求者能够重试或者开启事务恢复策略。
请求者明确知道(或者能够确定)哪个或哪些交易，用户以及记录被错误所影响。服务器无响应时，请求者的错误处理代码可能能够执行满足应用程序需求(例如，通过把交易置于“暂停”状态)的策略。至少，它可以将应用数据置于自给(self-consistent)状态。这样服务器错误不会传播导致应用程序范围的崩溃。更进一步说，请求者可以在本地日志文件中存放尽可能多的交易上下文和历史记录以加速故障处理和恢复，如果他想这么做的话。
不幸的是，对许多开发者来说，客户端错误处理和日志记录好像是“新要求”。就像代码注释和文档。开发者重点放在满足正面情况，而不是处理不可避免的负面情况(或者甚至是“没有事情发生”的情况)。云应用开发者需要被鼓励发展更好的错误处理习惯，因为他们常常不能依赖服务器日志处理苦差事。
开发请求者或客户端错误管理时，考虑日志应该在哪儿记录是个不错的主意。在虚拟化环境中，传统的“抛出消息到文本文件中”的策略并不那么理想，因为文本文件可能在另一个虚拟机上，大约一个月后文件的位置可能很难找到。(是的，你的策略需要假定你可能不了解事后几个月进行排错或调试的需求，因此错误日志将需要支持若干级别的取证。)
在相关的记录中存储详细的错误信息怎么样呢?对于大的堆栈跟踪(想想J2EE)，可能吞噬磁盘空间。但是磁盘空间是磁盘空间，一些BLOb实际上不会将数据库拖得很慢。这个策略的问题是“涉及单一记录的第二个(可能相关的)错误发生了什么?”你的开发者足够聪明想出如何归档之前的错误—给他们提出了一个编程挑战。
错误日志的最终区域是通知。某个人应该怎样知道去查找问题?许多云开发环境没有一个强大的功能集用于提醒，这意味着或者不断的积累错误情况，或者管理员和开发者周期性的处理苦差事。无论是你想发一条信息到推特获得反馈或者打开USB 端口状态灯闪烁，恰当的实时通知是错误防范和快速恢复的第一步。
David Table是Prentice Hall出版社出版的新书“ 成功的秘诀”的作者，也是SalesLogistix的CEO。SalesLogistix是 认证的咨询公司，关注于通过使用CRM系统来改进业务流程。SalesLogistix客户遍布北美，欧洲，以色列以及印度。David在高科技领域拥有超过25年的经验，其中包括担任副总裁及以上级别10年的经验。
转播
分享
淘帖
()
