作者 | bugpool
项目监控
项目能跑就行！管他什么项目监控，项目问题通通等用户反馈，挂了就重启！SQL慢用户就等着，我怎么知道哪里执行慢？项目访问不了就是用户网络问题！用户遇到问题就是一清缓存、二换浏览器、三重启大法好！你怕是没经过社会的毒打，KPI分分钟垫底，再过2个月就可以实现家里蹲的愿望了。
这里拿alibaba的druid做个例子，druid可以监控以下几个部分：
- 数据源：显示当前项目下所有数据源，多数据源的项目才会用到。当然了，肯定不会显示密码。
- SQL监控：监控所有执行的SQL语句，包括耗时，参数等等。
- SQL防火墙：druid提供了黑白名单的访问，可以清楚的看到SQL防护情况。
- Web应用：可以看到目前运行的Web程序的并发数，事务书等等详细信息。
- URI监控：可以监控到所有的请求路径的请求次数、请求时间等参数。
- Session监控：监控session状况，创建时间、最后活跃时间、请求次数、请求时间等参数。
集成完druid，项目马上提高一个档次，可以在boss面前打开页面吹嘘一把。最最关键的是，集成druid是分分钟的事情，几乎没有代码的侵入性，要改造也只需添加个bean，改下配置文件。详细可参考springboot集成druid，绝对是排查慢SQL、优化性能、监控项目居家必备良药！
日志
日志记录操作轨迹、监控系统运行状态、回溯系统故障，保留系统故障现场，方便程序员快定位问题。生产环境不同于学生项目，随时有问题就重启debug，在公司里，开发人员你碰服务器的资格都没有，所以保留日志成了排查Bug唯一的方法。这里就谈谈容易被忽视的几点：
- 等级：DEBUG
- 定期巡检：初级项目往往是用户反馈了故障才进行问题排查。而标准的项目应该定期巡检error日志，因为②中已经做好的分类，error一定是需要人为介入的，将这些error日志逐条排查便可以提前发现项目潜在风险。
- 日志完整性：初学者往往会打出log.error(e.getMessage)或log.error("错误信息：" + e)的日志，这种写法将吃掉所有的堆栈信息！这是非常非常严重的事情，正确的写法应该是logger.error("第x部分出错 " + e)。
- 日志配置：初学者往往并不关心日志文件存放在哪里，日志文件保留多久，日志文件按等级生成等配置细节，而作为一名架构师，你需要充分评估项目的需求，对这些进行自定义的配置。笔者也曾因为不关心这些配置，导致日志爆满撑死服务器！
- 日志框架分为日志门面、日志实现库、日志适配器三类。JCL、SLF4j、Jboss-logging这些框架都是日志门面；而真实干活的人则是日志实现库，常见的Log4j、Log4j2、Logback、JUL；当门面与实现库不匹配时则需要日志适配器。当然现在百分之90的项目使用的都是slf4j + logback，可以不太关心日志框架的选型。但是如果你立志成为一名架构师，那框架的选型就是一门必修课，还是得去了解。
状态码
对比一下上图有什么区别？很简单，就是多了个状态码。有没有这个状态码似乎对前端请求的数据也没什么影响，不加状态码前端还是可以正常显示。确实，在核心数据上是不会有任何影响的，但是一旦出现一些业务异常，返回的数据就会如下图所示：
{
"timestamp": "2020-04-25T03:55:26.179+0000