转塘有做网站的吗,建设个网站从哪里盈利,wordpress标题收起,盐城专业网站建设哪家好【编者按】本文作者是 Archanaa Panda #xff0c;从 2000 以来一直在软件开发#xff08;构架、设计和编程#xff09;团队担任 Java / JavaEE 构架师#xff0c;目前立志于做一个与时俱进的独立的顾问架构师。在本篇文章中#xff0c;作者通过多个方面为生产环节的日志提… 【编者按】本文作者是 Archanaa Panda 从 2000 以来一直在软件开发构架、设计和编程团队担任 Java / JavaEE 构架师目前立志于做一个与时俱进的独立的顾问架构师。在本篇文章中作者通过多个方面为生产环节的日志提供建议和指导最后还介绍了一个高性能的智能日志技术帮助大家构建高性能的智能日志框架。 1.摘要 当应用在生产过程中日志通常处于开发周期的次要位置但实际上高性能的日志可能成为开发团队的重要生命线。在此我们假设读者已熟悉了各种日志框架如 Log4j 、 SLF4J 等所以不再详细介绍本文旨在为「真实」的生产日志提供指南检测其对应用质量的影响同时还为大家介绍了一个被遗忘已久的高性能的智能日志技术。 2.介绍 在为应用搭建架构、设计、开发甚至是提升性能的整个环节中大家都常常忽略日志的重要性。最后当应用程序一切准备就绪打算部署的时候会发生什么呢 糟糕应用程序已经脱离你的开发环境它无法运行出你想要的 IDE 平台而且没有对应的调试器可用此时你才想起来日志的重要性似乎为时已晚。然后当你费劲地想从一大堆日志中尝试调试出应用哪里出了问题才发现这个任务不仅仅是艰巨而且极其无聊、繁琐还会浪费大量的时间。根据你多年的经验和专业知识来看这样的做法毫无疑问是大海捞针再或者你把这个任务分配给下属或运维团队而这样一份繁琐无比费力不讨好的工作搁谁身上都会招致抱怨甚至他们也无功而返集体抱怨你的失策你只有让专业架构师和设计师参与进来。 所以日志应该是生产应用的重要生命线谁都不应该掉以轻心。当然众所周知可以根据需求开启或关闭各种日志的记录级别市面上知道有多种日志类别和日志框架如 Log4j 、 Commons Logging 或是 SLF4J 我们可以直接将日志发到不同目的地如文件、数据库、 JMS 队列等。 但是我们中有多少人会真正地计划日志呢又有多少人理解日志是如何影响系统质量的呢谁又会不断地去优化日志时刻记得一旦应用上线日志会对系统和工作生活产生哪些影响还有多少人已经尝试过利用日志框架的先进功能来提升日志性能呢 本文主要想唤醒大家对应用日志的重视同时为部署应用日志提供基本指导。最后本文会介绍一个被遗忘已久的日志技术在不影响应用性能和质量的前提下帮助大家实现高质量的日志记录。 3.记录其他系统质量属性 3.1.1监控 日志记录是最常见的质量监控方式它可以帮助应用开发者探究到问题的根源。但这些往往只通过监控来实现对于开发者来说在代码的各个地方编写一个 System.out.println() 或 logger.log() 语句再简单不过。然而问题在于大量的日志可能会导致有用的事件日志被忽略掉这样完全达不到日志记录的目的。所以开发者可能会寻找其他系统监控技术如使用或开发 JMX 控制台。这一点会在后面的 「为待生产的应用进行日志记录」章节中详细讨论。 3.1.2 性能 不管咨询哪位性能专家或架构师对于 90% 的应用来说过多的日志记录都会对性能产生非常不利的影响。日志是一种 I/O 密集型活动的确会对应用性能产生不良影响特别是传统的日志方式还会写入应用线程环境的 FileAppender 中。不仅如此日志代码还会造成大量的堆消耗和垃圾收集比如 if (logger.isDebugEnabled())logger.debug(name person.name age person.age address person.address); 除此之外内部调用日志到 Log4J Appender 的 doappend() 方法会与线程安全同步。这也意味着应用线程不仅在同步地进行大量的磁盘 I/O 操作还会在写入日志时互相阻塞在某电子政务门户网站上最严峻的性能情形之一就是线程转储显示在日志记录写入到单个文件 appender 时应用日志也被写入到这个的 appender 文件集中 事实上性能专家首先会确定应用的当前日志级别然后通常只是把日志级别从 DEBUG 切换 INFO 或 WARNING 模式来达到提升应用性能的目的。但是在完成性能基准测试工作或即时可伸缩问题之后应用开发者在寻找应用功能性 bug 的根本原因时又会将日志级别改回到 DEBUG 模式。事实上这并不是一个科学的日志操作。在「为待生产的应用进行日志记录」中我们还会进一步讨论日志规范和卫生维护。「高性能质量的日志记录」中也会详细阐述在不影响应用性能的前提下能够实现质量记录的相关技术。 3.1.3安全性审核和其他敏感信息 审核日志是一类特殊的日志主要用于应用的安全审核和跟踪用户操作。以下示例主要介绍了日志在安全性方面的帮助。 但是如果走向另一个极端日志中携带的敏感信息如用户的帐户密码可能会暴露系统漏洞。 第三记录应用程序的事件和流程可能有助于开发者监控和调试但同时可能会无意地暴露应用的内部架构。 在当前的云应用环境中应用可以在公共云上托管这样的漏洞会对应用所有者的知识产权构成威胁。 3.1.4可扩展性和高可用性 日志记录会和扩展性、高可用性之间互相影响。利用「高性能质量的日志」技术来提高应用性能用更少的硬件提高扩展性和可用性在现有的资源和条件下你的应用完全可以「重拳出击」。 当应用被扩展成能够对可用性进行主动或被动配置时就会有多个应用实例而日志策略就显得非常重要。应用是否能支持或者开发团队是愿意收集来自10个不同机器或目录的日志还是找一个位置能集中收集日志呢此时集中的分布式日志变得至关重要。 3.1.5可恢复性 像如 Oracle 这样的重要数据库已经使用 Redo 日志来确保事务恢复。应用也可以参考这种做法使用一类特殊的日志帮助恢复以防万一。 3.1.6错误处理和容错 在大多数应用中日志只是其中一种错误处理方式有时只用来评估错误。在复发性错误如短信/邮件服务器或数据库长期不可用的情况下重复地、频繁地记录错误是百害而无一利特别在大量的异常堆栈跟踪下只会大大地增加 I/O 活动。在这个过程中当你要分析一个星期前被忽略的老问题时这时候关于这个问题的日志早已滚动更新这种方法只会「火上浇油」。 3.1.7容量 在考虑应用的容量问题时架构师会参考生产环节的日志大小再估计所需的磁盘空间、集中文件系统的配置等。 对于分布式环境中的集中式日志也需要估计分布在网络到远程机器的日志对象的大小。 4.缺少重要日志的案例分析 本节主要介绍作者对嵌入式应用案例的研究经验如果在架构、设计和开发阶段忽略了日志记录的重要性问题一旦发生之前所做的一切可能功亏一篑只得在惨痛的教训面前学着「吃一堑长一智」。 举一个大家都熟悉的场景 GPS 设备就是一个嵌入式应用装载在车中可以进行位置跟踪。该设备不提供任何用户界面除了 LEDs 和几个按钮所以几乎没有人来管理车辆内部的应用程序不像豪华车型那样会和服务器端应用进行交互。因此如果设备应用出现了问题应用开发者应该如何诊断问题根源呢随着各种卡车被运往全国各地日志又是何时写入车内设备的呢 应用开发者可能会异想天开全国各地都配备了服务工程师能够取下设备带回去进一步分析。以上设想纯属虚构实际上开发者只会和服务工程师登入设备的操作系统去复制日志。但面对繁杂的日志连续的加班作战只会让人身心疲惫 为了更方便地完成这项工作应用开发者在设备的桌面服务应用中加上「日志下载」按钮。服务工程师就可以直接利用笔记本里的服务应用下载相关的设备日志。这至少是一个进步至少不必再让车停下来再取走设备了也给了本该陪同服务工程师夜以继日下载日志的可怜开发者们一丝喘息的空间。显然服务工程师也不至于全世界乱跑了他们只要盯着应用开发团队注意下载日志即可。 最后开发团队不得不提高设备应用的性能让它像发送其他跟踪数据一样直接通过无线 GPRS 就可以发送日志到后端服务器。 需要注意是在初始的预估和开发过程中所有这些额外工作都没有被计入需求池或预算中。开发团队已经有一个典型的由客户功能需求驱动的思维定势。应用日志既不是一个客户驱动的需求也并非是突出的非功能属性。所以新手开发者通常缺乏远见也无力说服高层或管理者给他们足够的时间预算来建立这样的设施。当这些设备准备上市时他们遇到了这样的问题经理和客户气得脸红脖子粗而他们不得不挑灯夜战。真是一个费力不讨好的活儿 5. 为待生产的应用进行日志记录 and donts in this section, which would make an application production ready. 在上一节「记录其他系统质量属性」中我们已经遇到了一些在生产环境中不得不面临的问题。接下来在本节中我们再罗列出哪些该做和哪些不该做为应用的待生产状态做准备。 - 日志规范和代码审查 日志规范极其重要因为这一步将为本文讨论的其他最佳实践铺平道路。事实上许多生产系统还会有那些无聊的日志如 「 Hi 」 、 「 Came over here 」、「 Done 」、「 xxxyyyyzzzz 」。这些日志通常会在应用调试阶段或开发阶段的单元测试中产生。 但生产阶段还有人仍然采用这样的无聊日志其给出的理由是它们只会在调试时产生而且便于关闭。但是在实践中开发者很少这样做关闭的同时也关掉了一些有价值的日志。为了更好地控制日志需要开发者非常精细地配置日志框架但在生产中却常常忽略这一点 同时代码审查必须提高效率。当高级开发者或团队领导审查日志时必须确保删除掉无用的日志即使要面对一些挑衅的言论比如有人说「我已经在测试时删过日志了」「不就是个日志么它又不是引发问题的原因」。但这是一个很好的规则日志并不是开发过程中用来调试问题的方式负责调试的是我们 IDE 的调试器 - 当你对应用进行模块化时也需要关注集中式日志 应用日志写入应用服务器的 SystemOut 或 SystemError 文件显示不是最高效的办法但在生产环境中仍然常见或如前所述电子政务门户的线程互相阻塞共同争夺一个 FileAppender 或者一个文件 I/O 。 最起码开发者应该将有基于软件包或完全限定类为已有的记录器命名约定并可能将不同的日志分类记录到不同的 Appender 位置。 在生产过程中应该牢记日志级别应该是 WARNING 或根据日志信息设为 INFO 级别。 一个有效的方法是在中央配置或常量类中列举出所有可能的日志并只允许开发者使用这些日志。我们将在「设计高性能的智能日志」章节中进行讨论。 - 在集群环境和分布式环境中记录日志 几乎所有的服务器端应用都必须采用集群和分布式环境因为这两种技术可以提供可扩展性和可用性。在集群环境中日志应该反映出组件、模块、子系统以及其过程实例。 在分布式和集群的环境采用集中的日志服务器可以避免从多个目录和机器上收集日志的繁琐。同时对于移动 I/O 到一个单独的机器上也更加方便而应用性能可以不再受日志 I/O 的影响。 - 在厚分布式客户端或嵌入式应用中进行日志记录 在「缺少重要日志的案例分析」章节中的趣闻中也提道在厚客户端或嵌入式应用的日志几乎不会发送给到开发团队也无从帮助他们进行问题分析。远程传输日志的机制需要再深思熟虑再适当地列入项目计划进行开发。 - 使用映射诊断环境和嵌套诊断环境 Log4j 的映射诊断环境 MDC 和嵌套诊断环境 NDC 使用 ThreadLocal 储存环境特定信息。它们可以存储如用户名、事务 ID 这样的信息来识别特定用户或事务所做的全部操作。这就不需要为了日志记录在类和方法中传递特定环境信息。利用 PatternLayout 的 %X 或 X { key } 存储的值将在日志中呈现。 - 规划日志的生命周期和维护 这包括规划日志滚动更新之前的日志文件大小和最大数量。为什么需要规划呢因为日志文件常常大到用文本编辑器都打不开正如脚本会定期对数据库进行备份一样也应该有脚本来备份和归档日志。当超出磁盘空间限制时压缩日志文件也是不错的想法这样远程传输起来会更加容易。 - 抵制实时记录源位置信息的诱惑 获取位置信息常常以昂贵的性能损失为代价因为日志框架试图确定当前的线程堆栈从而获得该方法、文件名和行数。确切地说日志信息本身就可以通过提供服务器、子系统、模块、组件、线程等信息找出日志的来源。 - 避免重复使用长堆栈跟踪来记录错误 如果可能的话日志中应该有足够的信息显示错误发生的位置并尽可能避免巨大的堆栈跟踪。当然这不是一个像 NullPointerException 那样的特例。但它可以为一些容易识别的特定应用错误进行记录。此外当经常性问题长期发生时如与 Email 、短信或数据库服务器的连接问题日志记录也会每隔5分钟地记录该问题而不是每隔几秒就用巨大的堆栈跟踪填充日志。 - 不要盲目使用 AOP 注入记录尤其在生产过程中 对于新手来说最基本的 AOP 教材案例就是日志。因为日志本身就是一个横切关注点新手可以在进入方法之前或退出方法之后注入日志。在应用于生产有价值的应用之前应该严肃地考虑这个示例或观点。对于以上已经建立的示例日志记录可不是一件小事它值得像大多数其他非功能性需求 NFRs 一样进行详细布局规划。 - 别把日志当作其他监控手段的替代品 最滑稽地使用日志记录的典型案例之一就是「性能日志」如下所示 19 Sept 2010 10:20:30 PERF INFO Thread-25 OrderInsertAction.java Time taken in processing OrderInsertAction: 50ms19 Sept 2010 10:20:33 PERF INFO Thread-8 OrderInsertDao.java Time taken in insert 30ms 笔者就曾犯过这样的问题却没意识到它增加 I/O 对性能产生的严重危害。 更明智的做法是捕获 「 TimeStatistic 」 的总时间并用计数器算出用 GUI 屏幕显示同样内容的平均时间、最长时间、最短时间。 6.设计高性能的智能日志 在这一节中主要讨论的策略是将集中式日志包装成记录器日志采用整数编码而不是字符串。这项技术已经由作者在导师的建议下成功地实现。 目前在网上有许多文章都介绍如何用 JMS 队列和主题或 sockets 来构建集中式日志记录。集中式日志记录能够通过移动 I/O 活动到不同的机器上进一步提高性能虽然会对程序节点有轻微的开销。 但是这里的关键是结合代码来记录集中式日志而非冗长的字符串。现有框架 Log4J 或者 Commons Logging 鼓励使用字符串来记录信息这样的作法会对内存、磁盘和网络资源造成一定影响而这些工作完全可以通过一段简单的代码搞定。 一个单独的文件可以列出错误代码和可识别字符串之间的映射。 如以下日志记录 [090822 16:02:48] TX WARNING (Tx-2-thread-1: 1163 transmitData): Server has not responded with an ACK, so trying again. 与下面的日志进行对比 1300604499194,4,192168001002,20600,1001,2,500000 以上日志显示了长时间戳、日志级别、生成日志的机器IP地址、处理的整数值、处理模块、应用的实例ID和一个完整的错误代码代码翻译过来也会传达相同的含义。这种对象非常便于在网络中以二进制格式进行传输。如果有上下文信息能进一步限定日志中的信息一个 Object[] 数组也可以被传递而主错误代码将转化成为带有 printf() 格式占位符的字符串。 使用短码表示错误的做法几乎在所有的主流产品中都很常见如 Oracle 、 WebSphere 、 Microsoft 。例如在微软的 Office 应用出现错误时所反馈的错误对话框就是一个难以读懂的整数代码然后会发送给微软用于诊断。 在查看错误时可以将各种错误代码翻译成完整的字符串进一步解读。 这样做的好处有如下几点 能节省磁盘空间从而延长日志的保质期和缩减文件大小应用内部设计和执行的一些安全措施不会被日志暴露。但在脱机查看时日志可以通过使用翻译机来翻译全文。避免构造或传输长字符串进一步减少内存使用。网络传输中日志是非常轻量的所以在调试日志时也尽可能保持最小开销。防止日志随机构造通过自定制工具更高效地搜索特定错误此外通过防止直接使用 Log4J 或其他类似的框架可以执行日志记录或者在你最喜欢的日志框架上或自定制日志上编写一个定制格式比如 public class LogClientFacade {public void log(int logLevel, int instanceId, int subsystemId, int componentId, int errorCode);public void logWithContext(int logLevel, int instanceId, int subsystemId, int componentId, int errorCode, Object[] contextInfo);public void logWithEx(int logLevel, int instanceId, int subsystemId, int componentId, int errorCode, Throwable ex);...} 这样的日志接口能确保开发者注意到在分布式环境下诊断日志的基本信息比如子系统、部件或其他不必在在实时操作中记录源代码的行号和文件名。 上图显示了一种解决方案的建议设计。其目的是通过在队列和异步处理中收集信息或在接收器线程中进行转移尽量确保日志的处理过程不存在阻塞。这种方式在网络传输过程中以二进制序列化格式进行信息传输具有诸多优势特别是完整的解决方案是同步地使用同一语言时。 当他们倒进服务器查看离线日志时应该有一个简单的图形用户界面来观看日志。然后用一个翻译机将日志转换为文本格式而日志本身也会以二进制格式写入磁盘。需要注意的是这种方法能和云环境很好地关联从而确保部署的知识产权的保密性。 6.1A 注意实施 扩展现有框架也是一种好方法如 Log4J 、 Commons Logging 、 SLF4J 。但是这样做的话为了遵循框架内部API的通用性可能会牺牲一部分效率。例如 Log4J 会序列化日志消息而堆栈跟踪会作为字符串在 SocketAppender 和 JMSAppender 中进行网络传递。该框架相当易于扩展而且能覆盖所选择框架的特定部分如通过添加或扩展新的 Appenders 扩展内部的数据传输对象如 LoggingEvent 并进行自定义序列化。再者如果需要最大的灵活性你可以仅用较短的时间来创建一个简单的自定义日志框架。 另一个有趣的决定是在应用运行在服务器时是否使用 JMS 或者通过使用一个独立队列如 WebSphereMQ 、HornetQ 或 ActiveMQ 。如果选择 JMS 以下是作者的几点建议 使用宽松质量属性来避免增加事务、持续性并允许队列重复。记住严格可靠性会降低性能对日志而言这是不必要的。在一个 JVM 中要么是在日志服务器或在客户子系统最好是使用轻量的 java.util.concurrent 队列或 in-VM 队列实现从而避免系列化开销。建议使用消息代理或运输桥梁而不是用一个集中式队列并做相同的远程调用。本人的个人偏好是使用简单的 socket。 7.总结 在这篇文章中我们已经讨论了最佳实践和日志记录中所发现的弊端。我们还提出了一种结合集中式日志和代码的技术从而取代字符串实现高性能的智能日志实践。 作者将构思高性能智能日志的设计归功于她的导师 Akash Gupt 先生是 InterGlobe 科技公司的解决方案架构师 http://in.linkedin.com/pub/akash-gupta/3/79/2b3 在他的指导下作者成功地实施并观察到这种技术的巨大性能优势。 8References 8.引用 Pro Apache Log4J by Samudra Gupta Log4J Source code (编译自https://dzone.com/articles/high-performance-and-smarter) OneAPM 为您提供端到端的 Java 应用性能解决方案我们支持所有常见的 Java 框架及应用服务器助您快速发现系统瓶颈定位异常根本原因。分钟级部署即刻体验Java 监控从来没有如此简单。想技术文章请访问 OneAPM 官方技术博客。 本文转自 OneAPM 官方博客 转载于:https://www.cnblogs.com/oneapm/p/5306895.html
