记得上次说到的 #1 中提到，需要搭建 ELK 来实现数据需求，其实还有另一个需求：日志系统。

联系到最近一直在看的 docker，我就直接用它来部署了，申请了台 8 核 16G 机器，CentOS7，其实 ELK 还是得深入看看，毕竟 docker 只是用来部署，而不是帮你解决日志系统的问题。

最近的一直进行的工作包括提升 mongo 的性能，在我接手的这段时间里，在 newrelic 上的平均响应时长是 200-300ms，遇到任务堵塞还会暴涨到 600ms 左右一小段时间。

第一次

尝试是升级 mongoose@4.4.9，效果是很明显的，响应时长立马降下来了，平均响应时长 100ms 左右。但，我们观察到 mongo 的连接数直接升了一倍，app 进程在阶段性重启，大约是 20 分钟一次，因为我们用 pm2 的时候，设置了最大内存，一旦超过就自动重启，于是我们放弃了。

部署 deploy

由于我们线上项目全部部署在高配主机上，使用的是 pm2 部署，于是当我刚接手的时候，十几台主机全部用 pm2 部署的意义不知你是否明白，每台部署至少 1 分钟，然后串行部署，于是开始部署之后，可以很悠闲地去喝杯茶了

一般来说，我们的项目都是放在反向代理后面的，比如 nginx，haproxy 之类的，这时候就会有个问题，你获取的 IP 地址可能一直是前面代理的 IP，而不是用户端的 IP，于是这时候 express 就需要设置下 trust proxy 了

默认是 false，也就是不信任任何代理，比如你所在的私有网络是 10.0.0.0/8，那么直接设置：

话说在我接手公司的项目后花时间去优化 API 性能的时候，在 newrelic 上面看到，大部分都是 mongo 的时间，因此很有必要花大时间去优化。

我们用的是 mongoose@3.8.23，然后修正了其中的复制集排序选择问题（3.8.39 已经修正了，目前我正在比较测试，包括目前最新的 4.4.x），先把项目的连接配置贴出来：

不知道大家如何应对运营以及营销同事的『临时』数据需求，在公司早期的时候，没有专门的 BI 工程师，其他工程师不够，开发任务紧。于是一次两次还好，多了之后，工程师会很烦，美女妹子的话，写个脚本导出个 excel，其他随便给导出个 CSV 文件，然后没准同事用的是 Windows，用 Excel 打开直接是乱码 :joy: