本次分享的内容大纲如下：

常见应用的日志类型

说到常见应用的日志类型，我们可以拿社区内目前最流行的web服务器nginx进行举例说明，目前nginx自身包括社区给nginx贡献的相关插件来看nginx的日志一共有以下两种常见类型：

文件日志

文件日志指的是nginx打印日志的方式为通过文件的方式打印日志，其中打印到文件中又可以划分以下几种文件类型，比方：错误日志文件，access日志文件等。在我们日常工作使用过程中还同时会考虑到以下几个特别常见的场景和文件日志的问题：

1，日志文件过大问题

在真正的生产环境中假如存在高QPS，或者者需要大量debug的时候会产生大量的日志，日志文件过大不利于生产环境排查和定位问题，也不利于日志文件的压缩，备份，删除策略配置。

针对这种情况常见的开源处理方案有使用logrotate等进行日志切分，也有通过标准自动重定向动态调整打印日志文件的方式进行日志文件拆分；我们公司是统一使用logrotate进行定时日志拆分，我拿我们公司经常使用的配置方式进行举例，大家可以看下logstate进行日志定时拆分是如何做的。

/path/to/logs/*.access.log /path/to/*.error.log {
 missingok
 ifempty
 sharedscripts
 rotate 20
 daily
 dateext
 dateformat -%Y%m%d%s
 postrotate
 /bin/kill -USR1 `cat /data/server/nginx/logs/nginx.pid 2> /dev/null` 2> /dev/null || true
 endscript
}

以上配置中我们定时执行logrotate并指定上述配置可以把/path/to/logs/*.access.log和/path/to/*.error.log进行定时切分，切分后日志保留格式新添加后缀年月日小时，总共保留日志20天。

2，打印日志的时候日志的格式设计问题

开发一个应用的时候讲应用的错误日志和请求日志进行区别对待是一个非常好的开发习惯，由于不同类型的日志拆分后更有利于对日志进行特殊的定制化，比方错误日志打印的形容信息可能比请求日志多，请求日志打印的信息可能更关心请求状态码等。

但是从日志平台的设计角度去思考不同日志文件的日志类型不一样又反而是一种限制，由于日志搜索和解析需要和对应的日志文件格式相匹配。

我这里列举一个当前社区比较常见的两种nginx日志配置方式供大家参考：

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" "$http_user_agent" '
 '"$http_x_forwarded_for" "$upstream_cache_status" "$upstream_addr" $request_time';

我们公司为理解析方便也经常把nginx的日志格式配置为json格式，尽管这种方式教上一种添加了文件的大小但是却节省理解析成本，我也把json格式的日志配置拿出让大家可以参考：

log_format logjson '{"remote_addr":"$remote_addr","request_method":"$request_method","request_uri":"$request_uri",'
'"server_addr":"$server_addr","status":"$status","request_time":"$request_time","body_bytes_sent":"$body_bytes_sent","upstream_response_time":"$upstream_response_time","server_port":"$server_port"}';

3，日志导致的磁盘IO问题

单位时间内写日志的速率过高产生的磁盘IO负载问题，把这项列出来并不是说要彻底处理这个问题，而是文件类型的日志是存在这个问题需要大家知道并且心里有数，对于这种问题没有什么好的处理方案，我理解的处理方法有：

减少刷磁盘频率，比方nginx添加buffer机制配置；
减少每行日志的大小，将无用信息剔除，保证日志信息尽量是最有用的关键信息；
改为网络日志传输避免磁盘IO；
优化磁盘，调整raid的配置，或者者直接使用高性能SSD；

4，日志文件的命名和路径问题

日志文件的命名和路径间接影响了文件日志的采集方式，因而假如能有商定的统一命名方式和日志路径对日志平台的建设会有很大的帮助。

相信做过通用日志平台的同学都会被各种各样的不规范命名和各种复杂日志路径搞的一头雾水，因而设计之初假如能做到规范化其实在后期日志平台的建设上会节约很大成本。既然我把这个大家大多数开发者不会关心的问题列出来了我就顺道把自己的少量经验的命名详情下，比方：/path/to/logs/{app_name}/{access|error|info|debug}.log。

5，不同编程语言，不同组件的日志问题

众所周知，不同编程语言甚至同一个编程语言的不同框架下打印日志都有可能不同，因而建议由一个公司级别的选型规范去商定该问题，将复杂化降低。

网络日志

网络日志指得是nginx通过网络将日志转发到指定日志接收服务器，而后再通过日志接收服务进行定制化转发和存储。假如采用网络日志进行传输可以处理少量本地磁盘空间占用问题，统一日志解决问题等，那么网络日志传输的方式就没有问题了吗？其实不然，网络传输带来的问题也有不少，比方：

日志可靠性如何保证，即：传输日志的过程中不丢失日志。
网络传输的性能如何保证，高QPS的应用日志一般也会很高，如何保证传输效率呢？
日志传输也需要带宽支持，主机的网卡资源也是有限资源，如何正当分配？

通过以上分析与常见的应用举例，我们不难发现做一个统一的日志平台其实面临很多问题，但是这些问题又是由来已久的，那么既然是由来已久的会不会社区已经有开源的好的处理方案了呢？这个答案是一定的，你关心的问题社区大多数公司也都关心着，我们抱着最小化造轮子重复开发的成原本做日志平台，接下来敬请期待我整理的社区常见的日志难题处理方案篇。下篇文章我会分析主流的日志采集组件，分别对应日志的两种类型，主要讲解其优缺点和落地实践。