应用系统日志打印规范实践之道.docx

上传人:p** 文档编号:1080910 上传时间:2024-06-29 格式:DOCX 页数:10 大小:19.58KB
下载 相关 举报
应用系统日志打印规范实践之道.docx_第1页
第1页 / 共10页
应用系统日志打印规范实践之道.docx_第2页
第2页 / 共10页
应用系统日志打印规范实践之道.docx_第3页
第3页 / 共10页
应用系统日志打印规范实践之道.docx_第4页
第4页 / 共10页
应用系统日志打印规范实践之道.docx_第5页
第5页 / 共10页
应用系统日志打印规范实践之道.docx_第6页
第6页 / 共10页
应用系统日志打印规范实践之道.docx_第7页
第7页 / 共10页
应用系统日志打印规范实践之道.docx_第8页
第8页 / 共10页
应用系统日志打印规范实践之道.docx_第9页
第9页 / 共10页
应用系统日志打印规范实践之道.docx_第10页
第10页 / 共10页
亲,该文档总共10页,全部预览完了,如果喜欢就下载吧!
资源描述

《应用系统日志打印规范实践之道.docx》由会员分享,可在线阅读,更多相关《应用系统日志打印规范实践之道.docx(10页珍藏版)》请在第壹文秘上搜索。

1、如果你是一名优秀的应用系统开发人员,想必应该非常清甦在应用系统运行期间.打印日志有多么重要.它不但能终记录应用系统运行情况及轨迹,还有助于提升故障排查及定位问题的效率,甚至还可以对其进行分析及监控,洞察系统隐患,提前预警防范.但并不是说只要打印尽可能多的日志,就能轻松获得这些能力.设想一下,如果你肆无忌惮地打印了一堆与无价值的日志,那请问日志又何以能够来为你提供价值呢.由此可见,这里的核心关键点并不在于日志的多少,而在于日志打印是否规范且合理.不规范合理的日志,不但无法发挥作用产生价值,还会增加故障定位难度、降低解决效率,以及额外增加日志存储成本,消耗应用系统性能.在极端情况下,甚至还会对应用

2、系统造成致命性打击,引发应用系统瘫痪的可能。讲到这,我想你应该明白我想说的一一应用系统日志打印确实非常重要,但日志打印规范将更为重要,官就像一把双刃剑,只有合理运用才能发探其特有的作用及价值.但在组织中,如果你想让你周围的人都能明白这个道理可并不容易,它需要一个漫长的传播过程,而在这个过程中,你不仅需要坚持不断地宣导来逐步增强他们的认知,还应借助必要的治理手段及工具平台进行辅助,只有利其所器,才能善其所事.利器一:规范先行在你想启动规范化日志打印前,建议先制定一份日志打印规范,它可能无法面面俱到,但没有关系,它的目的仅是为了先突显日志打印规范的重要性,并且让这件事情能够正式进入正轨.如果组织中

3、大部分都是JaVa应用,那么规范内容可以主要围绕Java应用来写,虽然无法湿盖所有开发语言,但其核心原则仍是可以借鉴的.另外,前期清务必不要将其豆杂化,否则它将无法具备普适性,也无法被接受和传播。JaVa应用系统日志打印规危Java日志框架:常用的Java日志框架可选择1.og4j1.ogback1.og4j2等,但为了避免后续更换日志框架所带来的额外改造成本,建议将接口屋和实现屋进行分寓,将S1.F4J作为接口层,将1.og4j1.OgbaCk/1.og4j2作为实现层,两者通过桥接的方式进行集成.Java日志规?S:规范一:【强制】级别只允许使用ERROR.WARN.INFO.DEBUG,

4、定义如下:级别定义ERROR表示应用系统出现异常或故障,需要预警并及时解决,否则该功第将无法正常运行并提供服务能力。WARN表示应用系统出现不符合预期的现短,但服芬并未受损,可根据实际情况选择性预警,解决时效要求不高,但需要85外关注.INFO表示用于记录系统运行过程或歪要信息点,主要为故隔定位、过程追溯、数据分析等提供辅助能力.DEBUG表示用于在测试或本地的非生产环境中使用,主要为了方便开发调试程序,而在生产环境中禁止使用。规范二:【强制】禁止使用1.ogback1.og4j2等的API,应使用S1.F4J的API.规范三:【强制】在接口/方法的入口/出口处,打印请求及响应参数日志.规范四

5、:【强制】ERROR级别日志需打印堆栈,而非ERRoR级别日志则不需要.规范五:【强制】禁止在代码循环体中直接打印非DEBUG级别的日志.规范六:【强制】禁止日志打印内容中仅打印特殊字符或数字的情况.规范七:【建议】日志内容中应包含关犍特征类信息,例如:用户标识或流水号.规范八:【建议】应采用异步打印模式,目打印时建议关闭打印位置信息.规范九:【建议】日志打印若出现堵塞,建议至少丢弃INFO级别以上的日志.规范十:【建议】每条日志在语义上可独立被理解,减少上下文关联理解.Java日志字段:中文名称英文名称打印要求备注说明组件版本version强制业务日志组件版本号系统简称SvstemName强

6、制系统名称SystemCiName强制工程名称ProjectName强制服务名称ServiceName强制数据中心dataCeter强制网络区域etwofkArea强制部署环境deployEnvromet强制逻辑集群IoqicaICIustef条件容器集群发布版本releaseVersion条件应用版本测试标识IestFIaq条件全局会话标识qlobalSessild条件前端应用监控组件染色全局跟踪标识QlobaITraceId强制后端应用监控组件染色本地跟踪标识IocaITraceId强制后端应用监控组件染色链路跟踪标识spanId强制后端应用监控组件染色父链路跟踪标识ParentSpanI

7、d条件后端应用监控组件染色主机名称hostName强制日期时间datetime强制日志级别level强制日志名称IoqqerName可选线程标识Ihreadld可选线程名称IhreadName可选日志信息message强制stack条件ERRoR级别日志时间戳timestamp强制类class可选文件file可选行号line可选位置信息.会影响性能方法method可选位置信序今静的熊.上下文ctext可选注:位置信息包括类(CIaSS,文件(file)/行号(Iine)/方法(method),若打印位置信息,则对性能有所账响.以上仅是一些规范参考,你可以根据组织中的实际情况来进行调整,但规范仅

8、仅只是规范,有了它并不代表你已达成目标,只能说明你已为日志打印规范化这件手,迈出了第一步.利器二:服务至上当制定完应用系统日志打印规范后,请不要幻想有任何人会来自觉地遵守它,一是不知它的存在,二是他们无从下手,三是大家都挺忙”的。我把它总结为六字真言,分别是不知、不会、不想.我曾见过组织中的有些规范,特别是技术规范,在制定完成后就会被长久地封存起来,没有人知道,也没有人想知道。所以,要落实好规范,你还得构思一套战术才行.否则,那些无法落实的规范就和废纸老无两样.在很多人眼里,可能会将规范视为是一种约束,而又错误地将约束理解为贬义词,从而避而远之.这种误解的发生,其原因并不出在他们本身,而更多的

9、出在那些制定规范的人身上.有些规范制定者不但没有身在其中,甚至也没有去诠释规范所能带来的价值,而仅仅只是强行推行那份冷冰冰的规危,请问此时谁会乐意在不知其所以然的情况下,无缘无故地背上这沉雨的“负担”.因此,你必须得为这份规范欲予更多的“温度”,而主动服务可能会是一种比较好的“升温”方式。但在行动前,切忌不要站在他们的对立面,并请做好放低姿态的觉悟,你要让对方深刻的意识到你和他们是同一阵营的.在发布规范后的初期,你可以尝试挑选几个日志打印情况最为槽糕的应用系统,扮演为VIP私人助理”来与对方进一步传达规范内容及作用,并为他们逐一列举出当前存在的日志打印问题,以及这些问题会对系统造成哪些影响.这

10、种方式不但能够避免仅用文字传达所产生的理解偏差,及时有效地为对方解答各种疑问,使他们能够更深一步地理解规范内容及作用,还能够让规范制定者更进一步地了解对方的顾虑及困难,并从同理心视角出发,为对方提供更好的建议及解决思路.就这样5个、10个、15个应用系统在精力有限的前提下逐步扩大辐射范围,事实证明,这种主动服务+循序渐进的方式对提升规范的接受度将会有所帮助.不过在过程中你仍然需要不断回看规苑的合理性及适用性,并对规范作出及时目有效的调整.利器三:度量为王当规范逐渐被更多的人接受后,你的使命并没有完成,而真正的考览才刚刚开始.一是接受并不代表整改,二是如何验证整改有效性,三是整改是否可持续性.如

11、果这些问题都不在你的考虑范围内,那你可能会前功尽弃.若想要解决以上这些问题,借助度18或许会是一个不错的选择.管理大帅德克曾说过:“没有度量,就没有管理”,它同样适用于规范的落实工作,你可以根据日志打印规范来制定一些度H指标,并配套研发相应的度最工具平台.通过度量工具平台可视化和自助化的两种特性,让开发人员能终及时发现日志打印规范的问题,还能够让他们自主验证日志打印规范整改后的效果,从而让他们感受到一种石得见+摸得着”的安全感.其中,度量指标的设计将会尤其重要,往往一个不合理的指标,会让整个事情朝着预想中的反方向发展.所以,在初期并不建议你设计过多的度量指标,并建议从度量难度、影响程度、达成难

12、度、可解释性四个方面进行综合性评估,以确定较为合理的指标.如下是当时初期选择的8个指标.类别指标级别ERRoR级别日志条数级别WARN级别日志条数级别ERRoR级别日志占比级别WARN级别日志占比堆栈ERRoR级别日志无堆栈条数堆栈非ERROR级别日志堆栈条数堆栈ERRoR级别日志无堆栈占比堆栈非ERRoR级别日志堆栈占比注:以上仅列出指标,指标要求建议你可根据实际情况进行动态调整,但过高的指标要求会变得亳无意义.可能会有人提出,对于规模较大且日志条数较多的应用系统,是否可放宽指标要求,这听上去好像蛮有道理的,但我却并不这么认为.规模越大意味着所承IS的职责和能力也就越大,一旦发生故障影响面也

13、就越大,所以反倒更应该达到指标要求.这些指标虽然有一定的指导性,但似乎并不能满足开发人员的-g,因为这些指标仍然无法直接褰瘟问题根源,也无法让他们可快速定位及明确优化方向.因此,你还得赋予指标一定的分析能力.例如:订单系统单日ERRoR级别日志888条(占日志总10.05%),(TOPl)90%在Com-OrderService的第88行。(TOP2)10%三COm.PayService的第188行.就这样,你可以逐步完善指标体系及配套的分析能力,但请在设计每一个指标时,遵循先进行系统现状摸排,再进行小范围试点运行,最后进行持续观测并调优,从而确保每一个指标的设计都具备一定的合理性和可解释性.

14、如下列出了一些指标,仅供参考.指标分类指标(不达标说明)冗余单笔事务日志中出现更复日志(亚合度=IO0%且1条)冗余单笔事务日志中出现相似日志(生合度80%且5条)冗余单日日志中出现生且日志(至合度=100%且占息量1%)语义单条日志中出现特殊符号(特殊符号占比100%)语义单条日志中出现特殊符号+数字(特殊符号+数字占比80%)语义单条日志中出现无法识别单词(无法识别单词占比80%)质H单日日志中ERRoR级别条数(10000或占总量0.1%)质量单日日志中WARN级别条数(50000或占总量0.5%)质量单日日志中ERRoR级别无堆找条数(10000或占总量01%)质单日日志中非ERROR级别堆栈条数(oooo或占总it。/)质量单日日志中ERROR级别条数突增(突增次数3次)除此之外,你还可以将不同应用系统的指标进行横向对比,并采用排行榜的形式在科技内部进行公开,它将会产生一种改变行为的驱动力,可以有效激发”想要赢和不想失败”的心理活动,这就好比某些产品也会采用排行榜的方式来激励用户一样.通过设计指标体系+研发度量平台+公开排行榜单这三个手段的组合,在一定程度上可以驱动开发人员持续性整改日志打印的问题.但万事无绝对,那些始终无动于衷的人依然会存在,不过请不要强行要求对方,毕竟有时候存在即合理.写在最后日志打印规范固然

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 微积分

copyright@ 2008-2023 1wenmi网站版权所有

经营许可证编号:宁ICP备2022001189号-1

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。第壹文秘仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知第壹文秘网,我们立即给予删除!