【.com原稿】不同规模的企业需要不同的日志运维方式。在WOT2016移动互联网技术峰会上，新浪微博高级系统开发工程师于炳哲与参会人员深入分析了小公司和大公司的日志运维问题，手机微博日志系统架构的优化，以及自己对日志运维的反思。小型企业日志运维小型企业日志运维关注：成本、数据规模、维护难度。首先我们来看看不同规模的小企业的日志架构。小型企业日志架构的特点：扩展相对简单，业务复杂度低，业务依赖度低，历史问题相对较少，因此重构成本相对较低，可以投入的资源相对较少。事实上，小型企业可能会经历几个阶段。首先是开荒阶段，即服务刚刚上线，还处于测试开发阶段。这时，企业的应用可能是部署一台或两台服务器。这个时候就没有必要搭建一个完整的日志架构了。日志提取可以使用纯文本+grep+awk+sed来完成。如果使用传统的数据库，开发时可以直接将重要数据写入数据库。或者使用第三方监控，使用业务接口监控（lua->nginxsharddict->DB(graphite)）。然后，进入数据增长阶段。这个时候架构已经变成分布式了，也就是日志可能在不同的服务器上，业务已经上线了。这时候就需要及时反馈信息，需要专业的运维人员来设计日志架构。基于ALK的简单设计如下图所示：随着日志的逐渐增多，业务逐渐扩展，进入了日志服务器传输阶段。此时需要采集的日志总量还没有达到Elasticsearch（单数据节点）的写入量。企业对日志数据的安全性要求不是特别高，不太关注单点问题。尽可能少的运维投入，希望快速建成。不要有太高的技术门槛。这时候，架构可能会变成这样。这是一家中小企业，或者50人以下，KPI上万的厂商，基本可以采用这种架构。也就是说，你面前有一个日志代理，日志直接写入日志服务器，直接落盘。在这上面使用logstash或者其他日志处理组件，直接收集日志写入ES。在这个阶段，还没有达到ES性能瓶颈。我一直强调的是，在整个日志架构中，没有必要一下子把这个架构做的特别，而是要强调这种循序渐进的方式，因为成本是非常高的。重要的是，对于小型企业。这时又提出了一个新的需求，即前端服务器已经无法承受增加的日志量，需要对日志进行统一归档，于是进入队列阶段。这时候就需要考虑数据安全问题，保证日志不丢失。同时需要一次写入，多次读取。所谓write-once-read-many就是你的日志结构写到一个地方同时在多个地方消费，比如业务部门或者你的运维部门。现在比较流行的一种日志处理架构，前端也是由agent写的，同时中间使用一个缓冲队列比如kafka或者redis来进行相应的队列存储。然后通过logstashindexer将这些数据写入ES或者写入DB。同时，我用kibana做了一些数据展示。这里面，就得考虑队列的选择了。首先，队列的选择。如果使用redis，可能会涉及成本问题。它的内存，如果数据很多，你的内存就比较贵了。在成本方面可能要考虑。另一个问题是分配。如果你用redis做分发，是不支持这个的。您可能需要一些其他组件来执行redis的分发。其实我推荐的是使用开箱即用的Kafka，可以说是天生的分布式队列。它使用磁盘进行这种数据存储，因此成本相对较低。在这里，我想强调存储的扩展，比如ES存储的扩展。这可能是一种常用的、常规的扩展架构，是一种基于角色的架构。前端使用client，前面挂了一个LB做负载均衡，然后把数据写到client。然后与客户端的Node和ES进行交互，同时使用master保存整个集群的一些数据状态。对于一些中小企业来说，能够做到这一步基本就够了。***，对于小业务的日志运维，我有以下补充：第一，所有的架构设计都必须基于测试和监控。二是涉及到logstash和Rsyslog的问题。logstash本身可能涉及到它的整个日志传输，这涉及到一些不可控的问题。虽然是开源的，但是它的很多流程并没有很好的内置。事实上，你不知道日志有没有丢失，传输过程有没有问题。只能对业务的两边进行对数。第三，Rsyslog提供了impstats监控模块。impstats模块专门用于事件级别的监控。对某个事件的成败一直很准确，表现非常好。通过Rsyslog的rmpc模块，我们可以监控整个日志传输。***、Elasticsearch监控可以使用自带的插件。我推荐Elasticsearch的监控。如果是没有特别强的人力投入的公司，可以直接使用自己的一些插件，也可以使用Elasticsearchmabo等插件。大型企业日志运维大型企业日志系统的特点和关注点是：成本、运维数据复杂、历史遗留问题多、各部门相互依存、应对业务突发增长的能力、损失率监控&SLA(日志传输丢失的长期数据必须保存在SLA中，而你的系统的一些评估是在SLA中进行的，即你的系统是否可靠实际上是由SLA衡量的。).涉及到大规模的日志传输，首先要考虑这个架构怎么设计，是用同步架构还是异步架构。什么是同步架构？它是ETL、格式化和转发放在一起的。有什么问题？如果整个业务比较稳定就好了。但是，如果业务突然爆发等意外情况发生，上述架构就会出现问题。你需要分析的可能放在那个地方，后面的数据无法转发，你可能不知道之前的服务发生了什么。此时，需要将传输和分析分开。因此，我建议在设计日志传输架构时，尽量设计成异步架构。如何控制成本，优化业务？日志量越大，成本越大。大日志量并不值得骄傲。可以用来骄傲的是，你用自己的成本做了多少有意义的事情。在大型企业的日志传输中，其实有很多垃圾数据，收集起来毫无意义。所以我们要做的第一件事就是对日志进行分类。然后就是约定格式，对日志进行合并分级，实现运维的侵入式开发。以Rsyslog为例，首先所有的日志都要有一个tag来区分。然后为高安全性标签调用高安全性规则集。其他日志标签通过syslogfacility-text区分，通过syslogfacility-text写入普通通道。***使用rsyslog的action中的属性：action.execOnlyEveryNthTime实现按比例丢弃。接下来，我主要关注日志退化。日志降级有什么用？当企业业务量遇到突发事件时，需要对服务进行降级。为什么要降级？因为正常情况下，日志量是比较稳定的状态，一点点传输。类似于某明星离婚，日志量会爆炸。为什么会爆炸？首先，日志有一个特点。一般情况下，是可以记录infor或者这些日志的，但是如果出现错误，错误量会随着业务量的增加而增加。这时候就要考虑日志降级的问题了。如果不降级，很有可能会充分利用下行带宽，遇到三个瓶颈：计算量、带宽、磁盘。以手机微博为例，我们看一下日志降级的逻辑。首先，需要动态调整各个日志标签的级别。然后，它定义了两个级别：是否转发和是否落盘。这是一个逻辑图，里面我们用了一个PHP动态加载库，里面可以放你对应的降级规则，也就是对于某个日志，需要降级的时候降级到哪个通道，降级的定义去哪个级别。然后我们会和监控对接，当监控发现一些业务突然增加的时候。这当然是基于规则。如果满足规则，降级将开始。在大型企业日志运维的情况下，需要注意的是企业的日志传输需要进行监控，架构的每一个环节都需要进行测试，主要是压力测试。另外，***利用队列解耦各部门的依赖，实现运维侵入开发，及时发现问题反馈给开发，在开发中发现不符合规范的问题，并提供解决方案。微博日志系统架构及相关调优一直没有标准答案。所有调优都必须从对系统内部的了解开始，调优必须以测试和监控为基础。下面我们以Elasticsearch和Rsyslog的调优为例来详细了解一下：◆Elasticsearch调优我们经常强调Elasticsearch调优究竟是什么调优。我们首先需要看一下写入一条数据的过程。.首先是将数据写入索引缓冲区，在这个阶段你的数据仍然不可搜索。然后会有一个异步程序从index-buffer中刷新数据，也就是refresh阶段。说到Elasticsearch调优，大家一定要说到一个调优项，叫做index-bufferrefresh，刷新间隔。然后是flosystem缓存层。当你到达这一层时，你的数据就可以被搜索到，因为它可能被分段了。最后一步是磁盘操作flush，它将数据从flosystem-cache刷新到磁盘。进入磁盘层有一个merge阶段，也就是说在ES中其实是有一个异步过程的。合并数据就是合并系统。因为这个操作是一个IO操作，它对性能的损耗比较大。然后是translog，其实就是记录操作日志的数据库。ES上的所有操作首先记录在translog中。如果系统写入异常，则从translog中恢复操作。flush写入后，删除translog。至此，我们可以看到，在写入的过程中，ES的性能主要消耗在translog的merge、flush、refresh、flush这几个阶段。知道了这个过程，我们就可以参考ES的官方文档来调优相应的阶段。当然，首先要了解企业的??业绩状况。如果IO有问题，调整merge。如果CPU有问题，可以考虑调整刷新率。然后是调整方向。merge官方默认参数是根据SSD盘调的。其实不适合做机械盘之类的服务。所以我建议，如果涉及到IO问题，可以考虑减少merge进程数。当数据写入特别大时，采用网络限流。在内核层面，ES配置文件包含了系统提供的一些不错的参数。◆Rsyslog的调优如图所示。这是Rsyslog的一个内部队列，Rsyslog的内部也比较复杂。首先是输入过程，然后是预处理阶段。比如它会进行一些分类，根据分类将某个日志标签写入某个地方。之后是过滤引擎。在这之前，会有一个Queue，也就是说这个数据内部会维护一个队列，然后Filter会主动从这个队列中拉取数据。后面是Action处理器，前面每个事件也有一个队列，Action进程会从对应的队列中写入数据。这是内部结构。rsyslog主要有Mainqueue和Actionqueue两种队列，以及四种队列设置，分别是：Directqueue，Diskqueue，In-memoryqueue（LinkedList，FixdArray），Disk-assistedmemoryqueue。综上所述，日志量就是成本，所以不要以花多少为荣，要以做多少为目标。传输有价值的数据！更加注重业务优化。另外，一定要记住：选择哪种架构是根据具体的场景来决定的，不要过度设计，要尽量快速迭代。【讲师介绍】余秉哲目前就职于新浪微博-移动微博移动服务保障部，担任系统开发工程师，负责移动微博服务器端和客户端的日志采集和传输，目前新浪微博&新浪微博***Elasticsearch集群维护及相关中间件开发维护。主要专注于日志相关技术，专注于日志的处理、传输、存储；等相关领域，对大规模数据量下的日志治理有一定经验。曾就职于北京闻日科技（365日历），从事Java服务器开发、日志处理、运维监控告警等相关工作。本文根据冰哲在2016年8月WOT2016移动互联网技术峰会运维与安全专场《日志漫谈-不同规模下的日志运维与优化》的主题演讲整理而成。WOT2016大数据峰会将于2016年11月25-26日在北京JW万豪酒店举行。届时，数十位大数据领域的一线专家和数据技术先驱将齐聚现场，围绕机器学习、实时计算、前沿技术进行深入交流和探讨将分享系统架构和NoSQL技术实践等话题，分享大数据领域的最新实践和最热门的行业应用。更多WOT2016大数据技术峰会信息，请访问大会官网：http://wot.51cto.com/2016bigdata/【原创稿件，合作网站转载请注明原作者和出处为.com】
