elasticsearch

elasticsearch

alpine构建elasticsearch6.0.1 节点之间无法通信

Elasticsearchkindy 回复了问题 • 3 人关注 • 3 个回复 • 119 次浏览 • 6 小时前 • 来自相关话题

Day 12 - Elasticsearch日志场景最佳实践

Adventginger 发表了文章 • 0 个评论 • 155 次浏览 • 7 小时前 • 来自相关话题

1. 背景

Elasticsearch可广泛应用于日志分析、全文检索、结构化数据分析等多种场景,大幅度降低维护多套专用系统的成本,在开源社区非常受欢迎。然而Elasticsearch为满足多种不同的使用场景,底层组合使用了多种数据结构,部分数据结构对具体的用户使用场景可能是冗余的,从而导致默认情况下无法达到性能和成本最优化。 幸运的是,Elasticsearch提供非常灵活的模板配置能力,用户可以按需进行优化。多数情况下,用户结合使用场景进行优化后,Elasticsearch的性能都会有数倍的提升,成本也对应有倍数级别的下降。本文主要介绍不同日志使用场景下的调优经验。

2. 日志处理基本流程

日志处理的基本流程包含:日志采集 -> 数据清洗 -> 存储 -> 可视化分析。Elastic Stack提供完整的日志解决方案,帮助用户完成对日志处理全链路的管理,推荐大家使用。每个流程的处理如下:

  • 日志采集:从业务所在的机器上,较实时的采集日志传递给下游。常用开源组件如Beats、Logstash、Fluentd等。
  • 数据清洗:利用正则解析等机制,完成日志从文本数据到结构化数据的转换。用户可使用Logstash 或 Elasticsearch Ingest模块等完成数据清洗。
  • 存储:使用Elasticsearch对数据进行持久存储,并提供全文搜索和分析能力。
  • 可视化分析:通过图形界面,完成对日志的搜索分析,常用的开源组件如Kibana、Grafana。

使用Elastic Stack处理日志的详细过程,用户可参考官方文章Getting started with the Elastic Stack,这里不展开介绍。

3. 日志场景调优

       对于Elasticsearch的通用调优,之前分享的文章Elasticsearch调优实践,详细介绍了Elasticsearch在性能、稳定性方面的调优经验。而对于日志场景,不同的场景使用方式差别较大,这里主要介绍常见使用方式下,性能和成本的优化思路。

3.1 基础场景

对于多数简单日志使用场景,用户一般只要求存储原始日志,并提供按关键字搜索日志记录的能力。对于此类场景,用户可跳过数据清洗阶段,并参考如下方式进行优化:

  • 建议打开最优压缩,一般可降低40%存储。
  • 设置原始日志字段(message)为text,去除keyword类型子字段,提供全文搜索能力,降低存储。
  • 关闭_all索引,前面已通过message提供全文搜索能力。
  • 对于其他字符串字段,统一设置为keyword类型,避免默认情况下字符串字段同时存储text、keyword两种类型的数据。
  • 使用开源组件(如Beats)上报数据时会包含较多辅助信息,用户可通过修改组件配置文件进行裁剪。

这样去除message的keyword子字段、_all等冗余信息后,再加上最优压缩,可以保证数据相对精简。下面给出这类场景的常用模板,供用户参考:

{
    "order": 5,
    "template": "my_log_*",
    "settings": {
        "translog.durability": "async",
        "translog.sync_interval": "5s",
        "index.refresh_interval": "30s",
        "index.codec": "best_compression"    # 最优压缩
    },
    "mappings": {
        "_default_": {
            "_all": {                        # 关闭_all索引
                "enabled": false
            },
            "dynamic_templates": [
                {
                    "log": {                 # 原始日志字段,分词建立索引
                        "match": "message",
                        "mapping": {
                            "type": "text"
                        }
                    }
                },
                {
                    "strings": {             # 其他字符串字段,统一设置为keyword类型
                        "match_mapping_type": "string",
                        "mapping": {
                            "type": "keyword"
                        }
                    }
                }
            ]
        }
    }
}

3.2 精准搜索场景

对于部分用户,普通的全文检索并不能满足需求,希望精准搜索日志中的某部分,例如每条日志中包含程序运行时多个阶段的耗时数据,对具体一个阶段的耗时进行搜索就比较麻烦。对于此类场景,用户可基于基础场景,进行如下调整:

  • 清洗过程中,可仅解析出需要精准搜索的部分作为独立字段,用于精准搜索。
  • 对于精准搜索字段,如果无排序/聚合需求,可以关闭doc_values;对于字符串,一般使用keyword,可按需考虑使用text。

下面给出这类场景的常用模板,供用户参考:

{
    "order": 5,
    "template": "my_log_*",
    "settings": {
        "translog.durability": "async",
        "translog.sync_interval": "5s",
        "index.refresh_interval": "30s",
        "index.codec": "best_compression"    # 最优压缩
    },
    "mappings": {
        "_default_": {
            "_all": {                        # 关闭_all索引
                "enabled": false
            },
            "dynamic_templates": [
                {
                    "log": {                 # 原始日志字段,分词建立索引
                        "match": "message",
                        "mapping": {
                            "type": "text"
                        }
                    }
                },
                {
                    "precise_fieldx": {       # 精准搜索字段
                        "match": "fieldx",
                        "mapping": {
                            "type": "keyword",
                            "doc_values": false
                        }
                    }
                },
                {
                    "strings": {             # 其他字符串字段,统一设置为keyword类型
                        "match_mapping_type": "string",
                        "mapping": {
                            "type": "keyword"
                        }
                    }
                }
            ]
        }
    }
}

3.3 统计分析场景

对于某些场景,日志包含的主要是程序运行时输出的统计信息,用户通常会完全解析日志进行精确查询、统计分析,而是否保存原始日志关系不大。对于此类场景,用户可进行如下调整:

  • 清洗过程中,解析出所有需要的数据作为独立字段;原始日志非必要时,建议去除。
  • 如果有强需求保留原始日志,可以设置该字段enabled属性为false,只存储不索引。
  • 多数字段保持默认即可,会自动建立索引、打开doc_values,可用于查询、排序、聚合。
  • 对部分无排序/聚合需求、开销高的字段,可以关闭doc_values。

下面给出这类场景的常用模板,供用户参考:

{
    "order": 5,
    "template": "my_log_*",
    "settings": {
        "translog.durability": "async",
        "translog.sync_interval": "5s",
        "index.refresh_interval": "30s",
        "index.codec": "best_compression"    # 最优压缩
    },
    "mappings": {
        "_default_": {
            "_all": {                        # 关闭_all索引
                "enabled": false
            },
            "dynamic_templates": [
                {
                    "log": {                 # 原始日志字段,关闭索引
                        "match": "message",
                        "mapping": {
                            "enabled": false
                        }
                    }
                },
                {
                    "index_only_fieldx": {   # 仅索引的字段,无排序/聚合需求
                        "match": "fieldx",
                        "mapping": {
                            "type": "keyword",
                            "doc_values": false
                        }
                    }
                },
                {
                    "strings": {             # 其他字符串字段,统一设置为keyword类型
                        "match_mapping_type": "string",
                        "mapping": {
                            "type": "keyword"
                        }
                    }
                }
            ]
        }
    }
}

ES 5.1及之后的版本,支持关键字查询时自动选择目标字段,用户没有必要再使用原始日志字段提供不指定字段进行查询的能力。

4. 小结

日志的使用方式比较灵活,本文结合常见的客户使用方式,从整体上对性能、成本进行优化。用户也可结合自身业务场景,参考文章Elasticsearch调优实践进行更细致的优化。

ES5.3 BM25文档score=25000,explain后计算过程没问题,score为什么不在1-20范围呢?

Elasticsearchmedcl 回复了问题 • 3 人关注 • 2 个回复 • 79 次浏览 • 1 天前 • 来自相关话题

es update字段时,如何将数值再除以2 ?

Elasticsearchmedcl 回复了问题 • 5 人关注 • 4 个回复 • 167 次浏览 • 1 天前 • 来自相关话题

restclient请求超时后,不断retry,尝试链接停掉的节点,如何限制retry次数?

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 41 次浏览 • 1 天前 • 来自相关话题

ES参数cluster.routing.allocation.disk.watermark.high值,疑惑

Elasticsearchmedcl 回复了问题 • 2 人关注 • 1 个回复 • 119 次浏览 • 2 天前 • 来自相关话题

Day 10 - Elasticsearch 分片恢复并发数过大引发的bug分析

Adventhowardhuang 发表了文章 • 4 个评论 • 487 次浏览 • 2 天前 • 来自相关话题

       大家好,今天为大家分享一次 ES 的填坑经验。主要是关于集群恢复过程中,分片恢复并发数调整过大导致集群 hang 死的问题。

场景描述

       废话不多说,先来描述场景。某日,腾讯云线上某 ES 集群,15个节点,2700+ 索引,15000+ 分片,数十 TB 数据。由于机器故障,某个节点被重启,此时集群有大量的 unassigned 分片,集群处于 yellow 状态。为了加快集群恢复的速度,手动调整分片恢复并发数,原本想将默认值为2的 node_concurrent_recoveries 调整为10,结果手一抖多加了一个0,设定了如下参数:

curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
    "persistent": {
        "cluster.routing.allocation.node_concurrent_recoveries": 100,
        "indices.recovery.max_bytes_per_sec": "40mb"
    }
}
'

       设定之后,观察集群 unassigned 分片,一开始下降的速度很快。大约几分钟后,数量维持在一个固定值不变了,然后,然后就没有然后了,集群所有节点 generic 线程池卡死,虽然已存在的索引读写没问题,但是新建索引以及所有涉及 generic 线程池的操作全部卡住。立马修改分片恢复并发数到10,通过管控平台一把重启了全部节点,约15分钟后集群恢复正常。接下来会先介绍一些基本的概念,然后再重现这个问题并做详细分析。

基本概念

ES 线程池(thread pool)

ES 中每个节点有多种线程池,各有用途。重要的有:

  • generic :通用线程池,后台的 node discovery,上述的分片恢复(node recovery)等等一些通用后台的操作都会用到该线程池。该线程池线程数量默认为配置的处理器数量(processors)* 4,最小128,最大512。
  • index :index/delete 等索引操作会用到该线程池,包括自动创建索引等。默认线程数量为配置的处理器数量,默认队列大小:200.
  • search :查询请求处理线程池。默认线程数量:int((# of available_processors * 3) / 2) + 1,默认队列大小:1000.
  • get :get 请求处理线程池。默认线程数量为配置的处理器数量,默认队列大小:1000.
  • write :单个文档的 index/delete/update 以及 bulk 请求处理线程。默认线程数量为配置的处理器数量,默认队列大小:200,在写多的日志场景我们一般会将队列调大。 还有其它线程池,例如备份回档(snapshot)、analyze、refresh 等,这里就不一一介绍了。详细可参考官方文档:https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-threadpool.html

集群恢复之分片恢复

       我们知道 ES 集群状态分为三种,green、yellow、red。green 状态表示所有分片包括主副本均正常被分配;yellow 状态表示所有主分片已分配,但是有部分副本分片未分配;red 表示有部分主分片未分配。 一般当集群中某个节点因故障失联或者重启之后,如果集群索引有副本的场景,集群将进入分片恢复阶段(recovery)。此时一般是 master 节点发起更新集群元数据任务,分片的分配策略由 master 决定,具体分配策略可以参考腾讯云+社区的这篇文章了解细节:https://cloud.tencent.com/developer/article/1334743 。各节点收到集群元数据更新请求,检查分片状态并触发分片恢复流程,根据分片数据所在的位置,有多种恢复的方式,主要有以下几种:

  • EXISTING_STORE : 数据在节点本地存在,从本地节点恢复。
  • PEER :本地数据不可用或不存在,从远端节点(源分片,一般是主分片)恢复。
  • SNAPSHOT : 数据从备份仓库恢复。
  • LOCAL_SHARDS : 分片合并(shrink)场景,从本地别的分片恢复。

PEER 场景分片恢复并发数主要由如下参数控制:

  • cluster.routing.allocation.node_concurrent_incoming_recoveries:节点上最大接受的分片恢复并发数。一般指分片从其它节点恢复至本节点。
  • cluster.routing.allocation.node_concurrent_outgoing_recoveries :节点上最大发送的分片恢复并发数。一般指分片从本节点恢复至其它节点。
  • cluster.routing.allocation.node_concurrent_recoveries :该参数同时设置上述接受发送分片恢复并发数为相同的值。 详细参数可参考官方文档:https://www.elastic.co/guide/en/elasticsearch/reference/current/shards-allocation.html

       集群卡住的主要原因就是从远端节点恢复(PEER Recovery)的并发数过多,导致 generic 线程池被用完。涉及目标节点(target)和源节点(source)的恢复交互流程,后面分析问题时我们再来详细讨论。

问题复现与剖析

       为了便于描述,我用 ES 6.4.3版本重新搭建了一个三节点的集群。单节点 1 core,2GB memory。新建了300个 index, 单个 index 5个分片一个副本,共 3000 个 shard。每个 index 插入大约100条数据。 先设定分片恢复并发数,为了夸张一点,我直接调整到200,如下所示:

curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
    "persistent": {
        "cluster.routing.allocation.node_concurrent_recoveries": 200 // 设定分片恢复并发数
    }
}
'

  接下来停掉某节点,模拟机器挂掉场景。几分钟后,观察集群分片恢复数量,卡在固定数值不再变化:

分片恢复统计信息.png

  通过 allocation explain 查看分片分配状态,未分配的原因是受到最大恢复并发数的限制:

分片恢复限制.png
  观察线程池的数量,generic 线程池打满128.

线程池统计.png

此时查询或写入已有索引不受影响,但是新建索引这种涉及到 generic 线程池的操作都会卡住。 通过堆栈分析,128 个 generic 线程全部卡在 PEER recovery 阶段。

堆栈分析.png
         现象有了,我们来分析一下这种场景,远程分片恢复(PEER Recovery)流程为什么会导致集群卡住。

       当集群中有分片的状态发生变更时,master 节点会发起集群元数据更新(cluster state update)请求给所有节点。其它节点收到该请求后,感知到分片状态的变更,启动分片恢复流程。部分分片需要从其它节点恢复,代码层面,涉及分片分配的目标节点(target)和源节点(source)的交互流程如下:

远端恢复时序分析.png
 

       6.x 版本之后引入了 seqNo,恢复会涉及到 seqNo+translog,这也是6.x提升恢复速度的一大改进。我们重点关注流程中第 2、4、5、7、10、12 步骤中的远程调用,他们的作用分别是:

  • 第2步:分片分配的目标节点向源节点(一般是主分片)发起分片恢复请求,携带起始 seqNo 和 syncId。
  • 第4步:发送数据文件信息,告知目标节点待接收的文件清单。
  • 第5步:发送 diff 数据文件给目标节点。
  • 第7步:源节点发送 prepare translog 请求给目标节点,等目标节点打开 shard level 引擎,准备接受 translog。
  • 第10步:源节点发送指定范围的 translog 快照给目标节点。
  • 第12步:结束恢复流程。

       我们可以看到除第5步发送数据文件外,多次远程交互 submitRequest 都会调用 txGet,这个调用底层用的是基于 AQS 改造过的 sync 对象,是一个同步调用。 如果一端 generic 线程池被这些请求打满,发出的请求等待对端返回,而发出的这些请求由于对端 generic 线程池同样的原因被打满,只能 pending 在队列中,这样两边的线程池都满了而且相互等待对端队列中的线程返回,就出现了分布式死锁现象。

问题处理

       为了避免改动太大带来不确定的 side effect,针对腾讯云 ES 集群我们目前先在 rest 层拒掉了并发数超过一定值的参数设定请求并提醒用户。与此同时,我们向官方提交了 issue:https://github.com/elastic/elasticsearch/issues/36195 进行跟踪。

总结

       本文旨在描述集群恢复过程出现的集群卡死场景,避免更多的 ES 用户踩坑,没有对整体分片恢复做详细的分析,大家想了解详细的分片恢复流程可以参考腾讯云+社区 Elasticsearch 专栏相关的文章:https://cloud.tencent.com/developer/column/2428

完结,谢谢!

Elastic日报 第473期 (2018-12-09)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 117 次浏览 • 3 天前 • 来自相关话题

1.ElasticSearch连接:Has_Child,Has_parent查询。 http://t.cn/EyEJZGO 2.(自备梯子)将full-scale ELK栈部署到Kubernetes。 http://t.cn/EyEiOtk 3.(自备梯子)Facebook建立在不平等的基础之上。 http://t.cn/EyE6quM 编辑:至尊宝 归档:https://elasticsearch.cn/article/6181 订阅:https://tinyletter.com/elastic-daily
1.ElasticSearch连接:Has_Child,Has_parent查询。 http://t.cn/EyEJZGO 2.(自备梯子)将full-scale ELK栈部署到Kubernetes。 http://t.cn/EyEiOtk 3.(自备梯子)Facebook建立在不平等的基础之上。 http://t.cn/EyE6quM 编辑:至尊宝 归档:https://elasticsearch.cn/article/6181 订阅:https://tinyletter.com/elastic-daily

请问es适合类似于百度搜索这种样子吗?

Elasticsearchrochy 回复了问题 • 3 人关注 • 1 个回复 • 163 次浏览 • 4 天前 • 来自相关话题

如何控制日志导入ElasticSearch之后的体积?

Elasticsearchwajika 回复了问题 • 6 人关注 • 5 个回复 • 581 次浏览 • 5 天前 • 来自相关话题

关于segment.memory的大小?应该如何配置或者限制?

Elasticsearchmedcl 回复了问题 • 3 人关注 • 1 个回复 • 132 次浏览 • 6 天前 • 来自相关话题

es非得分搜索(消除缓存)为什么结果每次都一样

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 59 次浏览 • 2018-12-05 11:34 • 来自相关话题

deprecation.log的作用?

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 86 次浏览 • 2018-12-03 19:06 • 来自相关话题

es能查看请求操作那个索引吗?

Elasticsearchzz_hello 回复了问题 • 2 人关注 • 1 个回复 • 64 次浏览 • 2018-12-03 11:14 • 来自相关话题

Elastic日报 第466期 (2018-12-02)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 131 次浏览 • 2018-12-02 09:26 • 来自相关话题

1.NoSQL vs SQL:有什么区别以及如何选择。 http://t.cn/ELDJY7y 2.什么是软件工程中的管道? Deployment,CI和CD管道简介。 http://t.cn/ELDcM82 3.(自备梯子)现在是时候认真对待Regulating Tech了。 http://t.cn/ELOozoo 编辑:至尊宝 归档:https://elasticsearch.cn/article/6165 订阅:https://tinyletter.com/elastic-daily
1.NoSQL vs SQL:有什么区别以及如何选择。 http://t.cn/ELDJY7y 2.什么是软件工程中的管道? Deployment,CI和CD管道简介。 http://t.cn/ELDcM82 3.(自备梯子)现在是时候认真对待Regulating Tech了。 http://t.cn/ELOozoo 编辑:至尊宝 归档:https://elasticsearch.cn/article/6165 订阅:https://tinyletter.com/elastic-daily

alpine构建elasticsearch6.0.1 节点之间无法通信

回复

Elasticsearchkindy 回复了问题 • 3 人关注 • 3 个回复 • 119 次浏览 • 6 小时前 • 来自相关话题

ES5.3 BM25文档score=25000,explain后计算过程没问题,score为什么不在1-20范围呢?

回复

Elasticsearchmedcl 回复了问题 • 3 人关注 • 2 个回复 • 79 次浏览 • 1 天前 • 来自相关话题

es update字段时,如何将数值再除以2 ?

回复

Elasticsearchmedcl 回复了问题 • 5 人关注 • 4 个回复 • 167 次浏览 • 1 天前 • 来自相关话题

restclient请求超时后,不断retry,尝试链接停掉的节点,如何限制retry次数?

回复

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 41 次浏览 • 1 天前 • 来自相关话题

ES参数cluster.routing.allocation.disk.watermark.high值,疑惑

回复

Elasticsearchmedcl 回复了问题 • 2 人关注 • 1 个回复 • 119 次浏览 • 2 天前 • 来自相关话题

请问es适合类似于百度搜索这种样子吗?

回复

Elasticsearchrochy 回复了问题 • 3 人关注 • 1 个回复 • 163 次浏览 • 4 天前 • 来自相关话题

如何控制日志导入ElasticSearch之后的体积?

回复

Elasticsearchwajika 回复了问题 • 6 人关注 • 5 个回复 • 581 次浏览 • 5 天前 • 来自相关话题

关于segment.memory的大小?应该如何配置或者限制?

回复

Elasticsearchmedcl 回复了问题 • 3 人关注 • 1 个回复 • 132 次浏览 • 6 天前 • 来自相关话题

es非得分搜索(消除缓存)为什么结果每次都一样

回复

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 59 次浏览 • 2018-12-05 11:34 • 来自相关话题

deprecation.log的作用?

回复

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 86 次浏览 • 2018-12-03 19:06 • 来自相关话题

es能查看请求操作那个索引吗?

回复

Elasticsearchzz_hello 回复了问题 • 2 人关注 • 1 个回复 • 64 次浏览 • 2018-12-03 11:14 • 来自相关话题

elasticsearch的节点不打印日志?

回复

Elasticsearchlocatelli 回复了问题 • 3 人关注 • 2 个回复 • 65 次浏览 • 2018-11-30 10:52 • 来自相关话题

求助有关nested嵌套obj的mapping设置问题

回复

Elasticsearchlaoyang360 回复了问题 • 3 人关注 • 2 个回复 • 139 次浏览 • 2018-11-29 08:40 • 来自相关话题

spring data elasticsearch怎么设置返回值的条数

回复

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 134 次浏览 • 2018-11-28 00:30 • 来自相关话题

kibana中controls的下拉是怎么获取到数据的

回复

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 47 次浏览 • 2018-11-26 16:58 • 来自相关话题

Day 12 - Elasticsearch日志场景最佳实践

Adventginger 发表了文章 • 0 个评论 • 155 次浏览 • 7 小时前 • 来自相关话题

1. 背景

Elasticsearch可广泛应用于日志分析、全文检索、结构化数据分析等多种场景,大幅度降低维护多套专用系统的成本,在开源社区非常受欢迎。然而Elasticsearch为满足多种不同的使用场景,底层组合使用了多种数据结构,部分数据结构对具体的用户使用场景可能是冗余的,从而导致默认情况下无法达到性能和成本最优化。 幸运的是,Elasticsearch提供非常灵活的模板配置能力,用户可以按需进行优化。多数情况下,用户结合使用场景进行优化后,Elasticsearch的性能都会有数倍的提升,成本也对应有倍数级别的下降。本文主要介绍不同日志使用场景下的调优经验。

2. 日志处理基本流程

日志处理的基本流程包含:日志采集 -> 数据清洗 -> 存储 -> 可视化分析。Elastic Stack提供完整的日志解决方案,帮助用户完成对日志处理全链路的管理,推荐大家使用。每个流程的处理如下:

  • 日志采集:从业务所在的机器上,较实时的采集日志传递给下游。常用开源组件如Beats、Logstash、Fluentd等。
  • 数据清洗:利用正则解析等机制,完成日志从文本数据到结构化数据的转换。用户可使用Logstash 或 Elasticsearch Ingest模块等完成数据清洗。
  • 存储:使用Elasticsearch对数据进行持久存储,并提供全文搜索和分析能力。
  • 可视化分析:通过图形界面,完成对日志的搜索分析,常用的开源组件如Kibana、Grafana。

使用Elastic Stack处理日志的详细过程,用户可参考官方文章Getting started with the Elastic Stack,这里不展开介绍。

3. 日志场景调优

       对于Elasticsearch的通用调优,之前分享的文章Elasticsearch调优实践,详细介绍了Elasticsearch在性能、稳定性方面的调优经验。而对于日志场景,不同的场景使用方式差别较大,这里主要介绍常见使用方式下,性能和成本的优化思路。

3.1 基础场景

对于多数简单日志使用场景,用户一般只要求存储原始日志,并提供按关键字搜索日志记录的能力。对于此类场景,用户可跳过数据清洗阶段,并参考如下方式进行优化:

  • 建议打开最优压缩,一般可降低40%存储。
  • 设置原始日志字段(message)为text,去除keyword类型子字段,提供全文搜索能力,降低存储。
  • 关闭_all索引,前面已通过message提供全文搜索能力。
  • 对于其他字符串字段,统一设置为keyword类型,避免默认情况下字符串字段同时存储text、keyword两种类型的数据。
  • 使用开源组件(如Beats)上报数据时会包含较多辅助信息,用户可通过修改组件配置文件进行裁剪。

这样去除message的keyword子字段、_all等冗余信息后,再加上最优压缩,可以保证数据相对精简。下面给出这类场景的常用模板,供用户参考:

{
    "order": 5,
    "template": "my_log_*",
    "settings": {
        "translog.durability": "async",
        "translog.sync_interval": "5s",
        "index.refresh_interval": "30s",
        "index.codec": "best_compression"    # 最优压缩
    },
    "mappings": {
        "_default_": {
            "_all": {                        # 关闭_all索引
                "enabled": false
            },
            "dynamic_templates": [
                {
                    "log": {                 # 原始日志字段,分词建立索引
                        "match": "message",
                        "mapping": {
                            "type": "text"
                        }
                    }
                },
                {
                    "strings": {             # 其他字符串字段,统一设置为keyword类型
                        "match_mapping_type": "string",
                        "mapping": {
                            "type": "keyword"
                        }
                    }
                }
            ]
        }
    }
}

3.2 精准搜索场景

对于部分用户,普通的全文检索并不能满足需求,希望精准搜索日志中的某部分,例如每条日志中包含程序运行时多个阶段的耗时数据,对具体一个阶段的耗时进行搜索就比较麻烦。对于此类场景,用户可基于基础场景,进行如下调整:

  • 清洗过程中,可仅解析出需要精准搜索的部分作为独立字段,用于精准搜索。
  • 对于精准搜索字段,如果无排序/聚合需求,可以关闭doc_values;对于字符串,一般使用keyword,可按需考虑使用text。

下面给出这类场景的常用模板,供用户参考:

{
    "order": 5,
    "template": "my_log_*",
    "settings": {
        "translog.durability": "async",
        "translog.sync_interval": "5s",
        "index.refresh_interval": "30s",
        "index.codec": "best_compression"    # 最优压缩
    },
    "mappings": {
        "_default_": {
            "_all": {                        # 关闭_all索引
                "enabled": false
            },
            "dynamic_templates": [
                {
                    "log": {                 # 原始日志字段,分词建立索引
                        "match": "message",
                        "mapping": {
                            "type": "text"
                        }
                    }
                },
                {
                    "precise_fieldx": {       # 精准搜索字段
                        "match": "fieldx",
                        "mapping": {
                            "type": "keyword",
                            "doc_values": false
                        }
                    }
                },
                {
                    "strings": {             # 其他字符串字段,统一设置为keyword类型
                        "match_mapping_type": "string",
                        "mapping": {
                            "type": "keyword"
                        }
                    }
                }
            ]
        }
    }
}

3.3 统计分析场景

对于某些场景,日志包含的主要是程序运行时输出的统计信息,用户通常会完全解析日志进行精确查询、统计分析,而是否保存原始日志关系不大。对于此类场景,用户可进行如下调整:

  • 清洗过程中,解析出所有需要的数据作为独立字段;原始日志非必要时,建议去除。
  • 如果有强需求保留原始日志,可以设置该字段enabled属性为false,只存储不索引。
  • 多数字段保持默认即可,会自动建立索引、打开doc_values,可用于查询、排序、聚合。
  • 对部分无排序/聚合需求、开销高的字段,可以关闭doc_values。

下面给出这类场景的常用模板,供用户参考:

{
    "order": 5,
    "template": "my_log_*",
    "settings": {
        "translog.durability": "async",
        "translog.sync_interval": "5s",
        "index.refresh_interval": "30s",
        "index.codec": "best_compression"    # 最优压缩
    },
    "mappings": {
        "_default_": {
            "_all": {                        # 关闭_all索引
                "enabled": false
            },
            "dynamic_templates": [
                {
                    "log": {                 # 原始日志字段,关闭索引
                        "match": "message",
                        "mapping": {
                            "enabled": false
                        }
                    }
                },
                {
                    "index_only_fieldx": {   # 仅索引的字段,无排序/聚合需求
                        "match": "fieldx",
                        "mapping": {
                            "type": "keyword",
                            "doc_values": false
                        }
                    }
                },
                {
                    "strings": {             # 其他字符串字段,统一设置为keyword类型
                        "match_mapping_type": "string",
                        "mapping": {
                            "type": "keyword"
                        }
                    }
                }
            ]
        }
    }
}

ES 5.1及之后的版本,支持关键字查询时自动选择目标字段,用户没有必要再使用原始日志字段提供不指定字段进行查询的能力。

4. 小结

日志的使用方式比较灵活,本文结合常见的客户使用方式,从整体上对性能、成本进行优化。用户也可结合自身业务场景,参考文章Elasticsearch调优实践进行更细致的优化。

Day 10 - Elasticsearch 分片恢复并发数过大引发的bug分析

Adventhowardhuang 发表了文章 • 4 个评论 • 487 次浏览 • 2 天前 • 来自相关话题

       大家好,今天为大家分享一次 ES 的填坑经验。主要是关于集群恢复过程中,分片恢复并发数调整过大导致集群 hang 死的问题。

场景描述

       废话不多说,先来描述场景。某日,腾讯云线上某 ES 集群,15个节点,2700+ 索引,15000+ 分片,数十 TB 数据。由于机器故障,某个节点被重启,此时集群有大量的 unassigned 分片,集群处于 yellow 状态。为了加快集群恢复的速度,手动调整分片恢复并发数,原本想将默认值为2的 node_concurrent_recoveries 调整为10,结果手一抖多加了一个0,设定了如下参数:

curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
    "persistent": {
        "cluster.routing.allocation.node_concurrent_recoveries": 100,
        "indices.recovery.max_bytes_per_sec": "40mb"
    }
}
'

       设定之后,观察集群 unassigned 分片,一开始下降的速度很快。大约几分钟后,数量维持在一个固定值不变了,然后,然后就没有然后了,集群所有节点 generic 线程池卡死,虽然已存在的索引读写没问题,但是新建索引以及所有涉及 generic 线程池的操作全部卡住。立马修改分片恢复并发数到10,通过管控平台一把重启了全部节点,约15分钟后集群恢复正常。接下来会先介绍一些基本的概念,然后再重现这个问题并做详细分析。

基本概念

ES 线程池(thread pool)

ES 中每个节点有多种线程池,各有用途。重要的有:

  • generic :通用线程池,后台的 node discovery,上述的分片恢复(node recovery)等等一些通用后台的操作都会用到该线程池。该线程池线程数量默认为配置的处理器数量(processors)* 4,最小128,最大512。
  • index :index/delete 等索引操作会用到该线程池,包括自动创建索引等。默认线程数量为配置的处理器数量,默认队列大小:200.
  • search :查询请求处理线程池。默认线程数量:int((# of available_processors * 3) / 2) + 1,默认队列大小:1000.
  • get :get 请求处理线程池。默认线程数量为配置的处理器数量,默认队列大小:1000.
  • write :单个文档的 index/delete/update 以及 bulk 请求处理线程。默认线程数量为配置的处理器数量,默认队列大小:200,在写多的日志场景我们一般会将队列调大。 还有其它线程池,例如备份回档(snapshot)、analyze、refresh 等,这里就不一一介绍了。详细可参考官方文档:https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-threadpool.html

集群恢复之分片恢复

       我们知道 ES 集群状态分为三种,green、yellow、red。green 状态表示所有分片包括主副本均正常被分配;yellow 状态表示所有主分片已分配,但是有部分副本分片未分配;red 表示有部分主分片未分配。 一般当集群中某个节点因故障失联或者重启之后,如果集群索引有副本的场景,集群将进入分片恢复阶段(recovery)。此时一般是 master 节点发起更新集群元数据任务,分片的分配策略由 master 决定,具体分配策略可以参考腾讯云+社区的这篇文章了解细节:https://cloud.tencent.com/developer/article/1334743 。各节点收到集群元数据更新请求,检查分片状态并触发分片恢复流程,根据分片数据所在的位置,有多种恢复的方式,主要有以下几种:

  • EXISTING_STORE : 数据在节点本地存在,从本地节点恢复。
  • PEER :本地数据不可用或不存在,从远端节点(源分片,一般是主分片)恢复。
  • SNAPSHOT : 数据从备份仓库恢复。
  • LOCAL_SHARDS : 分片合并(shrink)场景,从本地别的分片恢复。

PEER 场景分片恢复并发数主要由如下参数控制:

  • cluster.routing.allocation.node_concurrent_incoming_recoveries:节点上最大接受的分片恢复并发数。一般指分片从其它节点恢复至本节点。
  • cluster.routing.allocation.node_concurrent_outgoing_recoveries :节点上最大发送的分片恢复并发数。一般指分片从本节点恢复至其它节点。
  • cluster.routing.allocation.node_concurrent_recoveries :该参数同时设置上述接受发送分片恢复并发数为相同的值。 详细参数可参考官方文档:https://www.elastic.co/guide/en/elasticsearch/reference/current/shards-allocation.html

       集群卡住的主要原因就是从远端节点恢复(PEER Recovery)的并发数过多,导致 generic 线程池被用完。涉及目标节点(target)和源节点(source)的恢复交互流程,后面分析问题时我们再来详细讨论。

问题复现与剖析

       为了便于描述,我用 ES 6.4.3版本重新搭建了一个三节点的集群。单节点 1 core,2GB memory。新建了300个 index, 单个 index 5个分片一个副本,共 3000 个 shard。每个 index 插入大约100条数据。 先设定分片恢复并发数,为了夸张一点,我直接调整到200,如下所示:

curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
    "persistent": {
        "cluster.routing.allocation.node_concurrent_recoveries": 200 // 设定分片恢复并发数
    }
}
'

  接下来停掉某节点,模拟机器挂掉场景。几分钟后,观察集群分片恢复数量,卡在固定数值不再变化:

分片恢复统计信息.png

  通过 allocation explain 查看分片分配状态,未分配的原因是受到最大恢复并发数的限制:

分片恢复限制.png
  观察线程池的数量,generic 线程池打满128.

线程池统计.png

此时查询或写入已有索引不受影响,但是新建索引这种涉及到 generic 线程池的操作都会卡住。 通过堆栈分析,128 个 generic 线程全部卡在 PEER recovery 阶段。

堆栈分析.png
         现象有了,我们来分析一下这种场景,远程分片恢复(PEER Recovery)流程为什么会导致集群卡住。

       当集群中有分片的状态发生变更时,master 节点会发起集群元数据更新(cluster state update)请求给所有节点。其它节点收到该请求后,感知到分片状态的变更,启动分片恢复流程。部分分片需要从其它节点恢复,代码层面,涉及分片分配的目标节点(target)和源节点(source)的交互流程如下:

远端恢复时序分析.png
 

       6.x 版本之后引入了 seqNo,恢复会涉及到 seqNo+translog,这也是6.x提升恢复速度的一大改进。我们重点关注流程中第 2、4、5、7、10、12 步骤中的远程调用,他们的作用分别是:

  • 第2步:分片分配的目标节点向源节点(一般是主分片)发起分片恢复请求,携带起始 seqNo 和 syncId。
  • 第4步:发送数据文件信息,告知目标节点待接收的文件清单。
  • 第5步:发送 diff 数据文件给目标节点。
  • 第7步:源节点发送 prepare translog 请求给目标节点,等目标节点打开 shard level 引擎,准备接受 translog。
  • 第10步:源节点发送指定范围的 translog 快照给目标节点。
  • 第12步:结束恢复流程。

       我们可以看到除第5步发送数据文件外,多次远程交互 submitRequest 都会调用 txGet,这个调用底层用的是基于 AQS 改造过的 sync 对象,是一个同步调用。 如果一端 generic 线程池被这些请求打满,发出的请求等待对端返回,而发出的这些请求由于对端 generic 线程池同样的原因被打满,只能 pending 在队列中,这样两边的线程池都满了而且相互等待对端队列中的线程返回,就出现了分布式死锁现象。

问题处理

       为了避免改动太大带来不确定的 side effect,针对腾讯云 ES 集群我们目前先在 rest 层拒掉了并发数超过一定值的参数设定请求并提醒用户。与此同时,我们向官方提交了 issue:https://github.com/elastic/elasticsearch/issues/36195 进行跟踪。

总结

       本文旨在描述集群恢复过程出现的集群卡死场景,避免更多的 ES 用户踩坑,没有对整体分片恢复做详细的分析,大家想了解详细的分片恢复流程可以参考腾讯云+社区 Elasticsearch 专栏相关的文章:https://cloud.tencent.com/developer/column/2428

完结,谢谢!

Elastic日报 第473期 (2018-12-09)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 117 次浏览 • 3 天前 • 来自相关话题

1.ElasticSearch连接:Has_Child,Has_parent查询。 http://t.cn/EyEJZGO 2.(自备梯子)将full-scale ELK栈部署到Kubernetes。 http://t.cn/EyEiOtk 3.(自备梯子)Facebook建立在不平等的基础之上。 http://t.cn/EyE6quM 编辑:至尊宝 归档:https://elasticsearch.cn/article/6181 订阅:https://tinyletter.com/elastic-daily
1.ElasticSearch连接:Has_Child,Has_parent查询。 http://t.cn/EyEJZGO 2.(自备梯子)将full-scale ELK栈部署到Kubernetes。 http://t.cn/EyEiOtk 3.(自备梯子)Facebook建立在不平等的基础之上。 http://t.cn/EyE6quM 编辑:至尊宝 归档:https://elasticsearch.cn/article/6181 订阅:https://tinyletter.com/elastic-daily

Elastic日报 第466期 (2018-12-02)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 131 次浏览 • 2018-12-02 09:26 • 来自相关话题

1.NoSQL vs SQL:有什么区别以及如何选择。 http://t.cn/ELDJY7y 2.什么是软件工程中的管道? Deployment,CI和CD管道简介。 http://t.cn/ELDcM82 3.(自备梯子)现在是时候认真对待Regulating Tech了。 http://t.cn/ELOozoo 编辑:至尊宝 归档:https://elasticsearch.cn/article/6165 订阅:https://tinyletter.com/elastic-daily
1.NoSQL vs SQL:有什么区别以及如何选择。 http://t.cn/ELDJY7y 2.什么是软件工程中的管道? Deployment,CI和CD管道简介。 http://t.cn/ELDcM82 3.(自备梯子)现在是时候认真对待Regulating Tech了。 http://t.cn/ELOozoo 编辑:至尊宝 归档:https://elasticsearch.cn/article/6165 订阅:https://tinyletter.com/elastic-daily

Elastic日报 第459期 (2018-11-25)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 169 次浏览 • 2018-11-25 10:42 • 来自相关话题

1.ElasticSearch搜索语法及Boolean和聚合搜索。 http://t.cn/E20PxFB 2.ElasticSearch命令备忘单。 http://t.cn/ELzpeNp 3.(自备梯子)抵制谷歌让你成为机器人的企图。 http://t.cn/ELz8ybs 编辑:至尊宝 归档:https://elasticsearch.cn/article/6155 订阅:https://tinyletter.com/elastic-daily
1.ElasticSearch搜索语法及Boolean和聚合搜索。 http://t.cn/E20PxFB 2.ElasticSearch命令备忘单。 http://t.cn/ELzpeNp 3.(自备梯子)抵制谷歌让你成为机器人的企图。 http://t.cn/ELz8ybs 编辑:至尊宝 归档:https://elasticsearch.cn/article/6155 订阅:https://tinyletter.com/elastic-daily

ET007 ElasticStack 6.5 介绍

ElasticsearchLeon J 发表了文章 • 0 个评论 • 390 次浏览 • 2018-11-19 09:18 • 来自相关话题

就在 11月14日,ElasticStack 6.5.0 发布了,此次发布带来了许多激动人心的特性,我们一起来体验一下:

WX20181118-120551@2x

如果没有任何数据,kibana会提示我们导入sample数据,这边我选择Try our sample data, 然后导入全部3个样例数据,这可以让我们在没有数据的情况下快速体验新特性。

Infrastructure & Logs UI

很多用户使用 ElasticStack 收集基础架构的日志和指标,比如系统日志、安全日志、CPU指标,内存指标等等。在6.5中,kibana 侧边栏中增加了 Infrastructure 和 Logs 两个新的 tab,让用户更简单地查看自己的基础架构,和每台主机或者容器里的日志。

logs

进入logs标签页,如果当前没有数据,kibana会引导我们添加数据

WX20181118-121032@2x

我们选择 system logs

WX20181118-121047@2x

根据指示,我们安装部署好filebeat并启动,再次进入 logs 标签页便可以看到收集到的系统日志了

image-20181118185158451

  1. 搜索过滤框:在这里可以像在 discover 里一样写query string,并且会有输入提示
  2. 时间选择框:可以选择需要查看的时间点,如果点了 Stream live,会持续监听尾部新输出的日志内容,类似 linux 命令中的tail -f
  3. 日志时间轴:高亮的部位是当前查看日志所在的时间范围,对应的区域图标识了日志量

假如我想实现 tail -f /var/log/system.log | grep google.com 一样的效果,可以打开 Stream live,并在搜索过滤框中这样输入:

WX20181118-173432@2x

很简单,很方便有木有?

Infrastructure

同样在kibana的引导下安装 Metric beat,并开启system模块,启动后进入 infrastructure 标签页:

image-20181118190614385

这里可以直观地看到所有基础架构的指标状况,深色的内层代表主机,颜色代表了健康状况。浅灰色的外层代表了group,因为我只在自己的笔记本上做了部署,所以只能看到一个host。

image-20181118191527060

点击主机会弹出菜单

  • View logs : 跳转到 logs 标签页,并通过搜索过滤框指定host,只查看这台主机的日志。
  • View metrics : 跳转到这台主机的指标详情,可以查看历史数据 shoot

APM

Java 和 Go

不负众望,继 Nodejs、Python、Ruby、Javascript 之后,Elastic APM 5.6.0 新增了对 Java 和 Golang 的支持!

Distributed Tracing

在 SOA 和 MSA 大行其道的年代,如何追踪请求在各个系统之间的流动成为了apm的关键问题。

Elastic APM 支持 OpenTracing 标准,并在各个agent里内置了 OpenTracing 兼容的bridge

以下是官网上该特性的截图:

distributed_tracing

APM Server 监控

如 ElasticStack的其他产品一般,APM也支持了监控,并可以在 Kinbana Montoring下查看监控信息:

apm_monitoring

APM Server 内存占用优化

通过新的基于NDJSON的协议,agent可以在采集信息后通过事件流立即发往APM server,这样 APM Server可以一个接一个地处理接收到的事件,而不是一次性地收到一大块(chunk),这样在很大程度上减少了APM Server的内存占用。

Elasticsearch

Cross-cluster replication

这里的副本并非我们平时常见的分片副本,而是通过在集群B配置一个副本indexB来追随集群A中的indexA,indexA中发生的任何变化都会同步到indexB中来。另外也可以配置一个pattern,当集群A出现符合pattern的索引,自动在集群B创建他的副本,这听起来很酷。值得一提的是,这将是白金版里新增的一个特性。

Minimal Snapshots

snapshot 是 es 中用来创建索引副本的特性,在之前的版本中,snapshot会把完整的 index 都保存下来,包括原始数据和索引数据等等。新的 Minimal Snapshots 提供了一种只备份 _source 内容和 index metadata,当需要恢复时,需要通过 reindex 操作来完成。最小快照最多可能帮你节省50%的磁盘占用,但是会花费更多的时间来恢复。这个特性可能并不适合所有人,但给恢复窗口比较长,且磁盘容量有限的用户多了一种选择。

SQL / ODBC

现在可以使用 支持 ODBC 的第三方工具来连接 elasticsearch 了!我想可以找时间试试用 tableau 直连 elasticsearch会是啥效果。

Java 11

Java11 是一个 LTS 版本,相信会有越来越多的用户升级到 java11

G1GC支持

经过无数的测试,Elasticsearch官方宣布了在 JDK 10+ 上支持 G1GC。G1GC 相比 CMS有诸多优势,如今可以放心地使用G1GC了。(期待对ZGC的支持!)

Authorization realm

X-Pack Security中的新特性,可以对用户认证和用户授权分别配置 realm,比如使用内置的用户体系来认证,再去ldap中获取用户的角色、权限等信息。这也是白金版新增的特性。

机器学习的新特性

  • 支持在同一个机器学习任务中分析多个时间系列
  • 为机器学习任务添加了新的多分桶(multi-bucket) 分析

Kibana

Canvas

Canvas ! 我在做数据分析师的同学看到之后说太酷了,像 PPT。

点击侧边栏的 canvas 标签,可以看到我们先前导入的样本数据也包含了 canvas 样例:

WX20181118-210126@2x

在 11月的 深圳开发者大会上,上海普翔 也用 canvas 对填写调查问卷的参会人员做了分析:

UNADJUSTEDNONRAW_thumb_1adc

https://github.com/alexfrancoeur/kibana_canvas_examples 这里有很多非常不错的 canvas 样例供大家学习,把json文件直接拖到 canvas 页面就可以导入学习了!

Spaces

把 kibana 对象(比如 visualizations、dashboards)组织到独立的 space 里,并且通过 RBAC 来控制哪些用户可以访问哪些 space。这实在是太棒了,想象在一个企业里,多个部门通过kibana查询、分析数据,大家关注的dashboard肯定是不一样的,在6.5之前,我们只能通过社区插件来实现这样的需求,而大版本的升级可能直接导致插件不可用,有了 Space,我们不必再担心!

image-20181118212404768

Rollups UI

Rollup 是 es6.4 中新增的一个特性,用来把一些历史数据压缩归档,用作以后的分析。6.5.0 中 kibana 增加了一个界面用来查看和管理 Rollup 任务。

image9

Data visualizer for files

通过可视化的方式查看文件的结构,查看其中出现最频繁的内容:

highlights_6_5_viz-logs

Beats

Beats Central Management

Beats 终于也支持中心化配置管理了!我们只需按照往常一样安装filebeat、metricbeat,然后使用 filebeat enroll <kibana-url> <token>,便可以通过kibana来管理beats的配置、甚至给他们打上tag:

Image from iOS

想一想,假如我们在上千台机器上部署filebeat,如果哪天需要批量变更配置文件,只需要通过脚本调用配置管理的API就可以了

Functionbeat

Functionbeat是一种新的beat类型,可以被部署为一个方法,而不需要跑在服务器环境上,比如 AWS Lambda function。

以上就是 6.5.0 版本的主要特性,更详细的内容可以查看 https://www.elastic.co/blog/elastic-stack-6-5-0-released ,希望通过我的介绍,可以让大家了解到新版本所带来的激动人心的特性。

Image from iOS

Elastic日报 第452期 (2018-11-18)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 139 次浏览 • 2018-11-18 11:07 • 来自相关话题

1.ElasticSearch嵌套搜索:如何搜索嵌入的文档。 http://t.cn/E2tAGhG 2.Spark ElasticSearch Hadoop更新和Upsert示例和说明。 http://t.cn/E2t2yg2 3.(自备梯子)我的数据科学恐怖故事。 http://t.cn/E2t2FrI 编辑:至尊宝 归档:https://elasticsearch.cn/article/6143 订阅:https://tinyletter.com/elastic-daily
1.ElasticSearch嵌套搜索:如何搜索嵌入的文档。 http://t.cn/E2tAGhG 2.Spark ElasticSearch Hadoop更新和Upsert示例和说明。 http://t.cn/E2t2yg2 3.(自备梯子)我的数据科学恐怖故事。 http://t.cn/E2t2FrI 编辑:至尊宝 归档:https://elasticsearch.cn/article/6143 订阅:https://tinyletter.com/elastic-daily

Elastic日报 第445期 (2018-11-11)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 237 次浏览 • 2018-11-11 10:37 • 来自相关话题

1.利用Elastic Machine Learning改善GoDaddy用户体验。 http://t.cn/EAKdvJf 2.使用ELASTICSEARCH,LOGSTASH和KIBANA可视化数据。 http://t.cn/EA9zCvV 3.使用Golang的Elasticsearch查询示例。 http://t.cn/RRmNcop 编辑:至尊宝 归档:https://elasticsearch.cn/article/6129 订阅:https://tinyletter.com/elastic-daily
1.利用Elastic Machine Learning改善GoDaddy用户体验。 http://t.cn/EAKdvJf 2.使用ELASTICSEARCH,LOGSTASH和KIBANA可视化数据。 http://t.cn/EA9zCvV 3.使用Golang的Elasticsearch查询示例。 http://t.cn/RRmNcop 编辑:至尊宝 归档:https://elasticsearch.cn/article/6129 订阅:https://tinyletter.com/elastic-daily

Elastic日报 第438期 (2018-11-04)

Elastic日报至尊宝 发表了文章 • 2 个评论 • 189 次浏览 • 2018-11-04 11:26 • 来自相关话题

1.使用Filebeat和Elasticsearch Ingest管道解析csv文件。 http://t.cn/EwClFun 2.(自备梯子)Netflix数据管道的演变。 http://t.cn/EwCTGgw 3.(自备梯子)在Docker容器中运行bash或任何命令。 http://t.cn/EwCEbxU 编辑:至尊宝 归档:https://elasticsearch.cn/article/3699 订阅:https://tinyletter.com/elastic-daily
1.使用Filebeat和Elasticsearch Ingest管道解析csv文件。 http://t.cn/EwClFun 2.(自备梯子)Netflix数据管道的演变。 http://t.cn/EwCTGgw 3.(自备梯子)在Docker容器中运行bash或任何命令。 http://t.cn/EwCEbxU 编辑:至尊宝 归档:https://elasticsearch.cn/article/3699 订阅:https://tinyletter.com/elastic-daily

Elastic日报 第431期 (2018-10-28)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 154 次浏览 • 2018-10-28 10:08 • 来自相关话题

1.在Elasticsearch中使用管道重建索引。 http://t.cn/EZQhdz5 2.使用Yelp的数据管道和Elasticsearch进行快速订单搜索。 http://t.cn/EZQzCpw 3.(自备梯子)数据科学家最需要的技能。 http://t.cn/E7jAYl9 编辑:至尊宝 归档:https://elasticsearch.cn/article/1007 订阅:https://tinyletter.com/elastic-daily
1.在Elasticsearch中使用管道重建索引。 http://t.cn/EZQhdz5 2.使用Yelp的数据管道和Elasticsearch进行快速订单搜索。 http://t.cn/EZQzCpw 3.(自备梯子)数据科学家最需要的技能。 http://t.cn/E7jAYl9 编辑:至尊宝 归档:https://elasticsearch.cn/article/1007 订阅:https://tinyletter.com/elastic-daily

Elastic日报 第424期 (2018-10-21)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 165 次浏览 • 2018-10-21 00:48 • 来自相关话题

1.Logstash和Elasticsearch 集成。 http://t.cn/EzYLgoO 2.如何在Logstash中设置Elasticsearch输出模板。 http://t.cn/EzYLx6u 3.(自备梯子)怎样真正成为高级开发人员。 http://t.cn/EzYyl2E 编辑:至尊宝 归档:https://elasticsearch.cn/article/996 订阅:https://tinyletter.com/elastic-daily
1.Logstash和Elasticsearch 集成。 http://t.cn/EzYLgoO 2.如何在Logstash中设置Elasticsearch输出模板。 http://t.cn/EzYLx6u 3.(自备梯子)怎样真正成为高级开发人员。 http://t.cn/EzYyl2E 编辑:至尊宝 归档:https://elasticsearch.cn/article/996 订阅:https://tinyletter.com/elastic-daily

Elastic日报 第417期 (2018-10-14)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 174 次浏览 • 2018-10-14 10:29 • 来自相关话题

1.使用Amazon Cognito进行Kibana访问控制。 http://t.cn/E7WTASh 2.使用GuardDuty实时监控您的安全性。 http://t.cn/E7WTpbr 3.(自备梯子)如何理解任何编程任务。 http://t.cn/EhkDGBF 活动预告: 1、Elastic 官方开发者认证现场考试+ Elastic 开发者大会 VIP 门票 https://elasticsearch.cn/article/827 编辑:至尊宝 归档:https://elasticsearch.cn/article/830 订阅:https://tinyletter.com/elastic-daily
1.使用Amazon Cognito进行Kibana访问控制。 http://t.cn/E7WTASh 2.使用GuardDuty实时监控您的安全性。 http://t.cn/E7WTpbr 3.(自备梯子)如何理解任何编程任务。 http://t.cn/EhkDGBF 活动预告: 1、Elastic 官方开发者认证现场考试+ Elastic 开发者大会 VIP 门票 https://elasticsearch.cn/article/827 编辑:至尊宝 归档:https://elasticsearch.cn/article/830 订阅:https://tinyletter.com/elastic-daily

Elastic日报 第410期 (2018-09-30)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 282 次浏览 • 2018-09-30 14:45 • 来自相关话题

1.将Apache Pig和Hadoop与Elasticsearch及Elasticsearch-Hadoop Connector一起使用。 http://t.cn/EPkOKwG 2.(自备梯子)日志管理:Graylog vs ELK http://t.cn/EPkpnzZ 3.(自备梯子)如何学习数据科学。 http://t.cn/Ev0BfUZ 活动预告: 1、Elastic 中国开发者大会门票发售中 https://conf.elasticsearch.cn/2018/shenzhen.html 编辑:至尊宝 归档:https://elasticsearch.cn/article/821 订阅:https://tinyletter.com/elastic-daily
1.将Apache Pig和Hadoop与Elasticsearch及Elasticsearch-Hadoop Connector一起使用。 http://t.cn/EPkOKwG 2.(自备梯子)日志管理:Graylog vs ELK http://t.cn/EPkpnzZ 3.(自备梯子)如何学习数据科学。 http://t.cn/Ev0BfUZ 活动预告: 1、Elastic 中国开发者大会门票发售中 https://conf.elasticsearch.cn/2018/shenzhen.html 编辑:至尊宝 归档:https://elasticsearch.cn/article/821 订阅:https://tinyletter.com/elastic-daily

Elastic日报 第403期 (2018-09-23)

Elastic日报至尊宝 发表了文章 • 0 个评论 • 193 次浏览 • 2018-09-23 10:04 • 来自相关话题

1.将Apache Hive与ElasticSearch一起使用。 http://t.cn/EPzJFKK 2.大数据与分析与数据科学:有什么区别? http://t.cn/EPzxm6P 3.(自备梯子)招聘数据科学家之前需要做的3件事。 http://t.cn/EPz6j4f 活动预告: 1、Elastic 中国开发者大会门票发售中 https://conf.elasticsearch.cn/2018/shenzhen.html 编辑:至尊宝 归档:https://elasticsearch.cn/article/814 订阅:https://tinyletter.com/elastic-daily
1.将Apache Hive与ElasticSearch一起使用。 http://t.cn/EPzJFKK 2.大数据与分析与数据科学:有什么区别? http://t.cn/EPzxm6P 3.(自备梯子)招聘数据科学家之前需要做的3件事。 http://t.cn/EPz6j4f 活动预告: 1、Elastic 中国开发者大会门票发售中 https://conf.elasticsearch.cn/2018/shenzhen.html 编辑:至尊宝 归档:https://elasticsearch.cn/article/814 订阅:https://tinyletter.com/elastic-daily

你看懂 Elasticsearch Log 中的 GC 日志了吗?

Elasticsearchrockybean 发表了文章 • 0 个评论 • 563 次浏览 • 2018-09-22 23:29 • 来自相关话题

如果你关注过 elasticsearch 的日志,可能会看到如下类似的内容:

[2018-06-30T17:57:23,848][WARN ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][228384] overhead, spent [2.2s] collecting in the last [2.3s]

[2018-06-30T17:57:29,020][INFO ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][old][228385][160772] duration [5s], collections [1]/[5.1s], total [5s]/[4.4d], memory [945.4mb]->[958.5mb]/[1007.3mb], all_pools {[young] [87.8mb]->[100.9mb]/[133.1mb]}{[survivor] [0b]->[0b]/[16.6mb]}{[old] [857.6mb]->[857.6mb]/[857.6mb]}

看到其中的[gc]关键词你也猜到了这是与 GC 相关的日志,那么你了解每一部分的含义吗?如果不了解,你可以继续往下看了。

我们先从最简单的看起:

  1. 第一部分是日志发生的时间
  2. 第二部分是日志级别,这里分别是WARNINFO
  3. 第三部分是输出日志的类,我们后面也会讲到这个类
  4. 第四部分是当前 ES 节点名称
  5. 第五部分是 gc 关键词,我们就从这个关键词聊起。

友情提示:对 GC 已经了如指掌的同学,可以直接翻到最后看答案。

1. 什么是 GC?

GC,全称是 Garbage Collection (垃圾收集)或者 Garbage Collector(垃圾收集器)。

在使用 C语言编程的时候,我们要手动的通过 mallocfree来申请和释放数据需要的内存,如果忘记释放内存,就会发生内存泄露的情况,即无用的数据占用了宝贵的内存资源。而Java 语言编程不需要显示的申请和释放内存,因为 JVM 可以自动管理内存,这其中最重要的一部分就是 GC,即 JVM 可以自主地去释放无用数据(垃圾)占用的内存。

我们研究 GC 的主要原因是 GC 的过程会有 Stop The World(STW)的情况发生,即此时用户线程会停止工作,如果 STW 的时间过长,则应用的可用性、实时性等就下降的很厉害。

GC主要解决如下3个问题:

  1. 如何找到垃圾?
  2. 如何回收垃圾?
  3. 何时回收垃圾?

我们一个个来看下。

1.1 如何找到垃圾?

所谓垃圾,指的是不再被使用(引用)的对象。Java 的对象都是在堆(Heap)上创建的,我们这里默认也只讨论堆。那么现在问题就变为如何判定一个对象是否还有被引用,思路主要有如下两种:

  1. 引用计数法,即在对象被引用时加1,去除引用时减1,如果引用值为0,即表明该对象可回收了。
  2. 可达性分析法,即通过遍历已知的存活对象(GC Roots)的引用链来标记出所有存活对象

方法1简单粗暴效率高,但准确度不行,尤其是面对互相引用的垃圾对象时无能为力。

方法2是目前常用的方法,这里有一个关键是 GC Roots,它是判定的源头,感兴趣的同学可以自己去研究下,这里就不展开讲了。

1.2 如何回收垃圾?

垃圾找到了,该怎么回收呢?看起来似乎是个很傻的问题。直接收起来扔掉不就好了?!对应到程序的操作,就是直接将这些对象占用的空间标记为空闲不就好了吗?那我们就来看一下这个基础的回收算法:标记-清除(Mark-Sweep)算法。

1.2.1 标记-清除 算法(Mark Sweep)

该算法很简单,使用通过可达性分析分析方法标记出垃圾,然后直接回收掉垃圾区域。它的一个显著问题是一段时间后,内存会出现大量碎片,导致虽然碎片总和很大,但无法满足一个大对象的内存申请,从而导致 OOM,而过多的内存碎片(需要类似链表的数据结构维护),也会导致标记和清除的操作成本高,效率低下,如下图所示:

1.2.2 复制算法(Copying)

为了解决上面算法的效率问题,有人提出了复制算法。它将可用内存一分为二,每次只用一块,当这一块内存不够用时,便触发 GC,将当前存活对象复制(Copy)到另一块上,以此往复。这种算法高效的原因在于分配内存时只需要将指针后移,不需要维护链表等。但它最大的问题是对内存的浪费,使用率只有 50%。

但这种算法在一种情况下会很高效:Java 对象的存活时间极短。据 IBM 研究,Java 对象高达 98% 是朝生夕死的,这也意味着每次 GC 可以回收大部分的内存,需要复制的数据量也很小,这样它的执行效率就会很高。

1.2.3 标记-整理算法(Mark Compact)

该算法解决了第1中算法的内存碎片问题,它会在回收阶段将所有内存做整理,如下图所示:

但它的问题也在于增加了整理阶段,也就增加了 GC 的时间。

1.2.4 分代收集算法(Generation Collection)

既然大部分 Java 对象是朝生夕死的,那么我们将内存按照 Java 生存时间分为 新生代(Young)老年代(Old),前者存放短命僧,后者存放长寿佛,当然长寿佛也是由短命僧升级上来的。然后针对两者可以采用不同的回收算法,比如对于新生代采用复制算法会比较高效,而对老年代可以采用标记-清除或者标记-整理算法。这种算法也是最常用的。JVM Heap 分代后的划分一般如下所示,新生代一般会分为 Eden、Survivor0、Survivor1区,便于使用复制算法。

将内存分代后的 GC 过程一般类似下图所示:

  1. 对象一般都是先在 Eden区创建
  2. Eden区满,触发 Young GC,此时将 Eden中还存活的对象复制到 S0中,并清空 Eden区后继续为新的对象分配内存
  3. Eden区再次满后,触发又一次的 Young GC,此时会将 EdenS0中存活的对象复制到 S1中,然后清空EdenS0后继续为新的对象分配内存
  4. 每经过一次 Young GC,存活下来的对象都会将自己存活次数加1,当达到一定次数后,会随着一次 Young GC 晋升到 Old
  5. Old区也会在合适的时机进行自己的 GC

1.2.5 常见的垃圾收集器

前面我们讲了众多的垃圾收集算法,那么其具体的实现就是垃圾收集器,也是我们实际使用中会具体用到的。现代的垃圾收集机制基本都是分代收集算法,而 YoungOld区分别有不同的垃圾收集器,简单总结如下图:

从上图我们可以看到 YoungOld区有不同的垃圾收集器,实际使用时会搭配使用,也就是上图中两两连线的收集器是可以搭配使用的。这些垃圾收集器按照运行原理大概可以分为如下几类:

  • Serial GC串行,单线程的收集器,运行 GC 时需要停止所有的用户线程,且只有一个 GC 线程
  • Parallel GC并行,多线程的收集器,是 Serial 的多线程版,运行时也需要停止所有用户线程,但同时运行多个 GC 线程,所以效率高一些
  • Concurrent GC并发,多线程收集器,GC 分多阶段执行,部分阶段允许用户线程与 GC 线程同时运行,这也就是并发的意思,大家要和并行做一个区分。
  • 其他

我们下面简单看一下他们的运行机制。

1.2.5.1 Serial GC

该类 Young区的为 Serial GCOld区的为Serial Old GC。执行大致如下所示:

1.2.5.2 Parallel GC

该类Young 区的有 ParNewParallel ScavengeOld 区的有Parallel Old。其运行机制如下,相比 Serial GC ,其最大特点在于 GC 线程是并行的,效率高很多:

1.2.5.3 Concurrent Mark-Sweep GC

该类目前只是针对 Old 区,最常见就是CMS GC,它的执行分为多个阶段,只有部分阶段需要停止用户进程,这里不详细介绍了,感兴趣可以去找相关文章来看,大体执行如下:

1.2.5.4 其他

目前最新的 GC 有G1GCZGC,其运行机制与上述均不相同,虽然他们也是分代收集算法,但会把 Heap 分成多个 region 来做处理,这里不展开讲,感兴趣的可以参看最后参考资料的内容。

1.2.6 Elasticsearch 的 GC 组合

Elasticsearch 默认的 GC 配置是CMS GC ,其 Young 区ParNewOld 区CMS,大家可以在 config/jvm.options中看到如下的配置:

## GC configuration
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly

1.3 何时进行回收?

现在我们已经知道如何找到和回收垃圾了,那么什么时候回收呢?简单总结如下:

  1. Young 区的GC 都是在 Eden 区满时触发
  2. Serial Old 和 Parallel Old 在 Old 区是在 Young GC 时预测Old 区是否可以为 young 区 promote 到 old 区 的 object 分配空间,如果不可用则触发 Old GC。这个也可以理解为是 Old区满时。
  3. CMS GC 是在 Old 区大小超过一定比例后触发,而不是 Old 区满。这个原因在于 CMS GC 是并发的算法,也就是说在 GC 线程收集垃圾的时候,用户线程也在运行,因此需要预留一些 Heap 空间给用户线程使用,防止由于无法分配空间而导致 Full GC 发生。

2. GC Log 如何阅读?

前面讲了这么多,终于可以回到开篇的问题了,我们直接来看答案

[2018-06-30T17:57:23,848][WARN ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][228384] overhead, spent [2.2s] collecting in the last [2.3s]

[gc][这是第228384次GC 检查] 在最近 2.3 s 内花了 2.2s 用来做垃圾收集,这占比似乎有些过了,请抓紧来关注下。

[2018-06-30T17:57:29,020][INFO ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][old][228385][160772] duration [5s], collections [1]/[5.1s], total [5s]/[4.4d], memory [945.4mb]->[958.5mb]/[1007.3mb], all_pools {[young] [87.8mb]->[100.9mb]/[133.1mb]}{[survivor] [0b]->[0b]/[16.6mb]}{[old] [857.6mb]->[857.6mb]/[857.6mb]}

我们直接来看具体的含义好了,相信有了前面的 GC 基础知识,大家在看这里解释的时候就非常清楚了。

  • [gc][本次是 old GC][这是第228385次 GC 检查][从 JVM 启动至今发生的第 160772次 GC]

  • duration [本次检查到的 GC 总耗时 5 秒,可能是多次的加和],

  • collections [从上次检查至今总共发生1次 GC]/[从上次检查至今已过去 5.1 秒],

  • total [本次检查到的 GC 总耗时为 5 秒]/[从 JVM 启动至今发生的 GC 总耗时为 4.4 天],

  • memory [ GC 前 Heap memory 空间]->[GC 后 Heap memory 空间]/[Heap memory 总空间],

  • all_pools(分代部分的详情) {[young 区][GC 前 Memory ]->[GC后 Memory]/[young区 Memory 总大小] } {[survivor 区][GC 前 Memory ]->[GC后 Memory]/[survivor区 Memory 总大小] }{[old 区][GC 前 Memory ]->[GC后 Memory]/[old区 Memory 总大小] }

3. 看看源码

从日志中我们可以看到输出这些日志的类名叫做JvmGcMonitorService,我们去源码中搜索很快会找到它/Users/rockybean/code/elasticsearch/core/src/main/java/org/elasticsearch/monitor/jvm/JvmGcMonitorService.java,这里就不详细展开讲解源码了,它执行的内容大概如下图所示:

关于打印日志的格式在源码也有,如下所示:

private static final String SLOW_GC_LOG_MESSAGE =
"[gc][{}][{}][{}] duration [{}], collections [{}]/[{}], total [{}]/[{}], memory [{}]->[{}]/[{}], all_pools {}";
private static final String OVERHEAD_LOG_MESSAGE = "[gc][{}] overhead, spent [{}] collecting in the last [{}]";

另外细心的同学会发现输出的日志中 gc 只分了 young 和 old ,原因在于 ES 对 GC Name 做了封装,封装的类为:org.elasticsearch.monitor.jvm.GCNames,相关代码如下:

    public static String getByMemoryPoolName(String poolName, String defaultName) {
        if ("Eden Space".equals(poolName) || "PS Eden Space".equals(poolName) || "Par Eden Space".equals(poolName) || "G1 Eden Space".equals(poolName)) {
            return YOUNG;
        }
        if ("Survivor Space".equals(poolName) || "PS Survivor Space".equals(poolName) || "Par Survivor Space".equals(poolName) || "G1 Survivor Space".equals(poolName)) {
            return SURVIVOR;
        }
        if ("Tenured Gen".equals(poolName) || "PS Old Gen".equals(poolName) || "CMS Old Gen".equals(poolName) || "G1 Old Gen".equals(poolName)) {
            return OLD;
        }
        return defaultName;
    }

    public static String getByGcName(String gcName, String defaultName) {
        if ("Copy".equals(gcName) || "PS Scavenge".equals(gcName) || "ParNew".equals(gcName) || "G1 Young Generation".equals(gcName)) {
            return YOUNG;
        }
        if ("MarkSweepCompact".equals(gcName) || "PS MarkSweep".equals(gcName) || "ConcurrentMarkSweep".equals(gcName) || "G1 Old Generation".equals(gcName)) {
            return OLD;
        }
        return defaultName;
    }

在上面的代码中,你会看到很多我们在上一节中提到的 GC 算法的名称。

至此,源码相关部分也讲解完毕,感兴趣的大家可以自行去查阅。

4. 总结

讲解 GC 的文章已经很多,本文又唠唠叨叨地讲一遍基础知识,是希望对于第一次了解 GC 的同学有所帮助。因为只有了解了这些基础知识,你才不至于被这些 GC 的输出吓懵。希望本文对你理解 ES 的 GC 日志 有所帮助。

5. 参考资料

  1. Java Hotspot G1 GC的一些关键技术(https://mp.weixin.qq.com/s/4ufdCXCwO56WAJnzng_-ow
  2. Understanding Java Garbage Collection(https://www.cubrid.org/blog/understanding-java-garbage-collection
  3. 《深入理解Java虚拟机:JVM高级特性与最佳实践》

6. 相关推荐

如果你想深入的了解 JAVA GC 的知识,可以关注 ElasticTalk 公众号,回复 GC关键词后即可获取作者推荐的电子书等资料。

elasticTalk,qrcode