国内外新闻动态,ASO干货,行业资讯。 德普优化,出海必备ASO数据分析平台! 投稿请发送至邮箱:2902675294@qq.com

如何配置ELK(es+logstash+kibana)

资讯快闻 蓝天白云 2019℃ 0评论

未命名

es+logstash+kibana作为如今新兴火爆的一个大型分布式索引系统,首先我们先来介绍一下如何安装ELK。

安装ES:

在ES2.0以前的版本还经常提示JDK出错等问题,在ES2.0后就更简单了,一站式下载和安装。

官网https://www.elastic.co/downloads/elasticsearch下载最新版的ES并解压就可以用了

##################代码段###########################
wget https://download.elasticsearch.org/elasticsearch/release/org/elasticsearch/distribution/tar/elasticsearch/2.2.0/elasticsearch-2.2.0.tar.gz
tar -xvf elasticsearch-2.2.0.tar.gz
cd /elasticsearch-2.2.0

因为elastic search在2.0版本后就不允许用root账户运行了,为了防止一些权限问题。所以我们还要再创建一个管理ES的用户(比如叫search)

##################代码段###########################
chown -R search:search elasticsearch-2.2.0
su search
./elasticsearch-2.2.0/bin/elasticsearch -d
安装head:
https://github.com/mobz/elasticsearch-head下载zip 解压unzip
在/data/soft/elasticsearch-2.0.0/plugins下建立目录head,将解压后的文件拷入目录中
head是一个很好的节点监管工具,有点脱题了。
安装logstash
官网https://www.elastic.co/downloads/logstash下载并解压
##################代码段###########################
wget https://download.elastic.co/logstash/logstash/logstash-2.2.2.tar.gz
tar -xvf logstash-2.2.2.tar.gz

同理Kibana在官网 https://www.elastic.co/downloads/kibana下载

##################代码段###########################
https://download.elastic.co/kibana/kibana/kibana-4.4.1-linux-x64.tar.gz
tar -xvf kibana-4.4.1-linux-x64.tar.gz
./kibana-4.4.1-linux-x64/bin/kibana

这样我们就把所需的客户端都装上了,有一点需要注意的是Kibana和ES版本必须匹配,详情请见官网。

接下来我们介绍es配置

数据规模和检索性能需求

假设我们有一个在线图书馆,目前线上销售100,000种各种语言的书籍。我们希望查询请求的平均响应时间不高于200毫秒,这样就能避免用户在使用搜索服务时等待太长的时间,也能避免浏览器渲染页面时等待太长时间。所以,现在来实现期望负载。我们做了一些性能测试(内容超出本书的范围),而且我们测到如下方案性能最好:给集群分配4个节点,数据切分到两个分片,而且每个分片挂载一个副本。

集群完整配置

接下来我们为集群创建配置信息,并详细讨论为什么要在集群中使用如下的属性:

配置文件
cluster.name: books
# node configuration
node.master: true
node.data: true
node.max_local_storage_nodes: 1
# indices configuration
index.number_of_shards: 2
index.number_of_replicas: 1
index.routing.allocation.total_shards_per_node: 1
# instance paths
path.conf: /usr/share/elasticsearch/conf
path.plugins: /usr/share/elasticsearch/plugins
path.data: /mnt/data/elasticsearch
path.work: /usr/share/elasticsearch/work
path.logs: /var/log/elasticsearch
# swapping
bootstrap.mlockall: true
#gateway
gateway.type: local
gateway.recover_after_nodes: 3
gateway.recover_after_time: 30s
gateway.expected_nodes: 4
# recovery
cluster.routing.allocation.node_initial_primaries_recoveries: 1
cluster.routing.allocation.node_concurrent_recoveries: 1
indices.recovery.concurrent_streams: 8
# discovery
discovery.zen.minimum_master_nodes: 3
# search and fetch logging
index.search.slowlog.threshold.query.info: 500ms
index.search.slowlog.threshold.query.debug: 100ms
index.search.slowlog.threshold.fetch.info: 1s
index.search.slowlog.threshold.fetch.debug: 200ms
# JVM gargabe collection work logging
monitor.jvm.gc.ParNew.info: 700ms
monitor.jvm.gc.ParNew.debug: 400ms
monitor.jvm.gc.ConcurrentMarkSweep.info: 5s
monitor.jvm.gc.ConcurrentMarkSweep.debug: 2s

节点层面的配置

在节点层面的配置中,我们指定了一个集群名字(使用cluster.name属性)来标识我们的集群。如果在同一个网段中配置了多个集群,名字相同的节点会相互连接成一个集群。接下来,这个特殊的节点会被选举成主节点(用node.master:true属性),而且该节点可以容纳索引数据(node.data:true)。此外,通过设置node.max\_local\_storeage\_nodes属性值为1,可以限制一个节点上最多能够运行1个ElasticSearch实例。

索引的配置

由于我们只有一个索引,而且暂时也不打算添加更多的索引,我们决定设置分片的默认数量为2(用index.number\_of\_shards属性),设置分片副本的默认数量为1(用index.number\_of\_replicas属性)。此外,我们还设置了index.routing.allocation.total\_shards\_per\_node属性值为1,这意味着对于每个索引,ElasticSearch只会在单个节点上分配一个分片。

各种目录的规划

我们已经把ElasticSearch安装到了/usr/share/elasticsearch目录,基于此,conf目录、plugins目录和工作目录都在该目录下。由于这个原因,我们把数据单独指定到硬盘的一个地方,这个地方就是/mnt/data/elasticsearch挂载点。最后,我们把日志文件安置到/var/log/elasticsearch目录。基于这样的目录规划,我们在做配置的更新操作时,只需要关注/usr/share/elasticsearch目录即可,无需接触其它的目录。

Gateway的配置

正如读者所了解的,gateway是负责存储索引和元数据的模块。在本例中,我们选择推荐的,也是唯一没有废弃的gateway类型,即local(gateway.type属性)。我们说我们希望当集群只有三个节点时,恢复进程就启动(gateway.recover\_after\_nodes属性),同时至少3个节点相互连接30秒后开始恢复任务(用gateway.recover\_after\_time属性)。此外,我们还可以通过设置gateway.expected\_nodes属性值为4,用来通知ElasticSearch,我们的集群将由4个节点组成。

集群恢复机制

对于ElasticSearch来说,最核心的一种配置就是集群恢复配置。尽管它不是每天都会用到,正如你不会每天都重启ElasticSearch,也不希望集群经常失效一样。但是防范于未然是必须的。因此我们来讨论一下用到的相关属性。我们已经设置了 cluster.routing.allocation.node\_initial\_ primaries\_recoveries属性为1,这意味着我们只允许每个节点同时恢复一个主分片。如果一个节点上有多个主分片时,不妨把这个值设置得大一点。 我们也设置了cluster. routing.allocation.node\_concurrent\_recoveries属性值为1,再一次限制每个节点同时恢复的分片数量。此外,我们也设置了indices.recovery.concurrent\_streams属性值为8,这是因为在最初测试recovery过程时,我们了解到我们的网络 和服务器在从对等的分片中恢复一个分片时能够轻松地使用8个并发流,这也意味着我们可以同时读取8个索引文件。

节点发现机制

在集群的discovery模块配置上,我们只需要设置一个属性:设置discovery.zen.minimum\_master\_nodes属性值为3。它指定了组成集群所需要的最少主节点候选节点数。这个值至少要设置成节点数的50%+1,在本例中就是3。它用来防止集群出现如下的状况:由于某些节点的失效,部分节点的网络连接会断开,并形成一个与原集群一样名字的集群(这种情况也称为“集群脑裂”状况)。这个问题非常危险,因为两个新形成的集群会同时索引和修改集群的数据。

记录慢查询日志

使用ElasticSearch时有件事情可能会很有用,那就是记录查询命令执行过程中一段时间或者更长的日志。记住这种日志并非记录命令的整个执行时间,而是单个分片上的执行时间,即命令的部分执行时间。在本例中,我们用INFO级别的日志来记录执行时间长于500毫秒的查询命令以及执行时间长于1秒的real time get请求。在调试时,我们把这些值分别设置为100毫秒和200毫秒。如下的配置片段用于上述需求:

##################代码段###########################
index.search.slowlog.threshold.query.info: 500ms
index.search.slowlog.threshold.query.debug: 100ms
index.search.slowlog.threshold.fetch.info: 1s
index.search.slowlog.threshold.fetch.debug: 200ms

记录垃圾回收器的工作日志

最后,由于我们的集群没有监控解决方案(至少刚开始没有),我们想看到垃圾收集器的工作状态。说得更清楚一点,我们希望看到垃圾回收器是否花了太多的时间,如果是,是在哪个时间段。为了实现这一需求,我们在elasticsearch.yml文件中添加下面的信息:

##################代码段###########################
monitor.jvm.gc.ParNew.info: 700ms
monitor.jvm.gc.ParNew.debug: 400ms
monitor.jvm.gc.ConcurrentMarkSweep.info: 5s
monitor.jvm.gc.ConcurrentMarkSweep.debug: 2s

在INFO级别的日志中,ElasticSearch会把运行时间太长的垃圾回收过程的相关信息记录下来,按照设置,阈值为 concurrent mark sweep收集器收集过程超过5秒,新生垃圾收集超过700毫秒。我们也添加了DEBUG级别的日志来应对debug需求和问题的修复。

锁定分配内存大小

还有一点没有提到,就是bootstrap.mlockall属性。该属性能够让ElasticSearch将堆内存锁住,并确保该块内存不会被操作系统替换成虚拟内存。如果把bootstrap.mlockall设置为true,推荐用户把ES\_MIN\_ME和ES\_MAX\_ME两个属性设置成相同的值。这样做可以确保服务器有足够的物理内存来启动ElasticSearch,并且保留足够的内存给操作系统让系统流畅运行。

Logstash配置我们下章介绍。

 

转载请注明:德普微新文 » 如何配置ELK(es+logstash+kibana)

喜欢 (1)
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址