日志代码 请记得输出日志，IT运维老兵看中的“日志数据”很重要

我可以是这篇文章的第一人，内容来自‘知乎’@丁伟峰

先说一个人从初级运维提升到高级运维期间实现的‘日志数据’！

现在项目里没有日志输出功能，总觉得缺少一个基本功能。特别是对于错误处理代码，没有日志输出功能，总觉得不放心。前几年主要写C/C++代码。开发过程中遇到的问题基本靠Debug。从写Ruby项目开始，我就逐渐养成了日志输出的习惯。早期的编辑器，Ruby自带的Debug功能，不是很好用。如果想发现bug，就要依靠日志输出信息来分析自己写代码的逻辑是否有问题，代码运行的定时是否有问题。最后，输出日志信息的习惯得以保留。到现在为止，不管什么项目，几乎第一个写出来的函数都是空的Log函数。

日志框架，Apache的Log4系列，很不错。在不同的语言环境下使用和配置差别不大，使用方法也很简单。这几年接触了一些PHP电商项目，还有一些其他公司做的项目，经常看到没有任何日志框架和日志输出的项目。比如，据统计，有效的代码行有几十万行，大部分来自各种插件。但是无论是核心框架部分，插件部分，甚至插件的插件代码，几乎找不到日志代码。想想就恐怖，也不知道堆了这么多代码。

一个开发IOS的朋友问我:“我想找两个PHP开发者。我应该检查他们什么？”。我想了几分钟，回答他:“检查一下对方有没有使用日志框架的习惯！”手头的这组PHP代码，在核心框架中，请有一个统一处理错误的Error函数，但是没有函数，是空函数。换句话说，项目一旦上线部署，如果出了问题，是不可能发现任何错误提示的，更别提恢复错误场景的能力了。只能说“心够大”。这样，用户和运营商将为所有系统问题买单。

日志代码贯穿整个系统，需要统一完整的设计才能发挥应有的作用。现在互联网上很多系统都是PHP做的，这些系统的主要用户都是小规模的初创企业或者传统行业对互联网的衍生品。资金不够或者不想一次性付出太多。最后因为价格问题，PHP项目成了首选。PHP项目，从CMS到电商、微信商务系统，都有一个看似强大实则非常糟糕的架构设计。那就是外挂系统。

从用户的角度来说，插件是一种增值服务。买一个有n个特效插件，一个“值”字的系统。但从技术上来说，这意味着整个系统的一部分设计是不受控制的，完全独立的。我看过很多插件，都是完全独立的小网站。所以从日志层来看，这些插件和插件的插件的日志管理也是独立的。这很尴尬。一旦出现任何运行时问题，就没有办法查错。[‘日志易’可以提供日志数据的集中收集和统一管理分析]

作为一个研发岗位，你需要有一个“我写的代码一定会出问题”的悲观想法，尽可能的留下自己代码的运行痕迹，以便出问题后迅速发现问题。一个设计良好的日志系统必须具备日志的八个关键要素，即“输出时间”、“日志类型”、“级别”、“线程ID”、“日志发生的文件名”、“行号”、“类名”、“函数名”，加上日志信息本身。可以快速定位问题。之所以建议我的朋友去调查PHP程序员日志框架的应用，是因为我看到了太多没有日志输出的PHP代码，这也是一个很好的调查点。类似于assert，可以用来判断“代码是否有接收输入前检查输入的习惯”，那么日志就是“写完代码后，你有没有想过出错了怎么办？”。换句话说。日志是编程的一种思维方式。

现在网上总有各种推广框架展示你团队的技术栈。但是很少有人讨论编程的基本功。框架再好，团队再强大。代码总是一行一行打出来的，基本功体现一种扎实的能力。代码的主要逻辑是千变万化的，但在错误处理和日志设计上有共性。不管是框架设计还是只是CRUD贴，都是一样的。写C/C++代码时，往往会有一两句函数主逻辑，但输入的判断代码和错误处理代码是主逻辑的几倍。也许是因为C/C++代码的崩溃相对于现在的Web系统来说太严重了，我们会尽量保证每一行代码的正确性。不同的语言会训练出不同的思维模式，间接反映整体设计。从我的日常来看，我个人对日志的设计已经越来越倾向于“运行时还原”。它有点类似于数据库附带的日志系统。当数据库崩溃并且无法启动时，可以通过日志文件还原数据库。这种设计的优点是，当Bug发生时，通过分析日志可以很容易地找到原因。缺点很明显，会产生大量日志，影响IO性能。有时候觉得自己太过分了，需要克制一下自己(笑)。

上周手头一个系统有异常数据，开发者也懒得来看，只是告诉我们系统日志文件的位置。找了一下，日志写的很详细，问题一下子就发现并处理掉了。一些成熟的软件和框架都有完整的日志。这些日志是开发过程中必不可少的一部分，也是发现bug的重要线索。

无论如何，关注日志，输出日志，从长远来看可以减少很多维护压力。写更多日志更容易，何乐而不为呢？

日志是企业的数据金矿。借助海量日志，通过“日志易”可以实现业务数据分析、运维故障排除、安全审计等。