当前位置: 亚洲城ca88 > 计算机网络 > 正文

B站日志系统的前生今生,2集群意况安插计划优化

时间:2020-04-16 11:52来源:计算机网络
作者简介 B站的日志系统(Billions)从2017年5月份开始建设,基于elasticstack,面向全站提供统一的日志采集、检索、监控服务。目前集群规模20台机器,接入业务200 ,单日日志量10T 。借此

作者简介

B站的日志系统(Billions)从2017年5月份开始建设,基于elastic stack,面向全站提供统一的日志采集、检索、监控服务。目前集群规模20台机器,接入业务200 ,单日日志量10T 。借此机会跟大家分享一些B站在日志系统的建设、演进以及优化的经历。由于经验尚少,抛砖引玉,欢迎大家一起交流讨论。文章主要分为三个部分:原有日志系统,现有系统演进,未来的展望。

ELKB5.2.2集群环境部署配置优化终极文档

王翔宇

原有日志系统

在Billions之前,B站内部并没有统一的日志平台,基本是业务之间各自为战,既有基于ELK的比较前瞻的方式,又有服务器上使用tail/grep比较基本原始的方式,水平参差不齐。在了解各个产品线的情况后,存在的问题和诉求主要有以下几点:

  1. 方案各异。 由于各个部门自行实现日志方案,没有专人维护,普遍存在维护成本高、系统不稳定、丢日志、易用性不足的情况。
  2. 业务日志没有统一的规范。业务日志格式各式各样,导致最直接的问题就是无法按照统一的规则对日志进行切分,这无疑大大的增加了日志的分析、检索成本。
  3. 对PAAS支持不好。公司内部正在大面积推广应用容器化,但是并没有一个好的日志方案支撑容器内应用日志的采集。
  4. 日志利用程度低。对于日志的利用程度普遍停留于日志检索的水平,受限于工具未对日志的价值进行进一步挖掘,例如:日志监控、统计分析、调用链分析。

针对上述问题,提出新的日志系统的设计目标如下:

  • 业务日志平滑接入:业务日志接入日志系统,只需要进行简单的配置;日志平台也只需要进行一些基本的配置,无须涉及日志内容等业务信息。
  • 多样性支持:环境多样:物理机(虚拟机)、容器;来源多样:系统日志、业务日志、中间件日志......;格式多样:单行/多行, plain/json。
  • 日志挖掘:快速可查,日志监控,统计分析。
  • 系统可用性:数据实时性;丢失率可控(业务分级、全链路监控)。

本人陆陆续续接触了ELK的1.4,2.0,2.4,5.0,5.2版本,可以说前面使用当中一直没有太多感触,最近使用5.2才慢慢有了点感觉,可见认知事务的艰难,本次文档尽量详细点,现在写文档越来越喜欢简洁了,不知道是不是不太好。不扯了看正文(注意这里的配置是优化前配置,正常使用没问题,量大时需要优化)。

Bilibili资深运维研发工程师。曾就职于百度、饿了么,2017年加入B站,负责B站日志平台的设计和开发工作。

Billions的演进

备注:

B站的日志系统从2017年5月份开始建设,基于elastic stack,面向全站提供统一的日志采集、检索、监控服务。目前集群规模20台机器,接入业务200 ,单日日志量10T 。

系统的初建

本次属于大版本变更,有很多修改,部署重大修改如下:

借此机会跟大家分享一些B站在日志系统的建设、演进以及优化的经历。由于经验尚少,抛砖引玉,欢迎大家一起交流讨论。文章主要分为三个部分:原有日志系统现有系统演进未来的展望

日志规范

为了解决业务日志格式多样性问题,统一制定了日志格式规范,使用JSON作为日志的输出格式。
格式要求:

  1. 必须包含四类元信息:
  • time: 日志产生时间,ISO8601格式
  • level:日志等级, FATAL、ERROR、WARN、INFO、DEBUG
  • app_id:应用id,用于标示日志来源,与公司服务树一致,全局唯一
  • instance_id:实例id,用于区分同一应用不同实例,格式业务方自行设定
  1. 日志详细信息统一保存到log字段中。
  2. 除上述字段之外,业务方也可以自行添加额外的字段。
  3. json的mapping应保持不变:key不能随意增加、变化,value的类型也应保持不变。

例如:

{"log": "hello billions, write more", "level": "INFO", "app_id": "testapp111", "instance_id": "instance1", "time": "2017-08-04T15:59:01.607483", "id": 0}

1,filebeat直接输出kafka,并drop不必要的字段如beat相关的

原有日志系统

日志系统技术方案

日志从产生到消费,主要经历以下几个阶段:采集->传输->切分->检索。

2,elasticsearch集群布局优化:分三master节点6data节点

在Billions之前,B站内部并没有统一的日志平台,基本是业务之间各自为战,既有基于ELK的比较前瞻的方式,又有服务器上使用tail/grep比较基本原始的方式,水平参差不齐。在了解各个产品线的情况后,存在的问题和诉求主要有以下几点:

日志采集

日志采集针对非落盘和落盘两种方式。

  • 对于业务模块日志,统一按照日志规范并且通过非落盘的方式进行输出。针对此类场景,与平台技术部合作,基于go我们开发了log agent模块。

    计算机网络 1

    • log agent部署在物理机上,暴露出一个domain sock文件,程序将日志通过unixgram方式输出到domain sock。
    • 对于运行在PAAS上的应用,在container初始化的时候,sock文件被默认mount到container内部,这样容器内的程序就可以输出日志。
    • log agent分为两个部分,collector和sender。collector用于接收日志,sender用于向传输系统发送日志。两者直接通过一个文件缓存进行交互。这样在日志传输系统故障的情况下,依赖本地缓存可以保证日志的正常接收。
    • 我们提供了不同语言对应的日志库(sdk),程序可以快速接入日志系统。
  • 非业务模块(中间件、系统模块、接入层)日志,由于定制化能力较差,我们通过读取生成的日志文件完成日志的采集。

    • 我们采用的elastic stack中的filebeat进行采集,filebeat具有方便部署、配置简单、资源消耗低的优势,而且支持多行日志的拼接。
    • 物理机上部署一个单独的filebeat进程,每一类日志对应一个单独的配置文件。
    • 每一条日志都会被单独打上一个app_id标签,这个类似业务日志的app_id字段,这样在最终消费日志的时候就可以进行区分了。
    • filebeat会自动标示日志来源机器,这样也就具有了区分同一应用不同实例的能力。

3,logstash filter 加入urldecode支持url、reffer、agent中文显示

1.方案各异。 由于各个部门自行实现日志方案,没有专人维护,普遍存在维护成本高、系统不稳定、丢日志、易用性不足的情况。

2.业务日志没有统一的规范。业务日志格式各式各样,导致最直接的问题就是无法按照统一的规则对日志进行切分,这无疑大大的增加了日志的分析、检索成本。

3.对PAAS支持不好。公司内部正在大面积推广应用容器化,但是并没有一个好的日志方案支撑容器内应用日志的采集。

4.日志利用程度低。对于日志的利用程度普遍停留于日志检索的水平,受限于工具未对日志的价值进行进一步挖掘,例如:日志监控、统计分析、调用链分析。

日志采集

公司内部已经有了统一的数据传输平台(lancer),lancer的优势如下:

  • 基于flume kafka做二次定制化开发,内部自动负载均衡,容量可水平扩展。
  • 数据接收端实现了一套可靠的数据传输协议,完善的链路监控,数据传输安全可靠。
  • 可以根据业务需要对接不同的消费方式(kafka、hdfs)。
  • 有专业的团队进行7*24维护。

因此我们直接选择lancer作为我们的日志传输系统。

  • log agent中的sender模块基于lancer的定制化的数据传输协议发送日志,最终日志被传输到kafka集群中的不同topic(根据日志流量,配置topic),后续从kafka消费日志,所有的topic采用一个统一的prefix。
  • 由于暂时没有精力对filebeat进行二次定制化开发,因此filebeat直接将日志输出到lancer的kafka集群。

4,logstash fileter加入geoip支持客户端ip区域城市定位功能

针对上述问题,提出新的日志系统的设计目标如下:

日志切分

日志切分模块的主要作用是从kafka消费日志,对日志进行处理(字段提取、格式转换),最终存储到elasticsearch的对应的index中。我们使用logstash作为我们的日志切分方案。

计算机网络 2

logstash.png

其中:

  • 对于按照日志规范生成的日志,日志的kafka topic采用了统一的前缀,因此我们采用topics_pattern的方式来消费日志。
  • logstash的partition_assignment_strategy要设置为"org.apache.kafka.clients.consumer.RoundRobinAssignor",默认的策略(Range partitioning)会导致partition分配不均,如果采用默认的策略,当consumer(logstash数量*worker数量)的数量大于topic partition数量时,partition总是只会被分配给固定的一部分consumer。
  • 对于非标准格式日志,由于logstash single event pipeline的限制,因此缺乏对于多配置的支持(期待6.0的multi event pipeline)。每种日志配置不同,因此需要单独的logstash进程进行消费。

5, logstash mutate替换字符串并remove不必要字段如kafka相关的

业务日志平滑接入:业务日志接入日志系统,只需要进行简单的配置;日志平台也只需要进行一些基本的配置,无须涉及日志内容等业务信息。多样性支持:环境多样:物理机、容器;来源多样:系统日志、业务日志、中间件日志……;格式多样:单行/多行, plain/json。日志挖掘:快速可查,日志监控,统计分析。系统可用性:数据实时性;丢失率可控。Billions的演进系统的初建日志规范

日志检索

elasticsearch集群规模为:master node3, hot node20, stale node20,client node2。es版本为5.4.3,集群配置如下:

  • 数据机器(40core,256G内存, 1T ssd, 6T*4 SATA)采用冷热分离的方案:同时部署一个hot node和stale node。hot node使用ssd作为存储介质,接收实时日志。stale node使用sata盘作为存储介质,存储历史日志(只读不写)。每日固定时间进行热->冷迁移。
  • client node对外提供读取api,对接kibana、管理程序(比如curator、cerebro等)。
  • index管理(迁移、删除)采用curator,日志默认保留7天。
  • es集群配置优化借鉴了很多社区的建议,就不详细介绍了。
  • 使用template进行index mapping的管理。
  • index提前一天进行创建,防止集中创建导致数据无法写入。
  • es监控:调研了官方的x-pack monitor,由于x-pack monitor功能不足(例如缺少对于线程池的监控),并且不能进行报警,最终选择自研。公司内部监控系统基于Prometheus,我们开发了es_exporter负责采集es的状态信息,最终监控报警通过Prometheus实现。报警主要包含关键指标,例如:es cluster的状态信息、thread rejected数量、node节点数量、unassign shard数量。

经过上述步骤,最终日志就可以在kibana上进行查询。第一阶段,日志系统的整体架构为:

计算机网络 3

5,elasticsearch插件需要另外部署node.js,不能像以前一样集成一起

为了解决业务日志格式多样性问题,统一制定了日志格式规范,使用JSON作为日志的输出格式。格式要求:

系统迭代

随着接入的日志量越来越大,渐渐出现一些问题和新的需求,Billions主要在以下方面进行了升级迭代。

6,nginx日志新增request参数、请求方法

必须包含四类元信息:time: 日志产生时间,ISO8601格式level:日志等级, FATAL、ERROR、WARN、INFO、DEBUGapp_id:应用id,用于标示日志来源,与公司服务树一致,全局唯一instance_id:实例id,用于区分同一应用不同实例,格式业务方自行设定日志详细信息统一保存到log字段中。除上述字段之外,业务方也可以自行添加额外的字段。json的mapping应保持不变:key不能随意增加、变化,value的类型也应保持不变。

shard管理

最初采用了es默认的管理策略,所有的index对应5*2个shard(5个primary,5个replica),带来的主要问题如下:

  • 每个shard都是有额外的开销的(内存、文件句柄),大部分的index的数量都比较小,完全没有必要创建5个shard。
  • 某些index的数据量很大(大于500GB/day),单个shard对应的数据量就会很大,这样会导致检索的速度不是最优, 并且磁盘write IO集中在少数机器上。

针对上述问题,开发了index管理模块(shard mng),根据index的历史数据量(昨日数据),决定创建明日index对应shard数量,目前策略为30GB/shard,shard数量上限为15。通过以上优化,集群shard数量降低了70% ,磁盘IO使用也更加高效。

一,架构

例如:

日志采样

某些业务的日志量很大(大于500GB/day),多为业务的访问日志,对日志而言,“大量数据中的一小部分就足以进行问题排查和趋势发现”,与研发和运维进行沟通,这个观点也得到认同。
因此在数据采集源头log agent(collector模块)中增加了日志采样(log sample)功能:

  • 日志采样以app_id为维度,INFO级别以下日志按照比例进行随机采样,WARN以上日志全部保留。
  • log agent接入公司配置中心,采样比例保存在配置中心,可以动态生效。
  • 有个细节额外说明下:由于要获取日志内的app_id字段,如果直接进行json解析, cpu消耗将非常之高。后续我们改进为字符查找(bytes.Index ),解决了这个问题。

针对日志量大的业务进行采样,在不影响使用的情况下,节省了大量的es资源。目前每天减少3T 的日志写入。

可选架构

{log: hello billions, write more, level: INFO, app_id: testapp111, instance_id: instance1, time: 2017-08-04T15:59:01.607483, id: 0}

data node硬件瓶颈解决

晚上20:00-24:00是B站业务的高峰期,同时也是日志流量的高峰期。随着流量的增长,经常收到日志延迟的报警(日志没有及时的写入es),通过观察监控,主要发现两个现象:

  • hot node出现了较多bulk request rejected,同时logstash收到了很多的429响应。尝试调大了thread pool size和 queue_size,但是问题依然存在。
![](https://upload-images.jianshu.io/upload_images/2639164-35adba505bfe145c.png)
  • hot node机器长时间出现io wait现象,同时SSD Disk io Utiliztion 100% 。
![](https://upload-images.jianshu.io/upload_images/2639164-17a21637c326a7b3.png)

billions_io_util.png

通过以上现象,怀疑是SSD IO不足导致的es写入拒绝。后续对SSD进行了性能测试和对比,发现此型机器上SSD的写性能较差。为了减少SSD IO压力,我们将一部分实时写流量迁移到了stale node(stale node之前不接受实时写流量,写入压力很小),日志延迟的问题暂时得以解决。
终极解决办法:data node的机型为40 core CPU,256G内存,1T SSD 4* 6T SATA,很明显此机型SSD从性能和容量上都是瓶颈,为了提升此机型的利用率和解决SSD IO性能瓶颈,最终我们为每台机器添加了2* 1.2T pcie SSD,一劳永逸!

filebeat--elasticsearch--kibana

日志系统技术方案

logstash性能解决

在解决了上述es写入瓶颈后,过了一段时间,高峰期日志延迟的问题又出现了。这次es并没有出现bulk request rejected的问题。 从整条链路进行排查,日志收集和日志传输上都没有出现日志延迟的现象,最终把注意力放在了日志切分模块(logstash)。

logstash性能差是社区内公认的,进一步针对logstash进行性能测试,在(2 core 4G memory)情况下,不断调整worker数量和pipeline.batch.size, 极限性能为8000qps,性能的确很差,高峰期的流量为40W/s, 因此至少需要50个logstash实例才能满足要求,显然这样的资源消耗无法接受。考虑到业务日志对应的切分功能较为单一,因此我们使用go自研了日志切分模块(billions index)。

自研的模块性能有了很大的提升,2 core 4G memory条件下,极限性能提升到5w qps,并且内存只消耗了150M。 线上的资源消耗从(2 core 4G memory)* 30 减少到了(2 core 150M memory)*15,性能问题也得到解决。

filebeat--logstash--kafka--logstash--elasticsearch--kibana

日志从产生到消费,主要经历以下几个阶段:采集-传输-切分-检索。

日志监控

随着越来越多的业务的接入,日志监控的需求越来越强烈。目前社区的解决方案中,Yelp的elastalert最为成熟,功能丰富,并且也方便进行进一步的定制化。因此我们选择基于elastalert实现日志监控。
结合自身需求,通过查看文档和阅读代码,elastalert也有一些不足之处:

  • rule存储在文件中,不可靠并且无法进行分布式扩展。
  • rule配置比较复杂,不够友好和易用。
  • 程序单点,高可用无法保证。
  • 监控规则顺序执行,效率低(如果所有规则执行时间大于执行间隔,单条规则的定期执行将无法保证)。

针对上述不足和自身需要,我们对于elastalert进行了二次开发:

计算机网络 4

主要的改进点包括:

  • 将所有的rule存储在elasticsearch中,即增加了rule存储的可靠性,也为elastalert的分布式实现做好准备。
  • 所有类型的日志监控rule使用模板进行封装,以降低配置复杂度。例如限制使用query string过滤日志,屏蔽某些配置项等等。
  • 封装出一套Restful api进行监控规则的增删改查。
  • 与公司现有监控系统(Bili Moni)结合:基于web配置日志监控,通过报警平台发送报警。
  • 利用全局锁解决单点问题:两个进程一热一冷,热进程故障后冷会自动接手,并进行报警。
  • 对于报警内容进行了调整(格式调整,汉化),表述更加清晰。

日志监控1.0目前已经投入使用,并且还在持续迭代。

最新Billions的架构如下:

计算机网络 5

filebeat--kafka--logstash--elasticsearch--kibana

日志采集

现有问题和下一步工作

目前日志系统还存在很多不足的地方,主要有:

  • 缺乏权限控制:目前权限控制缺失,后续需要实现统一认证、基于index的授权、操作审计等功能,类比xpack。
  • 缺乏全链路监控:日志从产生到可以检索,经过多级模块,目前监控各层独立实现,未进行串联,因此无法对堆积和丢失情况进行精准监控。
  • 日志监控性能瓶颈:目前日志监控为单节点(一个热节点工作)并且规则顺序执行,后续需要优化为分布式架构 规则并行执行。
  • 日志切分配置复杂:对于非标准格式日志,基于logstash实现日志切分,每一种日志需要单独的logstash实例进行消费,配置和上线过程复杂,后续需要平台化的系统进行支撑。

上述不足之处也是下一阶段我们着重改善的地方。除此之外,基于es强大的检索和聚合分析功能,日志更深层次的价值挖掘也是我们探索的方向。我们需要努力的地方还有很多,期待和社区中的伙伴们有更深层次的沟通交流!

由于filebeat5.2.2支持多种输出logstash、elasticsearch、kafka、redis、syslog、file等,为了优化资源使用率且能够支持大并发场景选择

日志采集针对非落盘和落盘两种方式。

filebeat(18)--kafka(3)--logstash(3)--elasticsearch(3)--kibana(3--nginx负载均衡

对于业务模块日志,统一按照日志规范并且通过非落盘的方式进行输出。针对此类场景,与平台技术部合作,基于go我们开发了log agent模块。log agent部署在物理机上,暴露出一个domain sock文件,程序将日志通过unixgram方式输出到domain sock。对于运行在PAAS上的应用,在container初始化的时候,sock文件被默认mount到container内部,这样容器内的程序就可以输出日志。log agent分为两个部分,collector和sender。collector用于接收日志,sender用于向传输系统发送日志。两者直接通过一个文件缓存进行交互。这样在日志传输系统故障的情况下,依赖本地缓存可以保证日志的正常接收。我们提供了不同语言对应的日志库,程序可以快速接入日志系统。非业务模块日志,由于定制化能力较差,我们通过读取生成的日志文件完成日志的采集。我们采用的elastic stack中的filebeat进行采集,filebeat具有方便部署、配置简单、资源消耗低的优势,而且支持多行日志的拼接。物理机上部署一个单独的filebeat进程,每一类日志对应一个单独的配置文件。每一条日志都会被单独打上一个app_id标签,这个类似业务日志的app_id字段,这样在最终消费日志的时候就可以进行区分了。filebeat会自动标示日志来源机器,这样也就具有了区分同一应用不同实例的能力。日志采集

共3台物理机、12台虚拟机、系统CentOS6.8、具体划分如下:

公司内部已经有了统一的数据传输平台,lancer的优势如下:

服务器一(192.168.188.186)

基于flume kafka做二次定制化开发,内部自动负载均衡,容量可水平扩展。数据接收端实现了一套可靠的数据传输协议,完善的链路监控,数据传输安全可靠。可以根据业务需要对接不同的消费方式。有专业的团队进行7*24维护。

kafka1  32G700G4CPU

因此我们直接选择lancer作为我们的日志传输系统。

logstash8G      100G    4CPU

log agent中的sender模块基于lancer的定制化的数据传输协议发送日志,最终日志被传输到kafka集群中的不同topic,后续从kafka消费日志,所有的topic采用一个统一的prefix。由于暂时没有精力对filebeat进行二次定制化开发,因此filebeat直接将日志输出到lancer的kafka集群。日志切分

elasticsearch1  40G1.4T    8CPU

日志切分模块的主要作用是从kafka消费日志,对日志进行处理,最终存储到elasticsearch的对应的index中。我们使用logstash作为我们的日志切分方案。

elasticsearch2  40G     1.4T    8CPU

其中:

服务器二(192.168.188.187)

对于按照日志规范生成的日志,日志的kafka topic采用了统一的前缀,因此我们采用topics_pattern的方式来消费日志。logstash的partition_assignment_strategy要设置为”org.apache.kafka.clients.consumer.RoundRobinAssignor”,默认的策略会导致partition分配不均,如果采用默认的策略,当consumer的数量大于topic partition数量时,partition总是只会被分配给固定的一部分consumer。对于非标准格式日志,由于logstash single event pipeline的限制,因此缺乏对于多配置的支持。每种日志配置不同,因此需要单独的logstash进程进行消费。日志检索

kafka2  32G700G4CPU

elasticsearch集群规模为:master node**3, hot node**20, stale node**20,client node**2。es版本为5.4.3,集群配置如下:

logstash8G      100G    4CPU

数据机器采用冷热分离的方案:同时部署一个hot node和stale node。hot node使用ssd作为存储介质,接收实时日志。stale node使用sata盘作为存储介质,存储历史日志。每日固定时间进行热-冷迁移。client node对外提供读取api,对接kibana、管理程序。index管理采用curator,日志默认保留7天。es集群配置优化借鉴了很多社区的建议,就不详细介绍了。使用template进行index mapping的管理。index提前一天进行创建,防止集中创建导致数据无法写入。es监控:调研了官方的x-pack monitor,由于x-pack monitor功能不足,并且不能进行报警,最终选择自研。公司内部监控系统基于Prometheus,我们开发了es_exporter负责采集es的状态信息,最终监控报警通过Prometheus实现。报警主要包含关键指标,例如:es cluster的状态信息、thread rejected数量、node节点数量、unassign shard数量。

elasticsearch3  40G1.4T    8CPU

经过上述步骤,最终日志就可以在kibana上进行查询。第一阶段,日志系统的整体架构为:

elasticsearch4  40G     1.4T    8CPU

系统迭代

服务器三(192.168.188.188)

随着接入的日志量越来越大,渐渐出现一些问题和新的需求,Billions主要在以下方面进行了升级迭代。

kafka3  32G700G4CPU

shard管理

logstash8G      100G    4CPU

最初采用了es默认的管理策略,所有的index对应5*2个shard,带来的主要问题如下:

elasticsearch5  40G1.4T    8CPU

每个shard都是有额外的开销的,大部分的index的数量都比较小,完全没有必要创建5个shard。某些index的数据量很大,单个shard对应的数据量就会很大,这样会导致检索的速度不是最优, 并且磁盘write IO集中在少数机器上。

elasticsearch6  40G     1.4T    8CPU

针对上述问题,开发了index管理模块,根据index的历史数据量,决定创建明日index对应shard数量,目前策略为30GB/shard,shard数量上限为15。通过以上优化,集群shard数量降低了70% ,磁盘IO使用也更加高效。

磁盘分区

日志采样

Logstach     100G

某些业务的日志量很大,多为业务的访问日志,对日志而言,“大量数据中的一小部分就足以进行问题排查和趋势发现”,与研发和运维进行沟通,这个观点也得到认同。因此在数据采集源头log agent中增加了日志采样功能:

SWAP  8G/boot200M  剩下/

日志采样以app_id为维度,INFO级别以下日志按照比例进行随机采样,WARN以上日志全部保留。log agent接入公司配置中心,采样比例保存在配置中心,可以动态生效。有个细节额外说明下:由于要获取日志内的app_id字段,如果直接进行json解析, cpu消耗将非常之高。后续我们改进为字符查找,解决了这个问题。

Kafka       700G

针对日志量大的业务进行采样,在不影响使用的情况下,节省了大量的es资源。目前每天减少3T 的日志写入。

SWAP  8G/boot200M/30G剩下/data

data node硬件瓶颈解决

Elasticsearch 1.4T

晚上20:00-24:00是B站业务的高峰期,同时也是日志流量的高峰期。随着流量的增长,经常收到日志延迟的报警,通过观察监控,主要发现两个现象:

SWAP  8G/boot200M/30G剩下/data

hot node出现了较多bulk request rejected,同时logstash收到了很多的429响应。尝试调大了thread pool size和 queue_size,但是问题依然存在。

IP分配

hot node机器长时间出现io wait现象,同时SSD Disk io Utiliztion 100% 。

Elasticsearch1-6     192.168.188.191-196

通过以上现象,怀疑是SSD IO不足导致的es写入拒绝。后续对SSD进行了性能测试和对比,发现此型机器上SSD的写性能较差。为了减少SSD IO压力,我们将一部分实时写流量迁移到了stale node,日志延迟的问题暂时得以解决。终极解决办法:data node的机型为40 core CPU,256G内存,1T SSD 4*6T SATA,很明显此机型SSD从性能和容量上都是瓶颈,为了提升此机型的利用率和解决SSD IO性能瓶颈,最终我们为每台机器添加了2*1.2T pcie SSD,一劳永逸!

kibana1-3              192.168.188.191/193/195

logstash性能解决

kafka1-3                192.168.188.237-239

在解决了上述es写入瓶颈后,过了一段时间,高峰期日志延迟的问题又出现了。这次es并没有出现bulk request rejected的问题。 从整条链路进行排查,日志收集和日志传输上都没有出现日志延迟的现象,最终把注意力放在了日志切分模块。

logstash                192.168.188.238/198/240

logstash性能差是社区内公认的,进一步针对logstash进行性能测试,在情况下,不断调整worker数量和pipeline.batch.size, 极限性能为8000qps,性能的确很差,高峰期的流量为40W/s, 因此至少需要50个logstash实例才能满足要求,显然这样的资源消耗无法接受。考虑到业务日志对应的切分功能较为单一,因此我们使用go自研了日志切分模块。

二,环境准备

自研的模块性能有了很大的提升,2 core 4G memory条件下,极限性能提升到5w qps,并且内存只消耗了150M。 线上的资源消耗从 30 减少到了15,性能问题也得到解决。

yum -y remove java-1.6.0-openjdk

日志监控

yum -y remove java-1.7.0-openjdk

随着越来越多的业务的接入,日志监控的需求越来越强烈。目前社区的解决方案中,Yelp的elastalert最为成熟,功能丰富,并且也方便进行进一步的定制化。因此我们选择基于elastalert实现日志监控。结合自身需求,通过查看文档和阅读代码,elastalert也有一些不足之处:

yum -y remove perl-*

rule存储在文件中,不可靠并且无法进行分布式扩展。rule配置比较复杂,不够友好和易用。程序单点,高可用无法保证。监控规则顺序执行,效率低。

yum -y remove sssd-*

针对上述不足和自身需要,我们对于elastalert进行了二次开发:

yum -yinstalljava-1.8.0-openjdk

主要的改进点包括:

java -version

将所有的rule存储在elasticsearch中,即增加了rule存储的可靠性,也为elastalert的分布式实现做好准备。所有类型的日志监控rule使用模板进行封装,以降低配置复杂度。例如限制使用query string过滤日志,屏蔽某些配置项等等。封装出一套Restful api进行监控规则的增删改查。与公司现有监控系统结合:基于web配置日志监控,通过报警平台发送报警。利用全局锁解决单点问题:两个进程一热一冷,热进程故障后冷会自动接手,并进行报警。对于报警内容进行了调整,表述更加清晰。

yum update

日志监控1.0目前已经投入使用,并且还在持续迭代。

reboot

最新Billions的架构如下:

设置host环境kafka需要用到

现有问题和下一步工作

cat /etc/hosts

目前日志系统还存在很多不足的地方,主要有:

12192.168.188.191   ES191(master和data)

缺乏权限控制:目前权限控制缺失,后续需要实现统一认证、基于index的授权、操作审计等功能,类比xpack。缺乏全链路监控:日志从产生到可以检索,经过多级模块,目前监控各层独立实现,未进行串联,因此无法对堆积和丢失情况进行精准监控。日志监控性能瓶颈:目前日志监控为单节点并且规则顺序执行,后续需要优化为分布式架构 规则并行执行。日志切分配置复杂:对于非标准格式日志,基于logstash实现日志切分,每一种日志需要单独的logstash实例进行消费,配置和上线过程复杂,后续需要平台化的系统进行支撑。

192.168.188.192   ES192(data)

上述不足之处也是下一阶段我们着重改善的地方。除此之外,基于es强大的检索和聚合分析功能,日志更深层次的价值挖掘也是我们探索的方向。我们需要努力的地方还有很多,期待和社区中的伙伴们有更深层次的沟通交流!

192.168.188.193   ES193(master和data)

原文来自微信公众号:高效运维

192.168.188.194   ES194(data)

192.168.188.195   ES195(master和data)

192.168.188.196   ES196(data)

192.168.188.237   kafka237

192.168.188.238   kafka238

192.168.188.239   kafka239

192.168.188.197   logstash197

192.168.188.198   logstash198

192.168.188.240   logstash240

三,部署elasticsearch集群

mkdir /data/esnginx

mkdir /data/eslog

rpm -ivh /srv/elasticsearch-5.2.2.rpm

chkconfig --add elasticsearch

chkconfig postfix off

rpm -ivh /srv/kibana-5.2.2-x86_64.rpm

chown  elasticsearch:elasticsearch /data/eslog -R

chown  elasticsearch:elasticsearch /data/esnginx -R

配置文件(3master 6data)

[root@ES191 elasticsearch]# cat elasticsearch.yml|grep -Ev '^#|^$'

cluster.name: nginxlog

node.name: ES191

node.master:true

node.data:true

node.attr.rack: r1

path.data:/data/esnginx

path.logs:/data/eslog

bootstrap.memory_lock:true

network.host: 192.168.188.191

http.port: 9200

transport.tcp.port: 9300

discovery.zen.ping.unicast.hosts: ["192.168.188.191","192.168.188.192","192.168.188.193","192.168.188.194","192.168.188.195","192.168.188.196"]

discovery.zen.minimum_master_nodes: 2

gateway.recover_after_nodes: 5

gateway.recover_after_time: 5m

gateway.expected_nodes: 6

cluster.routing.allocation.same_shard.host:true

script.engine.groovy.inline.search: on

script.engine.groovy.inline.aggs: on

indices.recovery.max_bytes_per_sec: 30mb

http.cors.enabled:true

http.cors.allow-origin:"*"

bootstrap.system_call_filter:false#内核3.0以下的需要,centos7内核3.10不需要

特别注意

/etc/security/limits.conf

elasticsearch  soft  memlock  unlimited

elasticsearch  hard  memlock  unlimited

elasticsearch  soft  nofile   65536

elasticsearch  hard  nofile   131072

elasticsearch  soft  nproc    2048

elasticsearch  hard  nproc    4096

/etc/elasticsearch/jvm.options

# Xms represents the initial size of total heap space

# Xmx represents the maximum size of total heap space

-Xms20g

-Xmx20g

启动集群

service elasticsearch start

健康检查

{

"cluster_name":"nginxlog",

"status":"green",

"timed_out":false,

"number_of_nodes": 6,

"number_of_data_nodes": 6,

"active_primary_shards": 0,

"active_shards": 0,

"relocating_shards": 0,

"initializing_shards": 0,

"unassigned_shards": 0,

"delayed_unassigned_shards": 0,

"number_of_pending_tasks": 0,

"number_of_in_flight_fetch": 0,

"task_max_waiting_in_queue_millis": 0,

"active_shards_percent_as_number": 100.0

}

elasticsearch-head插件

连接上面192.168.188.191:9200任意一台即可

设置分片

官方建议生成索引时再设置

curl -XPUT '' -d '{

"index.number_of_replicas" : "1",

"index.number_of_shards" : "6"

}'

没有生效,后来发现这个分片设置可以在模版创建时指定,目前还是使用默认1副本,5分片。

其他报错(这个只是参考,优化时有方案)

bootstrap.system_call_filter: false   # 针对 system call filters failed to install,

参见

[WARN ][o.e.b.JNANatives ] unable to install syscall filter:

java.lang.UnsupportedOperationException: seccomp unavailable: requires kernel 3.5 with CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER compiled in

四、部署kafka集群

kafka集群搭建

1,zookeeper集群

wget 

tarzxvf zookeeper-3.4.10.tar.gz -C/usr/local/

ln-s/usr/local/zookeeper-3.4.10//usr/local/zookeeper

mkdir-p/data/zookeeper/data/

vim/usr/local/zookeeper/conf/zoo.cfg

tickTime=2000

initLimit=5

syncLimit=2

dataDir=/data/zookeeper/data

clientPort=2181

server.1=192.168.188.237:2888:3888

server.2=192.168.188.238:2888:3888

server.3=192.168.188.239:2888:3888

vim/data/zookeeper/data/myid

1

/usr/local/zookeeper/bin/zkServer.sh start

2,kafka集群

wget

tar zxvf kafka_2.11-0.10.0.1.tgz -C /usr/local/

ln -s /usr/local/kafka_2.11-0.10.0.1 /usr/local/kafka

diff了下server.properties和zookeeper.properties变动不大可以直接使用

vim /usr/local/kafka/config/server.properties

broker.id=237

port=9092

host.name=192.168.188.237

num.network.threads=4

num.io.threads=8

socket.send.buffer.bytes=102400

socket.receive.buffer.bytes=102400

socket.request.max.bytes=104857600

log.dirs=/data/kafkalog

num.partitions=3

num.recovery.threads.per.data.dir=1

log.retention.hours=24

log.segment.bytes=1073741824

log.retention.check.interval.ms=300000

log.cleaner.enable=false

zookeeper.connect=192.168.188.237:2181,192.168.188.238:2181,192.168.188.239:237

zookeeper.connection.timeout.ms=6000

producer.type=async

broker.list=192.168.188.237:9092,192.168.188.238:9092,192.168.188.239:9092

mkdir /data/kafkalog

修改内存使用大小

vim /usr/local/kafka/bin/kafka-server-start.sh

export KAFKA_HEAP_OPTS="-Xmx16G -Xms16G"

启动kafka

/usr/local/kafka/bin/kafka-server-start.sh /usr/local/kafka/config/server.properties

创建六组前端topic

/usr/local/kafka/bin/kafka-topics.sh --create --topic ngx1-168 --replication-factor 1 --partitions 3 --zookeeper 192.168.188.237:2181,192.168.188.238:2181,192.168.188.239:2181

/usr/local/kafka/bin/kafka-topics.sh --create --topic ngx2-178 --replication-factor 1 --partitions 3 --zookeeper  192.168.188.237:2181,192.168.188.238:2181,192.168.188.239:2181

/usr/local/kafka/bin/kafka-topics.sh --create --topic ngx3-188 --replication-factor 1 --partitions 3 --zookeeper  192.168.188.237:2181,192.168.188.238:2181,192.168.188.239:2181

检查topic

/usr/local/kafka/bin/kafka-topics.sh --list --zookeeper  192.168.188.237:2181,192.168.188.238:2181,192.168.188.239:2181

ngx1-168

ngx2-178

ngx3-188

3,开机启动

cat /etc/rc.local

/usr/local/zookeeper/bin/zkServer.sh start

/usr/local/kafka/bin/kafka-server-start.sh /usr/local/kafka/config/server.properties &

五,部署配置logstash

安装

rpm -ivh logstash-5.2.2.rpm

mkdir /usr/share/logstash/config

#1. 复制配置文件到logstash home

cp /etc/logstash /usr/share/logstash/config

#2. 配置路径

vim /usr/share/logstash/config/logstash.yml

修改前:

path.config: /etc/logstash/conf.d

修改后:

path.config: /usr/share/logstash/config/conf.d

#3.修改 startup.options

修改前:

LS_SETTINGS_DIR=/etc/logstash

修改后:

LS_SETTINGS_DIR=/usr/share/logstash/config

修改startup.options需要执行/usr/share/logstash/bin/system-install 生效

配置

消费者输出端3个logstash只负责一部分

in-kafka-ngx1-out-es.conf

in-kafka-ngx2-out-es.conf

in-kafka-ngx3-out-es.conf

[root@logstash197 conf.d]# cat in-kafka-ngx1-out-es.conf

input {

kafka {

bootstrap_servers =>"192.168.188.237:9092,192.168.188.238:9092,192.168.188.239:9092"

group_id =>"ngx1"

topics => ["ngx1-168"]

codec =>"json"

consumer_threads => 3

decorate_events =>true

}

}

filter {

mutate {

gsub => ["message","\x","%"]

remove_field => ["kafka"]

}

json {

source=>"message"

remove_field => ["message"]

}

geoip {

source=>"clientRealIp"

}

urldecode {

all_fields =>true

}

}

output {

elasticsearch {

hosts => ["192.168.188.191:9200","192.168.188.192:9200","192.168.188.193:9200","192.168.188.194:9200","192.168.188.195:9200","192.168.188.196:9200"]

index =>"filebeat-%{type}-%{ YYYY.MM.dd}"

manage_template =>true

template_overwrite =>true

template_name =>"nginx_template"

template =>"/usr/share/logstash/templates/nginx_template"

flush_size => 50000

idle_flush_time => 10

}

}

nginx 模版

[root@logstash197 logstash]# cat /usr/share/logstash/templates/nginx_template

{

"template":"filebeat-*",

"settings": {

"index.refresh_interval":"10s"

},

"mappings": {

"_default_": {

"_all": {"enabled":true,"omit_norms":true},

"dynamic_templates": [

{

"string_fields": {

"match_pattern":"regex",

"match":"(agent)|(status)|(url)|(clientRealIp)|(referrer)|(upstreamhost)|(http_host)|(request)|(request_method)|(upstreamstatus)",

"match_mapping_type":"string",

"mapping": {

"type":"string","index":"analyzed","omit_norms":true,

"fields": {

"raw": {"type":"string","index":"not_analyzed","ignore_above": 512}

}

}

}

} ],

"properties": {

"@version": {"type":"string","index":"not_analyzed"},

"geoip": {

"type":"object",

"dynamic":true,

"properties": {

"location": {"type":"geo_point"}

}

}

}

}

}

}

启动

/usr/share/logstash/bin/logstash -f /usr/share/logstash/config/conf.d/in-kafka-ngx1-out-es.conf  &

默认logstash开机启动

参考

/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-output-kafka-5.1.5/DEVELOPER.md

报错处理

[2017-05-08T12:24:30,388][ERROR][logstash.inputs.kafka    ] Unknown setting 'zk_connect' for kafka

[2017-05-08T12:24:30,390][ERROR][logstash.inputs.kafka    ] Unknown setting 'topic_id' for kafka

[2017-05-08T12:24:30,390][ERROR][logstash.inputs.kafka    ] Unknown setting 'reset_beginning' for kafka

[2017-05-08T12:24:30,395][ERROR][logstash.agent           ] Cannot load an invalid configuration {:reason=>"Something is wrong with your configuration."}

验证日志

[root@logstash197 conf.d]# cat /var/log/logstash/logstash-plain.log

[2017-05-09T10:43:20,832][INFO ][logstash.outputs.elasticsearch] Elasticsearch pool URLs updated {:changes=>{:removed=>[], :added=>[, , , , , 

[2017-05-09T10:43:20,838][INFO ][logstash.outputs.elasticsearch] Running health check to seeifan Elasticsearch connection is working {:healthcheck_url=>, :path=>"/"}

[2017-05-09T10:43:20,919][WARN ][logstash.outputs.elasticsearch] Restored connection to ES instance {:url=>#}

[2017-05-09T10:43:20,920][INFO ][logstash.outputs.elasticsearch] Running health check to seeifan Elasticsearch connection is working {:healthcheck_url=>, :path=>"/"}

[2017-05-09T10:43:20,922][WARN ][logstash.outputs.elasticsearch] Restored connection to ES instance {:url=>#}

[2017-05-09T10:43:20,924][INFO ][logstash.outputs.elasticsearch] Running health check to seeifan Elasticsearch connection is working {:healthcheck_url=>, :path=>"/"}

[2017-05-09T10:43:20,927][WARN ][logstash.outputs.elasticsearch] Restored connection to ES instance {:url=>#}

[2017-05-09T10:43:20,927][INFO ][logstash.outputs.elasticsearch] Running health check to seeifan Elasticsearch connection is working {:healthcheck_url=>, :path=>"/"}

[2017-05-09T10:43:20,929][WARN ][logstash.outputs.elasticsearch] Restored connection to ES instance {:url=>#}

[2017-05-09T10:43:20,930][INFO ][logstash.outputs.elasticsearch] Running health check to seeifan Elasticsearch connection is working {:healthcheck_url=>, :path=>"/"}

[2017-05-09T10:43:20,932][WARN ][logstash.outputs.elasticsearch] Restored connection to ES instance {:url=>#}

[2017-05-09T10:43:20,933][INFO ][logstash.outputs.elasticsearch] Running health check to seeifan Elasticsearch connection is working {:healthcheck_url=>, :path=>"/"}

[2017-05-09T10:43:20,935][WARN ][logstash.outputs.elasticsearch] Restored connection to ES instance {:url=>#}

[2017-05-09T10:43:20,936][INFO ][logstash.outputs.elasticsearch] Using mapping template from {:path=>"/usr/share/logstash/templates/nginx_template"}

[2017-05-09T10:43:20,970][INFO ][logstash.outputs.elasticsearch] Attempting toinstalltemplate {:manage_template=>{"template"=>"filebeat-*","settings"=>{"index.refresh_interval"=>"10s"},"mappings"=>{"_default_"=>{"_all"=>{"enabled"=>true,"omit_norms"=>true},"dynamic_templates"=>[{"string_fields"=>{"match_pattern"=>"regex","match"=>"(agent)|(status)|(url)|(clientRealIp)|(referrer)|(upstreamhost)|(http_host)|(request)|(request_method)","match_mapping_type"=>"string","mapping"=>{"type"=>"string","index"=>"analyzed","omit_norms"=>true,"fields"=>{"raw"=>{"type"=>"string","index"=>"not_analyzed","ignore_above"=>512}}}}}]}}}}

[2017-05-09T10:43:20,974][INFO ][logstash.outputs.elasticsearch] Installing elasticsearch template to _template/nginx_template

[2017-05-09T10:43:21,009][INFO ][logstash.outputs.elasticsearch] New Elasticsearch output {:class=>"LogStash::Outputs::ElasticSearch", :hosts=>[#, #, #, #, #, #]}

[2017-05-09T10:43:21,010][INFO ][logstash.filters.geoip   ] Using geoip database {:path=>"/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-filter-geoip-4.0.4-java/vendor/GeoLite2-City.mmdb"}

[2017-05-09T10:43:21,022][INFO ][logstash.pipeline        ] Starting pipeline {"id"=>"main","pipeline.workers"=>4,"pipeline.batch.size"=>125,"pipeline.batch.delay"=>5,"pipeline.max_inflight"=>500}

[2017-05-09T10:43:21,037][INFO ][logstash.pipeline        ] Pipeline main started

[2017-05-09T10:43:21,086][INFO ][logstash.agent           ] Successfully started Logstash API endpoint {:port=>9600}

六,部署配置filebeat

安装

rpm -ivh filebeat-5.2.2-x86_64.rpm

nginx日志格式需要为json的

log_format access'{ "@timestamp": "$time_iso8601", '

'"clientRealIp": "$clientRealIp", '

'"size": $body_bytes_sent, '

'"request": "$request", '

'"method": "$request_method", '

'"responsetime": $request_time, '

'"upstreamhost": "$upstream_addr", '

'"http_host": "$host", '

'"url": "$uri", '

'"referrer": "$http_referer", '

'"agent": "$http_user_agent", '

'"status": "$status"} ';

配置filebeat

vim /etc/filebeat/filebeat.yml

filebeat.prospectors:

- input_type: log

paths:

-/data/wwwlogs/*.log

document_type: ngx1-168

tail_files:true

json.keys_under_root:true

json.add_error_key:true

output.kafka:

enabled:true

hosts: ["192.168.188.237:9092","192.168.188.238:9092","192.168.188.239:9092"]

topic:'%{[type]}'

partition.round_robin:

reachable_only:false

required_acks: 1

compression:gzip

max_message_bytes: 1000000

worker: 3

processors:

- drop_fields:

fields: ["input_type","beat.hostname","beat.name","beat.version","offset","source"]

logging.to_files:true

logging.files:

path:/var/log/filebeat

name: filebeat

rotateeverybytes: 10485760# = 10MB

keepfiles: 7

filebeat详细配置参考官网

采用kafka作为日志输出端

output.kafka:

# initial brokers for reading cluster metadata

hosts: ["kafka1:9092", "kafka2:9092", "kafka3:9092"]

# message topic selection partitioning

topic: '%{[type]}'

partition.round_robin:

reachable_only: false

required_acks: 1

compression: gzip

max_message_bytes: 1000000

启动

chkconfig filebeat on

/etc/init.d/filebeat start

报错处理

[root@localhost ~]# tail -f /var/log/filebeat/filebeat

2017-05-09T15:21:39 08:00 ERR Error decoding JSON: invalid character 'x' in string escape code

使用$uri 可以在nginx对URL进行更改或重写,但是用于日志输出可以使用$request_uri代替,如无特殊业务需求,完全可以替换

参考

七,验证

1,kafka消费者查看

/usr/local/kafka/bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic ngx1-168

2,elasticserch head查看Index及分片信息

八,部署配置kibana

1,配置启动

cat /etc/kibana/kibana.yml

server.port: 5601

server.host: "192.168.188.191"

elasticsearch.url: ""

chkconfig --add kibana

/etc/init.d/kibana start

2,字段格式

{

"_index":"filebeat-ngx1-168-2017.05.10",

"_type":"ngx1-168",

"_id":"AVvvtIJVy6ssC9hG9dKY",

"_score": null,

"_source": {

"request":"GET /qiche/奥迪A3/ HTTP/1.1",

"agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36",

"geoip": {

"city_name":"Jinhua",

"timezone":"Asia/Shanghai",

"ip":"122.226.77.150",

"latitude": 29.1068,

"country_code2":"CN",

"country_name":"China",

"continent_code":"AS",

"country_code3":"CN",

"region_name":"Zhejiang",

"location": [

119.6442,

29.1068

],

"longitude": 119.6442,

"region_code":"33"

},

"method":"GET",

"type":"ngx1-168",

"http_host":"www.niubi.com",

"url":"/qiche/奥迪A3/",

"referrer":"",

"upstreamhost":"172.17.4.205:80",

"@timestamp":"2017-05-10T08:14:00.000Z",

"size": 10027,

"beat": {},

"@version":"1",

"responsetime": 0.217,

"clientRealIp":"122.226.77.150",

"status":"200"

},

"fields": {

"@timestamp": [

1494404040000

]

},

"sort": [

1494404040000

]

}

3,视图仪表盘

1),添加高德地图

编辑kibana配置文件kibana.yml,最后面添加

tilemap.url: ''

ES 模版的调整,Geo-points 不适用 dynamic mapping 因此这类项目需要显式的指定:

需要将 geoip.location 指定为 geo_point 类型,则在模版的 properties 中增加一个项目,如下所示:

"properties": {

"@version": { "type": "string", "index": "not_analyzed" },

"geoip"  : {

"type": "object",

"dynamic": true,

"properties": {

"location": { "type": "geo_point" }

}

}

}

4,安装x-pack插件

参考

注意要修改密码

或者

curl -XPUT 'localhost:9200/_xpack/security/user/elastic/_password?pretty' -H 'Content-Type: application/json' -d'

{

"password": "elasticpassword"

}

'

curl -XPUT 'localhost:9200/_xpack/security/user/kibana/_password?pretty' -H 'Content-Type: application/json' -d'

{

"password": "kibanapassword"

}

'

curl -XPUT 'localhost:9200/_xpack/security/user/logstash_system/_password?pretty' -H 'Content-Type: application/json' -d'

{

"password": "logstashpassword"

}

'

下面是官网x-pack安装升级卸载文档,后发现注册版本的x-pack,只具有监控功能,就没安装

Installing X-Pack on Offline Machines

The plugininstallscripts require direct Internet access to download andinstallX-Pack. If your server doesn’t have Internet access, you can manually download andinstallX-Pack.

ToinstallX-Pack on a machine that doesn’t have Internet access:

Manually download the X-Pack zipfile:  (sha1)

Transfer the zipfileto a temporary directory on the offline machine. (Do NOT put thefileinthe Elasticsearch plugins directory.)

Run bin/elasticsearch-plugininstallfrom the Elasticsearchinstalldirectory and specify the location of the X-Pack zipfile. For example:

bin/elasticsearch-plugininstallfile:///path/to/file/x-pack-5.2.2.zip

Note

You must specify an absolute path to the zipfileafter thefile://protocol.

Run bin/kibana-plugininstallfrom the Kibanainstalldirectory and specify the location of the X-Pack zipfile. (The pluginsforElasticsearch, Kibana, and Logstash are includedinthe same zipfile.) For example:

bin/kibana-plugininstallfile:///path/to/file/x-pack-5.2.2.zip

Run bin/logstash-plugininstallfrom the Logstashinstalldirectory and specify the location of the X-Pack zipfile. (The pluginsforElasticsearch, Kibana, and Logstash are includedinthe same zipfile.) For example:

bin/logstash-plugininstallfile:///path/to/file/x-pack-5.2.2.zip

Enabling and Disabling X-Pack Features

By default, all X-Pack features are enabled. You can explicitlyenableor disable X-Pack featuresinelasticsearch.yml and kibana.yml:

SettingDescription

xpack.security.enabled

Set tofalseto disable X-Pack security. Configureinboth elasticsearch.yml and kibana.yml.

xpack.monitoring.enabled

Set tofalseto disable X-Pack monitoring. Configureinboth elasticsearch.yml and kibana.yml.

xpack.graph.enabled

Set tofalseto disable X-Pack graph. Configureinboth elasticsearch.yml and kibana.yml.

xpack.watcher.enabled

Set tofalseto disable Watcher. Configureinelasticsearch.yml only.

xpack.reporting.enabled

Set tofalseto disable X-Pack reporting. Configureinkibana.yml only.

九、Nginx负载均衡

1,配置负载

[root@~# cat /usr/local/nginx/conf/nginx.conf

server

{

listen   5601;

server_name 192.168.188.215;

index index.html index.htm index.shtml;

location / {

allow  192.168.188.0/24;

deny all;

proxy_pass ;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection'upgrade';

proxy_set_header Host $host;

proxy_cache_bypass $http_upgrade;

auth_basic"Please input Username and Password";

auth_basic_user_file/usr/local/nginx/conf/.pass_file_elk;

}

access_log/data/wwwlogs/access_kibanangx.niubi.com.log  access;

}

upstream kibanangx_niubi_com {

ip_hash;

server  192.168.188.191:5601;

server  192.168.188.193:5601;

server  192.168.188.195:5601;

}

2,访问


完美的分割线


优化文档

ELKB5.2集群优化方案

一,优化效果

优化前

收集日志请求达到1万/s,延时10s内,默认设置数据10s刷新。

优化后

收集日志请求达到3万/s,延时10s内,默认设置数据10s刷新。(预估可以满足最大请求5万/s)

缺点:CPU处理能力不足,在dashboard大时间聚合运算是生成仪表视图会有超时现象发生;另外elasticsarch结构和搜索语法等还有进一步优化空间。

二,优化步骤

1,内存和CPU重新规划

1),es16CPU  48G内存

2),kafka8CPU   16G内存

3),logstash            16CPU  12G内存

2,kafka优化

kafka manager 监控观察消费情况

kafka heap size需要修改

logstash涉及kafka的一个参数修改

1),修改jvm内存数

vi /usr/local/kafka/bin/kafka-server-start.sh

if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then

export KAFKA_HEAP_OPTS="-Xmx8G -Xms8G"

export JMX_PORT="8999"

fi

2),Broker参数配置

配置优化都是修改server.properties文件中参数值

网络和io操作线程配置优化

# broker处理消息的最大线程数(默认3,可以为CPU核数)

num.network.threads=4

# broker处理磁盘IO的线程数 (默认4,可以为CPU核数2倍左右)

num.io.threads=8

3),安装kafka监控

/data/scripts/kafka-manager-1.3.3.4/bin/kafka-manager

3,logstah优化

logstas需要修改2个配置文件

1),修改jvm参数

vi /usr/share/logstash/config/jvm.options

-Xms2g

-Xmx6g

2),修改logstash.yml

vi /usr/share/logstash/config/logstash.yml

path.data: /var/lib/logstash

pipeline.workers: 16#cpu核心数

pipeline.output.workers: 4#这里相当于output elasticsearch里面的workers数

pipeline.batch.size: 5000#根据qps,压力情况等填写

pipeline.batch.delay: 5

path.config: /usr/share/logstash/config/conf.d

path.logs: /var/log/logstash

3),修改对应的logstash.conf文件

input文件

vi /usr/share/logstash/config/in-kafka-ngx12-out-es.conf

input {

kafka {

bootstrap_servers =>"192.168.188.237:9092,192.168.188.238:9092,192.168.188.239:9092"

group_id =>"ngx1"

topics => ["ngx1-168"]

codec =>"json"

consumer_threads => 3

auto_offset_reset =>"latest"#添加这行

#decorate_events =>   #true 这行去掉

}

}

filter文件

filter {

mutate {

gsub => ["message","\x","%"]#这个是转义,url里面的加密方式和request等不一样,用于汉字显示

#remove_field => ["kafka"]这行去掉  decorate events 默认false后就不添加kafka.{}字段了,这里也及不需要再remove了

}

output文件

修改前

flush_size => 50000

idle_flush_time => 10

修改后

4秒集齐8万条一次性输出

flush_size => 80000

idle_flush_time => 4

启动后logstash输出(pipeline.max_inflight是8万)

[2017-05-16T10:07:02,552][INFO ][logstash.pipeline        ] Starting pipeline {"id"=>"main","pipeline.workers"=>16,"pipeline.batch.size"=>5000,"pipeline.batch.delay"=>5,"pipeline.max_inflight"=>80000}

[2017-05-16T10:07:02,553][WARN ][logstash.pipeline        ] CAUTION: Recommended inflight events max exceeded! Logstash will run with up to 80000 eventsinmemoryinyour current configuration. If your message sizes are large this may cause instability with the default heap size. Please consider setting a non-standard heap size, changing the batch size (currently 5000), or changing the number of pipeline workers (currently 16)

4,elasticsearch优化

1),修改jvm参加

vi /etc/elasticsearch/jvm.options

调整为24g,最大为虚拟机内存的50%

-Xms24g

-Xmx24g

2),修改GC方法(待定,后续观察,该参数不确定时不建议修改)

elasticsearch默认使用的GC是CMS GC

如果你的内存大小超过6G,CMS是不给力的,容易出现stop-the-world

建议使用G1 GC

注释掉:

JAVA_OPTS=”$JAVA_OPTS -XX: UseParNewGC”

JAVA_OPTS=”$JAVA_OPTS -XX: UseConcMarkSweepGC”

JAVA_OPTS=”$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75″

JAVA_OPTS=”$JAVA_OPTS -XX: UseCMSInitiatingOccupancyOnly”

修改为:

JAVA_OPTS=”$JAVA_OPTS -XX: UseG1GC”

JAVA_OPTS=”$JAVA_OPTS -XX:MaxGCPauseMillis=200″

3),安装elasticsearch集群监控工具Cerebro

Cerebro 时一个第三方的 elasticsearch 集群管理软件,可以方便地查看集群状态:

安装后访问地址

4),elasticsearch搜索参数优化(难点问题)

发现没事可做的,首先默认配置已经很好了,其次bulk,刷新等配置里都写好了

5),elasticsarch集群角色优化

es191,es193,es195只做master节点 ingest节点

es192,es194,es196只做data节点(上面是虚拟机2个虚拟机共用一组raid5磁盘,如果都做data节点性能表现不好)

再加2个data节点,这样聚合计算性能提升很大

5,filebeat优化

1),使用json格式输入,这样logstash就不需要dcode减轻后端压力

json.keys_under_root: true

json.add_error_key: true

2),drop不必要的字段如下

vim /etc/filebeat/filebeat.yml

processors:

- drop_fields:

fields: ["input_type", "beat.hostname", "beat.name", "beat.version", "offset", "source"]

3),计划任务删索引

index默认保留5天

cat /data/scripts/delindex.sh

#!/bin/bash

OLDDATE=`date-d  -5days   %Y.%m.%d`

echo$OLDDATE1

curl -XDELETE 

curl -XDELETE 

curl -XDELETE 

编辑:计算机网络 本文来源:B站日志系统的前生今生,2集群意况安插计划优化

关键词: 亚洲城ca88