elasticsearch篇

elasticsearch篇

elasticsearch不能用root用户启动        为什么不能：./elasticsearch -Des.insecure.allow.root=true 用vim打开elasicsearch执行文件，在变量ES_JAVA_OPTS使用前添加以下命令 ES_JAVA_OPTS="-Des.insecure.allow.root=true"
groupadd elk
useradd -g elk elk
chown -R elk:elk elasticsearch/

修改elasticsearch的配置文件
---------------------------------- Cluster -----------------------------------
cluster.name: mxc-es 设置elasticsearch集群名称
------------------------------------ Node ------------------------------------
node.name: node-14 设置elasticsearch节点名称
此外还有两个参数很重要 node.master和node.data
在生产环境下，如果不修改elasticsearch节点的角色信息，在高数据量，高并发的场景下集群容易出现脑裂等问题。
默认情况下，elasticsearch集群中每个节点都有成为主节点的资格，也都存储数据，还可以提供查询服务。
这些功能是由两个属性控制的。
node.master和node.data
默认情况下这两个属性的值都是true。
node.master：这个属性表示节点是否具有成为主节点的资格
注意：此属性的值为true，并不意味着这个节点就是主节点。
因为真正的主节点，是由多个具有主节点资格的节点进行选举产生的。
所以，这个属性只是代表这个节点是不是具有主节点选举资格。
node.data：这个属性表示节点是否存储数据。

这两个属性可以有四种组合：
第一种：这种组合表示这个节点即有成为主节点的资格，又存储数据，
这个时候如果某个节点被选举成为了真正的主节点，那么他还要存储数据，这样对于这个节点的压力就比较大了。
elasticsearch默认每个节点都是这样的配置，在测试环境下这样做没问题。实际工作中建议不要这样设置，
这样相当于主节点和数据节点的角色混合到一块了。
node.master: true
node.data: true

第二种：这种组合表示这个节点没有成为主节点的资格，也就不参与选举，只会存储数据。
这个节点我们称为data(数据)节点。在集群中需要单独设置几个这样的节点负责存储数据。后期提供存储和查询服务。
node.master: false
node.data: true

第三种：这种组合表示这个节点不会存储数据，有成为主节点的资格，可以参与选举，有可能成为真正的主节点。
这个节点我们称为master节点
node.master: true
node.data: false

第四种：这种组合表示这个节点即不会成为主节点，也不会存储数据，
这个节点的意义是作为一个client(客户端)节点，主要是针对海量请求的时候可以进行负载均衡。
node.master: false
node.data: false
默认情况下，每个节点都有成为主节点的资格，也会存储数据，还会处理客户端的请求。
在一个生产集群中我们可以对这些节点的职责进行划分。

建议集群中设置3台以上的节点作为master节点【node.master: true node.data: false】
这些节点只负责成为主节点，维护整个集群的状态。
再根据数据量设置一批data节点【node.master: false node.data: true】
这些节点只负责存储数据，后期提供建立索引和查询索引的服务，这样的话如果用户请求比较频繁，这些节点的压力也会比较大
所以在集群中建议再设置一批client节点【node.master: false node.data: false】
这些节点只负责处理用户请求，实现请求转发，负载均衡等功能。

master节点：普通服务器即可(CPU 内存 消耗一般)
data节点：主要消耗磁盘，内存
client节点：普通服务器即可(如果要进行分组聚合操作的话，建议这个节点内存也分配多一点)
----------------------------------- Paths ------------------------------------
mkdir -p /data/elasticsearch/{data,logs} 存放elasticsearch的日志与数据的文件夹

path.data: /data/elasticsearch/data
path.logs: /data/elasticsearch/logs
# ---------------------------------- Network -----------------------------------
network.host: 192.168.1.14
http.port: 9200
# --------------------------------- Discovery ----------------------------------

discovery.seed_hosts: ["192.168.1.12:9300", "192.168.1.13:9300", "192.168.1.14:9300"]

cluster.initial_master_nodes: ["node-12", "node-13", "node-14"]

discovery.seed_hosts
Out of the box, without any network configuration, Elasticsearch will bind to the available loopback addresses and will scan local ports 9300 to 9305 to try to connect to other nodes running on the same server. This provides an auto- clustering experience without having to do any configuration.
开箱即用，没有任何网络配置，Elasticsearch将绑定到可用的环回地址，并将扫描本地端口9300到9305以尝试连接到在同一服务器上运行的其他节点。 这提供了自动集群体验，无需进行任何配置。
When you want to form a cluster with nodes on other hosts, you must use the discovery.seed_hosts setting to provide a list of other nodes in the cluster that are master-eligible and likely to be live and contactable in order to seed the discovery process. This setting should normally contain the addresses of all the master-eligible nodes in the cluster. This setting contains either an array of hosts or a comma-delimited string. Each value should be in the form of host:port or host (where port defaults to the setting transport.profiles.default.port falling back to transport.port if not set). Note that IPv6 hosts must be bracketed. The default for this setting is 127.0.0.1, [::1].
如果要在其他主机上形成包含节点的群集，则必须使用discovery.seed_hosts设置提供群集中其他节点的列表，这些节点符合主要条件且可能是实时且可联系的，以便为发现过程设定种子。 此设置通常应包含群集中所有符合主节点的节点的地址。 此设置包含主机数组或逗号分隔的字符串。 每个值应采用host：port或host的形式（其中port默认为设置transport.profiles.default.port，如果未设置则返回transport.port）。 请注意，必须将IPv6主机置于括号内。 此设置的默认值为127.0.0.1，[:: 1]。
The port will default to transport.profiles.default.port and fallback to transport.port if not specified.
如果未指定，端口将默认为transport.profiles.default.port并回退到transport.port。
If a hostname resolves to multiple IP addresses then the node will attempt to discover other nodes at all resolved addresses.
如果主机名解析为多个IP地址，则该节点将尝试发现所有已解析地址的其他节点。

cluster.initial_master_nodes
When you start a brand new Elasticsearch cluster for the very first time, there is a cluster bootstrapping step, which determines the set of master-eligible nodes whose votes are counted in the very first election. In development mode, with no discovery settings configured, this step is automatically performed by the nodes themselves. As this auto-bootstrapping is inherently unsafe, when you start a brand new cluster in production mode, you must explicitly list the names or IP addresses of the master-eligible nodes whose votes should be counted in the very first election. This list is set using the cluster.initial_master_nodes setting.
当您第一次启动全新的Elasticsearch集群时，会出现一个集群引导步骤，该步骤确定在第一次选举中计票的主要合格节点集。 在开发模式下，如果未配置发现设置，则此步骤由节点本身自动执行。 由于此自动引导本质上是不安全的，因此当您在生产模式下启动全新集群时，必须明确列出符合条件的节点的名称或IP地址，这些节点的投票应在第一次选举中计算。 使用cluster.initial_master_nodes设置设置此列表。
Initial master nodes can be identified by their node.name, which defaults to the hostname. Make sure that the value in cluster.initial_master_nodes matches the node.name exactly. If you use a fully-qualified domain name such as master-node-a.example.com for your node names then you must use the fully-qualified name in this list; conversely if node.name is a bare hostname without any trailing qualifiers then you must also omit the trailing qualifiers in cluster.initial_master_nodes.
初始主节点可以通过其node.name来标识，该节点默认为主机名。 确保cluster.initial_master_nodes中的值与node.name完全匹配。 如果您使用完全限定的域名（例如master-node-a.example.com）作为节点名称，则必须在此列表中使用完全限定名称; 相反，如果node.name是一个没有任何尾随限定符的裸主机名，那么您还必须省略cluster.initial_master_nodes中的尾随限定符。
Initial master nodes can also be identified by their IP address.
初始主节点也可以通过其IP地址识别。

su - elk
./elasticsearch 会报错
elasticsearch对系统的要求
vim /etc/security/limits.conf
* soft nproc 65536
* hard nproc 65536
* soft nofile 65536
* hard nofile 65536
让文件生效 可以新开一个窗口
vi /etc/sysctl.conf
vm.max_map_count=262144
让文件生效 sysctl -p

检查：
ulimit -Hn 硬件
ulimit -Sn 软件

 

elasticsearch使用
Elasticsearch 是一个分布式的 RESTful 风格的搜索和数据分析引擎。

查询 ： Elasticsearch 允许执行和合并多种类型的搜索 — 结构化、非结构化、地理位置、度量指标 — 搜索方式随心而变。
分析 ： 找到与查询最匹配的十个文档是一回事。但是如果面对的是十亿行日志，又该如何解读呢？Elasticsearch 聚合让您能够从大处着眼，探索数据的趋势和模式。
速度 ： Elasticsearch 很快。真的，真的很快。
可扩展性 ： 可以在笔记本电脑上运行。 也可以在承载了 PB 级数据的成百上千台服务器上运行。
弹性 ： Elasticsearch 运行在一个分布式的环境中，从设计之初就考虑到了这一点。
灵活性 ： 具备多个案例场景。数字、文本、地理位置、结构化、非结构化。所有的数据类型都欢迎。
HADOOP & SPARK ： Elasticsearch + Hadoop

Elasticsearch是一个高度可伸缩的开源全文搜索和分析引擎。它允许您快速和接近实时地存储、搜索和分析大量数据。

这里有一些使用Elasticsearch的用例：
你经营一个网上商店，你允许你的顾客搜索你卖的产品。在这种情况下，您可以使用Elasticsearch来存储整个产品目录和库存，并为它们提供搜索和自动完成建议。
你希望收集日志或事务数据，并希望分析和挖掘这些数据，以查找趋势、统计、汇总或异常。在这种情况下，你可以使用loghide (Elasticsearch/ loghide /Kibana堆栈的一部分)来收集、聚合和解析数据，然后让loghide将这些数据输入到Elasticsearch中。一旦数据在Elasticsearch中，你就可以运行搜索和聚合来挖掘你感兴趣的任何信息。
你运行一个价格警报平台，允许精通价格的客户指定如下规则:“我有兴趣购买特定的电子设备，如果下个月任何供应商的产品价格低于X美元，我希望得到通知”。在这种情况下，你可以抓取供应商的价格，将它们推入到Elasticsearch中，并使用其反向搜索(Percolator)功能来匹配价格走势与客户查询，并最终在找到匹配后将警报推送给客户。
你有分析/业务智能需求，并希望快速调查、分析、可视化，并对大量数据提出特别问题(想想数百万或数十亿的记录)。在这种情况下，你可以使用Elasticsearch来存储数据，然后使用Kibana (Elasticsearch/ loghide /Kibana堆栈的一部分)来构建自定义仪表板，以可视化对您来说很重要的数据的各个方面。此外，还可以使用Elasticsearch聚合功能对数据执行复杂的业务智能查询

Near Realtime (NRT)

Elasticsearch是一个近乎实时的搜索平台。这意味着从索引文档到可以搜索的时间只有轻微的延迟（通常是1秒）。
Cluster
集群是一个或多个节点(服务器)的集合，它们共同保存你的整个数据，并提供跨所有节点的联合索引和搜索功能。一个集群由一个唯一的名称标识，默认这个唯一标识的名称是"elasticsearch"。这个名称很重要，因为如果节点被设置为按其名称加入集群，那么节点只能是集群的一部分。
确保不要在不同的环境中用相同的集群名称，否则可能导致节点加入到错误的集群中。例如，你可以使用"logging-dev", "logging-test", "logging-prod"分别用于开发、测试和正式集群的名字。
Node
节点是一个单独的服务器，它是集群的一部分，存储数据，并参与集群的索引和搜索功能。就像集群一样，节点由一个名称来标识，默认情况下，该名称是在启动时分配给节点的随机通用唯一标识符(UUID)。如果不想用默认的节点名，可以定义任何想要的节点名。这个名称对于管理来说很重要，因为你希望识别网络中的哪些服务器对应于你的Elasticsearch集群中的哪些节点。
一个节点可以通过配置集群名称来加入到一个特定的集群中。默认情况下，每个节点都被设置加入到一个名字叫"elasticsearch"的集群中，这就意味着如果你启动了很多个节点，并且假设它们彼此可以互相发现，那么它们将自动形成并加入到一个名为"elasticsearch"的集群中。
一个集群可以有任意数量的节点。此外，如果在你的网络上当前没有运行任何节点，那么此时启动一个节点将默认形成一个单节点的名字叫"elasticsearch"的集群。
Index
索引是具有某种相似特征的文档的集合。例如，你可以有一个顾客数据索引，产品目录索引和订单数据索引。索引有一个名称（必须是小写的）标识，该名称用于在对其中的文档执行索引、搜索、更新和删除操作时引用索引。
Document
文档是可以被索引的基本信息单元。文档用JSON表示。
Shards & Replicas
一个索引可能存储大量数据，这些数据可以超过单个节点的硬件限制。例如，一个包含10亿条文档占用1TB磁盘空间的索引可能不适合在单个节点上，或者可能太慢而不能单独处理来自单个节点的搜索请求。
为了解决这个问题，Elasticsearch提供了将你的索引细分为多个碎片（或者叫分片）的能力。在创建索引时，可以简单地定义所需的分片数量。每个分片本身就是一个功能完全独立的“索引”，可以驻留在集群中的任何节点上。
分片之所以重要，主要有两个原因：
它允许你水平地分割/扩展内容卷
它允许你跨分片（可能在多个节点上）分布和并行操作，从而提高性能和吞吐量
在一个网络/云环境中随时都有可能出现故障，强烈推荐你有一个容灾机制。Elasticsearch允许你将一个或者多个索引分片复制到其它地方，这被称之为副本。
复制之所以重要，有两个主要原因：
它提供了在一个shard/node失败是的高可用性。出于这个原因，很重要的一个点是一个副本从来不会被分配到与它复制的原始分片相同节点上。也就是说，副本是放到另外的节点上的。
它允许扩展搜索量/吞吐量，因为搜索可以在所有副本上并行执行。
总而言之，每个索引都可以分割成多个分片。索引也可以被复制零(意味着没有副本)或更多次。一旦被复制，每个索引都将具有主分片(被复制的原始分片)和副本分片(主分片的副本)。在创建索引时，可以为每个索引定义分片和副本的数量。创建索引后，您可以随时动态地更改副本的数量，但不能更改事后分片的数量。
在默认情况下，Elasticsearch中的每个索引都分配了5个主分片和1个副本，这意味着如果集群中至少有两个节点，那么索引将有5个主分片和另外5个副本分片（PS：这5个副本分片组成1个完整副本），每个索引总共有10个分片。
（画外音：副本是针对索引而言的，同时需要注意索引和节点数量没有关系，我们说2个副本指的是索引被复制了2次，而1个索引可能由5个分片组成，那么在这种情况下，集群中的分片数应该是 5 × (1 + 2) = 15 ）


elasticsearch验证
验证集群启动
http://192.168.10.150:9200 查看集群名称等信息
http://192.168.10.150:9200/_cat 集群相关API
http://192.168.10.150:9200/_cat/nodes?v 查看集群节点
验证集群磁盘分配情况：http://192.168.10.150:9200/_cat/allocation?v
验证集群健康状况：http://192.168.10.150:9200/_cat/health?v
查看集群的索引数： http://192.168.10.150:9200/_cat/indices?v

通过restful语法验证
curl -X GET "localhost:9200/_cat/health?v" 验证集群健康状况
curl -X GET "localhost:9200/_cat/nodes?v" 查看集群节点
curl -X GET "localhost:9200/_cat/indices?v" 查看集群的索引数
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size 意味着：我们在集群中没有索引

创建一个索引
curl -X PUT "localhost:9200/customer?pretty" pretty的意思是响应（如果有的话）以JSON格式返回

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open customer rG5fxdruTNmD-bdYIF5zOg 5 1 0 0 1.1kb 1.1kb

我们现在有叫"customer"的索引，并且他有5个主分片和1个副本（默认是1个副本），有0个文档。
"customer"索引的健康状态是yellow
之所以会出现这种情况，是因为Elasticsearch默认情况下为这个索引创建了一个副本。由于目前我们只有一个节点在运行，所以直到稍后另一个节点加入集群时，才会分配一个副本(对于高可用性)。一旦该副本分配到第二个节点上，该索引的健康状态将变为green。

无论何时我们请求集群健康时，我们会得到green, yellow, 或者 red 这三种状态。
Green ： everything is good（一切都很好）（所有功能正常）
Yellow ： 所有数据都是可用的，但有些副本还没有分配（所有功能正常）
Red ： 有些数据不可用（部分功能正常）

put一些数据到我们的"customer"索引：
请求：
curl -X PUT "localhost:9200/customer/_doc/1?pretty" -H 'Content-Type: application/json' -d'{"name": "John Doe"}'
响应：
{
"_index" : "customer",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 0,
"_primary_term" : 1
}

从上面的响应可以看到，我们在"customer"索引下成功创建了一个文档。这个文档还有一个内部id为1，这是我们在创建的时候指定的。
需要注意的是，Elasticsearch并不要求你在索引文档之前就先创建索引，然后才能将文档编入索引。在前面的示例中，如果事先不存在"customer"索引，Elasticsearch将自动创建"customer"索引。
（画外音：也就是说，在新建文档的时候如果指定的索引不存在则会自动创建相应的索引）
现在，让我重新检索这个文档：
请求：
curl -X GET "localhost:9200/customer/_doc/1?pretty"
响应：
{
"_index" : "customer",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"found" : true,
"_source" : {
"name" : "John Doe"
}
}

可以看到除了"found"字段外没什么不同，"_source"字段返回了一个完整的JSON文档。

删除一个索引
现在，让我们删除前面创建的索引，然后查看全部索引
请求：
curl -X DELETE "localhost:9200/customer?pretty"
响应：
{
"acknowledged" : true
}
接下来，查看一下
curl -X GET "localhost:9200/_cat/indices?v"
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size

仔细研究上面的命令，我们实际上可以看到如何在Elasticsearch中访问数据的模式。这种模式可以概括如下：
<REST Verb> /<Index>/<Type>/<ID>