企业规模不同，日志运维的方式就有所不同。在WOT2016移动互联网技术峰会上，来自新浪微博的资深系统开发工程师于炳哲，同与会者深入分析了小企业与大企业的日志运维问题，手机微博日志系统架构相关的调优，以及自己对日志运维的反思。
小企业日志运维
小企业日志运维关注点在于：成本、数据规模以及维护的难度。首先，我们来看看小企业在不同规模下的日志架构。小企业日志架构的特点：扩展相对简单、业务复杂度低、业务依赖度低、历史遗留问题相对较少，所以重构成本相对较低、可投入的资源相对较少。
其实对于小企业来讲可能都会经历几个阶段，首先是开荒的阶段，即是服务刚刚上线，还处于测试和开发的阶段。这时候，企业的应用可能就是布置一台或者两台服务器，此时没有必要做一套完整的日志架构。用纯文本 + grep + awk + sed即可完成日志的提取。如果使用传统的数据库，可以在开发中将重要数据直接写入数据库。或者使用第三方监控，采用业务接口监控(lua -> nginx shard dict -> DB(graphite))。
然后，进入数据增长阶段。此时的架构变成了分布式，也就是日志可能在不同的服务器上，业务也已经上线，这时候需要及时的反馈信息，需要专业的运维人员做日志架构设计。如下图的基于ALK简单的设计：
随着日志的逐渐增多，业务的逐渐扩展，进入了日志服务器中转阶段，此时需要收集的日志总量还未达到Elasticsearch(单数据节点)的写入量，企业对日志数据的安全性要求并不是特别高，同时对单点问题也不是很重视。在尽量少的运维投入下，希望快速构建。不要有太高的技术门槛。
这时候架构可能就会变成这样，这是一个大家中小企业，或者在50人以下，KPI在几万左右的厂商，基本就可以采用这种架构。就是说你的前面是日志agent，把日志直接写到日志服务器上，直接落磁盘。在这个上面用logstash或者其他的一些日志处理的组件，直接进行收集，把日志写到ES里。在这个阶段还没有到达一个ES的性能瓶颈，我一直强调的是在整个日志的架构当中不需要一下把这个架构架的特别完美，而是要强调这种渐进的方式，因为成本是很重要的，对于小企业来讲。
这时提出了一个新的要求，就是前端服务器已无法承载增幅的日志量，日志需要统一归档，就此进入队列阶段。这时需要考虑数据安全问题，保障日志安全不丢失。同时需要一写多读。所谓一写多读就是你的日志架构是往一个地方写，同时有多个地方进行消费，比如说业务部门，或者是你的运维部门。
现在比较流行的一个日志处理的架构，前端也是agent写入，同时中间使用kafka或者redis这种缓冲的队列做相应的队列存储。然后通过logstash indexer，把这个数据写到ES里面，或者写到DB里面。同时我这里面用了kibana做一些数据展示。在这个里面你要考虑队列的选型问题，首先队列选型问题，如果使用redis可能涉及到一个成本的问题，它的内存，如果数据比较多的话，你的内存是比较昂贵的，在成本上面可能要考虑。另外还有一个是分布式的问题，如果你用redis进行分布式方面的话，它本身是不支持这种的，你可能需要一些其他的组件来做这个redis的分布式。其实我比较建议的是使用开包即用的kafka，它可以说是天生的分布式的队列，它是用磁盘做这种数据存储的，所以在成本方面也是相对比较低廉的。
在此，我想强调的是存储的扩展，比如说ES存储的扩展，这个可能是一个常用的、常规的一个扩展架构，就是一个分角色的架构。最前端用client，前面挂一个LB的方式做负载均衡，然后把数据写到client上。随后在client和ES的Node进行交互，同时使用master进行整个集群数据状况的一些保存。对于一些中小规模的企业，能做到这一步基本就够用。
最后，对于小企业日志运维，我有以下几点补充：一是，一切架构设计都要以测试为先，同时做好监控。二是，涉及到logstash和Rsyslog的问题，logstash本身可能涉及到的它的整个日志传输，涉及到一些不可控的问题，它虽然是开源的，但是它很多的一些过程并没有很好的自带的监控，丢不丢日志，传输过程中有没有问题，实际上你是不知道的，你只能是通过业务两边进行对数。三是，Rsyslog提供impstats监控模块。impstats模块专门做事件级别的监控，已经精确到某一个事件是成功还是失败的这种监控，而且性能非常好。通过Rsyslog的rmpc的模块，我们可以做整个日志传输的监控。最后，Elasticsearch的监控可以使用自带的插件。Elasticsearch的监控我推荐，如果是在人力投入并不是特别强的公司，可以直接完全使用它自带的一些插件，同时可以使用比如说Elasticsearchmabo这种插件。