elasticsearch服务器？elasticsearch官方文档

配置Elasticsearch

Elasticsearch船只具有良好的默认值，并且只需要很少的配置。可以在运行的集群上使用集群更新设置API更改大多数设置。

配置文件应该包含特定于节点的设置(例如node.name和路径)，或者节点为了能够加入集群而需要的设置，例如 cluster.name和 network.host。

Elasticsearch有三个配置文件:

这些文件位于config目录中，其默认位置取决于安装是来自存档分发版(tar.gz或zip)还是包分发版(Debian或RPM包)。

对于存档发行版，config目录位置默认为$ES_HOME/config。配置目录的位置可以通过 ES_PATH_CONF环境变量改变，如下所示:

或者，您可以通过命令行或shell配置文件导出ES_PATH_CONF环境变量。

对于包分发，配置目录位置默认为/etc/elasticsearch。配置目录的位置也可以通过 ES_PATH_CONF环境变量更改，但是请注意，仅在shell中设置是不够的。相反，这个变量来源于/etc/default/elasticsearch(用于Debian包)和/etc/sysconfig/elasticsearch(用于RPM包)。您需要相应地在其中一个文件中编辑 ES_PATH_CONF=/etc/elasticsearch条目，以更改配置目录的位置。

配置格式为YAML。下面是更改数据和日志目录路径的示例:

设置也可以扁平化如下:

在YAML中，你可以将非标量值格式化为序列:

虽然不太常见，但你也可以将非标量值格式化为数组:

使用${…}符号将被替换为环境变量的值。例如:

环境变量的值必须是简单字符串。使用逗号分隔的字符串来提供Elasticsearch将解析为列表的值。例如，Elasticsearch将以下字符串分割为${HOSTNAME}环境变量的值列表

集群和节点设置可以根据配置方式进行分类:

您可以使用集群更新设置API在运行的集群上配置和更新动态设置。您还可以使用 elasticsearch.yml在未启动或关闭的节点上本地配置动态设置。

使用集群更新设置API进行的更新可以是持久的(跨集群重启应用)，也可以是短暂的(在集群重启后重置)。您还可以通过使用API为临时或持久设置赋值为空来重置它们。

如果您使用多个方法配置相同的设置，Elasticsearch将按照以下优先顺序应用这些设置:

例如，您可以应用瞬变设置来覆盖持久设置或 elasticsearch.yml设置。然而，对 elasticsearch.yml的更改,不会覆盖已定义的瞬态或持久设置。

最好使用集群更新设置API设置动态的集群范围设置，并使用 elasticsearch.yml仅用于本地配置。使用集群更新设置API可以确保所有节点上的设置是相同的。如果您不小心在 elasticsearch.yml中配置了不同的设置。在不同的节点上，很难注意到差异。

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

必须在集群中的每个相关节点上设置静态设置

Elasticsearch开始时只需要很少的配置，但是在生产环境中使用集群之前，有很多方面需要考虑:

Elasticsearch将创建索引的数据写入索引，将数据流写入数据目录。Elasticsearch将自己的应用程序日志(其中包含关于集群运行状况和操作的信息)写入日志目录

对于macOS.tar.gz、Linux.tar.gz和Windows.zip安装，数据和日志默认是$ES_HOME的子目录。但是，在升级过程中，$ES_HOME中的文件有被删除的风险

In production, we strongly recommend you set the path.data and path.logs in elasticsearch.yml to locations outside of$ES_HOME. Docker, Debian, RPM, macOS Homebrew, and Windows.msi installations write data and log to locations outside of$ES_HOME by default.

To avoid errors, only Elasticsearch should open files in the path.data directory. Exclude the path.data directory from other services that may open and lock its files, such as antivirus or backup programs.

Supported path.data and path.logs values vary by platform

只有当一个节点与集群中的所有其他节点共享 cluster.name时，该节点才能加入集群。默认名称是 elasticsearch，但是您应该将其更改为描述集群用途的适当名称。

不要在不同的环境中重用相同的集群名称。否则，节点可能会加入错误的集群

Elasticsearch使用 node.name作为Elasticsearch特定实例的人类可读标识符。这个名称包含在许多api的响应中。当Elasticsearch启动时，节点名默认为机器的主机名，但是可以在 elasticsearch.yml中显式配置

缺省情况下，Elasticsearch只绑定到 127.0.0.1和 [::1]等环回地址。这对于在单个服务器上运行一个或多个节点的集群进行开发和测试已经足够了，但是弹性生产集群必须包含其他服务器上的节点。有许多网络设置，但通常你只需要配置 network.host:

当你为 network.host提供值时。Elasticsearch假定您正在从开发模式转向生产模式，并将一些系统启动检查从警告升级到异常。看看开发和生产模式之间的区别。

在投入生产之前，配置两个重要的发现和集群形成设置，以便集群中的节点能够相互发现并选择一个主节点。

Elasticsearch可以开箱即用，无需任何网络配置，它将绑定到可用的环回地址，并扫描本地端口 9300到 9305，以便与运行在同一服务器上的其他节点连接。这种行为提供了一种无需进行任何配置的自动集群体验。

当您希望与其他主机上的节点形成集群时，使用静态 discovery.seed_hosts设置. This setting provides a list of other nodes in the cluster that are master-eligible and likely to be live and contactable to seed the discovery process.

此设置接受集群中所有符合主节点的地址的YAML序列或数组。每个地址可以是一个IP地址，也可以是通过DNS解析为一个或多个IP地址的主机名。

当您第一次启动Elasticsearch集群时，集群引导步骤将确定在第一次选举中计票的符合主资格的节点集。在开发模式下，如果没有配置发现设置，这个步骤将由节点自己自动执行。

因为自动引导本身就不安全,，所以在生产模式下启动新集群时，必须显式列出符合主资格的节点，这些节点的投票应该在第一次选举中计算。您可以使用集群设置此列表。 initial_master_nodes设置。

在集群第一次成功形成之后，删除每个节点配置中的 Initial_master_nodes设置。在重新启动集群或向现有集群添加新节点时，不要使用此设置。

通过节点的 node.name标识初始主节点,该节点默认为主节点的主机名。请确保 cluster.initial_master_nodes值与 node.name完全匹配如果您使用完全限定的域名(FQDN)，例如master-node-a.example.com作为您的节点名，那么您必须在此列表中使用FQDN。相反，如果node.name是没有任何尾随限定符的裸主机名，您也必须省cluster.initial_master_nodes中的尾随限定符如果您使用完全限定的域名(FQDN)，例如 master-node-a.example.com作为您的节点名,那么您必须在此列表中使用FQDN。相反，如果f node.name是没有任何尾随限定符的裸主机名，您也必须省略 cluster.initial_master_nodes中的尾随限定符。

请参见 bootstrapping a cluster以及发现和集群形成设置.

默认情况下，Elasticsearch会根据节点的角色和总内存自动设置JVM堆大小。对于大多数生产环境，我们建议使用默认大小。

自动堆大小需要 bundled JDK，如果使用自定义JRE位置，则需要Java 14或更高版本的JRE。

如果需要，您可以通过手动设置JVM堆大小来覆盖默认大小

默认情况下，Elasticsearch将JVM配置为将堆内存溢出异常转储到默认数据目录。在RPM和Debian软件包中，数据目录是/var/lib/elasticsearch。在Linux、MacOS和Windows发行版上，数据目录位于Elasticsearch安装的根目录下。

如果此路径不适合接收堆转储，请修改-XX:HeapDumpPath=… jvm.options

默认情况下，Elasticsearch启用垃圾收集(GC)日志。这些是在jvm中配置的 jvm.options并输出到与Elasticsearch日志相同的默认位置。默认配置每64mb轮换一次日志，最多可以消耗2gb的磁盘空间。

您可以使用 JEP 158: Unified JVM Logging中描述的命令行选项重新配置JVM日志。除非您更改了默认jvm。选项文件，Elasticsearch默认配置将应用于您自己的设置之外。要禁用默认配置，首先通过提供-Xlog:disable选项禁用日志记录，然后提供您自己的命令行选项。这将禁用所有JVM日志记录，因此一定要检查可用选项并启用所需的所有内容。

要查看原始JEP中未包含的其他选项，请参见使用 JVM统一日志框架启用日志记录.

Change the default GC log output location to/opt/my-app/gc.log by creating$ES_HOME/config/jvm.options.d/gc.options with some sample options:

Configure an Elasticsearch Docker container to send GC debug logs to standard error( stderr). This lets the container orchestrator handle the output. If using the ES_JAVA_OPTS environment variable, specify:

默认情况下，Elasticsearch使用启动脚本直接在系统临时目录下创建的私有临时目录。

在某些Linux发行版上，如果最近没有访问过/tmp中的文件和目录，系统实用程序将清除它们。如果需要临时目录的特性长时间不使用，那么在Elasticsearch运行时，这种行为会导致私有临时目录被删除。如果随后使用需要此目录的特性，则删除私有临时目录会导致问题。

如果您使用.deb或.rpm包安装Elasticsearch，并在systemd下运行它，那么Elasticsearch使用的私有临时目录将被排除在定期清理之外。

如果您打算在Linux或MacOS上长时间运行.tar.gz发行版，请考虑为Elasticsearch创建一个专用的临时目录，该目录不在将旧文件和目录清除的路径下。这个目录应该设置权限，以便只有作为Elasticsearch运行的用户才能访问它。然后，在启动Elasticsearch之前，设置$ES_TMPDIR环境变量指向这个目录。

默认情况下，Elasticsearch将JVM配置为将致命错误日志写入默认日志目录。对于 RPM和 Debian软件包,这个目录是/var/log/elasticsearch. On Linux and MacOS and Windows发行版, logs目录位于Elasticsearch安装根目录下。

这些日志是JVM遇到致命错误(例如分段错误)时产生的。如果此路径不适合接收日志，请修改-XX:ErrorFile=...在 jvm.options条目。

在灾难中，快照可以防止数据永久丢失。快照生命周期管理是对集群进行定期备份的最简单方法。有关更多信息，请参见备份集群。

在灾难中,快照可以防止数据永久丢失.快照生命周期管理是对集群进行定期备份的最简单方法.有关更多信息,请参见备份集群。

备份集群的唯一可靠和受支持的方法是使用快照。您不能通过复制Elasticsearch集群节点的数据目录来备份该集群。不支持从文件系统级备份恢复任何数据的方法。如果试图从这样的备份恢复集群，可能会出现损坏、丢失文件或其他数据不一致的报告，或者看起来已经成功地悄无声息地丢失了一些数据。

有些设置是敏感的，仅依靠文件系统权限来保护它们的值是不够的。对于这个用例，Elasticsearch提供了一个密钥存储库和 elasticsearch-keystore工具来管理密钥存储库中的设置。

只有重新启动Elasticsearch后，对keystore的所有修改才会生效。

这些设置就像elasticsearch中的常规设置一样。Yml配置文件，需要在集群中的每个节点上指定。目前，所有安全设置都是特定于节点的设置，在每个节点上必须具有相同的值。

Just like the settings values in elasticsearch.yml,对密钥存储库内容的更改不会自动应用到运行的Elasticsearch节点。重新读取设置需要重新启动节点。但是，某些安全设置被标记为可重新加载。. Such settings can be re-read and applied on a running node.

所有安全设置的值(无论是否可重新加载)必须在所有集群节点上相同。在进行所需的安全设置更改后，使用 bin/elasticsearch-keystore add命令, call:

keystore-password:用于加密Elasticsearch密钥库的密码

此API在每个集群节点上解密并重新读取整个密钥存储库，但只应用可重新加载的安全设置。对其他设置的更改直到下次重启才会生效。一旦调用返回，重新加载就完成了，这意味着依赖于这些设置的所有内部数据结构都已更改。所有的设置都应该从一开始就具有新值。

当更改多个可重新加载的安全设置时，在每个集群节点上修改所有安全设置，然后发出 reload_secure_settings调用，而不是在每次修改后重新加载。

有可重新加载的安全设置:

如何在 Docker 上运行 Elasticsearch 8.x 进行本地开发

针对Elasticsearch 8.x版本，运行Elasticsearch和Kibana在Docker上有了重大更新。针对以前版本的Docker和Docker Compose的命令和语法需要更新以适应最新版本。本文将介绍如何使用Docker和Docker Compose启动Elasticsearch（8.6.0版本）和Kibana进行本地开发。

我在先前的文章中也对这一过程进行了描述，但本文将从另一个角度进行展示。本文将展示如何安装不带安全的Elasticsearch。这在很多情况下都是适用的。

本文将使用最新的ElasticStack 8.6.0版本进行演示。

在禁用xpack安全性情况下，在Docker上运行Elasticsearch和Kibana：

默认情况下，xpack安全性是启用的，这意味着您需要身份验证才能访问Elasticsearch服务器。但对于本地开发，我们通常不需要很高的安全级别，因为一切都在本地。我们将更多地关注业务逻辑和代码，而不是基础设施。当代码准备好用于生产时，我们可以使用托管的Elasticsearch解决方案，例如开发和维护Elasticsearch的公司elastic.co。

直接使用Docker启动Elasticsearch和Kibana非常简单。首先，我们需要创建一个供Elasticsearch和Kibana使用的network。这个network将被用于Elasticsearch和Kibana之间的通信。

然后我们可以为Elasticsearch创建一个Docker容器：

要点：

我们可以使用Dockerhub上托管的docker镜像，也可以使用Elasticsearch直接提供的镜像。

运行完上面的命令后，我们可以使用如下的命令来查看正在运行的docker容器：

在macOS上，我们可以使用如下的命令来查看9200是否已经被使用：

在terminal中，我们可以打入如下的命令来进行查看：

上面表明我们的Elasticsearch已经成功地运行起来了。当你看到上面的输出时，表示Elasticsearch Docker容器已成功启动。

然后我们可以启动一个Kibana容器来管理带有漂亮用户界面的Elasticsearch服务器。要为Kibana启动Docker容器，请在另外一个terminal中运行：

重点是：

如果访问，就可以直接打开Kibana的Web UI，不需要认证。

我们可以使用如下的命令来查看正在运行的容器：

使用Docker Compose运行Elasticsearch和Kibana：

最好在docker-compose.yaml文件中指定我们需要运行的Docker容器，尤其是当你有多个容器时。这样，你可以同时管理它们，而不需要一个一个地启动它们。有了docker-compose.yaml，代码的版本控制和共享也更加方便。

上面演示的Elasticsearch和Kibana容器的docker-compose.yaml文件如下。设置与直接启动Docker容器相同。我们先使用CTRL+C来停止上面运行的容器。我们创建如下的docker-compose.yml文件：

docker-compose.yml

可以看到，我们可以在同一个文件中管理网络、volume和容器，超级方便。请记住在使用此docker-compose.yaml文件启动容器/服务之前关闭上面启动的elasticsearch和kibana容器，否则会发生端口冲突。或者，你可以在此文件中指定不同的已发布端口。我们使用如下的命令来启动：

等Elasticsearch及Kibana容器起来后，我们就可以访问它们了。当我们完成上面的运行并不再使用这些容器的话，请使用如下的命令来删除使用的资源：

在启用xpack安全性的Docker上运行Elasticsearch和Kibana：

上面我们介绍了如何快速启动Elasticsearch和Kibana的Docker容器进行本地开发。当不需要担心身份验证问题时，它们非常适合本地开发。

对于生产，我们当然应该启用xpack安全功能。但是，如果可能的话，我们不应该自己托管Elasticsearch服务器，而应该通过专门的提供商来托管，例如开发和维护Elasticsearch的公司elastic.co。这样，我们就不用担心硬件、安全、升级等细节问题，可以专注于业务逻辑和数据。

然而，在某些情况下也需要本地身份验证。我们可以删除上面演示的xpack.security.enabled=false环境变量，xpack安全将自动启用。我们先创elastic这个网络：

如果网络已经存在，你可以不创建。

要启动启用了xpack安全性的Elasticsearch容器，请运行：

如果你已经做了上面的练习，那么你可能会遇到如下的错误信息：

这是因为elasticsearch这个名字已经被使用。我们可以通过如下的方法来删除它：

这样，我们删除了上面的两个容器：elasticsearch及kibana。我们再次运行上面的命令：

请注意，我们为默认用户elastic指定了密码。如果此处不指定，则在启动容器时会生成一个随机密码。你还将看到为Kibana生成的注册token：

我们向下滚动，我们可以看到：

打开一个新的控制台，我们先直接调用Elasticsearch API。奇怪的是，我们需要从Docker容器中复制安全证书并将其用于curl身份验证：

我们在上面的目录中使用如下的命令：

然后让我们创建一个Kibana容器来管理这个带有身份验证的Elasticsearch服务器。该命令实际上与上面相同：

在控制台中，我们看到类似这样的内容：

注意：我们需要在URL中指定验证码才能访问Kibana。0.0.0.0表示本地计算机上的所有IPv4地址都可以访问此端口。当你转到0.0.0.0:5601/?...时，系统会提示你输入注册token：

复制并粘贴启动Elasticsearch容器时屏幕上显示的注册token。如果屏幕上满是日志或令牌已过期，你可以使用elasticsearch-create-enrollment-token命令生成一个新token。我们可以直接在Elasticsearch容器内使用elasticsearch-create-enrollment-token命令：

然后在你点击“Configure Elastic”之后，你需要输入你的用户名和密码，在这个例子中都elastic。最后，你可以使用Kibana来管理你的Elasticsearch服务器。嗯，启用xpack安全性确实非常安全。我们需要验证码、注册token和用户名/密码，这将确保安全。

启用xpack安全性时使用Docker Compose运行Elasticsearch和Kibana：

令人惊讶的是，在启用xpack安全性的情况下，编写docker-compose.yaml文件来管理Elasticsearch和Kibana容器非常复杂。我们需要自己明确管理证书，可以在“如何使用Docker compose来一键部署Elastic Stack 8.x”中找到。很奇怪，直接使用Docker如此简单，而使用Docker Compose对于xpack安全性却复杂得多。我认为在他们有更好的版本之前，我们应该避免使用它。

总结：

我们已经介绍了在Docker上运行Elasticsearch和Kibana的各种方法。对于本地开发，在大多数情况下我们可以禁用xpack安全性，只关注数据和查询。在禁用xpack安全性时使用Docker会更加直接。对于生产，我们通常会将数据托管在专门的提供商（例如）上，这样可以省去管理服务器、证券和升级的工作，让我们专注于重要的业务逻辑。

如何查看elasticsearch版本

1、一般情况下如果es服务正常启动，可以通过接口的方式获取elasticsearch版本信息：

curl

上述命令可以得到elasticsearch的服务状态和其他信息包括版本号。

2、如果elasticsearch没有启动，则可以直接找到es的lib包来确认版本号，使用以下命令

lllib|grep'elasticsearch-\d\.\d\.\d\.jar'

可以得到如elasticsearch-1.7.4.jar类似的结果，1.7.4即为其版本号。

扩展资料

Elasticsearch的优点介绍：

Elasticsearch可以用于搜索各种文档。它提供可扩展的搜索，具有接近实时的搜索，并支持多租户。

Elasticsearch是分布式的，这意味着索引可以被分成分片，每个分片可以有0个或多个副本。每个节点托管一个或多个分片，并充当协调器将操作委托给正确的分片。再平衡和路由是自动完成的。

Elasticsearch使用Lucene，它支持facetting和percolating，如果新文档与注册查询匹配，这对于通知非常有用。另一个特性称为“网关”，处理索引的长期持久性；例如，在服务器崩溃的情况下，可以从网关恢复索引。

参考资料：百度百科-elasticsearch