• Elasticsearch-8.2文档(更新于2023/01/29)

    What is Elasticsearch?

    link

    You know, for search (and analysis)

    Data in documents and indices

    link

    Scalability and resilience: clusters, nodes, and shards

    link

    Set up Elasticsearch

    link

      这个章节介绍了如何设置Elasticsearch并且使其运行,包含的内容有:

    Supported platforms

      官方给出的操作系统以及JVM的支持列表见Support Matrix.Elasticsearch在这些平台上都经过了测试,但是在列表外的其他平台上还是有可能可以正常工作的。

    Java(JVM)Version

      Elasticsearch使用Java构建,并且每次发布都捆绑了一个OpenJDK,这个OpenJDK由JDK维护者使用GPLv2+CE协议维护。建议使用捆绑的JDK,它位于Elasticsearch home目录中名为jdk的目录中。

      可以通过设置环境变量ES_JAVA_HOME来使用你自己的Java版本。如果你一定要使用一个跟捆绑的JVM不一样的Java版本,我们建议你使用Java的长期支持版本LTS 。如果使用了一个错误Java版本的,Elasticsearch将不会启动。当你使用了自己的JVM后,绑定的JVM目录可能会被删除。

    Use delicated hosts 使用专用的主机

      在生产上,我们建议你在专用的主机或者主服务器上(primary service)运行Elasticsearch。假定Elasticsearch是主机上或者容器上唯一的资源密集型的应用,那么一些Elasticsearch的特性比如自动化分配JVM堆大小就能实现。比如说,你可能同时运行Metribeat跟Elasticsearch来做集群统计,那么就应该将resource-heavy的Logstash部署在它自己的主机上。

    Installing Elasticsearch

    link

    Hosted Elasticsearch

      你可以在自己的设备上运行Elasticsearch或者也可以使用AWS, GCP, and Azure上专用的Elasticsearch服务器

    Installing Elasticsearch Yourself

      Elasticsearch以下列的打包方式呈现:

    Configuration Management Tools

      我们同样提供了下列的配置管理工具有助于大型的部署

    Install Elasticsearch from archive on Linux or MacOS

    link

      在Linux和MacOS平台下,Elasticsearch是作为一个.tar.gz的归档文件。

      这个安装包同时包含了免费和订阅的特性,30天试用可以使用所有的特性。

      Elasticsearch最新的稳定版本可以从这个页面下载,其他版本可以从过去的发布页面下载。

    NOTE: Elasticsearch中捆绑了一个OpenJDK,这个OpenJDK由JDK维护者使用GPLv2+CE协议维护,如果要使用自己的Java版本,

    Download and install archive for Linux

      Linux下Elasticsearch-7.15.2归档文件的下载以及安装如下所示:

      上文第三行Compares the SHA of the downloaded .tar.gz archive and the published checksum,which should output elasticsearch-{version}-linux-x86_64.tar.gz: OK

      上文第五行就是所谓的 $ES_HOME

    Download and install archive for MacOS

      MacOS下Elasticsearch-7.15.2归档文件的下载以及安装如下所示:

      上文第三行Compares the SHA of the downloaded .tar.gz archive and the published checksum,which should output elasticsearch-{version}-linux-x86_64.tar.gz: OK

      上文第五行就是所谓的 $ES_HOME

    Enable automatic creation of system indices

      一些商业特性会自动创建索引。默认情况下,Elasticsearch可以被配置为允许自动创建索引,并且不需要再做额外的步骤。然而,如果你关闭了自动创建索引, 你必须在elasticsearch.yml中配置action.auto_create_index来允许商业特性创建下面的索引:

    IMPORTANT:如果你正在使用Logstash或者Beats,那么你很有可能需要在action.auto_create_index配置额外的索引名,确切的名字取决去你的本地配置。如果你不能保证正确的名字,你可以考虑将索引名设置为*,这样就会自动创建所有的索引

    Running Elasticsearch from the command line

      Elasticsearch可以通过下面的命令行启动:

      如果Elasticsearch keystore有密码保护,你会被提示(be prompted to)输入keystore's的密码,详细内容见安全配置

      默认情况下,Elasticsearch将日志打印到控制台(标准输出)以及日志目录<clustername>.log文件中。Elasticsearch在启动期间会生成一些日志,但一旦初始化完成,它将继续在前台(foreground)运行并且不再生成任何日志直到一些值的记录的信息产生。在Elasticsearch运行期间,你可以通过HTTP接口访问默认的9200端口与Elasticsearch交互。输入Ctrl-c来停止Elasticsearch。

    NOTE:Elasticsearch安装包中的所有脚本要求的Bash版本需要支持arrays并且假定/bin/bash是存在的,同样的,Bash在这个路径是存在的或者能通过动态链接找到

    Checking that Elasticsearch is running

      你能通过HTTP请求访问localhost:9200来测试Elasticsearch节点是否在运行中:

      你应该能收到类似下面的回应(response)

    Running as a daemon

      在命令行指定-d使得Elasticsearch成为一个后台程序,并且通过参数-p生成一个pid文件记录进程号。

      如果Elasticsearch keystore有密码保护,你会被提示(be prompted to)输入keystore's的密码,详细内容见安全配置

      $ES_HOME/logs/目录能找到日志信息。

      通过杀死pid文件中记录的进程号来关闭Elasticsearch。

    NOTE:tar.gz的安装包中不包含systemd组件。如果要把Elasticsearch作为一个服务管理,用RPM或者Debian的安装包进行安装。

    Configuring Elasticsearch on the command line

      Elasticsearch默认装载(load)的配置文件路径为$ES_HOME/config/elasticsearch.yml,这个配置文件中的格式见Configuring Elasticsearch

      在配置文件中可以指定的任何设置(settings)都可以通过命令行的参数指定,使用-E语法:

    TIP:一般来说,任何集群范围(cluster-wide)的配置(比如说 cluster.name)都应该在elasticsearch.yml文件中配置,同时具体节点的任意配置比如说node.name可以通过命令行参数指定

    Directory layout of archives

      归档发行版 (archive distribution)是self-contained(意思就是所有的文件都在同一个目录中,Elasticsearch还有安装包发行版package distribution,通过这种方式安装后,文件会分散在不同的目录中)。所有的文件和目录默认情况下都在$ES_HOME下,$ES_HOME在解压归档后会被创建。

      这是一种非常方便的方式因为你不需要创建任何目录来开始使用Elasticsearch,并且当卸载Elasticsearch时只要简单的移除$ES_HOME。然而我们建议把配置文件目录config directory、数据目录data directory、以及日志目录log directory的位置进行变更,以免在以后重要的数据被删除。

    类型Type描述Description默认位置Default Location设置Setting
    homeElasticsearch home目录或者$ES_HOME解压归档后创建这个目录 
    bin二进制脚本,包含elasticsearch用于启动一个节点以及elasticsearch-plugin用于安装插件$ES_HOME/binES_PATH_CONF
    conf包含elasticsearch.yml的所有配置文件$ES_HOME/config 
    data每一个索引/分片的数据文件的位置$ES_HOME/datapath.data
    logs日志文件位置$ES_HOME/logspath.logs
    plugins插件文件位置。每个插件在一个子目录中$ES_HOME/plugins 
    repoShared file system repository locations. Can hold multiple locations. A file system repository can be placed in to any subdirectory of any directory specified here.NOT_configuredpath.repo
    Next steps

      现在你建好了一个Elasticsearch测试环境。在你开始认真做开发护着进入Elasticsearch的生产环境,你必须做一些额外的设置:

    Configuring Elasticsearch

    link

      Elasticsearch附带(ship with)了很好的默认配置并且只需要较小的配置。在一个运行中的集群中,大部分的设置可以通过Cluster update settings API进行更改。

      配置文件应该包含对指定节点(node-specific)的设置,例如node.name以及路径,或者是能让节点加入集群的配置,例如cluster.name以及network.host

    Config files location

      Elasticsearch有三个配置文件:

      这三个文件都在config目录中,他们的默认路径取决于使用哪种方式安装:归档发行版(archive distribution)tar.gz或者zip还是安装包发行版(package distribution)Debian 或者RPM安装包。

      对于归档发行版,config目录位置默认是$ES_HOME/config。config目录的位置能通过ES_PATH_CONFIG这个环境变量进行更改:

      或者,通过在命令行或profile文件中export ES_PATH_CONFIG这个环境变量。

      对于安装包发行版,config目录的位置默认在/etc/elasticsearch,config目录的位置可以通过ES_PATH_CONF这个环境变量变更。注意的是在shell中设置这些是不够的。Instead, this variable is sourced from /etc/default/elasticsearch (for the Debian package) and /etc/sysconfig/elasticsearch (for the RPM package). You will need to edit theES_PATH_CONF=/etc/elasticsearch entry in one of these files accordingly to change the config directory location.

    Config file format

      配置格式是YAML,下面是更改数据和日志目录的例子

      配置也可以平整化(flattened)

      在YAML中,你可以格式化non-scalar的值写成序列:

      尽管下面的方式不是很常见(Thought less common),你也可以把non-scala的值写成数组:

    Environment variable substitution

      在配置文件中可以通过使用${...}这类符号的方式引用环境变量:

      环境变量的值必须是简单的String值,用逗号分隔的String值会被Elasticsearch解析成一个list。例如,Elasticsearch将下面的环境变量的String值根据逗号切分到list中。

    Cluster and node setting types

      集群跟节点的设置基于他们是如何被配置可以分类为:

    Dynamic

      在一个正在运行的集群上,你可以使用cluster update settings API来配置或更新动态设置。你也可以使用elasticsearch.yml对本地未启动或者关闭的节点配置动态设置。

      使用cluster update settings API更新可以是永久的(persistent),即使集群重启也生效,也可以是临时的(transient),集群在重启后就重置了。你也可以通过使用API把配置设置为null也能重置使用persistent或者transient更新过的设置。

      如果你用多种方式配置了一样的设置,那么Elasticsearch会根据下面的优先顺序(order of precedence)来应用设置(apply settings)。

    1. Transient Setting
    2. Persistent Setting
    3. elasticsearch.yml setting
    4. Default setting value

      例如,你可以使用一个transient setting覆盖persistent setting或者elasticsearch.yml。然而,在elasticsearch.yml上的变更不会覆盖定义好的(defined)transient 或者 persistent setting。

    TIP:如果你使用Elasticsearch Service,使用user settings特性来配置所有的设置。这个方法能让Elasticsearch自动的拒绝(reject)掉任何会破坏你集群的设置。 如果你在自己的设备(hardware)上运行Elasticsearch,可以使用cluster update settings API来配置集群动态设置。对于集群或者节点的静态设置只使用elasticsearch.yml来配置。使用API不会要求重启并且保证所有节点都被配置成相同的值。

    WARNING: We no longer recommend using transient cluster settings. Use persistent cluster settings instead. If a cluster becomes unstable, transient settings can clear unexpectedly, resulting in a potentially undesired cluster configuration. See the Transient settings migration guide.

    Static(settings)

      静态设置只能在未启动或者关闭的节点上使用elasticsearch.yml来配置。

      静态配置必须在集群中相关的所有节点上一一配置。

    Important Elasticsearch configuration

    (8.2)link

      Elasticsearch只需要很少的配置就能启动。但是在生产中使用你的集群时必须要考虑这些条目:

      我们的Elastic Cloud service能自动配置这些条目,使得你的集群处在生产就绪状态。

    Path settings

      Elasticsearch把你的索引数据和数据流都写到data目录中。

      Elasticsearch本身也会生产应用日志,包含集群健康信息以及集群操作信息,并且写入到logs目录中。

      对于在MacOS和Linux下使用.tar.gz, 以及Windows下使用zip方式安装时,datalogs目录默认是$ES_HOME下的子目录,然而在升级Elasticsearch时,位于$ES_HOME下的文件是存在风险的。

      在生产中,我们强烈建议在elasticsearch.yml中设置path.datapath.logsdatalogs目录放到$ES_HOME以外的位置。其他安装方式(rpm、macOS Homebrew、Windows .msi)默认会把datalogs目录放到$ES_HOME以外的位置。

      支持在不同的平台,path.datapath.logs可以是不同的值:

    WARNING:不要更改data目录中的任何内容(content),也不要允许可能会影响data目录内容的程序。如果除了Elasticsearch以外更改了data目录的内容,那么Elasticsearch可能会失败,报告损坏或者其他数据不一致性(data inconsistencies)的问题,也可能工作正常但是丢失了一些你的数据。

    Multiple data paths

    WARNING: 在7.13.0版本中废弃了

      如果有这个需要,你可以在path.data中指定多个路径。Elasticsearch会在这些路径上存储节点的数据,但是会在相同的路径上存储同一个shard的数据。

      Elasticsearch不会在多个路径上去平衡shards的写入。在某个路径上的高磁盘使用率会触发整个节点的high disk usage watermark。触发后,Elasticsearch不会在这个节点增加shard,尽管这个节点的在其他路径上有可用的空间。如果你需要额外的磁盘空间,我们建议你增加新的节点而不是增加data的路径。

    Migrate from multiple data paths

      在学习了 rolling restart process后再来写着一段内容。

    Cluster name setting

      在一个集群中,一个节点只有跟集群中的其他节点共享他的cluster.name才能加入到这个集群中。默认的名字是elasticsearch,但是你应该把这个名字改成一个合适的名字,这个名字能描述这个集群的目的。

    IMPORTANT:在不同的环境中不要重复使用相同的集群名,否则节点可能会加入到错误的集群中。

    Node name setting

      Elasticsearch使用node.name作为可读(human-readable)的一个特定的Elasticsearch实例。在很多APIs的返回中(response)会用到。当Elasticsearch启动后,节点名字默认是服务器的hostname,可以在elasticsearch.yml中显示配置:

    Network host setting

      默认清下,Elasticsearch只绑定类似127.0.0.1以及[::1]的回调地址(lookback address)。这样的话能够在单个服务上允许一个集群的多个节点用于开发以及测试。但是一个resilient production cluster必须是包含在其他服务上的节点。尽管还有许多newwork settings,但是通常你只需要配置network.host

    当你提供了network.host的值,Elasticsearch会假设你正在从开发模式转到生产模式,并且会在系统启动时升级warning到exception的检查。见development and production modes的差异。

    Discovery and cluster formation settings

      在进入生产前配置两个重要的discovery和cluster formation设置,使得这个集群中的节点能互相发现并且选出一个master节点。

    discovery.seed_hosts

      如果没有配置任何网络设置,Elasticsearch会绑定可见的回调地址并且扫描本地的9300到9305端口去连接同一个服务上的其他节点。这种行为提供了一种自动集群体验,而无需进行任何配置。即开箱即用(out of box)。

      当你想要组成(form)一个集群,它包含的节点在其他服务器上时,可以使用静态discovery.seed_hosts设置。这个设置可以提供一个集群中其他节点的list,这些节点是候选的主节点(mater-eligible),并且有可能是live的,并且能在discovery process中作为可以联系的节点来选出种子选手(and contactable to seed the discovery process。翻译能力有限,只可意会,不可言传)。这个设置可以将集群中所有候选的主节点的地址用YAML中的序列或者数组的风格书写。每一个地址可以是IP地址或者hostname,hostname可以通过DNS关联一个或多个IP地址。

    1. 如果IP地址中没有指定端口号,那么就是默认的9300,默认的端口号也可以被override
    2. 如果hostname关联多个IP 地址,那么当前节点会试图发现hostname关联的所有地址上的节点
    3. IPv6地址使用方括号包裹(enclosed in square brackets)

      如果候选的主节点的节点没有固定的名字或者地址,可以使用alternative hosts provider 来动态的找到他们的地址。

    cluster.initial_master_nodes

      当你第一次启动Elasticsearch集群,在cluster bootstrapping阶段确定在第一次参与投票的候选主节点。在development mode中,with no discovery settings configured, this step is performed automatically by the nodes themselves。

      因为auto-bootstrapping是内在不安全的,在生产模式中启动一个新的集群时,你必须显式列出候选的主节点并且他们的投票要被统计在第一轮的选票中。你可以使用cluster.initial_master_nodes设置来列出这些候选的主节点。

    IMPORTANT:当一个新的集群第一次形成之后,从每个节点的配置中移除cluster.initial_master_nodes设置。当重启一个集群或者往已存在的集群中添加一个新的节点时,不要使用该配置。

    1. 通过node.name来确定最初的master节点身份,默认是hostname。要确保cluster.initial_master_nodesnode.name的值是一致的。如果节点的名字使用了全限定域名(fully-qualified domain name),比如master-node-a.example.com,那么你必须在cluster.initial_master_nodes中使用FQDN。相反的,如果只是仅仅使用了hostname而没有尾随的限定符,那么在cluster.initial_master_nodes也不能带尾随的限定符

      bootstrapping a clusterdiscovery and cluster formation settings

    Heap size settings

      默认情况下,Elasticsearch会根据节点的roles跟内存大小来自动的设置JVM堆的大小。我们建议使用默认的大小,它适用于大部分生产环境。

    NOTE:堆大小的自动配置需要bundle JDK,如果使用自定义的JRE位置,需要Java 14以及更新的JRE。

      如果有必要,你可以通过setting the JVM heap size手动覆盖默认值。

    JVM heap dump path setting

      默认情况下,Elasticsearch会配置JVM,使得OOM异常转存(dump)到data目录。在基于ROM跟Debian的安装包中,data目录位于/var/lib/elasticsearch。在Linux、MacOs以及Windows发行版中,data目录位于Elasticsearch安装目录的根目录。

      如果默认的路径用于接受heap dump不是很合适,那么可以通过在文件jvm.options中修改-XX:HeapDumpPath=...

    GC logging settings

      默认情况下,Elasticsearch开启了垃圾回收日志。在jvm.options文件中配置,并且输出到Elasticsearch的logs文件中。默认的配置中,每64M就会轮换一次日志,最多消耗2G的磁盘空间。

      你可以命令行来配置JVM的日志打印,见JEP 158: Unified JVM Logging。除非你直接更改jvm.options文件,Elasticsearch的默认配置会被应用(apply)除了你自己的设置。如果要关闭默认配置,第一步先通过提供参数-Xlog:disable关闭日志打印,然后提供你自己的命令选项。以上操作会关闭所有的JVM日志打印,所以要确定好可用的选项来满足你的需求。

      Enable Logging with the JVM Unified Logging Framework了解更多在原始的JEP(origin JEP)中不包含的虚拟机选项。

    Examples

      下面的例子中创建了$ES_HOME/config/jvm.options.d/gc.options并包含一些虚拟机选项:把默认的GC 日志输出到/opt/my-app/gc.log

      下面的例子中配置一个Elasticsearch Docker container,将GC的debug日志输出到stderr,让容器编排器处理输出。

    Temporary directory settings

      默认情况下,Elasticsearch会使用一个私有的临时目录,它由一个启动脚本创建,并位于系统的临时目录中。

      在一些Linux发行版中,一些系统工具会清楚 /tmp 目录下长时间未被访问的文件。这会导致Elasticsearch的私有临时目录可能会被删除。移除私有的临时目录会导致一些问题,比如一些功能随后会访问这些私有临时目录。

      如果你使用.deb或者.rpm安装的Elasticsearch,并且在systemd下运行,那么Elasticsearch使用的私有临时目录不会被周期性的清除(periodic cleanup)。

      如果你想要在Linux跟MacOS上运行.tar.gz发行版,可以考虑为Elasticsearch创建一个专用的临时目录,并且该目录所在路径中不包含旧的文件或目录,并且这个目录只有Elasticsearch有访问权限。最后在Elasticsearch启动前设置环境变量$ES_TMPDIR

    JVM fatal error log setting

      默认情况下,Elasticsearch会配置JVM将fatal错误日志写到默认的日志目录中。在RPMDebian安装中,目录位置为/var/log/elasticsearch,在Linux、MacOs、Windows发行版中,logs目录位于Elasticsearch的安装目录。

      当遇到一些fatal错误日志,它由JVM产生,比如说段错误(segmentation fault)。如果接受这些日志的路径不是很合适,可以在jvm.options中修改-XX:ErrorFile=...

    Cluster backups

      在发生灾难时,snapshot能防止数据永久丢失。Snapshot lifecycle management是最简单的办法来对集群实现定期备份。见Create a snapshot

    WARNING:快照是唯一可靠并且被支持的方式(supported way)来备份集群。 你不能通过拷贝data目录中的节点数据进行备份。没有一种支持方式(supported way)从文件系统层面的备份来恢复数据。如果你想尝试从这种备份中恢复集群,可能会失败并且Report出corruption或者文件丢失或者其他数据一致性的问题,或者出现成功的悄无声息的丢失一些你的数

    Secure settings

    (8.2)link

      有些设置是敏感的(sensitive),仅仅依靠文件系统的权限来保护这些值是不够。对于这种情况,Elasticsearch提供了keystore和 elasticsearch-keystore tool 来管理这些设置。

    IMPORTANT:只有一些设置被设计为从keystore中读取。但是keystore没有验证一些不支持的设置。增加不支持的设置会导致Elasticsearch启动失败。

      所有在keystore中的变更只有在Elasticsearch重启后才生效。

      keystore中设置跟配置文件elasticsearch.yml中的普通的设置项一样都需要在每个节点上指定。当前,所有的安全设置都是特定于节点的,即所有的节点上必须设置相同的值。

    Reloadable secure settings

      elasticsearch.yml中的设置值一样,keystore中的内容无法自动的应用(apply)到正在运行的Elasticsearch节点,需要重启。然而有一些安全设置被标记为reloadable,这些设置可以被reload

      对于安全设置的值,不管是否可以reloadable,集群中的所有节点都必须一致。在安全设置变更后,执行bin/elasticsearch-keystore调用下面的请求:

    1. Elasticsearch keystore会对密码进行加密。

      上述API会解密并且重新读取集群中所有节点的整个keystore,但是只有reloadable的安全设置可以被应用(apply)。其他的安全设置不会生效直到下一次重启。一旦API调用返回了,意味着reload完成了,即所以依赖这些设置的内部数据结构都已经发生了变更。Everything should look as if the settings had the new value from the start。

      当更改了多个reloadable安全设置后,在集群中的每一个节点上修改后,随后发起reload_secure_settings的调用,而不用在每一次变更后reload。

      下面是reloadable安全设置

    Auditing security settings

    (8.2)link

      你可以使用audit logging来记录安全相关的事件,比如认证失败,拒绝连接,以及数据访问事件。另外也会记录通过API访问安全配置的操作,例如创建、更新、移除nativebuilt-in users,rolesrole mappings 以及 API keys

    TIP:日志审计只在某些订阅中提供,详细信息见 https://www.elastic.co/subscriptions

      在配置后,集群上的所有节点都需要设置一遍。静态设置,比如说xpack.security.audit.enabled,在每个节点的elasticsearch.yml中都必须配置。对于动态的日志设置,使用cluster update settings API 可以让所有节点的设置一致。

    General Auditing Settings
    xpack.security.audit.enabled

      Static)设置为true来开启。默认值为false。在每个节点上日志事件会被放到一个名为<clustername>_audit.json的专用的文件中。

      如果开启了,集群中的所有节点的elasticsearch.yml都需要配置该设置。

    Audited Event Settings

      日志事件以及其他一些信息比如获取什么样的日志可以通过下面的设置来控制:

    xpack.security.audit.logfile.events.include

      Dynamic)在日志输出中指定事件类型(kind of events),设置为_all会彻底的记录所有的日志事件,但通常不建议这么做因为会非常的verbose。默认值是一个list包含:access_denied, access_granted, anonymous_access_denied, authentication_failed, connection_denied, tampered_request, run_as_denied, run_as_granted, security_config_change

    xpack.security.audit.logfile.events.exclude

      Dynamic)从包含的(kind of events)列表中指定排除部分选项。当xpack.security.audit.logfile.events.include的值设置为_all时,然后用xpack.security.audit.logfile.events.exclude来进行指定选项的排除是不错的方式。默认值是空的list。

    xpack.security.audit.logfile.events.emit_request_body

      Dynamic)用于指定是否将REST请求的请求body作为日志事件的属性,这个设置可以用于audit search queries

      默认是false,那么请求body不会被打印出来。

    IMPORTANT:注意的是,当日志事件中包含请求body时,一些敏感数据可能以明文形式被记录,即使是一些安全相关API,比如修改用户密码,认证信息在开启后有被泄露(filter out)的风险

    Local Node Info Settings
    xpack.security.audit.logfile.emit_node_name

      Dynamic)指定在每一个日志事件中,节点名字node name是否作为其中的一个域field。默认值是false。

    xpack.security.audit.logfile.emit_node_host_address

      Dynamic)指定在每一个日志事件中,节点的地址是否作为其中的一个域field。默认值是false。

    xpack.security.audit.logfile.emit_node_host_name

      Dynamic)指定在每一个日志事件中,节点的主机名是否作为其中的一个域field。默认值是false。

    xpack.security.audit.logfile.emit_node_id

      Dynamic)指定在每一个日志事件中,节点的id是否作为其中的一个域field。不同于node name,管理员可以在配置文件中修改节点id,节点id在集群启动后将不可变更,默认值是true。

    Audit Logfile Event Ignore Policies

      下面的设置会影响ignore policies,它们能更精细的(fine-grained)控制日志事件打印到日志文件中。拥有相同police_name的设置将会组合到一个策略(police)中。如何一个事件匹配到任意一条策略的所有条件,该日志事件将被忽略并不会被打印。大多数的日志事件都遵照(subject to)忽略策略。唯一的例外(sole exception)是security_config_change类型的事件,无法被过滤掉(filter out),除非完全的通过xpack.security.audit.logfile.events.exclude进行exclude。

    xpack.security.audit.logfile.events.ignore_filters.<policy_name>.users

      Dynamic)用户名字列表或者名字通配值(wildcards)。匹配该值的所有用户的日志事件不会打印出来。

    xpack.security.audit.logfile.events.ignore_filters.<policy_name>.realms

      Dynamic)authentication realm的列表或者通配值,匹配该值的所有realm的日志事件不会打印出来。

    xpack.security.audit.logfile.events.ignore_filters.<policy_name>.actions

      Dynamic)action名字的列表或者通配值,action的名字可以在日志事件的action域中找到, 匹配该值的所有action的日志事件不会打印出来。

    xpack.security.audit.logfile.events.ignore_filters.<policy_name>.roles

      Dynamic)角色列表或者角色通配值(wildcards)。匹配该值并且拥有该角色的所有用户的日志事件不会打印出来。如果用户拥有多个角色,而一些角色没有被策略覆盖到,那么该策略不会覆盖其日志事件。

    xpack.security.audit.logfile.events.ignore_filters.<policy_name>.indices

      Dynamic)索引名字列表或者通配值,日志事件中所有的索引名都匹配后才不会打印。如果事件中涉及(concern)了多条索引,并且一些索引没有被该策略覆盖到,那么该策略不会覆盖日志事件。

    Circuit breaker settings

    (8.2)link

      Elasticsearch包含多种熔断器来防止导致OOM的操作。每一种熔断器指定了内存的使用限制。另外,父级别的熔断器指定了内存的总量,限制子级别的熔断器的内存使用总量。

      除了特别的说明,这些设置能通过cluster-update-settings API在运行中的集群上进行动态的更新。

      关于熔断器提供的报错信息,见Circuit breaker errors

    Parent circuit breaker

      父级别的熔断器可以通过下面的设置进行配置:

    indices.breaker.total.use_real_memory

      Static)如果该值为true,那么父级别的熔断器会考虑真实的内存使用量,否则考虑的是子级别的熔断器预定(reserved)的内存量总和。默认值为true。

    indices.breaker.total.limit

      Dynamic)当indices.breaker.total.use_real_memory为false,并且虚拟机的内存使用量达到70%,或者当indices.breaker.total.use_real_memory为true时,并且虚拟机的内存使用量达到95%,所有的父熔断器开始限制内存使用。

    Field data circuit breaker

      Filed data熔断器会估算把域filed载入到field data cache所使用的堆内存量。如果载入后会导致缓存超过了先前定义的内存限制值,熔断器将会停止该操作并返回错误。

    indices.breaker.fielddata.limit

      Dynamic)fielddata breaker的限制值,默认是40%的JVM堆内存量。

    indices.breaker.fielddata.overhead

      Dynamic)该配置是一个常量,所有field data的估算值乘以这个常量来计算出最终的估算值。默认是值1.03。

    Request circuit breakeredit

      Request熔断器允许Elasticsearch防止每一个请求的数据结构(例如,在一次请求中,聚合计算占用的内存量)超过一定量的内存量。

    indices.breaker.request.limit

      Dynamic)Request熔断器的限制值,默认是60%的JVM堆内存量。

    indices.breaker.request.overhead

      Dynamic)该配置是一个常量,所有Request的估算值乘以这个常量来计算出最终的估算值。默认是值1。

    In flight requests circuit breaker

      in flight Request熔断器允许Elasticsearch限制所有在传输或者HTTP层的请求的内存使用量不超过在一个节点上的相对内存总量。内存使用量基于请求本身的content length。This circuit breaker also considers that memory is not only needed for representing the raw request but also as a structured object which is reflected by default overhead。

    network.breaker.inflight_requests.limit

      Dynamic)in flight Request熔断器的限制值,默认是60%的JVM堆内存量。

    network.breaker.inflight_requests.overhead

      Dynamic)该配置是一个常量,所有in flight Request的估算值乘以这个常量来计算出最终的估算值。默认是值2。

    Accounting requests circuit breaker

      accounting熔断器允许Elasticsearch限制某些请求已经结束,但是相关内存还未被释放的内存量。比如说Lucene的段占用的内存。

    indices.breaker.accounting.limit

      Dynamic)accounting熔断器的限制值,默认是100%的JVM堆内存量。这意味着受到父级熔断器的配置限制。

    indices.breaker.accounting.overhead

      Dynamic)该配置是一个常量,所有accounting Request的估算值乘以这个常量来计算出最终的估算值。默认是值1。

    Script compilation circuit breaker

      和上文中的熔断器稍微不同的是,Script compilation熔断器限制了在一个时间周期内inline script compilation的数量。

      scripting 文档中prefer-parameters章节的内容来了解更多。

    script.max_compilations_rate

      Dynamic)Limit for the number of unique dynamic scripts within a certain interval that are allowed to be compiled. Defaults to 150/5m, meaning 150 every 5 minutes。

    Regex circuit breakeredit

      写的不好的正则表达式会降低(degrade)集群稳定性以及性能。regex熔断器限制了Painless scripts中正则表达式的使用以及复杂性。

    script.painless.regex.enabled

      Static))允许painless脚本中使用正则表达式,该值可以是:

    script.painless.regex.limit-factor

      Static))用来限制painless脚本中正则表达式的字符数量。Elasticsearch通过当前设置的值与脚本输入的值的长度的乘积值作为限制值。

      比如说输入值foobarbaz的长度为9,如果script.painless.regex.limit-factor的值为6,那么基于foobarbaz的正则表达式的长度为54(6 * 9)。如果超过这个限制值,将触发regex熔断器并返回错误。

      只有script.painless.regex.enabledlimited时,Elasticsearch才会使用该限制值。

    Cluster-level shard allocation and routing settings

    link

      Shard allocation说的是分配分片到节点的过程。该过程会在initial recovery、副本(replica)分配、rebalancing或者增加或者移除节点时发生。

      master node的其中一个作用是决定如何分配分片到节点,何时在节点之间移动分片来平衡集群。

      以下的一些设置用来控制分配分片的过程:

      除此之外,还有一些其他的配置,见Miscellaneous cluster settings

    Cluster-level shard allocation settings

      你可以使用下面的设置来控制分片的分配以及恢复:

    cluster.routing.allocation.enable

      Dynamic)开启或者关闭某些分片类型的分配:

      在节点重启后,上述的配置不会影响本地主分片的恢复。重启后的节点的一个未分配的主分片的allocation id如果匹配集群状态中的active allocation ids,那么会立即恢复。

    cluster.routing.allocation.node_concurrent_incoming_recoveries

      Dynamic)在一个节点上允许同时进行恢复incoming recoveries的并发数量。incoming recoveries中的分片(大多数是分片副本或者就是分片正在重新分配位置relocating)将被分配到当前节点上。默认值是2。

    cluster.routing.allocation.node_concurrent_outgoing_recoveries

      Dynamic)在一个节点上允许同时进行恢复outgoing recoveries的并发数量。outgoing recoveries中的分片(大多数是当前节点上的主分片或者就是分片正在重新分配位置relocating)将被分配到当前节点上。默认值是2。

    cluster.routing.allocation.node_concurrent_recoveries

      Dynamic)一种快捷方法shortcut来设置cluster.routing.allocation.node_concurrent_incoming_recoveriescluster.routing.allocation.node_concurrent_outgoing_recoveries

    cluster.routing.allocation.node_initial_primaries_recoveries

      Dynamic)在一个节点重启后,分片副本replica的恢复是通过网络实现的,然而一个未分配的主分片unassigned primary则是通过读取本地磁盘数据恢复的。在同一个节点上通过这种本地恢复的方式是很快的,默认值是4。

    cluster.routing.allocation.same_shard.host

      Dynamic)该值允许执行一个检查,防止在单个主机上上分配多个相同的分片,通过主机名以及主机地址来描述一台主机。默认值是false。意味着默认不会进行检查。只有在同一台机器上的多个节点启动后,该值才会作用(apply)。

    Shard rebalancing settings

      当每一个节点上的分片数量是相等并且在任何节点的任何索引上没有集中分片(concentration of shards),那么集群是平衡的。Elasticsearch会运行一个自动化处理(automatic process)称为rebalancing,它会在集群中的节点之间移动分片来提高平衡性。rebalancing遵守类似 allocation filteringforced awareness的分片分配规则。这些规则会阻止完全的平衡集群,因此rebalancing会努力(strive to)在你配置的规则下尽可能的去平衡集群。如果你正在使用 data tiers,那么Elasticsearch会自动的应用分配过滤规则将每一个分配放到合适的数据层,这些规则意味着平衡器在每一层中独立工作。

      你可以使用下面的设置在集群中控制分片的平衡:

    cluster.routing.rebalance.enable

      Dynamic)为指定的分片类型开启或关闭rebalancing:

    cluster.routing.allocation.allow_rebalance

      Dynamic)用于指定什么时候允许分片rebalancing

    cluster.routing.allocation.cluster_concurrent_rebalance

      Dynamic)用于控制集群范围(cluster wide)内分片平衡并发数,默认值是2。注意的是这个设置仅仅控制因为集群不平衡导致的分片重定位(shard relocating)的并发数。这个设置不会限制因 allocation filteringforced awareness导致的分片重定位。

    Shard balancing heuristics settings

      基于每个节点上分片的分配情况计算出一个weight来实现rebalancing,并且通过在节点之间移动分片来降低heavier节点的weight并且提高lighter节点的weight。当不存在可能使任何节点的权值与其他节点的权值更接近超过可配置阈值的分片移动时,集群是平衡的。下面的设置允许你控制计算的细节

    cluster.routing.allocation.balance.shard

      Dynamic)为节点上分配的分片总数定义一个weight因子。默认值是0.45f。提高这个值会使集群中所有节点的分片数量趋于均衡。

    cluster.routing.allocation.balance.index

      Dynamic)为每一个索引的分片数量定义一个weight因子。默认值是0.55f。提高这个值会使集群中所有节点上的每一个索引的的分片数量趋于均衡。

    cluster.routing.allocation.balance.threshold

      Dynamic)该值时候一个非负的浮点之后,Minimal optimization value of operations that should be performed。提高这个值将导致集群在优化分片平衡方面不那么积极(leess aggressive)。

    NOTE:无论balancing算法的结果如何,rebalancing可能因为forced awareness或者allocation filtering而无法执行

    Disk-based shard allocation settings

      基于磁盘的分片分配器能保证所有节点都有足够的磁盘空间而不用执行更多的分片移动。它基于一对阈值来分配分片:low wateremark 和 high watermark。主要的目的是保证在每一个节点不会超过high watermark,或者是暂时的超过(overage is temporary)。如果某个节点上超过了high watermark,那么Elasticsearch会通过把分片移动到集群中的其他节点来的方式来解决。

    NOTE:节点上有时(from time to time)出现临时的超过high watermark是正常的

      分配器总是尝试通过禁止往已经超过low watermark的节点分配更多分配的方式来让节点远离(clear of)high watermark。重要的是,如果所有的节点都已经超过了low watermark那么不会有新的分片会被分配并且Elasticsearch不会通过在节点间移动分片的方式来让磁盘使用率低于high watermark。你必须保证在你的集群中有足够的磁盘空间并且总存在一些低于low watermark的节点。

      通过基于磁盘的分片分配器进行的分片移动必须满足(satisfy)其他的分片分配规则,例如 allocation filteringforced awareness。如果这些规则过于严格,它们还可以防止碎片移动,以保持节点的磁盘使用在控制之下。如果你正在使用 data tiers,那么Elasticsearch会自动的应用分配过滤规则将每一个分配放到合适的数据层,这些规则意味着平衡器在每一层中独立工作。

    (未完成)

    cluster.routing.allocation.disk.watermark.high
    cluster.routing.allocation.disk.watermark.flood_stage

     

    Shard allocation awareness

      你可以自定义节点属性作为感知属性(awareness attributes)让Elasticsearch在分配分片时考虑你物理硬件的配置。如果Elasticsearch知道哪些节点在同一台物理机上、同一个机架(rack)、或者同一个区域,使得在发布主分片跟分片副本时能最低限度的降低丢失所有分片副本的风险。

      当使用(Dynamic)的cluster.routing.allocation.awareness.attributes的设置开启awareness attribute后,分片只会被分配到设置了awareness attributes的节点上。当你使用多个awareness attribute时,Elasticsearch在分配分片时会单独地(separately)考虑每一个attribute。

    NOTE: attribute values的数量决定了每一个位置上分配副本的分配数量。如果在每一个位置上的节点数量是unbalanced并且有许多的副本,副本分片可能不会被分配

    Enabling shard allocation awareness

      开启分片的分配awareness,需要:

    1. 使用一个自定义的节点属性来指定每个节点的位置。如果你想要Elasticsearch在不同的机架间发布分片,你可能需要在配置文件elasticsearch.yml上设置一个名为rack_id的属性。

      你也可以在启动的时候设置自定义的属性。

    1. 在每一个master-eligible node的配置文件elasticsearch.yml上设置cluster.routing.allocation.awareness.attributes,告诉Elasticsearch在分配分片的时候要考虑一个或者多个awareness attribute。

      用逗号分隔多个属性。

      你也可以使用cluster-update-settings API来设置或者更新集群的awareness attributes。

      基于上述的配置例子,如果你启动了两个节点并且都设置node.attr.rack_idrack_one并且为每个index设置5个主分片,每个主分片设置一个分片副本,那么这两个节点都包含所有的主分片以及分片副本。

      如果你增加了两个节点并且都设置node.attr.rack_idrack_two,Elasticsearch会把分配移动到新的节点,ensuring(if possible)相同的分片副本不会在相同的机架上。

      如果rack_two失败并关闭了它的两个节点,默认情况下,Elasticsearch会将丢失的碎片副本分配给rack_one中的节点。为了防止特定分片的多个副本被分配到相同的位置,可以启用forced awareness。

    Forced awareness

      默认情况下,如果一个位置失败了(one location fails),Elasticsearch将缺失的分片分配到剩余的位置。可能所有的位置都有足够的资源来存放主分片跟分片副本,也有可能某个位置无法存储所有的分片。

      为了防止某个位置因为失败事件(event of failure)而造成负载过高(overload),你可以设置cluster.routing.allocation.awareness.force使得分片副本不会被分配直到其他位置可以被分配。

      比如说,如果你有一个awareness attribute 名为zone并且在两个节点分别配置zone1zone2,那么在只有一个zone可用的情况,你可以使用forced awareness来防止Elasticsearch分配分片副本。

      为awareness attribute指定所有可能的值。

      基于上述的配置例子,如果启动了两个节点并且设置node.attr.zone的值为zone1并且为每个index设置5个分片,每个分片设置一个分片副本,那么Elasticsearch会创建索引并且分配5个主分片但是不会有分片副本。只有某个节点设置node.attr.zone的值为zone2才会分配分片副本。

    Cluster level shard allocation filtering

      你可以使用cluster-level shard allocation filters来控制Elasticsearch从任何索引分配分片的位置。结合per-index allocation filteringallocation awareness来应用集群级别(cluster wide)的filter。

      Shard allocation filters可以基于自定义的节点属性或者内建的属性:_name, _host_ip, _publish_ip, _ip, _host,_id_tier

      cluster.routing.allocation设置是动态的Dynamic,允许将live indices从一组节点上移动到其他组。只有在不破坏路由约定(routing constraint)下才有可能重新分配分片,比如说不会将主分片和它的分片副本分配到同一个节点上。

      最常用的cluster-level shard allocation filtering用例是当你想要结束(decommission)一个节点。要在关闭节点之前将分片移出节点,您可以创建一个过滤器,通过其 IP 地址排除该节点:

    Cluster routing settings
    cluster.routing.allocation.include.{attribute}

      (Dynamic)将分配分片到一个节点,这个节点的{attribute}至少是用逗号隔开的多个属性中的一个。

    cluster.routing.allocation.require.{attribute}

      (Dynamic)只将分片分配到一个节点,这个节点的{attribute}包含所有用逗号隔开的多个属性。

    cluster.routing.allocation.exclude.{attribute}

      (Dynamic)不将分片分配到一个节点,这个节点的{attribute}包含用逗号隔开的多个属性中的任意一个。

      cluster allocation settings支持下面的内建属性:

    _name根据node name匹配节点
    _host_ip根据host IP 地址(hostname关联的IP)匹配节点
    _publish_ip根据发布的IP地址匹配节点
    _ip根据_host_ip或者_publish_ip匹配节点
    _host根据hostname匹配节点
    _id根据node id匹配节点
    _tier根据节点的data tier角色匹配节点

    NOTE: _tier的过滤基于 node roles,只有部分角色是 data tier 角色,并且generic data role将会匹配任何的tier filtering。a subset of roles that are data tier roles, but the generic data role will match any tier filtering.

      在指定attribute values时可以使用通配符,例如:

    Miscellaneous cluster settings
    Metadata

      通过下面的设置可以将整个集群设置为read-only:

    cluster.blocks.read_only

      (Dynamic) 让整个集群read only(索引不支持写操作),metadata不允许更改(创建或者删除索引)

    cluster.blocks.read_only_allow_delete

      (Dynamic) 与cluster.blocks.read_only一样,但是允许删除索引来释放资源。

    WARNING: 不要依赖这些设置来防止集群发生变更。任何有cluster-update-settings API 访问权限的用户都可以让集群再次read-write

    Cluster shard limit

      基于集群中的节点数量,集群中分片的数量有一个soft limit。这是为了防止可能无意中破坏集群稳定性的操作。

    IMPORTANT:这个限制作为一个安全网(safety net),不是一个推荐的大小。你集群中可以安全支持的准确的分片数量取决于你的硬件配置跟工作负载,但是在大部分case下,这个limit应该还不错,因为默认的limit是非常大的。

      如果一个操作,比如创建新的索引,恢复索引的snapshot,或者打开一个关闭的索引会导致集群中的分片数量超过限制。这个会失败并且给出shard limit的错误。

      如果由于node membership的变化或者设置的变更使得集群已经超过了限制,所有创建或者打开索引的操作都会失败直到下文中将介绍的提高limit或者关闭删除一些索引使得分片的数量降到了limit以下。

      对于normal indices(non-frozen),每一个non-frozen data node上cluster shard limit的默认值是1000,对于frozen indices,每一个frozen data node上的默认值是3000。所有打开的索引的主分片跟分片副本的数量都会纳入到统计中(count toward the limit),包括未分配的分片。例如5个主分片和2个副本的数量为15个分片。关闭的索引不会参与分片的统计。

      你可以使用下面的方式动态的调整cluster shard limit:

    cluster.max_shards_per_node

      (Dynamic) 限制集群中主分片跟副本分片的总数量。Elasticsearch使用下面的公式统计limit:

      cluster.max_shards_per_node * number of non-frozen data nodes

      关闭的索引不会纳入到统计中。默认是1000。没有data node的集群是没有限制的。

      超过上限后,Elasticsearch会reject创建更多分片的请求。比如集群的cluster.max_shards_per_node的值是100,并且三个data node就有300的分片数量限制。如果集群中已经包含了296个分片,Elasticsearch会reject增加5个或者更多分片数量的请求。

      注意的是frozen shard有他们自己独立的限制。

    cluster.max_shards_per_node.frozen

      (Dynamic) 限制集群中主分片跟replica frozen shard的总数量。Elasticsearch使用下面的公式统计limit:

      cluster.max_shards_per_node * number of frozen data nodes

      关闭的索引不会纳入到统计中。默认是3000。没有frozen data node的集群是没有限制的。

      超过上限后,Elasticsearch会reject创建更多frozen shard的请求。比如集群的cluster.max_shards_per_node.frozen的值是100,并且三个frozen data node就有300的分片数量限制。如果集群中已经包含了296个分片,Elasticsearch会reject增加5个或者更多frozen shard数量的请求。

    NOTE: These setting do not limit shards for individual nodes. 可以使用设置cluster.routing.allocation.total_shards_per_node来限制每一个节点上的分片数量。

    User-defined cluster metadata

      可以通过Cluster Settings API来存储以及查询用户自定义的集群元信息(User-defined cluster metadata)。可以用来存储任意的(arbitrary),很少更改(infrequently-changing)的关于集群的信息,而不需要创建索引来存储这些信息。使用以cluster.metadata为前缀的任意的key来存储信息。例如,在cluster.metadata.administrator这个key下存储管理员的email地址,如下所示:

    IMPORTANT: User-defined cluster metadata不要存储敏感的或者机密信息。任何人都可以通过Cluster Get Settings API访问存储在User-defined cluster metadata的信息,并且会被记录在Elasticsearch日志中。

    Index tombstones

      集群状态(cluster state)维护者index tombstone来显示的告知(denote)被删除的索引。集群状态维护tombstone的数量,通过下面的设置来进行控制:

    cluster.indices.tombstones.size

    Static)当发生删除时,Index tombstones会阻止不属于集群的节点加入集群并重新导入索引,就好像delete was never issued。为了防止增长的太大,我们只保留最新的cluster.indices.tombstones.size数量的删除,默认值是500。You can increase it if you expect nodes to be absent from the cluster and miss more than 500 deletes. We think that is rare, thus the default. Tombstones don’t take up much space, but we also think that a number like 50,000 is probably too big.

      如果 Elasticsearch 遇到当前集群状态中不存在的索引数据,则这些索引被认为是dangling。 例如,如果你在 Elasticsearch 节点离线时删除超过 cluster.indices.tombstones.size 的索引,就会发生这种情况。

      你可以使用Dangling indices API来进行管理。

    Logger

      这个设置用来控制日志,使用logger.为前缀的key来动态的更新。发布下面的请求(issue this request)来提高indices.recovery模块的日志等级为DEBUG

    Persistent tasks allocation

      Plugin可以创建一系列称为persistent task的任务。这些任务通常是long-lived并且存储在cluster state中,并且允许在一次full cluster restart后恢复(revive)这些任务。

      每一次创建一个persistent task时,master node会负责将任务分配到集群中的一个节点。然后被分配的节点会pick up这个任务然后在本地执行。通过下面的设置来控制被分配的persistent task的运行:

    cluster.persistent_tasks.allocation.enable

    (Dynamic)开启或者关闭persistent task的分配:

      这个设置不会影响已经执行的persistent task。只有最新创建的,或者必须要重新被分配的persistent task才会收到这个设置的影响。

    cluster.persistent_tasks.allocation.recheck_interval

    (Dynamic)master node会自动的检查在cluster state发生重大变化(change significantly)后persistent tast是否需要被分配。然而,也会有其他的一些因素,比如说memory usage,这个会影响persistent task能否被分配但这不会引起cluster state的变更。这个设置控制了检查的间隔。默认是30秒。最小允许的时间为10秒。

    Field data cache settings

    (8.2)link

      field data cache中包含了field dataglobal ordinals,它们都是用来让某些域能够用于聚合。由于是on-heap的数据结构,所以很有必要监控缓存的使用情况。

    Cache size

      构建cache中实体(entities)的开销是很昂贵的,所以默认情况下会保留载入到内存的entities。默认的cache大小是没有限制的,cache大小会不断增大直到达到field data circuit breaker设定的上限。这种行为可以配置。

      如果设置了cache大小的上限,cache将会清除cache中最近更新的实体(If the cache size limit is set, the cache will begin clearing the least-recently-updated entries in the cache)。这个设置会自动的避免circuit breaker limit,代价就是需要重新构建cache。

      如果达到了circuit breaker limit,后续会增加cache大小的请求将被阻止。在这种情况下你必须要手动clear the cache

    indices.fielddata.cache.size

      Static)) field data cache的最大值。比如节点堆空间大小的38%,或者是一个absolute value,12GB。默认是没有限制。如果选择设置这个值,这个值应该小于Field data circuit breaker limit

    Monitoring field data

      你可以使用nodes stats APIcat fielddata API来监控filed data的内存使用情况以及 field data circuit breaker。

    Index lifecycle management settings in Elasticsearch

    link

    Index level settings
    index.lifecycle.origination_date
    index.lifecycle.parse_origination_date
    index.lifecycle.step.wait_time_threshold

    Index management settings

    link

    stack.templates.enabled

    Indexing buffer settings

    (8.2)link

      indexing buffer用来缓存新添加的文档,当缓冲区满后,缓存中的文档会被写入到一个段中并且存放到磁盘上。Indexing buffer的大小被节点上的所有分片共享。

      下面的设置都是静态的必须在集群中的每一个节点上配置:

    indices.memory.index_buffer_size

      Static)可以是百分比或者是字节单位的数值。默认是10%意味着堆内存的10%会被分配给节点用于Indexing buffer,并且被节点上所有的分片共享。

    indices.memory.min_index_buffer_size

      Static)如果index_buffer_size指定为百分比,那这个设置用来指定为一个绝对最小值(absolute minimum)。默认是是48m

    indices.memory.max_index_buffer_size

      Static)如果index_buffer_size指定为百分比,那这个设置用来指定为一个绝对最大值(absolute maximum)。默认是无限制的。

    Local gateway settings

    link

    Dangling indices

    Logging

    link

    Machine learning settings in Elasticsearch

    link

    Node

    (8.2)link

      任何时候在你启动了一个Elasticsearch的实例时,即你正在启动一个节点(Node)。相互连接的节点集合成为一个集群(cluster)。如果你运行了 一个单个节点的Elasticsearch,那么你拥有一个只有一个节点的集群。

      默认情况下,集群中的每个节点都可以处理 HTTP and transport的传输。transport layer只用来处理节点之间的交互,HTTP layer用于REST clients 。

      所有的节点都知道集群中的其他节点并且可以转发客户端的请求到合适的节点。

    Node roles

      你可以在elasticsearch.yml中设置node.roles来定义一个节点的角色。如果你设置了node.roles,这个节点只会被分配为你指定的角色。如果你不指定node.roles,这个节点会被分配为下面的角色:

    IMPORTANT:如果你设置了node.roles,你要保证你的集群需要你指定的这些角色。每一个集群需要有下面的角色:

    • master
    • (data_content和data_hot) 或者 data

    一些Elastic Stack 特性同样要求指定下面的节点角色:

    • 跨集群搜索(Cross-cluster search)和跨集群副本(Cross-cluster replication)需要remote_cluster_client角色
    • Stack Monitoring和ingest pipeline需要ingest角色
    • Fleet,Elastic Security应用,和transforms需要transform角色。remote_cluster_client角色同样需要用于这些特性中的cross-cluster search
    • Machine learning特性,比如异常检测(anomaly detection)需要ml角色

      随着集群的增长,特别是集群中有大规模的machine learning任务、continuous transforms,我们建议从专用的data node、machine learning node、transform node中分离出master-eligible节点。

    Master-eligible node拥有master角色的节点,使得节点有资格被选举为master node来控制整个集群
    Data node拥有data角色的节点,data node保留数据并且执行相关操作例如CRUD、查询、聚合。一个拥有data角色的节点可以添加任何其他特定的数据节点角色,例如hot 、warm等
    Ingest node拥有ingest角色的节点,ingest node可以对文档进行ingest pipeline使得可以在索引前transform或者丰富文档。对于繁重的ingest,使用专用的ingest node并且让拥有master或者data角色的节点不要有ingest角色
    Remote-eligible node拥有remote_cluster_client角色的节点,使得这个节点有资格成为一个remote client
    Machine learning node拥有ml角色的节点,如果你想要使用machine learning特性,你的集群中至少要有一个machine learning node。见Machine learning settingsMachine learning in the Elastic Stack了解更多信息
    Transform node拥有transform角色的节点。如果想要使用transform,你的集群中至少要有一个transform node。见Transforms settingsTransforming data了解更多信息

    NOTE:Coordinating node 一些像查询请求或者块索引(bulk-indeing)的请求可能涉及不同data node上的数据。一次查询请求,例如,搜索请求分两个阶段执行,由接收客户端请求的节点进行协调 - coordinating node。

    在scatter阶段,coordinating node将请求转发给持有数据的数据节点。 每个数据节点在本地执行请求并将其结果返回给coordinating node。 在收集(gather)阶段,协调节点将每个数据节点的结果减少为单个全局结果集。

    每个节点都隐含的是一个coordinating node。 这意味着通过设置 node.roles 为空的角色列表的节点将作为coordinating node,并且不能被关闭这种设定。 因此,这样的节点需要有足够的内存和 CPU 才能处理收集阶段。

    Master-eligible node

      master node负责轻量级(lightweight)的集群范围(cluster-wide)的一些工作,比如创建、删除一个索引,跟踪哪些节点是集群的一部分以及决定给哪里节点分配分片。稳定的master node对于集群的健康是十分重要的。

      一个不是voting-only的master-eligible node会在master election process中被选为master node。

    IMPORTANT: master node必须有一个path.data目录,其内容在重启后仍然存在,跟data node一样,这个目录中存放了集群的元数据(cluster metadata)。集群元数据描述了如何读取存储在data node上的数据,所以如果丢失了集群元数据就无法读取data node上的数据。

    Dedicated master-eligible node

      满足被选举为master的节点为了能完成它的职责所需要的资源对于集群的健康是十分重要的。如果被选举为master的节点因为其他的工作导致超负荷了,那么集群将无法较好的运行。避免master node工作超负荷最可靠的方法就是将所有master-eligible node只配置为master角色,让它们作为专用的master-eligible node(dedicated master-eligible node),让它们集中做好管理集群的工作。Master-eligible node可以跟coordinating nodes一样将客户端的请求路由到集群中的其他节点,但是你不应该让专用的master-eligible node做这些事情。

      在一些小规模或者轻负载(lightly-loaded)的集群中,如果master-eligible node有其他的角色和职责也可以正常的运行,但是,一旦集群中包含多个节点,通常使用专用的master-eligible node是有意义的。

      通过设置下面的配置来创建一个专用的master-eligible节点:

    Voting-only master-eligible node

      voting-only master-eligible node是会参与master elections的节点,但是不会成为集群的master节点。特别在于一个voting-only node可以成为选举过程中的tiebreaker。

      使用"master-eligible"这个词来描述一个voting-only node看起来有点让人困惑,因为这种节点是完全没资格成为master节点的。使用这个术语是因为历史的原因(This terminology is an unfortunate consequence of history):master-eligible node是那些参与选举、集群状态发布(cluster state publication)期间执行一些任务的节点,而voting-only node有着相同的工作职责(responsibility)只是他们不会被选举为master节点。

      通过添加mastervoting_only角色来配置一个master-eligible node为voting-only node。下面的例子创建了一个voting-onyl data node:

    IMPORTANT:只有拥有master角色的节点才可以标记为拥有voting_only角色。

      高可用(HA:high availability)的集群要求至少有三个master-eligible node,他们中的至少两个节点不是voting-only node。这样的集群才能够在其中一个节点发生故障后选出一个master节点。

      由于voting-only node不会被选举为master节点,所以相比较真正的master node,它们需要较少的堆以及较低性能的CPU。然而所有的master-eligible node,包括voting-only node,相比较集群中的其他节点,它们需要相当快速的持久存储以及一个可靠的低延迟的网络连接,因为它们处于publishing cluster state updates的关键路径(critical path)上。

      Voting-only master-eligible node在集群中可能被分配其他的角色。比如说一个节点同时是data node或者Voting-only master-eligible node。一个专用的voting-only master-eligible node 在集群中是不会有其他的角色的。通过下面的方式来创建一个专用的voting-only master-eligible nodes:

    Data node

      data note保留了你索引的文档的分片。data note处理像CRUD、查询、聚合的操作。这些操作有I/O-, memory-, and CPU-intensive。监控这些资源以及工作负载大后增加更多的data node是非常重要的。

      拥有专用的data node最主要的好处是将master和data角色分开出来。

      通过下面的方式创建一个专用的data node:

      多层部署架构(multi-tier)中,你可以根据为data node分配不同数据层对应的数据角色(data role):data_content,data_hot, data_warm, data_cold, 或者data_frozen。一个节点可以属于多个层,但是已经拥有一个指定数据角色的节点不能有通用的data角色(generic data role)。

    Content data node

      Content data node属于content tier的一部分。存储在content tier上的数据通常是iterm的集合比如说产品目录(product catalog)或者文章归档(article archive)。跟时序数据不同的是,这些内容的价值随着时间的流逝相对保持不变的,所以根据这些数据的寿命(age)将它们移到性能不同的数据层是不合理的。Content data通常有长时间保留(retention)的要求,并且也希望无论这些数据的寿命的长短,总是能很快的检索到。

      Content tier node会为查询性能做优化-优先优化IO吞吐使得可以处理复杂的查询,聚合并且能很快的返回结果。同时这类节点也用来索引,content data通常没有例如log和metric这种时序数据一样高的ingest rate。从弹性的角度(resiliency perspective)看,当前层的索引应该配置为使用一个或者多个副本(replica)。

      Content tier是必须要有的(required)。系统索引以及其他不是data stream的索引都会被自动分配到content tier。

      通过下面的方式创建一个专用的content node:

    Hot data node

      hot data node是 hot tier的一部分。hot tier是Elasticsearch中时序数据的入口点(entry point),并且保留最近,最频繁搜索的时序数据。hot tier节点上的读写速度都需要很快,要求更多的硬件资源和更快的存储(SSDs)。出于弹性目的,hot tier上的索引应该配置一个或多个分片副本。

      hot tier是必须要有的。data stream中新的索引会被自动分配到hot tier。

      通过下面的方式创建一个专用的hot node:

    Warm data node

      warm data node是warm tie的一部分。一旦时序数据的访问频率比最近索引的数据(recently-indexed data)低了,这些数据就可以移到warm tier。warm tier通常保留最近几周的数据。允许更新数据,但是infrequent。warm tier节点不需要像hot tier一样的快。出于弹性目的,warm tier上的索引应该配置一个或多个分片副本。

      通过下面的方式创建一个专用的warm node:

    Cold data node

      cold data node是cold tier的一部分。当你不再经常(regular)搜索时序数据了,那可以将它们从warm tier移到cold tier。数据仍然可以被搜索到,在这一层的通常会被优化成较低的存储开销而不是查询速度。

      为了更好的节省存储(storage saveing),你可以在cold tier保留fully mounted indicessearchable snapshots。跟普通索引(regular index)不同的是,这些fully mounted indices不需要分片副本来满足可靠性(reliability),一旦出现失败事件,可以从底层(underlying)snapshot中恢复。这样可以潜在的减少一般的本地数据存储开销。snapshot仓库要求在cold tier使用fully mounted indices。Fully mounted indices只允许读取,不能修改。

      另外你可以使用cold tier存储普通索引并且使用分片副本的方式,而不是使用searchable snapshot,这样会帮你在较低成本的硬件上存储较老的索引,但是相比较warm tier不会降低磁盘空间。

      通过下面的方式创建一个专用的cold node:

    Frozen data node

      frozen data node是frozen tier的一部分。一旦数据不需要或者很少(rare)被查询,也许就可以将数据从cold tier移到frozen tier,where it stays for the rest of its life。

      frozen tier需要用到snapshot repository。frozen tier使用partially mounted indices的方式存储以及从snapshot repository中载入数据。这样仍然可以让你搜索frozen数据并且可以减少本地储存(local storage)和操作开销(operation cost)。因为Elasticsearch必须有时从snapshot repository中提取(fetch)数据,在frozen tier的查询速度通常比cold tier慢。

    Ingest node

      Ingest node可以执行pre-processing pipelines。由一个或者多个ingest processor组成。基于ingest processor执行的操作类型以及需要的资源,拥有一个专用的ingest node还是有意义的,使得这个节点只运行指定的任务。

      通过下面的方式创建一个专用的Ingest node:

    Coordinating only node

      如果你的节点不需要(take away)处理master职责(duty)、保留数据、pre-process文档的能力,那么你还剩下一个coordinating only node,只能处理路由请求、查询的reduce phase、以及分布式的块索引(bulk Indexing)。本质上coordinating only node表现为像一个智能的负载均衡节点。

      在大规模的集群中将coordinating node角色从data node和master-eligible node中剥离(offload)出来能体现coordinating only nodes的益处。这些节点加入到集群中并且接收完整的cluster state,就像每一个其他的节点一样,他们使用cluster state将请求路由到合适的地方。

    WARNING:集群中添加太多的coordinating only nodes会增加整个集群的负担(burden),因为被选举为master的节点必须等待从每一个节点更新后的cluster state的回应。不能过度夸大(overstate)coordinating only node的益处-data node也可以实现跟coordinating only nodes相同的目的(same purpose)

      通过下面的方式创建一个专用的coordinating node:

    Remote-eligible node

      一个remote-eligible node扮演一个cross-cluster client的角色以及连接remote clusters。一旦连接后,你可以使用cross-cluster search搜索远端的集群。你可以使用cross-cluster replication在集群间同步数据。

    Machine learning node

      Machine learning node运行任务并且处理machine learning API的请求。见Machine learning settings查看更多的信息

      通过下面的方式创建一个专用的machine learning node:

      remote_cluster_client是可选的,但是强烈建议配置进去。否则当使用machine learning jobs 或者 datafeed时,cross-cluster search会失败。如果在你的异常检测任务中使用corss-cluster search,在所有的master-eligible node上同样需要remote_cluster_client这个角色。否则 datafeed无法开始,见Remote-eligible node

    Transform node

      Transform node运行transforms并且处理transform API的请求。见Transforms settings

      通过下面的方式创建一个专用的transform node:

      remote_cluster_client是可选的,但是强烈建议配置进去。否则当使用transforms时,cross-cluster search会失败。见Remote-eligible node

    Changing the role of a node

      每一个data node在磁盘上维护下面的数据:

      同样的,每一个master-eligible node在磁盘上维护下面的数据:

      每一个节点在启动时会检查数据路径的内容。如果发现了非预期(unexpected)的数据,节点将拒绝启动。这样就可以避免导入会导致红色的集群健康的unwanted dangling indices。更准确的说,如果在启动时发现磁盘上有分片数据但是这个节点没有data角色,那么这个节点不会启动。如果在启动时发现磁盘上有索引元数据但是这个节点没有datamaster角色,那么这个节点不会启动。

      可以通过更改elasticsearch.yml然后重启节点来修改节点的角色。这就是众所周知的 repurposing一个节点。为了能满足上文中描述的对非预期的检查,在启动没有data或者master角色的节点前,你必须执行一些额外的步骤来为repurposing做准备。

      如果没有办法按照这些额外的步骤实现你的目的,你可以使用elasticsearch-node repurpose工具来删除阻止节点启动的多余的数据(excess data)。

    Node data path settings
    path.data

      每个data node、master-eligible node都要访问一个数据目录,这个目录中存放了分片、索引和集群元数据。path.data的默认值是$ES_HOME/data但是可以在elasticsearch.yml中配置一个全路径或者一个相对于$ES_HOME的相对路径:

      跟其他的节点设置一样,可以在命令行上指定:

      path.data的内容在启动时必须存在,因为这是你数据存储的位置。Elasticsearch 要求文件系统像由本地磁盘支持一样运行,但这意味着只要远程存储正常运行,它就可以在配置正确的远程块设备(例如 SAN)和远程文件系统(例如 NFS)上正常工作,与本地存储没有什么不同。你可以在同一个文件系统上运行多个Elasticsearch节点,但是每个节点要有自己的数据路径。

      Elasticsearch集群的性能常常受制于底层存储的性能,所以你必须保证你的存储能有可以接受的性能范围内。一些远程存储的性能很差,尤其是在 Elasticsearch 施加(impose)的那种负载下,所以在使用特定的存储架构之前,请确保仔细地对你的系统进行基准测试。

    TIP:如果使用了.zip或者.tar.gz的发行版,path.data的值应该设置到ELasticsearch home目录以外的路径上,这样删除home目录时不会删除你的数据!RPM和Debian发行版已经为你做了这些工作。

    IMPORTANT:不要修改数据目录中的任何东西或者运行可能会影响这个目录中内容的程序。如果一些不是Elasticsearch的操作修改了数据目录的内容,那么Elasticsearch可能会发生故障,报告出corruption或者其他data inconsistencies,或者工作正常但是轻微的丢失了一些你的数据。不要尝试做文件系统级别的数据目录的备份。因为没有可用的方法来恢复这类备份。而是应该用 Snapshot and restore做安全的备份。不要在数据目录做病毒扫描,病毒扫描会使得Elasticsearch不能正确的工作并且可能会修改数据目录的内容。数据目录不包含可执行文件,因此病毒扫描只会发现误报

    Other node settings

      更多的跟节点相关的设置可以在Configuring ElasticsearchImportant Elasticsearch configuration找到,包括:

    Networking

    link

    Node query cache settings

    link

    Advanced HTTP settings
    http.max_content_length

    License settings

    link

    Search settings

    (8.2)link

      下面的expert setting用来管理全局的查询和聚合限制。

    indices.query.bool.max_clause_count

      Static integer)一个查询能包含的clause的最大数量。默认值为4096

      这个设置限制了一颗query tree能包含的clause的最大数量。4096这个默认值已经是非常高了,通常来说该值是够用的。这个限制会作用于重写query(rewrite query),所以不仅仅是bool query,所有会重写为bool query的query,例如fuzzy query,都会有较高数量的clause。这个限制的目的是防止查询的范围变得很大,占用过多的CPU和内存。如果你一定要提高这个值,保证你已经竭尽全力尝试了所有其他的选项,否则就不要这么做。较高的值会导致性能降低以及内存问题,特别是在负载高或者资源较少的集群上。

      Elasticsearch提供了一些工具来防止遇到这个clause数量上限的问题,例如在terms query中,它允许查询许多不一样的值,但是它只作为一个clause。或者是带有index_prefixes选项的text域,它会执行prefix query,这个query会膨胀为较高数量的term,但是只作为一个term query。

    search.max_buckets

      Dynamic,integer)在一次响应中,aggregation buckets 的最大分桶数量。默认值为65535。

      尝试返回超过这个限制的请求会返回一个错误。

    indices.query.bool.max_nested_depth

      Static integer)bool query的最大深度。默认值为20

      这个设置限制了bool query的嵌套深度。深度大的bool query可能会导致stack overflow。

    Shard request cache settings

    (8.2)link

      当一个查询请求运行在一个或者多个索引上时,每一个参与的分片会在本地执行查询然后将结果返回到coordinating note,节点会结合(combine)分片级别(shard-level)的结果到一个"全局的"的结果集中。

      分片层的请求缓存模块会在每一个分片上缓存本地的结果。这允许经常使用(并且可能很重)的搜索请求几乎立即返回结果。请求缓存(request cache)非常适用于日志用例,因为这类数据只有最近的索引会持续更新,从旧的索引中获取的结果可以直接从缓存中返回。

    IMPORTANT:默认情况下,请求缓存在size=0时仅仅缓存查询请求的结果。所以不会缓存hits,但是它会缓存hits.total, aggregations以及suggestions

    大多数使用now(见 Date Math)的请求不能被缓存。

    使用脚本的查询使用了一些不确定的API调用不会被缓存,比如说Math.random() 或者 new Date()

    Cache invalidation

      The cache is smart。它可以跟非缓存的查询一样的近实时查询。

      当分片refresh后文档发生了变更或者当你更新了mapping时,缓存的结果会自动的被废止。换句话说,你总是可以从缓存中获得与未缓存搜索请求相同的结果。

      refresh的间隔时间越长意味着缓存的结果保留时间越长,即使文档已经发生了变化。如果缓存满了,基于LRU(least recently used)机制来丢弃缓存。

      可以通过clear-cache API手动将缓存置为过期的(expired):

    Enabling and disabling caching

      缓存默认开启,可以在创建一个新的索引时来关闭缓存:

      可以通过update-settings API来手动的开启或关闭缓存:

    Enabling and disabling caching per request

      request_cache 这个query-string参数可以用于在每一次请求中来开启或关闭缓存。如果设置了这个参数,会覆盖索引层(index-levele)的设置:

      请求中的size如果大于0的话则不会缓存即使在索引设置中开启了缓存。要缓存这些请求,你需要使用的query-string参数。

    Cache key

      使用完整的JSON计算出的hash值作为cache key。这意味着如果JSON发生了变更,比如说key的先后顺序发生了变化,那么对应的cache key就无法被识别。

    TIP:大多数 JSON 库都支持规范模式(canonical mode),可确保 JSON的key始终以相同的顺序发出。这种规范模式可以在应用程序中使用,以确保始终以相同的方式序列化请求。

    Cache settings

      缓存在节点层进行管理,缓存大小的最大值默认是堆内存的1%。可以通过config/elasticsearch.yml修改:

      同样的你可以使用indices.requests.cache.expire为缓存结果设置一个TTL,但是并没有理由要这么做。因为过时的结果(stale result)会在refresh后自动的废止。这个设置只是为了completeness(This setting is provided for completeness' sake only)。

    Monitoring cache usage

      缓存的大小(字节)和evictions的数量可以通过indices-stats接口来查看:

      或者通过nodes-stats接口查看:

    Transforms settings in Elasticsearch

    link

    Thread pools

    (8.2)link

      一个节点会使用多个线程池来管理内存消费(memory consumption)。许多的线程池使用队列hold住pending中的请求而不是丢弃。

      节点中有很多的线程池,下面介绍主要的几个线程池:

    generic

      用于一般的操作(例如background node discovery)。线程池类型是scaling

      用于count/search/suggest操作。线程池类型是fixed。线程数量为int((# of allocated processors * 3) / 2) + 1。队列大小为1000

    search_throttled

      用于在search_throttled indices上的count/search/suggest/get操作。线程池类型为fixed,线程数量为1,队列大小为100

    search_coordination

      用于轻量级的查询相关的协同操作(search-related coordination)。线程池类型为fixed,线程数量为a max of min(5, (# of allocated processors) / 2),队列大小为1000

    get

      用于get操作,线程池类型为fixed,线程数量为# of allocated processors,队列大小为1000

    analyze

      用于analyzer请求,线程池类型为fixed,线程数量为1,队列大小为16

    write

      用于单篇文档的 index/delete/update以及bulk的请求,线程池类型为fixed,线程数量为# of allocated processors,队列大小为10000。这个线程池的最大值是1 + # of allocated processors

    snapshot

      用于snapshot/restore请求,线程池类型为scaling,keep-alived的值为5m以及a max of min(5, (# of allocated processors) / 2)

    snapshot_meta

      用于读取snapshot repository metadata的请求,线程池类型为scaling,keep-alived的值为5m以及a max of min(50, (# of allocated processors) / 3)

    warmer

      用于segment warm-up的操作,线程池类型为scaling,keep-alived的值为5m以及a max of min(5, (# of allocated processors) / 2)

    refresh

      用于refresh的操作,线程池类型为scaling,keep-alived的值为5m以及a max of min(10, (# of allocated processors) / 2)

    fetch_shard_started

      用于列出分片状态(list shard state)的操作,线程池类型为scaling,keep-alived的值为5m以及a default maximum size of 2 * # of allocated processors

    fetch_shard_store

      用于列出分片存储(list shard store)的操作,线程池类型为scaling,keep-alived的值为5m以及a default maximum size of 2 * # of allocated processors

    flush

      用于flushtranslog fsync的操作,线程池类型为scaling,keep-alived的值为5m以及a max of min(10, (# of allocated processors) / 2)

    force_merge

      用于force merge操作,线程池类型为fixed,线程数量为1,队列大小为unbounded

    management

      用于集群管理,线程池类型为scaling,keep-alived的值为5m以及a default maximum size of 5

    system_read

      用于读取系统索引的操作,线程池类型为fixed,keep-alived的值为5m以及a default max of min(5, (# of allocated processors) / 2)

    system_write

      用于写入系统索引的操作,线程池类型为fixed,keep-alived的值为5m以及a default max of min(5, (# of allocated processors) / 2)

    system_critical_read

      用于读取关键系统索引(critical system indices)的操作,线程池类型为fixed,keep-alived的值为5m以及a default max of min(5, (# of allocated processors) / 2)

    system_critical_write

      用于写入关键系统索引(critical system indices)的操作,线程池类型为fixed,keep-alived的值为5m以及a default max of min(5, (# of allocated processors) / 2)

    watcher

      用于watch executions。线程池类型为fixed,以及a default max of min(5 * (# of allocated processors) , 50),队列大小为50

      线程池的设置是static,通过编辑elasticsearch.yml更改。下面的例子中更改了write线程池中的线程数量:

    Thread pool types

      下文中介绍的是线程池的类型以及对应的参数:

    fixed

      fixed类型的线程池中有固定数量的线程,以及一个队列(通常是有界的),当线程池中没有可用线程时,队列会hold住请求。

      size参数控制了线程的数量。

      queue_size控制了队列中的请求数量,当没有可用线程时,队列会hold住请求。默认情况下,该值为-1意味着队列是无界的。但一个新的请求到来时,如果队列已满则abort这个请求。

    scaling

      scaling类型的线程池中拥有动态数量的线程。线程数量跟工作负载成正比(proportional)。线程数量在参数coremax之间变化。

      keep_alive参数用于决定当线程池中的线程没有任何工作时,呆在线程池中的最大时间。

    Allocated processors setting

      处理器(processor)的数量会被自动的检测。线程池的会基于处理器的数量自动的设置。在有些情况下,覆盖(override)处理器的数量是很有用的。可以显示的(explicit)设置node.processors

      以下的情况要显示的覆盖设置node.processors

    1. If you are running multiple instances of Elasticsearch on the same host but want Elasticsearch to size its thread pools as if it only has a fraction of the CPU, you should override the node.processors setting to the desired fraction, for example, if you’re running two instances of Elasticsearch on a 16-core machine, set node.processors to 8. Note that this is an expert-level use case and there’s a lot more involved than just setting the node.processors setting as there are other considerations like changing the number of garbage collector threads, pinning processes to cores, and so on.
    2. Sometimes the number of processors is wrongly detected and in such cases explicitly setting the node.processors setting will workaround such issues.

      若要检查检查到的处理器的数量,使用nodes info AP带上os这个flag。

    Important system configuration

    link

    Configuring system settings

    (8.2)link

      根据你安装Elasticsearch时使用的安装包,以及你正在使用的操作系统,系统设置的配置位置略有不同。

      当使用.zip或者.tar.gz的安装包时,可以通过下面的方式配置系统设置:

      当使用RPM或者Debian发行版时,大多数的系统设置在system configuration file中设置,然而在使用systemd的系统中,要求在systemd configuration file中指定system limit。

    ulimit

      在linux系统中,ulimit用于临时更改资源限制(resource limit)。Limits通常需要使用root用户进行设置,然后切换到普通用户启动Elasticsearch。例如,将文件句柄(file handler)的最大数量设置为65,536(ulimit -n),你可以按照下面的方式进行设置:

      第1行,切换到root用户

      第2行,设置打开的文件最大数量(max number of open files)

      第3行,切换到普通用户来启动Elasticsearch

      这个新的限制(new limit)只适用于当前会话(current session)

      你可以通过ulimit -a查询(consult)当前目前所有的limit

    /etc/security/limits.conf

      在linux系统中,可以通过编辑文件/etc/security/limits.conf为linux的某个系统用户设置persistent limits。如果要为elasticsearch这个系统用户设置可以打开的文件最大数量为65,535,在文件中添加一行下面的内容:

      这个变更只有在elasticsearch这个用户下次打开一个新的session时才会生效。

    NOTE: Ubuntu and limits.conf 在Ubuntu中,由init.d启动的进程会忽略limits.conf文件,如果需要让这个文件生效,可以编辑/etc/pam.d/su然后注释下面这一行的内容:# session required pam_limits.so

    Sysconfig file

      当使用RPM或者Debian安装包时,可以在系统配置文件中指定系统变量:

    RPM/etc/sysconfig/elasticsearch
    Debian/etc/default/elasticsearch

      然而system limits需要通过systemd来指定。

    Systemd configuration

      当在使用systemd的系统上使用RPM或者Debian安装包时,system limits需要通过systemd来指定。

      systemd service file(/usr/lib/systemd/system/elasticsearch.service)中包含了默认的limit。

      你可以新增一个文件名为/etc/systemd/system/elasticsearch.service.d/override.conf(或者你可以执行sudo systemctl edit elasticsearch,它会在默认编辑器中自动打开文件),在这个文件中做如下的变更:

      完成更改后,运行下面的命令来reload units:

    Disable swapping

    (8.2)link

      大多数的操作系统会为文件系统缓存(file system cache)尽可能多的使用内存并且急切的(eagerly)将unused application memory交换出去(swap out)。这会导致部分JVM堆甚至executable page被交换到磁盘上。

      Swapping对性能、节点稳定影响是非常大的,无论如何(at all cost)都要避免。这会导致垃圾回收的时间达到分钟级别而不是毫秒级别,使得节点的响应时间变慢甚至与节点的断开连接。在弹性分布式系统中,让操作系统杀死节点反而更有效。

      有三种方法关闭swapping。较好的方法(prefer option)是完全的关闭swapping。如果不能用这个方法,那么基于你的环境选择最小化swappiness还是内存锁定。

    Disable all swap files

      通常Elasticsearch是一个box中唯一运行的服务,并且通过JVM参数来控制内存的使用,就没有必要开启swapping。

      在linux系统中,你可以运行下面的命令临时关闭swapping:

      这个操作不需要重启Elasticsearch。

      若要永久关闭,你需要编辑文件/etc/fstab,然后将所有包含swap的内容都注释。

      在Windows上,可以通过System Properties → Advanced → Performance → Advanced → Virtual memory达到相同的目的。

    Configure swappiness

      要确保Linux系统上另一个可用的选项:sysctl的vm.swappiness的值是1。这个选项会降低kernel进行swap的趋势,在正常情况下(normal circumstances)不会进行swapping,并且允许在紧急情况下运行将整个系统进行swapping。

    Enable bootstrap.memory_lock

      另一种方式是通过在Linux/Unix系统上使用mlockall或者是Windows系统上的VirtualLock,将进程地址空间锁定到RAM,防止Elasticsearch堆内存被swapping。

    NOTE: 一些平台在使用了memory lock后仍然会swap off-heap memory。为了防止swap off-heap memory,转而尝试disable all swap files

      elasticsearch.yml中设置bootstrap.memory_locktrue来开启memory lock:

    WARNNING:如果尝试分配比可用内存更多的内存量,mlockall可能会导致JVM或者shell session退出。

      在启动Elasticsearch之后,你可以通过下面这个请求输出的mlockall的值检查是否应用了设置:

      如果你看到mlockall的值为false,那么意味着mlockall请求失败了。你可以在日志中看到包含Unable to lock JVM Memory的更详细的信息。

      在Linux/Unix系统上最有可能导致失败的原因是运行中的Elasticsearch没有权限来lock memory。可以通过下面的方式授权:

      另一个导致mlockall可能的原因是the JNA temporary directory (usually a sub-directory of /tmp) is mounted with the noexec option,可以使用ES_JAVA_OPTS环境变量为JNA指定一个临时的目录来解决:

      或者在配置文件jvm.options中设置这个JVM标志。

    File Descriptors

    (8.2)link

    NOTE:File Descriptors仅仅适用于Linux以及MacOs,在Windows平台上运行Elasticsearch可以忽略。在 Windows 上,JVM 使用仅受可用资源限制的 API

      Elasticsearch会使用很多file descriptors 或者 file handles。文件描述符用完可能是灾难性的,并且很可能会导致数据丢失。要确保将open files descriptors的数量提高到65,536或者更高用于Elasticsearch的运行。

      对于.zip.tar.gz的安装包,在Elasticsearch启动前使用root用户执行ulimit -n 65535,或者在/etc/security/limits.conf设置nofile的值为65535

      在MacOs平台上,你必须要使用JVM参数-XX:-MaxFDLimit让Elasticsearch使用更高的file descriptors限制。

      RPM和Debian已经默认将file descriptors的最大值设置为65535并且不需要进一步的配置。

      你可以使用Nodes stats API检查每一个节点上的max_file_descriptors

    Virtual memory

    (8.2)link

      Elasticsearch默认使用mmapfs存储索引文件。默认情况下操作系统会将mmap count限制的太低导致OOM的异常。

      在Linux下,你可以使用root通过下面的命令来提高上限:

      可以在/etc/sysctl.conf中更新vm.max_map_count来永久的设置该值。在重启后使用sysctl vm.max_map_count命名来验证刚才的变更。

      RPM跟Debian安装包会自动进行配置。不需要进行额外的配置。

    Number of threads

    (8.2)link

      Elasticsearch会使用线程池用于不同类型的操作。重要的是当有需要时就会创建新的线程。保证Elasticsearch能创建的线程数量至少可以有4096个。

      在启动Elasticsearch前切换到root设置ulimit -u 4096,或者在/etc/security/limits.conf中将nproc设置为4096。

      systemd下运行的service会自动的为Elasticsearch进程设置线程数量。不需要额外的配置。

    DNS cache settings

    link

      

    Bootstrap Checks

    link

    Discovery and cluster formation

    link

    Discovery

    link

    Quorum-based decision making

    link

    Bootstrapping a cluster

    link

    Publishing the cluster state

    link

    Advanced configuration

    link

    Full-cluster restart and rolling restart

    (8.2)link

      可能会存在一些情况where you want to perform a full-cluster restart 或者rolling restart。对于full-cluster restart,需要关闭并重启集群中所有的节点,而对于rolling restart,则是需要在某一时间只关闭一个节点,这样提供的服务就不会停止。

    Full-cluster restart

    1. Disable shard allocation

      当你关闭了一个data node,allocation process将位于该节点上的主分片复制到其他节点前会等待index.unassigned.node_left.delayed_timeout(默认一分钟),因为这会占用很多I/O。由于节点很快就要重启,那这个I/O是没有必要的。你可以在关闭data nodedisabling allocation of replica,免得在超时前没有重启好节点。

    1. Stop indexing and perform a flush

      执行flush加快分片恢复。

      2.1 Temporarily stop the tasks associated with active machine learning jobs and datafeeds (Optional)

      Machine leanring功能需要subscription

      当你关闭一个集群时,你有两个选项来处理machine learning jobs和datafeeds。

      2.2 Shut down all nodes

    1. Perform any needed changes
    2. Restart nodes

      如果你有专用的master node,那可以在处理你的data node前,先启动它们,然后等待他们形成一个集群并选举出一个master。你可以通过日志查看处理进程。

      一旦有足够的master-eligible node相互的发现了对方,他们就会形成一个集群并且选举出master。在这个时候,你可以使用cat healthcat nodes来监控加入到集群的节点。

      _cat/health返回的status列显示了集群中每一个节点的状态: redyellow或者green

    1. Wait for all nodes to join the cluster and report a status of yellow

      当一个节点加入到集群,它开始恢复存储在本地的所有的主分片。_cat/health API最开始会报出值为redstatus,意思是还有主分片没有被分配。

      某个节点一旦恢复了本地的分片,status会切换到yellow,意思是所有的主分片已经恢复,但不意味着所有的分片副本已经分配好。这是意料之中的事,因为你还没有重新开启副本分片的分配。延迟副本分片的分片直到所有的节点的statusyellow,使得master能将副本分片分配到那些已经有本地分片拷贝的节点上。

    1. Re-enable allocation

      当所有的节点加入到集群后,并且恢复好了它们的主分片后,将cluster.routing.allocation.enable恢复到它的默认值来重新开启分配:

      一旦重新开启了分配,集群开始将副本分片分配到data node。在这个时间点恢复索引和查询是安全的,但如果你能等待所有的分片和分片副本成功的分配结束并且所有节点的状态都是green,那你的集群能更快的恢复。

      你可以使用_cat/health _cat/recovery APIs来监控处理进程:

    1. Restart machine learning jobs (Optional)

      如果你临时暂停了machine learning jobs相关的任务,使用set upgrade mode API将它们返回到活跃状态:

      如果你在停止节点前关闭了所有的machine learning jobs,可以在Kibana中打开jobs并开始datafeed或者使用open jobsstart datafeed APIs。

    Rolling restart

    1. Disable shard allocation

      当你关闭了一个data node,allocation process将该节点上的主分片复制到其他节点前会等待index.unassigned.node_left.delayed_timeout(默认一分钟),因为这会占用很多I/O。由于节点很快就要重启,那这个I/O是没有必要的。你可以在关闭data nodedisabling allocation of replica,免得在超时前没有重启好节点。

    1. Stop non-essential indexing and perform a flush (Optional)

      尽管你可以在rolling restart期间继续执行索引操作,但如果你临时的停止没有必要的索引操作并执行flush可以让分片恢复的更快

    1. Temporarily stop the tasks associated with active machine learning jobs and datafeeds (Optional)

      Machine leanring功能需要subscription

      当你关闭一个集群时,你有两个选项来处理machine learning jobs和datafeeds。

    1. Shut down a single node in case of rolling restart
    1. Perform any needed changes
    2. Restart the node you changed

      启动节点后并通过查看日志文件或者提交一个_cat/nodes请求来确认该节点加入到了集群:

    1. Reenable shard allocation

      对于data node,一旦它加入到集群后,就可以移除cluster.routing.allocation.enable这个设置来开启分片分配并开始使用这个节点:

    1. Repeat in case of rolling restart

      当节点恢复后并且集群已经稳定,对每一个需要变更的节点重复这些步骤。

    1. Restart machine learning jobs (Optional)

      如果你临时暂停了machine learning jobs相关的任务,使用set upgrade mode API将它们返回到活跃状态:

      如果你在停止节点前关闭了所有的machine learning jobs,可以在Kibana中打开jobs并开始datafeed或者使用open jobsstart datafeed APIs。

    Remote clusters

    link

    Index Modules

    link

      Index Modules是按索引创建的模块,控制与索引相关的所有方面。

    Index Settings

      索引层的设置可以根据每一个索引进行配置,索引配置可以划分为:

    static

      只能在索引创建期间或者对一个closed index进行设置。

    dynamic

      使用update-index-settings对live index的索引配置进行变更。

    Static index settings

      下面是所有的静态索引设置,这些设置跟任何特定的索引模块都没有关联(associate):

    index.number_of_shards

      一个索引应该具有的主分片数量。默认值是1。这个设置只能在索引创建期间设置。不能对关闭的索引进行设置。

    index.number_of_routing_shards

      整数值,跟index.number_of_shards一起用来将文档路由到主分片中,见_routing field

      Elasticsearch在对索引进行split时会使用这个值。例如,一个拥有5个分片,并且index.number_of_routing_shards的值设置为30时,那么每个分片可以按照因子2或者3进行划分,换句话说,可以按照下面的方式进行划分:

      默认值取决于索引的主分片数量,默认情况下根据切分因子2进行切分,并且最多切分出1024个分片。

    index.codec

      默认使用LZ4对store data进行压缩,但是可以设置为best_compression,其使用DEFLATE有更高压缩率,代价是降低了存储域stored filed的性能。如果你更新了压缩类型compression type,新的数据在段合并后会被应用apply。可以使用force merge对段进行强制合并。

    index.routing_partition_size

      使用自定义的路由值可以被路由到的分片的数量(区别于路由到某一个分片,这里指的是可以被路由到某个分片集合中,集合的大小即index.routing_partition_size)。默认值是1并且只能在创建索引时设置,该值必须比index.number_of_shards小,除非index.number_of_shards的值就是1。见Routing to an index partition查看如何使用该值。

    index.soft_deletes.enabled

      该值描述了当前索引是否开启soft deletes。Soft deletes只能在创建索引时配置并且只能在Elasticsearch6.5及以后的版本的索引上配置。默认值为true。

    index.soft_deletes.retention_lease.period

      在分片的history retention lease过期之前被保留的最大时间。Shard history retention leases能保证在Lucene层的段合并后soft deletes仍然能被保留retain。如果soft deletes在follower节点上生成副本期间被合并了merge away,那么在随后的处理中会因为在leader节点上不完整的history而导致失败。默认值为12h。

    index.load_fixed_bitset_filters_eagerly

      该值描述了cached filters是否为nested queries提前载入了pre-loaded。可选值是true(默认值)和false。

    index.shard.check_on_startup

      Elasticsearch在分片的生命周期的不同时刻自动对其内容执行完整性检查。比如当恢复一个副本replica时,会对传输的每一个文件进行校验和的验证或者拍摄快照时take a snapshot。当启动一个节点或者完成一个分片的恢复跟重分配时,同样的会在打开一个分片时对重要的文件进行完整性的验证。因为你可以手动的对正在运行中的所有分片进行完整性的校验,方法是对其进行拍摄快照并放到新的仓库中fresh repository或者在一个新的节点恢复recovery它。

      当前配置用来描述Elasticsearch在打开一个分片时是否要对其进行额外的完整性检查。如果检查出corruption,那么阻止这个分片被打开,该配置接受下面的值:

    Dynamic index settings

      下面列出的是所有的动态索引设置,这些设置与任何特定的index module没有关联。

    index.number_of_replicas

      每个主分片的副本的数量,默认值是1。

    index.auto_expand_replicas

      基于集群中节点的数量自动增加auto-expand分片副本的数量。该值可以设置为一个用破折号来区分上下界的值(例如: 0-5),或者使用all作为上界(例如:0-all)。默认值是false。注意的是这种自动增加分片副本数量只会考虑allocation filtering规则,会忽视其他的分配allocation规则例如total shards per node,如果适用的规则applicable rules阻止分配所有的分片副本,会导致集群变成yellow

      如果上界是all,那么shard allocation awarenesscluster.routing.allocation.same_shard.host这两个配置在这个索引上会被忽略。

    index.search.idle.after

      某个分片在多久未收到搜索或者请求后被认定为空闲的,默认值是30秒。

    index.refresh_interval

      多久执行一次refresh操作。该操作使得最近的修改能够被搜索到。默认值是1秒。可以被设置为-1来关闭refresh。如果没有显示的explicit设置这个值,那么分片在至少index.search.idle.after时间内没有收到搜索请求则不会收到后台刷新,直到分片收到查询请求。搜索时如果遇到某个分片正在进行refresh,那么会等待下一次后台refresh,这种行为的目的是在没有搜索请求时能优化bulk Indexing。为了避免这种行为,应该显式设置1s的值作为刷新间隔。

    index.max_result_window

      当前索引返回的结果最大值,基于from + size,默认值是10000。搜索请求占用的堆内存和时间与from + size成比例。见scrollSearch After ,替换成这些方式来获得更多的搜索结果。

    index.max_inner_result_window
    index.query.default_field
    index.default_pipeline
    index.final_pipeline
    index.hidden

    (未完成)

    Index Shard Allocation

    link

    Index-level shard allocation filtering

    (8.2)link

      你可以使用shard allocation filtering来控制Elasticsearch如何为一个指定的索引进行的分片的分配。索引层(index-level)的filtering跟 cluster-wide allocation filteringallocation awareness结合应用。

      Shard allocation filtering可以基于节点上自定义的属性或者内置属性例如_name, _host_ip, _publish_ip, _ip, _host, _id, _tier 以及_tier_preferenceIndex lifecycle management使用基于自定义的节点属性的filtering来决定在进行阶段转变时如何重新分配分片。

      设置(setting)cluster.routing.allocation是动态的,使得可以让live index从一些节点移到其他节点。只有在不会破坏其他路由限制(routing constraint)时才会重新分配分片,比如说不会在一台机器上同时分配主分片和副本。

      例如,你可以使用自定义的节点属性来指示(indicate)一个节点的性能属性并且使用shard allocation filtering将指定的索引路由到级别最合适的硬件中(the most appropriate class of hardware)。

    Enabling index-level shard allocation filtering

      基于自定义的节点属性进行过滤(筛选):

    1. 在每一个节点的配置文件elasticsearch.yml中指定过滤节点属性。例如,如果你有small, medium, 和 big三类节点,你可以添加一个size属性,基于节点的大小进行过滤。

      你也可以在节点启动时指定自定义的属性:

    1. 在索引中添加shard allocation filtering信息。index.routing.allocation这个设置支持三种类型的过滤:include, excluderequire。例如,告诉Elasticsearch使用index.routing.allocation.include将索引text的分片在值为big或者medium的节点上进行分配:

      如果你指定多个条件并要求节点同时满足才能在其节点上进行分片的分配:

      例如,将索引text的分片移到机架值为ranck1并且大小为big的节点,你可以这么指定:

    Index allocation filter settings
    index.routing.allocation.include.{attribute}

      将索引分配给一个节点,这个节点的{attribute}属性中至少包含用逗号隔开的值。

    index.routing.allocation.require.{attribute}

      将索引分配给一个节点,这个节点的{attribute}属性中包含所有用逗号隔开的值。

    index.routing.allocation.exclude.{attribute}

      将索引分配给一个节点,这个节点的{attribute}属性中不包含用逗号隔开的值。

      索引的分配设置支持下列的内置属性:

    _name根据节点名字进行匹配
    _host_ip根据host ip进行匹配
    _publish_ip根据发布的IP(publish IP)地址进行匹配
    _ip根据_host_ip或者_publish_ip进行匹配
    _host根据hostname进行匹配
    _id根据节点id进行匹配
    _tier根据data tier角色匹配,见data tier allocation filtering了解更多细节

      _tier这种过滤属性基于node角色,只有部分角色是 data tier角色并且一般的(generic)data role会匹配到任意的tier filtering。

      你可以使用通配符来指定属性值,例如:

    Index recovery prioritization

    (8.2)link

      whenever possible,未分配的索引会根据优先级依次进行恢复。根据下面的条件对索引进行排序:

      这意味着默认情况下,新的索引会先于旧的索引进行恢复。

      使用每一个索引中可自动更新的index.priority来自定义索引的优先顺序。例如:

      在上面的例子中:

      这个设置可以是一个整数,可以通过update indices settings更新。

    Total shards per node

    link

    index.routing.allocation.total_shards_per_node
    cluster.routing.allocation.total_shards_per_node

    Index-level data tier allocation filtering

    link

    Data tier allocation settings
    index.routing.allocation.include._tier_preference

    Index blocks

    link

    Index block settings

    index.blocks.read_only

    Merge

    link

    Slow log

    (8.2)link

    Search Slow Log

      分片层的慢查询日志(slow search log)允许将慢查询(query and fetch phases)记录到一个指定的日志文件中。

      可以同时为query跟fetch设置阈值,见下面的例子:

      上述的设置都是动态的,可以通过update indices settings设置,例如:

      默认情况下阈值是关闭的(默认值为-1)。

      由于是分片层级别范围,意味着记录的是对于特定分片的查询。日志中不包含全部的查询请求,而是通过广播到每一个分片去执行日志的记录。跟请求级别(request level)相比,这种分片层级别的日志记录的好处是能关联到某个机器上的情况。

      log4j2.properties文件中配置查询慢日志。

    Identifying search slow log origin

      明确是什么导致了慢查询通常是非常有用的。如果在请求的header中带有X-Opaque-ID,那么在查询慢日志(Search Slow log)中会增加一个额外的id域来描述user ID。

    Index Slow log

      索引慢日志跟查询慢日志是类似的。以_index_indexing_slowlog.json.为后缀的日志以及阈值使用跟查询慢日志相同的配置方式:

      上述的设置都是动态的,可以通过update indices settings设置,例如:

      默认情况下,Elasticsearch会在慢日志(slowlog)中记录_source中前1000个字符。你可以通过index.indexing.slowlog.source更改这个限制。设置为0或者false将不会记录source字段。如果设置为true则会记录完整的_source并且不关心其内容的大小。_source中的内容被格式化(format)过使得可以作为日志中的单独一行。如果不格式化_source的内容是件重要的事情,那么可以通过将index.indexing.slowlog.reformat设置为false来关闭formatting,这样会使得_source中的内容以多行的形式出现在日志中。

      log4j2.properties文件中配置索引慢日志。

    Slow log levels

      可以通过设置查询\索引慢日志日志级别来设置合适的域值,来关闭(switch off)冗长的(more verbose)设置。例如可以设置index.indexing.slowlog.level: INFO那么我们就可以设置index.indexing.slowlog.threshold.index.debugindex.indexing.slowlog.threshold.index.trace-1

    Store

    (8.2)link

      Store模块允许你控制索引数据在磁盘上的存储和访问方式。

    NOTE:这是一个low-level的设置。一些store的实现有较差的并发性或者没有对堆内存的使用进行优化。我们建议使用默认值(sticking to the defaults)

    File system storage types

      现在有不同的文件系统实现或者存储类型(file system implementations or storage types)。默认情况下,Elasticsearch会基于操作系统环境来选择最佳实现。

      Storage type可以通过在config/elasticsearch.yml文件中配置来显示的为所有的索引进行设置:

    这是一个静态设置,可以在创建索引时基于每个索引进行设置:

    WARNING:这是一个专家(expert-only)设置并且可能在未来的版本中移除。

      下面的内容列出了所有支持的不同类型的存储:

    fs

      默认的文件系统实现。会根据操作系统环境选择最佳的实现方式。目前在所有支持的系统上都是hybridfs,但可能会发生变化。

    simplefs

      deprecated::[7.15, "simplefs已经被弃用并将在8.0中移除",转而用niofs或者其他文件系统。Elasticsearch 7.15 及以后的版本中使用niofs作为simplefs这个存储类型会提供相对于simplefs更好或者相同的性能]

      Simple FS 类型是使用随机访问文件的文件系统存储的简单实现(straightforward implementation)(对应Lucene中的SimpleFsDirectory)。这种实现有较差的并发性能(使用多线程会有瓶颈)并且没有对堆内存的使用进行优化。

    niofs

      NIO FS类型使用NIO将分片索引存储在文件系统上(对应Lucene中的NIOFSDirectory)。他允许多线程并发的读取相同的文件。由于在SUN Java实现中存在一个bug,所以不建议在Windows上使用这个类型并且没有对堆内存的使用进行优化。

    mmapfs

      MMap FS 类型通过将文件映射到内存(mmap)将分片索引存储在文件系统上(对应Lucene中的MMapDirectory)。内存映射占用了进程中的一部分虚拟内存地址空间,等于被映射文件的大小。在使用这个之前确保你拥有大量的virtual address space

    hybridfs

      hybridfs类型是niofsmmapfs的混合类型,基于不同类型的文件的读取访问模式选择最佳的文件系统类型。目前只有Lucene term dictionary,norms和doc values文件是内存映射的。其他的文件使用Lucene的NIOFSDirectory打开。跟mmapfs一样,在使用这个之前确保你拥有大量的virtual address space

      你可以通过node.store.allow_mmap来限制(restrict)mmapfs以及hybridfs的使用。这是一个布尔类型的设置描述是否允许内存映射(memory-mapping)。默认值是允许的。这个设置是很有用的,比如说,如果你处于无法控制创建大量内存映射的环境中,那么你需要禁用使用内存映射的能力。

    Preloading data into the file system cache

    link

    Translog

    (8.2)link

      Lucene中的commit会将更改(changes)持久化到磁盘,这是一种开销很大的操作,所以不能在每次索引或者删除操作后执行commit。如果在索引过程中退出或者硬件错误,那么在一次commit后,下一次commit前这个期间发生的变更会被移除(丢失)。

      Lucene中,每一次单独的变更都执行commit的话其开销是很大的,所以每一个分片都会把写操作(writes operation)写入到事务日志(transaction log)中,即所谓的translog。所有的索引和删除操作在Lucene中建立索引后会被添加到translog中,在发生crash时间后,最近被确认的(acknowledge)但是不在Lucene commit中的操作,在分片恢复时会使用translog进行恢复。

      Elasticsearch中执行flush即执行Lucene中的commit操作,并且开始一个新的translog generation。flush会在后台自动执行使得不会让translog记录太多操作,这样在恢复期间不会因为重新(replay)执行translog中的操作使得花费很多的时间。也可以通过API来执行flush,但这几乎是没必要的。

    Index Sorting

    link

    Use index sorting to speed up conjunctions

    link

    Translog settings

      translog中的数据只有在它是fsync并且commit后会持久化到磁盘上。硬件故障的事件或者是操作系统崩溃或者JVm崩溃或者分片失败,上一次commit之后的translog数据都会丢失。

      index.translog.durability默认设置为request意味着在translog在成功fsynced并且commit到主分片以及每一个分配的副本后,Elasticsearch将只报告成功的索引、删除、更新、bulk request给client。如果index.translog.durability设置为async,那么Elasticsearch只会每隔index.translog.sync_interval对translog进行fsynced并且commit,意味着当节点恢复时,任何crash之前的操作可能会丢失。

      下面每个索引的dynamically updatable设置控制translog的行为:

    index.translog.sync_interval

      translog fsynced 到磁盘并且commit的间隔,不考虑写操作,默认时间是5s。不允许设置100ms以下的值。

    index.translog.durability

      translog是否在每一次的index、delete、update或者bulk request都进行fsynced并且commit。可以设置为下面的值:

    request

      (默认值)每一个请求都进行fsynced并且commit。硬件错误事件时,所有确认的写操作已经commit到磁盘。

    async

      每隔index.translog.sync_interval进行fsynced并且commit。在出现失败事件时,上一次自动commit后的所有确认的写操作都会被丢弃

    index.translog.flush_threshold_size

      所有在Lucene中没有安全持久化的操作都会存储在translog中,这个操作对读操作是可见的,在分片被停后并且必须要恢复时,它们用于重新索引操作。这个设置控制了这些操作占用总量的最大值,防止恢复时占用太长的时间。当达到最大值时会触发flush,生成一个新的Lucene commit。默认值是512mb

    Indexing pressure

    (8.2)link

      索引文档到Elasticsearch会引入系统的内存和CPU的负载。每一个索引操作,包含了coordinating, primary和replica这几个阶段。这些阶段在集群中的多个节点上运行。

      Indexing pressure可以由外部的索引请求或者内部的例如恢复,跨集群分片副本(cross-cluster replication)引起。如果系统中有过多的索引工作,集群会达到饱和(saturated)。这会对其他操作造成不好的(adversely)影响,例如查询,cluster coordination以及background processing。

      为了防止出现这个问题,Elasticsearch内部会监控索引负载。当负载超过一定的限制,新的索引操作会被reject。

    Indexing stages

      外部的索引操作(external indexing operation)会经历三个阶段:coordinating,primary以及replica。见Basic write model

    Memory limits

      节点设置indexing_pressure.memory.limit严格限制了未完成(outstanding)索引请求的可用的字节数量。这个设置默认值是堆内存的10%。

      每一个索引阶段(indexing stage)的开头,Elasticsearch会统计一个索引请求占用的字节数。在索引阶段的结尾才会释放这个统计。意味着上游的阶段会统计请求开销直到所有的下游都完成。例如,coordinating请求会保留统计直到primary和replica阶段完成,primary请求会保留统计直到每一个同步的replica返回响应,如果有需要的话开启replica重试。

      当未完成的coordinating, primary和 replica的索引占用字节超过配置的值后,节点会在coordinating或者primary阶段reject这个新的索引请求。

      当未完成的replica阶段的索引字节超过配置限制的1.5倍后,节点会在replicate阶段reject这个索引请求。这种设计意味着由于indexing pressure作用于节点,它会天然的在发生未完成的replica工作时会停止coordinating和primary工作。

      indexing_pressure.memory.limit的默认为10%。你应该深思熟虑后再去修改它。这个设置只作用于索引请求。这意味着其他的索引开销(buffers,listener,等等)同样需要堆内存。Elasticsearch的其他组件同样需要内存,这个值设置的太高会影响其他有内存操作(memory operation)的操作和组件。

    Monitoring

      你可以使用node stats API查询indexing pressure metrics。

    Indexing pressure settings

    indexing_pressure.memory.limit

      索引请求可能需要消费的字节数。当达到或者超过这个限制后,节点会reject新的coordinating和primary操作。当replica操作消费超过1.5倍,节点会reject新的replicate请求。默认值是堆内存的10%。

    Mapping

    link

    Settings to prevent mapping explosion

    Dynamic mapping

    (8.2)link

      Elasticsearch最重要的一个特性就是能够让你快速的去探索数据。索引一篇文档,你不需要首先创建一个索引,然后定义好mapping,接着定义每一个域,你只需要直接对一篇文档进行索引,索引名、类型、域都会自动的配置好。

      第1行,创建一个名为data的索引,以及_doc类型的mapping,和一个域名为count,数据类型为long的域。

      这种自动检测并且添加(addition of)一个新域的机制成为动态索引dynamic mapping。可以基于下列方法来自定义你的动态索引规则:

    TIP:Index templates允许你为新的索引配置默认的mapping,settings 以及aliases ,不管是自动还是显示创建索引。

    Dynamic field mapping

    (8.2)link

      当Elasticsearch检测到文档中有一个新域,会默认将它添加到mapping中。参数dynamic控制了其行为方式。

      你可以设置参数dynamic的值为true或者runtime来显示的指引Elasticsearch对于即将到来的文档动态的创建域。当开启了dynamic field mapping ,Elasticsearch会根据下表中的规则决定如何映射为不同类型的域。

    NOTE:Elasticsearch仅支持下表中域的数据类型(field data type)的自动检测,你必须显式的指定其他数据类型。

    JSON data type"dynamic":"true""dynamic":"runtime"
    nullNo field addedNo field added
    true or falsebooleanboolean
    doublefloatdouble
    longlonglong
    objectobjectNo field added
    arrayDepends on the first non-null value in the arrayDepends on the first non-null value in the array
    string that passes date detectiondatedate
    string that passes numeric detectionfloat or longdouble or long
    string that doesn’t pass datedetection or numeric detectiontext with a .keywordsub-fieldkeyword

      你可以同时在文档层或者object层来关闭动态mapping。将参数dynamic设置为false来忽略新的域,设置为strict来当Elasticsearch遇到一个未知的域时就reject这个文档。

    TIP:可以通过update mapping API来对现有的域的参数dynamic的值进行更新。

      你可以为Date detectionNumeric detection自定义dynamic field mapping的规则。你可以使用dynamic_templates来自定义个性化的mapping规则并应用到额外的dynamic fields。

    Date detection

      如果开启了date_detection(默认开启),新来的string类型的域会被检测是否其域值能够被dynamic_date_formats中指定的日期模板匹配到。如果匹配到了,就添加对应的新的date域。

      dynamic_date_formats的默认值是:

      例如:

      第6行,create_date域以"yyyy/MM/dd HH:mm:ss Z||yyyy/MM/dd Z"这种format作为date被添加。

    Disabling date detection

      可以将date_detection的值设置为false来关闭date detection。

      第8行,create_date被添加为text域。

    Customizing detected date formats

      另外,dynamic_date_formats也能定制为你自己的formats):

    Numeric detection

      JSON原生支持浮点型以及整数的数据类型,但是有些应用或者语言有时会将数值类型作为(render)字符串类型。通常正确的解决办法是显示的映射这些域。但是numeric detection能使得自动实现(默认关闭):

      第10行,my_float被添加为float

      第11行,my_integer被添加为integer

    Dynamic templates

    link

      

    Explicit mapping

    link

    Runtime fields

    link

      runtime field是在查询阶段计算出来的域,可以让你用于:

      你可以像通过search API来访问runtime field,就像访问其他域一样,Elasticsearch不会对runtime field区别对待。你可以在index mapping或者search request中定义runtime field,提供不同的方式体现了runtime field内部的灵活性。

      _search API上使用fields参数来 retrieve the values of runtime fields,runtime filed不会在_source中展示,但是fields API可以在所有域上使用,即使这些域不在_source中。

      Runtime fields用于处理日志数据(log data)时候特别好用(见例子),特别是当你不确定数据结构时。查询性能会降低,但是你能更快的索引日志数据,并且索引大小较小。

    Benefits

      由于runtime fiels没有被索引,所以新增runtime field不会增加索引大小。你直接在索引mapping中定义runtime fields可以节省存储开销以及提高提取(ingestion)速度。你能够更快的把数据提取到Elastic Stack并可以正确的访问。当你定义了一个runtime field,你可以在在查询请求中使用它用于聚合、过滤、和排序。

      如果你让一个runtime field成为了一个索引域(indexed field),你不需要修改任何请求来指定runtime filed。甚至你可以指定某个域在某些索引中是runtime field,同时在某个索引中是一个索引域。你可以灵活的选择哪些域作为索引域还是runtime field。

      Runtime fileds最核心、最重要的好处就是它提供了在提取(ingest)文档后可以在这篇文档中添加域的能力。这种能力简化了mapping的设计,因为你不需要提前决定用哪种数据类型进行解析,可以在任何时候修改。使用runtime field使得有更小的索引和更快的提取时间,这将使用更少的资源并降低你的操作成本。

    Incentives

      (未完成)

    Compromises

      (未完成)

    Map a runtime field

    (8.2)link

      通过在mapping中定义一个runtime section以及一个Painless script就可以映射到runtime fileds。这个脚本可以访问所在文档中所有的内容,包括可以通过params._source来读取到_source的内容以及任何域加上域值。在查询时,查询条件中包含了这个scripted field(下文中的day_of_week),脚本会运行并且生成结果给scripted field。

    当定义了一个脚本用于runtime fields时,脚本中必须使用 emit method来输出计算的值。

      下面例子的脚本中,将根据@timestamp的域值计算出的结果赋值给day of the weekday of the week是一个data类型:

      runtime中可以是以下的类型:

      date类型的runtime fileds的域值格式跟date域接受的format是一致的。

      lookup类型的runtime fileds允许从关联的索引中检索域的信息,见retrieve fields from related indices

      如果开启了dynamic field mapping,并且dynamic参数设置了参数值runtime,新的域会作为runtime自动添加到索引mapping中。

    Define runtime fields without a script

      Runtime fileds通常使用脚本来管理数据,然后有些情况下可以不使用脚本来使用runtime fileds。比如你想从_source中检索出某个域的域值并不作任何的改变,那你不需要提供脚本,你只需要创建一个不带脚本的runtime fileds:

      当没有提供脚本时,在查询期间,Elasticsearch会从_source中查找到跟runtime fields域名一样的域,如果存在的话就会域值。如果不存在,那么在response中不会包含runtime fields的任何值。

      在大多数情况下,会优先从doc_values中读取。由于在Lucene中不同的存储方式,相比较从_source中检索,通过doc_values的方式读取速度更快。

      但是有些场景下需要从_source中检索域的信息。比如说由于text类型默认情况下不会有doc_values,所以不得不从_source中读取,在其他情况下,可以选择禁用特定域上的doc_values。

    NOTE:你可以在params._source中添加前缀来检索想要的数据(比如params._source.day_of_week),为了简单起见,定义runtime fields时,建议尽可能在mapping定义中不使用脚本。

    Updating and removing runtime fields

      你可以在任何时候更新或者移除runtime fileds。添加一个相同名字的runtime files就可以覆盖现在有的runtime files,通过设置为null来移除现在有的runtime files:

    Downstream impacts

      更新或者移除runtime files可能会使得正在查询的请求返回的数据不一致。由于mapping的变更可能会影响到每一个分片会访问到不同版本的脚本。

    WARNING:如果你对runtime fileds进行变更或者移除,依赖runtime fileds的Existing queries or visualizations in Kibana可能会出现失败的情况,比如可视化的图表使用runtime field类型的ip被改为boolean,或者被移除后会导致出错。

    Define runtime fields in a search request

    (8.2)link

      你可以在查询请求中指定一个runtime_mappings区域(section)来创建runtime fields,它只属于这次的请求。你指定了一个脚本作为runtime_mappings的一部分跟adding a runtime field to the mappings是一样的。

      在查询请求中定义一个runtime field跟在index mapping中使用的格式是一样的,所以只需要把查询请求中runtime_mappings区域中的内容直接拷贝到index mapping的runtime区域中。

      下面的查询请求添加了day_of_week域到runtime_mappings区域中,这个域的域值将被自动的计算出来并且只处于这次查询请求的上下文中(only within the context of this search request)。

    Create runtime fields that use other runtime fields

      你甚至可以在查询请求中定义runtime field,并且它的域值可以从其他的runtime field中计算出来。比如你批量索引了传感器的数据:

      你意识到你将数值类型numeric type索引成了text类型,你想要在measures.start以及measures.end域上进行聚合操作却无法实现,因为你不能在text类型上进行聚合。Runtime fields to the rescue!。你可以添加runtime fileds,跟索引域index field(即measures.start和measures.end)的域名保持一致并且修改域的类型:

      Runtime field的优先级(take precedence over)比相同域名的索引域高。这种灵活性使得你可以投影(shadow)现有的域(existing fields)并且计算出新值而不用修改域本身的信息。如果你在索引数据的时候犯错了,那么你可以使用runtime field在查询阶段重新计算,将获得的值进行override values

      现在你可以很容易的在measures.startmeasures.end域上执行average aggregation

      响应中返回了聚合结果并且没有改变 the underlying data(指的是measures.start跟measures.end):

      另外你还可以定义一个runtime field作为查询请求中的一部分来计算出一个值,在相同的query(基于上文中介绍的query)中对这个runtime field进行stats aggregation

      duration这个runtime field不在 index mapping中,当我们仍然可以使用这个域进行查询和聚合计算。下面的请求将返回经过计算的duration的值并且从用于聚合的文档中基于数值类型的数据执行stats aggregation来计算统计值(即count、min、max、avg、sum):

      尽管 duration这个runtime field只在这次查询请求的上下文中存在,你也可以对该字段进行搜索和聚合。灵活性十分的强大,它可以弥补(rectify)你在index mapping中犯的错误并且在单个查询请求中动态的完成计算。

     

    Override field values at query time

    (8.2)link

      如果您创建的runtime field与mapping已经存在的字段具有相同的名称,则runtime field会将对mapping filed进行投影(shadow)。在查询时,Elasticsearch计算runtime field,根据脚本计算一个值,并将该值作为查询的一部分返回。因为runtime field会对mapping field进行投影(shadow),所以你可以覆盖搜索中返回的值,而不需要修改mapping field。

      例如你在索引my-index-000001中添加了以下的文档:

      你后来意识到HG537PU传感器并没有报告它们的真实电压。索引值应该是报告值的1.7倍。你可以在_search请求的runtime_mappings部分定义一个脚本,来投影(shadow)电压场,并在查询时计算一个新值,而不是重新索引数据。

      如果你想要查询 model number是HG537PU的文档:

      相应中包含了model number是HG537PU的索引值:

      下面的请求中定义了一个runtime field,它的脚本中将估算域值为HG537PUmodel_number域,会对于每一个满足条件的voltage的域值乘以1.7。

      通过在_serach API中使用field参数,你可以检索measures.voltage field,满足查询请求中的文档会根据脚本对该域值进行计算。