关于生产环境日志收集

xizhibei commented 8 years ago

日志收集的重要性不言而喻，总结下在日志方面做的一些尝试：

日志收集的选型

目前nodejs比较流行的工具有winston，log4js，还有bunyan，也是我用过比较多的，总体看来的话，winston功能丰富，log4js老牌有保障，bunyan比较轻量级，我最后选择了bunyan是因为看中它的轻量级，怎么说呢，winston太复杂了以至于影响到了我们系统的性能，具体可以看看这个：A Benchmark of Five Node.js Logging Libraries。

收集工具

当然是ELK，有条件的话最好搭一个集群，还有SSD的机器。这个成本呢，可以这么来跟你老板说：『养兵千日用兵一时』，有些致命的线上错误，只能用这个日志来发现与调试，同时呢，方便我们开发与运维，对提高系统性能，提早发现问题有很大的帮助。

日志传输方式

首选UDP，传输快，不占用应用机器的磁盘，缺点么，丢数据，UDP么； TCP的话，如果日志集群足够稳定可以考虑，几乎不会丢数据；然后还有elastic公司的filebeat，这个就需要把日志输入到应用机器的文件里面了，只要日志写入到文件，几乎不会丢数据，只是部署比较麻烦，在一定程度上，限制了应用机器的快速横向拓展；

日志规范

最好是每个请求都只有一条日志，这样ELK的压力会小一点，如果请求一条数据，返回一条数据，那就是x2了，如果重要的接口，需要多条日志，那就是更多了。

可以考虑在每条日志中加入reqId，即请求ID，每次请求若有多条日志，reqId是把它们串起来的唯一线索，（用bunyan另一点就是它的child logger，可以将reqId放在生成的child logger上，然后附在res或者req上面，后续的middleware直接打日志即可，不用管reqId）然后也需要写在response header里面返回给客户端，这样的话，可以方便调试，APP开发的同事直接给这个reqId，就可以查询了，日后如果客户端也需要上传日志，也需要将reqId上报。

其它呢，能记上的都记上，可以方便日后的日志分析。

日志安全

日志里面可能会有一些敏感信息，反正端口不能暴露在外网，然后如果真的需要的话，最简单的方式是用nginx做个反向代理，做个basic auth，但是！！！不建议这么干！

其他的方案么，sheild，哎。。。要收费，Search Guard 挺不错的，功能丰富，细粒度的权限控制，只是配置起来真的挺麻烦，人员多了之后可以考虑配置一下。

其它作用

日志除了查询与分析之外，还有个作用就是报警，这个目前还没做，不过做起来也挺简单，定时去ES查询相关的结果，直接根据结果决定是否报警即可。

zysam commented 8 years ago

最近也有做 elk 日志收集分析，app 里用的 winston，选择时也有些困难。鉴权还没有做好，这又是件麻烦的事呀。

xizhibei commented 8 years ago

放内网，只能连VPN看，能省点事

zysam commented 8 years ago

这个解决方案不错。。。

iShawnWang commented 7 years ago

正在学习Node 的移动开发小白, 想问一下, 服务端的崩溃收集没有类似 crashlytics, Bugly 这种的崩溃收集统计分析平台么... 为什么偏向于自己搭建呢 ?

xizhibei commented 7 years ago

@iShawnWang

首先在这里我说的是日志收集，其中会包含错误日志可以用来分析问题，但还有其它很多能帮我们分析问题的详细日志。而且，基于日志可以用来做用户行为分析、反爬虫 https://github.com/xizhibei/blog/issues/46 以及数据挖掘等；

其次，这里有成本取舍，目前我们的日志量已经到了 T 级别，放任何一个日志收集服务平台都意味着一笔可能比自建大得多的支出。而对于刚建立不久的创业公司，如果仅仅是分析性能跟问题，还是推荐 newrelic 还有 tingyun 之类的 APM 工具，具体可以看看这里：https://github.com/xizhibei/blog/issues/40

xizhibei / blog