logstash好说,client只需要在代码逻辑改下redis地址就可以了,logstash server直接docker pull镜像就可以了。
elasticsearch需要我们自己写脚本迁移,因为跨机房导入导出,挺费工夫的,关于elasticsearch的迁移,我下篇再写,今天主要写kibana的迁移。
kibana配置的迁移,他的配置是在elasticsearch里面,下图就是elasticsearch里kibana的配置信息。
业务和日志的elasticsearch都是一个集群,业务的数据肯定是迁移过去的,至于日志就算了… 我们这的日志,每个月有几十T,这对于迁移来说,很是繁重… 索性直接干掉…
这里重点说下怎么把kibana4的配置导出并迁移。 如果你不偷懒,可以自己用pyhton写个elasticsearch的导出程序,实现起来很简单… 如果你跟我一样很偷懒,那么就直接用现成的工具。 elasticdump是个nodejs开发的一个小而精的elasticsearch导出程序。
Python
apt-get update
apt-get install nodejs
curl -L >
elasticsearchurl需要指定一个一个es节点 比如 1731501:9200
访问es前面挂一个nginx,由nginx帮你做es节点的故障检测和切换
es 集群;kibanayml配置
# The Elasticsearch instance to use for all your queries
elasticsearchurl: ">
我们这里用到的是 filebeat+elk(elasticsearch+logstash+kibana) 来进行系统日志的收集。filebeat安装在各个服务器中,Logstash+ElasticSearch+Kibana安装在一台专门用于基础服务的服务器上。
Filebeat是一个轻量级的托运人,用于转发和集中日志数据 Filebeat作为代理安装在服务器上,监视您指定的日志文件或位置,收集日志事件,并将它们转发到 ElasticSearch 或 Logstash 进行索引
官方中文文档: >
0基础架构:
说明:filebeat日志直接传送给es,直接从界面查看日志
1架构图
使用filebeat收集日志直接写入kafka,然后再由logstash从kafka读取写到elasticsearch
其中各组件说明如下:
Filebeat:轻量级数据收集引擎。早期的ELK架构中使用Logstash收集、解析日志,但是Logstash对内存、cpu、io等资源消耗比较高。如果用它来对服务器进行日志收集,将加重服务器的负载。相比 Logstash,Beats所占系统的CPU和内存几乎可以忽略不计,所以filebeat作为一个轻量级的日志收集处理工具(Agent),它可以用来替代Logstash,由于其占用资源少,所以更适合于在各个服务器上搜集日志后传输给Logstash,这也是官方推荐的一种做法。收集日志
Logstash:数据收集处理引擎。支持动态的从各种数据源搜集数据,并对数据进行过滤、分析、丰富、统一格式等 *** 作,然后存储以供后续使用。对日志进行过滤、分析
Elasticsearch:分布式搜索引擎。是基于Lucene的开源分布式搜索服务器,具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析,并能将这三者结合起来。搜集、分析、存储数据
Kibana:可视化平台。它能够搜索、展示存储在 Elasticsearch 中索引数据。使用它可以很方便的用图表、表格、地图展示和分析数据。图形化展示日志
如果还是遇到性能瓶颈
使用filebeat收集日志,先转发到beat端的logstash1,然后logstash1转发到kafka,然后再由logstash2从kafka读取写到elasticsearch。
2架构升级:
架构解释:
(1)首先用户通过nginx代理访问ELK日志统计平台,这里的Nginx可以设置界面密码。
(2)Nginx将请求转发到kibana
(3)kibana到Elasticsearch中去获取数据,这里的Elasticsearch是两台做的集群,日志数据会随机保存在任意一台Elasticsearch服务器。
(4)Logstash1从Kafka中取出数据并发送到Elasticsearch中。
(5)Kafka服务器做日志数据的持久化保存,避免web服务器日志量过大的时候造成的数据收集与保存不一致而导致日志丢失,其中Kafka可以做集群,然后再由Logstash服务器从Kafka持续的取出数据。
(6)logstash2从Filebeat取出的日志信息,并放入Kafka中进行保存。
(7)Filebeat在客户端进行日志的收集。
注1:Kafka的加入原因与作用
整个架构加入Kafka,是为了让整个系统更好的分层,Kafka作为一个消息流处理与持久化存储软件,能够帮助我们在主节点上屏蔽掉多个从节点之间不同日志文件的差异,负责管理日志端(从节点)的人可以专注于向 Kafka里生产数据,而负责数据分析聚合端的人则可以专注于从 Kafka内消费数据。所以部署时要把Kafka加进去。
而且使用Kafka进行日志传输的原因还在于其有数据缓存的能力,并且它的数据可重复消费,Kafka本身具有高可用性,能够很好的防止数据丢失,它的吞吐量相对来说比较好并且使用广泛。可以有效防止日志丢失和防止logsthash挂掉。综合来说:它均衡了网络传输,从而降低了网络闭塞,尤其是丢失数据的可能性,
注2:双层的Logstash作用
这里为什么要在Kafka前面增加二台logstash呢?是因为在大量的日志数据写入时,容易导致数据的丢失和混乱,为了解决这一问题,增加二台logstash可以通过类型进行汇总分类,降低数据传输的臃肿。
如果只有一层的Logstash,它将处理来自不同客户端Filebeat收集的日志信息汇总,并且进行处理分析,在一定程度上会造成在大规模日志数据下信息的处理混乱,并严重加深负载,所以有二层的结构进行负载均衡处理,并且职责分工,一层汇聚简单分流,一层分析过滤处理信息,并且内层都有二台Logstash来保障服务的高可用性,以此提升整个架构的稳定性。
以上就是关于怎么实现kibana的数据导入导出全部的内容,包括:怎么实现kibana的数据导入导出、kibana xpath的安装与使用、kibana配置elasticsearchurl选项 怎么才能配置灵活等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)