茂名手机网站建设公司名录,合肥seo网络营销推广,wordpress友链首页显示,网上做效果图尽管在写这篇博文的时候#xff0c;我是在负责运维工作#xff0c;不过本文主要是写给开发者的。 对我来说#xff0c;明白如何记录日志和记录什么#xff0c;是软件工程师必须明了的最艰巨的任务之一。之所以这么说#xff0c;是因为这项任务与预测#xff08;divinatio… 尽管在写这篇博文的时候我是在负责运维工作不过本文主要是写给开发者的。 对我来说明白如何记录日志和记录什么是软件工程师必须明了的最艰巨的任务之一。之所以这么说是因为这项任务与预测divination类似你不知道当你要调试的时候需要些什么信息……我希望这10个建议能帮助你更好地在应用程序中记录日志让运维工程师们受益。:) 1. 你不应自己写log 绝对不要即便是用printf或者是自己写入到log文件又或自己处理logrotate。请给你的运维同志们省省心调用标准库或者系统API来完成它。 这样你可以保证程序的运行与其他系统组件好好相处把log写到正确的位置或者网络服务上而不需要专门的系统配置。 假如你要使用系统API也就是syslog(3)学习好怎么用它。 如果你更喜欢用logging库在Java里面你有很多选择例如Log4jJCLslf4j和logback。我最喜欢用slf4j和logback的组合因为它们特别给力而且相对地容易配置(还允许使用JMX进行配置或者重载配置文件)。 slf4j最好的是你可以修改logging控制台的位置。如果你在编写一个库这会变得非常重要因为这可以让库的使用者使用自己的logging控制台而不需要修改你的库。 其他语言当然也有多种logging库例如ruby的Log4rstdlib logger和几近完美的Jordan Sissel’s Ruby-cabin。 如果你想纠结CPU占用问题那么你不用看这篇文章了。还有不要把log语句放在紧内部循环体内否则你永远看不出区别来。 2. 你应在适当级别上进行log 如果你遵循了上述第一点的做法接下来你要对你程序中每一个log语句使用不同的log级别。其中最困难的一个任务是找出这个log应该是什么级别 以下是我的一些建议: TRACE level: 如果使用在生产环境中这是一个代码异味(code smell)。它可以用于开发过程中追踪bug但不要提交到你的版本控制系统DEBUG level: 把一切东西都记录在这里。这在debug过程中最常用到。我主张在进入生产阶段前减少debug语句的数量只留下最有意义的部分在调试(troubleshooting)的时候激活。INFO level: 把用户行为(user-driven)和系统的特定行为(例如计划任务…)NOTICE level: 这是生产环境中使用的级别。把一切不认为是错误的可以记录的事件都log起来WARN level: 记录在这个级别的事件都有可能成为一个error。例如一次调用数据库使用的时间超过了预设时间或者内存缓存即将到达容量上限。这可以让你适当地发出警报或者在调试时更好地理解系统在failure之前做了些什么ERROR level: 把每一个错误条件都记录在这。例如API调用返回了错误或是内部错误条件FATAL level: 末日来了。它极少被用到在实际程序中也不应该出现多少。在这个级别上进行log意味着程序要结束了。例如一个网络守护进程无法bind到socket上那么它唯一能做的就只有log到这里然后退出运行。 记住在你的程序中默认的运行级别是高度可变的。例如我通常用INFO运行我的服务端代码但是我的桌面程序用的是DEBUG。这是因为你很难在一台你没有接入权限的机器上进行调试但你在做用户服务时比起教他们怎么修改log level再把生成的log发给你我的做法可以让你轻松得多。当然你可以有其他的做法:) 3. honor the log category 我在第一点中提到的大部分logging库允许指定一个logging类别。它可以分类log信息并基于logging框架的配置在最后以某一形式进行log或是不进行。 通常Java开发者在log语句处使用完整合格的类名作为类别名。如果你的程序遵循单一职责原则(Single responsibility principle原文有误)这种模式还不错。 在Java的logging库中Log类别是按等级划分的例如在com.daysofwonder.ranking.ELORankingComputation会匹配到顶级的com.daysofwonder.ranking。这可以让运营工程师配置一个对此类别下指定的所有ranking子系统作用的logging。如果需要的话还可以同时生成子类别的logging配置。 拓展开来我们讲解一下特定情况下的调试。假设你在做一个应答用户请求的服务端软件(如REST API)。它正在对my.service.api.apitoken进行log(其中apitoken用于识别用户)。那么你可以选择对my.service.api类别进行log记录所有的api或是对某违规API用户的my.service.api.bad-user-api-token进行log。当然这需要系统允许你在运行中修改logging配置。 4. 你应该写有意义的log 这可能是最重要的建议了。没有什么比你深刻理解程序内部却写出含糊的log更糟了。 在你写日志信息之前总要提醒自己有突发事件的时候你唯一拥有的只有来自log文件你必须从中明白发生了什么。这可能就是被开除和升职之间的微妙的差距。 当开发者写log的时候它(log语句)是直接写在代码环境中的在各种条件中我们应该写入基于当前环境的信息。不幸的是在log文件中并没有这些环境这可能导致这些信息无法被理解。 解决这个情况(在写warn和error level时尤为重要)的一个方法是添加辅助信息到log信息中如果做不到那么改为把这个操作的作用写下。 还有不要让一个log信息的内容基于上一个。这是因为前面的信息可能由于(与当前信息)处于不同的类别或者level而没被写入。更坏的情况是它因多线程或异步操作在另一个地方(或是以另一方式)出现。 5. 日志信息应该用英语 这个建议可能有点奇怪尤其是对法国佬(French guy)来说。我还是认为英语远比法语更简炼更适应技术语言。如果一个信息里面包含超过50%的英语单词你有什么理由去用法语写log呢 把英法之争丢一边下面是这个建议背后的原因 英语意味着你的log是用ASCII编码的。这非常重要因为你不会真正知道log信息会发生什么或是它被归档前经过何种软件层和介质。如果你的信息里面使用了特殊字符集乃至UTF-8它可能并不会被正确地显示(render)更糟的是它可能在传输过程中被损坏变得不可读。不过这还有个问题log用户输入时可能有各种字符集或者编码。如果你的程序被大多数人使用而你又没有足够的资源做国际化英语会成为你的不二之选。如果你有国际化那么让界面与终端用户更亲近(closer)(这通常不会是你的log)如果你国际化了你的log(例如所有的warning和error level信息)给他们一个特定的有意义的错误码。这样用户做与语言无关的搜索找到相关信息。这种良好的模式已经在虚拟内存(VMS)操作系统中应用了很久而我必须承认它非常有用。如果你曾经设计过这种模式你还可以试试这种模式: APP-S-CODE 或者 APP-S-SUB-CODE它们分别代表:APP: 应用程序的3字缩写S: 严重程度的1字缩写(例如D代表debugI代表info)SUB: 这个code所从属的应用程序的子部分CODE: 一个数字代号指定这个问题中的错误 6. 你应该给log带上上下文 没有什么比这样的log信息更糟的了 相关文章: 免费开源分布式系统日志收集框架 Exceptionless使用 Exceptionless 作为 Log Server 搭配 NLog 记录系统日志使用Elasticsearch 与 NEST 库 构建 .NET 企业级搜索为elasticsearch集成一些实用 插件以及配置的开箱即用的版本 原文地址http://blog.jobbole.com/52018/ .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
