日志系统的作用：
1、了解线上系统的运行状态
2、快速准确定位线上问题
3、发现系统瓶颈
4、预警系统潜在风险
5、挖掘产品最大价值
6、……

设计目标：
1、支持高并发日志写入
2、亿级消息内容存储
3、支持监控报警
4、分布式、高可用

存储选择：
mysql TokuDB+redis
mysql TokuDB是一个支持事务的“新”引擎，有着出色的数据压缩功能。经测试，压缩后的数据只占原数据大小的10%以下。
redis用来做队列，解决日志并发写入的压力。

字段设计：
id 主键
type 日志类型
client_ip 客户端ip
service_ip 服务器ip
site 站点名
file_path 文件路径
name 日志名称
content 日志内容(数组需要json_encode)
cookie 当前的cookie内容(需要json_encode)
url 当前的url
params 当前的url参数（需要json_encode）
create_time 时间
notice 通知方式(对应通知类型的配置文件)

日志类型：

FATAL – The FATAL level designates very severe error events that will presumably lead the application to abort.
ERROR – The ERROR level designates error events that might still allow the application to continue running.
WARN – The WARN level designates potentially harmful situations.
INFO – The INFO level designates informational messages that highlight the progress of the application at coarse-grained level.
DEBUG – The DEBUG Level designates fine-grained informational events that are most useful to debug an application.

对于日志级别的分类，有以下参考：
FATAL — 表示需要立即被处理的系统级错误。当该错误发生时，表示服务已经出现了某种程度的不可用，系统管理员需要立即介入。这属于最严重的日志级别，因此该日志级别必须慎用，如果这种级别的日志经常出现，则该日志也失去了意义。通常情况下，一个进程的生命周期中应该只记录一次FATAL级别的日志，即该进程遇到无法恢复的错误而退出时。当然，如果某个系统的子系统遇到了不可恢复的错误，那该子系统的调用方也可以记入FATAL级别日志，以便通过日志报警提醒系统管理员修复；
ERROR — 该级别的错误也需要马上被处理，但是紧急程度要低于FATAL级别。当ERROR错误发生时，已经影响了用户的正常访问。从该意义上来说，实际上ERROR错误和FATAL错误对用户的影响是相当的。FATAL相当于服务已经挂了，而ERROR相当于好死不如赖活着，然而活着却无法提供正常的服务，只能不断地打印ERROR日志。特别需要注意的是，ERROR和FATAL都属于服务器自己的异常，是需要马上得到人工介入并处理的。而对于用户自己操作不当，如请求参数错误等等，是绝对不应该记为ERROR日志的；
WARN — 该日志表示系统可能出现问题，也可能没有，这种情况如网络的波动等。对于那些目前还不是错误，然而不及时处理也会变为错误的情况，也可以记为WARN日志，例如一个存储系统的磁盘使用量超过阀值，或者系统中某个用户的存储配额快用完等等。对于WARN级别的日志，虽然不需要系统管理员马上处理，也是需要及时查看并处理的。因此此种级别的日志也不应太多，能不打WARN级别的日志，就尽量不要打；
INFO — 该种日志记录系统的正常运行状态，例如某个子系统的初始化，某个请求的成功执行等等。通过查看INFO级别的日志，可以很快地对系统中出现的 WARN,ERROR,FATAL错误进行定位。INFO日志不宜过多，通常情况下，INFO级别的日志应该不大于TRACE日志的10%；
DEBUG — 这两种日志具体的规范应该由项目组自己定义，该级别日志的主要作用是对系统每一步的运行状态进行精确的记录。通过该种日志，可以查看某一个操作每一步的执 行过程，可以准确定位是何种操作，何种参数，何种顺序导致了某种错误的发生。可以保证在不重现错误的情况下，也可以通过DEBUG级别的日志对问题进行诊断。需要注意的是，DEBUG日志也需要规范日志格式，应该保证除了记录日志的开发人员自己外，其他的如运维，测试人员等也可以通过 DEBUG日志来定位问题；

参考文档：

1、Seaslog http://blog.csdn.net/yangzaiqiu1986814/article/details/50728053

2、https://www.zhihu.com/question/21427267

3、https://zhuanlan.zhihu.com/p/27363484?hmsr=toutiao.io&utmmedium=toutiao.io&utmsource=toutiao.io