【ELK前期准备】ES的部署实施

【ELK前期准备】ES的快速部署学习

ES概述

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

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

场景描述

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

这里有一些使用Elasticsearch的用例：

1. 你经营一个网上商店，你允许你的顾客搜索你卖的产品。在这种情况下，您可以使用Elasticsearch来存储整个产品目录和库存，并为它们提供搜索和自动完成建议。
2. 你希望收集日志或事务数据，并希望分析和挖掘这些数据，以查找趋势、统计、汇总或异常。在这种情况下，你可以使用loghide (Elasticsearch/ loghide /Kibana堆栈的一部分)来收集、聚合和解析数据，然后让loghide将这些数据输入到Elasticsearch中。一旦数据在Elasticsearch中，你就可以运行搜索和聚合来挖掘你感兴趣的任何信息。
3. 你运行一个价格警报平台，允许精通价格的客户指定如下规则:“我有兴趣购买特定的电子设备，如果下个月任何供应商的产品价格低于X美元，我希望得到通知”。在这种情况下，你可以抓取供应商的价格，将它们推入到Elasticsearch中，并使用其反向搜索(Percolator)功能来匹配价格走势与客户查询，并最终在找到匹配后将警报推送给客户。
4. 你有分析/业务智能需求，并希望快速调查、分析、可视化，并对大量数据提出特别问题(想想数百万或数十亿的记录)。在这种情况下，你可以使用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
部署
注意：部署ES的时候需要将用户切换，不可直接使用root
直接去GitHub上搜索ES，上面有ELK提供下载，但是下载时注意这个版本的ES有没有配套的Logstash和Kibnna

运行：
bin/elasticsearch

检查ES是否启动成功：
curl http://Hadoop101:9200/

The REST API
集群健康：
请求
curl -X GET “localhost:9200/_cat/health?v”
相应

命名为“elasticsearch”的集群现在是green状态，并且有三个节点。
Green ： everything is good（一切都很好）（所有功能正常）
Yellow ： 所有数据都是可用的，但有些副本还没有分配（所有功能正常）
Red ： 有些数据不可用（部分功能正常）

下面看一下集群的节点列表：
请求：
curl -X GET “localhost:9200/_cat/nodes?v”
响应：

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

这些命令自行百度查吧~~~~

The Search API
现在让我们从一些简单的搜索开始。运行搜索有两种基本方法：一种是通过REST请求URI发送检索参数，另一种是通过REST请求体发送检索参数。
一种是把检索参数放在URL后面，另一种是放在请求体里面。相当于HTTP的GET和POST请求
请求体方法允许你更有表现力，也可以用更可读的JSON格式定义搜索。
用于搜索的REST API可从_search端点访问。下面的例子返回"bank"索引中的所有文档：
curl -X GET “localhost:9200/bank/_search?q=*&sort=account_number:asc&pretty”
让我们来剖析一下上面的请求。

我们在"bank"索引中检索，q=*参数表示匹配所有文档；sort=account_number:asc表示每个文档的account_number字段升序排序；pretty参数表示返回漂亮打印的JSON结果。