线上系统使用forever来启动服务，最开始就直接使用了forever来记录
forever start -a -l ./logs/forever.log
-a 表示追加日志文件
-l 指定日志文件
-s 忽略console.log输出的日志记录(使用log4j时要用这个)
最开始还挺好的，所有日志都能记录下来，但是既然是线上环境，日志比较多，跑着跑着就出问题了。
forever.log文件变得越来越大，在我的系统里直接占了3GB的内存，而且全在内存里面，然后服务器就报警了。
然后尝试对forever.log文件进行切割，结果这SB玩意更本没法切割，具体问题：
1、对forever.log 重命名 forever.log.bak 然后新建forever.log，结果日志仍然往forever.log.bak里写，内存一点也没减少
2、直接删除forever.log ，forever不会新建forever.log，占用的内存也一直不释放
似乎是forever一直使用着文件句柄根本不释放就往里面写，根本没法做日志切割。
二、log4j记录日志
log4j是nodejs的一个log日志包，说下怎么配置和分割日志
{
"appenders": [
{ "type" : "console" },
{
"type": "dateFile",
"filename": "logs/access.log",
"pattern": "-yyyy-MM-dd",
"category" : "normal",
"level" : "LOG"
},
{
"type": "file",
"filename": "logs/error.log",
"maxLogSize": 2097152,
"backup": 10,
"category": "error"
},
{
"type": "dateFile",
"filename": "logs/record.log",
"pattern": "-yyyy-MM-dd",
"category": "record"
}
],
"replaceConsole" : true,
"levels": {
"error": "error",
"record" : "trace"
}
}
log4j的type:
console 往控制台输出
file 文件日志 maxLogSize 表示当文件超过这个值时切换文件 backup:n 会循环使用 error[1,n].log 的文件名
dateFile 使用这个就会按天切割日志，按天生成文件名 access.log-2014-12-14
问题：
日志文件名和内容会相差一天 access.log-2014-12-14 的文件里其实记录的是 2014-12-15 的日志文件，这个暂时还没有找到解决办法
换了log4j之后会自动切割日志，按天进行保存，内存就一直没暴增了。
内存不满就没报警，没了报警整个世界都清净了。
为了完成这点，你会需要使用一个最流行的开发包，叫做 winston. Winston 是一个 Node.js 的多通道异步传输日志库。
你可以通过安装 winston 的方式，添加它到你的项目中：
一旦你安装之后，你可以这样添加 winston 到你的项目：
上面的代码片段会推送接下来的这行信息到 stdout ：
如同你所看到的那样，我们传递了 info 字符串到 winston ，从而告诉 winston 这个将要日志的事件有一个日志级别与之关联，也就是 info。默认情况下， winston 附带了接下来的几种日志级别 （也可以添加自定义的级别） ：
你可以通过接下来的一行设置日志的级别：
在 RisingStack ，我们通常利用一个叫 LOG_LEVEL 的环境变量来配置。这样的话，我们就可以动态改变哪些内容应该被日志记录：
当你的日志级别是 silly 时，你应该尽可能的多记录所有的日志。尽管如此，你还是需要遵守一个经验法则：绝对不要记录凭证，密码以及任何敏感的信息。
“绝对不要记录凭证，密码以及任何敏感的信息。” via @RisingStack #nodejs #logging #security
点击直达 TWEET
通常来说，会有至少一个以上的用户访问日志，所以，日志事件里面包含凭证信息会增加额外的风险。
当你 开始使用微服务 ， 从日志角度来看，最大的挑战就是分布式追踪。
在一个分布式的架构中，错误检测会令人沮丧，因为由于系统的瑕疵会导致大量的警报信息涌现。分布式追踪的目的就是为了消除这个问题，它可以提供更多的事务和错误的视角，而普通的日志文件并没有能力做到这些。
为了做到这点，你不得不使用一个所谓的相关标识符——并且把它传递给所有的参与事务操作的服务。然后，如果每行日志都标注了这个 ID ，你就可以搜索这些事件了。
为了生成一个唯一的 ID ，你可以这样使用 uuid 模块:
这个 ID 不得不在函数调用中传递，并且它也不得不被发送到下游的服务。 如同你可以想象到的，这不是个特别值当的任务。
这里讲到追踪，我们的 Node.js / 微服务监控 解决方案如下图所示。追踪相关的 ID 到请求的容器，并且可视化了一个简单的树状图的数据流。你不会需要去搜索日志，因为它会直接以一种容易理解的方式去展示你的事务：
Node.js distributed tracing with trace by risingstack
根据这种方式， 你可以直接看到你的微服务和持续产生的 issue 之间的依赖关系
如果你实现了我们刚刚讨论的这些方法和工具，Node.js 的日志记录将不再是一件难事。
