作为普通开发，可能都有过这种感受，正在疯狂的coding运营 测试跑过来，有投诉，线上出问题了、有报警，线上出问题了，内心不免一惊仔细排查后发现：第三方问题，要找第三方解决、网络问题要找网络组解决、配置错误，你们运营配置有误、正常业务错误，用户输入数据有误，等等等，一方便耽误了我们coding改变世界，一方面因为我们去日志定位问题需要时间，但可能问题在我们这里并解决不了，白白延长了解决问题的时间。
不免抱怨明明日志里都有read time out了，你找网络啊、找通道方啊，他们服务挂了，明明通道返回system error这是他们的错误啊，你找我能解决吗？Flume Kafaka elasticsearch 都搞好了你们倒是用啊！！！！，但这能怪运营吗？你可能觉得system error很简单，但他们知道吗？不觉心里替运营一阵委屈。这明明是你自己挖的坑啊！写代码的时候，我们只是从自己的角度捕获了异常，记录了各种出错堆栈信息，对我们足够了，但有时候可能这错误第一手并不是我们看到的，一个稳定的产品，大多数的错误可能都来自于用户投诉后运营的反馈，这个时候，如果他们在日志平台上看到的不是system error，而是“支付网关通道下单，单号：{123231312}，通道方返回错误信息：{system error}”，完美，锅已经走远了，这个错我们不背所以日志记录不光是面向程序员，也要面向运营，面向产品，面向测试，面向一切可能查看日志的人员，要知道，我们的编码产品是面向用户的，但我们的日志是面向我们内部人员的，远远不止我们开发自己，所以在实际开发，一套合理的日志规范至关重要，玩不可玩逼格高，只是定义一堆为了方便数据分析，业务监控等而打印出只有统计代码和我们自己看得懂的日志。
一、不要丢了中文
不要认为各种英文和符号才是逼格高，但并不实用，可能代码懂、我们懂，但并不一定其他看日志的同事懂，甚至下一位继续维护代码的程序员也看不懂越是简单易懂的日志，就会有更多的同事替我们分担查日志的问题，想想都轻松的不行（奸笑）
二、要有统一明确的规范
统一的日志规范是老生常谈的问题，统一规范不但有助于后期日志的分析统计，更对我们平常查询错误结果一目了然，可能相关问题我们辅助运营查一次，解释一次，以后类似问题，他们就可以自助查询，去分析，到底应该找哪个部门，哪个同事去解决相关问题，这个规范不是以前的只考虑机器，只考虑错误堆栈分析，还要考虑除了开发和日志分析系统以外的其他同事。良好的规范要包括以下信息：打印日志的系统、打印日志的业务、业务单号、报错系统名称（自己系统报错？渠道报错？上游系统参数错误？）、错误信息，其他的如响应时长、调用参数等依据业务去做相关的打印当然还要注意敏感信息的脱敏处理。
三、简单易用的日志平台
日志写好了，如果是让运营去敲命令也太low了吧，而且互联网公司的业务日志也很多，系统调用复杂，所以必须有一个完善的日志平台，去串联起来系统间的调用日志，现在开源的ELK很方便的，开可以以此进行二次开发那就更好了