大企业日志运维
大企业日志系统的特点和关注点在于：成本、运营与运维数据复杂性、历史遗留问题较多、各部门相互依赖、应对业务突增情况的能力以及丢失率监控&SLA(针对日志传输丢失情况的长久数据，都要保存到SLA里面，在SLA里面做一些你系统的一些评价，就是你这个系统到底靠不靠谱，其实是要用SLA来衡量的。)。
谈到大规模的日志传输，我们首先要考虑这个架构到底要怎么设计，到底是使用同步架构还是使用异步架构。什么叫同步架构?就是ETL、格式整理和转发放在一起。这会存在一个什么问题?如果整个业务比较平稳的话还好。但是如果业务突然间出现爆增等突发情况的时候，上面的架构就会出现问题。你需要解析的，可能就放在那个地方，后面的数据又转发不出去，前的服务发生了什么你可能根本不知道。此时，就需要把传输和解析进行分隔。
因此，我建议在设计日志传输架构的时候尽量设计成异步架构。
如何控制成本和优化业务呢?日志量越大成本就会越大，日志量大不是可以用来自豪的事情。可以用来自豪的是，你的成本做了多少意义的事情。在大企业的日志传输中其实存在很多垃圾数据，没有收集的意义。所以我们首先要做的就是对日志进行分类。然后就是对格式进行协定，对日志进行合并以及分级传输，实现运维侵入开发。
以Rsyslog为例，首先所有日志要有志tag，以其进行区分。然后需要高保的tag调用高保RuleSet，其他的日志tag以syslogfacility-text进行区分，通过syslogfacility-text来写入普通的通道。最后使用rsyslog的action中的属性：action.execOnlyEveryNthTime实现按比例丢弃。
接下来，我重点介绍一下日志降级。日志降级是用来干什么的?在企业的业务量遇到突发情况的时候，需要对服务进行降级。为什么要降级?因为正常情况下，日志量处于一个比较平稳的状态，一点点的传。类似于某某明星离婚的时候，这个日志量就会爆增。为什么会爆增呢?首先日志是有一个特点的，在正常情况下可能就记录一下infor或者这些日志，但是如果出现错误的时候，这个错误量就会跟着这个业务量一样样的往上涨。这时就要考虑日志降级的问题，如果不降级的话，很有可能把下行带宽全部打满，遭遇计算量、带宽以及磁盘三个瓶颈。
以手机微博为例，我们来看看日志降级的逻辑。首先，就是要动态调整各个日志tag的级别。然后，它定义了两种级别：是否转发与是否落磁盘。
这是一个逻辑的图，这里面我们用了一个PHP的动态加载库，它可以把你相应的降级规则，就是对某一个日志，在需要降级的时候把它降到哪个通道里，把它降到哪个级别里的定义。然后我们会和监控进行连接，当监控发现某些业务突然出现突增的时候。这里面当然是基于规则，如果说这个规则满足的时候，就开始进行降级。
在大企业日志运维的情况下，我们需要注意，企业的日志传输是需要监控的，对于架构的每个环节都需要进行测试，主要是压测。此外，最好通过队列解藕各个部门的依赖，并实现运维侵入开发，及时发现问题反馈给开发，发现开发中的不合乎规范的问题，并提供解决方案。
微博日志系统架构及相关调优
调优从来就没有一个标准的答案，所有调优一定要从内部了解系统开始，调优一定要基于测试与监控。下面，我们以Elasticsearch和Rsyslog的调优为例来具体了解一下：
◆Elasticsearch的调优
我们经常强调Elasticsearch的调优到底在调什么，我们首先要看一下一条数据写进来的时候是经过怎样的过程。首先是把数据写到index-buffer当中，在这个阶段你的数据还是搜索不到的。然后会有异步的程序把这个数据从index-buffer当中refresh出来，这个就是refresh阶段。一讲到Elasticsearch调优的时候，肯定大家就要讲到有一个调优项叫做index-buffer refresh，这个refresh的间隔时间。然后就到了这个flosystem cache这一层，到了这一层的时候你的数据是可以被搜到了，因为它可能就进行切分。最后一步是磁盘操作flush，把数据从flosystem-cache刷到磁盘当中。进入disk层有个merge阶段，也就是说其实在ES当中是有一个异步的进程，Merge这个数据，就是把system进行合并，这个操作因为它是IO操作，它对性能的损耗是比较大的。再就是translog，它实际是一个数据库记录操作日志，把所有的对ES的操作首先先记到translog当中，如果在系统写入发生异常的时候，从translog把操作进行恢复。在flush写入之后，删除translog。