ElasticSearch结合kibana常见运维命令使用
文章目录
- ElasticSearch结合kibana常见运维命令使用
- 1：ES使用curl工具查询
- 2：结合kibana使用ES
- 2.1常用运维命令
- 2.1.1：get _cluster/health ：查看集群状态
- 2.1.2：GET _cluster/allocation/explain查看分片分配详情
- 2.1.2：segments
- 2.1.3：ES的cat 操作，查看ES的各种数据：get _cat
- 2.1.3.1：get _cat/indices?v&s=store.size：ES集群索引状态查看
- 2.1.3.2：get_cat/nodes：集群主从节点状态查看
- 2.1.3.3：get _cat/master?v ：查看当前集群的主节点
- 2.1.3.4：GET _cat/nodes?v :查看各节点状态，内存消耗
- 2.1.3.5：GET _cat/allocation?v：各节点分片总数，磁盘使用
- 2.1.3.6：GET _cat/shards?v&S=store :desc列出集群中所有分片
- 2.1.3.7：GET /_cat/thread_pool：各节点线程池信息查看
- 2.1.3.8：GET cat/hot_threads
- 2.1.3.9：GET /_cluster/pending_tasks？v
- 2.1.2：GET /_nodes/stats：查看节点索引性能状态
- 2.2：ES的查询query命令使用
- 2.3：ES的过滤器使用
- 3：es的log日志文件
1：ES使用curl工具查询
在es任意一台服务器执行就可以。使用版本6.8
1.1：curl介绍
curl 是centos自带的利用 URL 语法在命令行方式下工作的开源文件传输工具，使用 curl 可以简单 实现常见的 get/post 请求。
1.2：curl的shell使用
curl
-x 指定 http 的请求方法有： HEAD GET POST PUT DELETE
-d 指定要传输的数据
-H 指定 http 请求头信息
&s=列名 s用于排序作用
1.3：curl -X
查询所有
curl -XGET http://localhost:9200/_index/_type/1?pretty
1：代表版本
2：？pretty,在任意的查询 url 中添加 pretty 参数，es 会美化获取 json 结果。`
3：?v 会展示列名
4：添加列参数&：？pretty&line=value 列名=值
5：列排序。可以对某列进行排序 ：desc
请求体基本同kibana中的请求体
curl -XGET “http://localhost:9200/_index/_type/1?pretty“ -d ‘{请求体}’
curl -XGET “http://localhost:9200/_cat/nodes?v“
1:实战
删除索引：curl -XDELETE “http://localhost:9200/INDEX—name?pretty&master_timeout=300s"
添加参数：curl -XDELETE “http://localhost:9200/INDEX—name?pretty&master_timeout=300s"
指定列并排序：
GET /_cat/nodes?v&h=heap.percent,diskUsedPercent,cpu,master,name&s=name：desc
2：结合kibana使用ES
安装下载自行百度
2.1常用运维命令
命令后+
?v 会显示列名，查看更直观
&s=列名:desc s用于列排序作用
?help 查看帮助
?pretty=true 会以json的形式返回结果，提升可读性
？v&h=列名，列名 可以指定查看列名
2.1.1：get _cluster/health ：查看集群状态
kibana查看集群状态
get _cluster/health
get _cluster/health/_index也可以查看某一索引的状态
curl查看集群状态：
索引级别的状态由分片的最差状态决定。集群状态由最差的索引状态控制。
$ curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'
{
"cluster_name" : "testcluster",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 2,
"number_of_data_nodes" : 2,
"active_primary_shards" : 5,
"active_shards" : 10,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0
}
集群健康状态是status：green，yellow和red。
在分片层次上，一个red状态表明有主分片没有分配，yellow表示主分片分配但有副本没有分配，
green表示所有的分片都已经分配。
"number_of_nodes" : # 集群所有节点数
"number_of_data_nodes" : # 集群所有数据节点数
"active_primary_shards" : # 集群所有索引正常的主分片数
"active_shards" : # 集群所有索引的主分片数
"relocating_shards" : #表示当前集群分片从一个节点转移到另一个节点的分片数，这个值一般情况为0
但是可能会增加，当ES集群不平衡时会存在这种情况，比如一个节点的加入或关闭。
"initializing_shards" : # 表示集群恢复或者索引创建后分片初始化分片数
"unassigned_shards" : # 未分配分片数，此时故障分析原因
"delayed_unassigned_shards": # 延迟的没有分配数据的分
"number_of_pending_tasks" : #master节点未执行的任务，代表的master的压力。
删除，移动，创建索引，移动分片执行或等待的任务数
集群健康状态
green
所有的主要分片和副片都正常运行。
yellow
所有的主要分片都正常运行，但不是所有的副片都正常运行。
red
有主角片不能正常运行。
“number_of_pending_tasks” :可以看到集群master的压力情况。如索引创建延迟或失败可排查
2.1.2：GET _cluster/allocation/explain查看分片分配详情
GET _cluster/allocation/explain
{
"index": "my-index-000001",
"shard": 0,
"primary": true
}
返回结果如下
allocate_explanation具体未分配的解释
{
"index" : "my-index-000001",
"shard" : 0,
"primary" : true,
"current_state" : "unassigned", //分片分配的状态
"unassigned_info" : { //分配的具体状态
"reason" : "INDEX_CREATED", //未分配的原因
"at" : "2017-01-04T18:08:16.600Z",
"last_allocation_status" : "no"
},
"can_allocate" : "no", //allocate_explanation具体未分配的解释
"allocate_explanation" : "Elasticsearch isn't allowed to allocate this shard to any of the nodes in the cluster. Choose a node to which you expect this shard to be allocated, find this node in the node-by-node explanation, and address the reasons which prevent Elasticsearch from allocating this shard there.",
"node_allocation_decisions" : [
]
}
“unassigned_info” :中的reason未分配原因详解
返回值包括：
* ALLOCATION_FAILED: 由于分片分配失败而未分配。
* CLUSTER_RECOVERED：由于完整的集群恢复而未分配。
* DANGLING_INDEX_IMPORTED: 由于导入了空索引而未分配。
* EXISTING_INDEX_RESTORED: 由于恢复到封闭索引而未分配。
* FORCED_EMPTY_PRIMARY：上次修改分片的分配是通过使用集群重新路由API 强制一个空的主分片。
* INDEX_CLOSED: 未分配，因为索引已关闭。
* INDEX_CREATED: 由于 API 创建索引而取消分配。
* INDEX_REOPENED: 由于打开封闭索引而未分配。
* MANUAL_ALLOCATION: 分片的分配最后由集群重新路由API修改。
* NEW_INDEX_RESTORED: 由于恢复到新索引而未分配。
* NODE_LEFT：由于托管它的节点离开集群而未分配。
* NODE_RESTARTING：与 类似NODE_LEFT，不同之处在于节点是使用* * Node shutdown API注册为重新启动的。
* PRIMARY_FAILED: 分片初始化为副本，但主分片在初始化完成前失败。
* REALLOCATED_REPLICA：识别出更好的副本位置并导致现有副本分配被取消。
* REINITIALIZED：当分片从启动回到初始化时。
* REPLICA_ADDED：由于显式添加副本而未分配。
* REROUTE_CANCELLED: 由于显式取消重新路由命令而未分配。
2.1.2：segments
segments分段数越多占用的资源文件句柄以及搜索的查询时间越多。
get index/_segments :某索引的eegment情况
get cat/segments:总的segment情况
get cat/_nodes :某节点占用的内存sm。
2.1.3：ES的cat 操作，查看ES的各种数据：get _cat
2.1.3.1：get _cat/indices?v&s=store.size：ES集群索引状态查看
get _cat/indices?v&s=store.size 根据存储大小排序查看
结果解释
status 分片的状态。open/close
1）pri：主分片， rep：副本分片
3）docs.count ：文档数
4）docs.delete : 删除文档数
5）store.size全部分片存储大小
6）pri store size, 主分片存储大小
2.1.3.2：get_cat/nodes：集群主从节点状态查看
GET _cat/nodes?v :查看各节点状态，内存使用率，segment占用的内存
GET _cat/nodes?v=true&h=name,node*,heap*
get _cat/master?v ：查看当前集群的主节点
一般不建议node的heap内存指数超过 85%，否则压力较大。JVM Memory Pressure = used_in_bytes / max_in_bytes
内存压力大排查现象
- 1：node的heap内存指数超过 85%
- 2：elasticsearch.log中出现o.e.m.j.JvmGcMonitorService]等大量的内存回收的日志
1、减轻内存压力 - 1：对于text字段，fielddata 可以使用大量的 JVM 内存。为避免这种情况，Elasticsearchtext默认禁用字段上的 fielddata
- 2：清除fielddata缓存 POST _cache/clear?fielddata=true
- 3：减少分片数量
- 4：避免大数据量的查询，减少返回的数据量。size使用 索引设置
- 降低限制index.max_result_window。
使用search.max_buckets集群设置 减少允许的聚合桶的最大数量 。
使用 search.allow_expensive_queries集群设置禁用昂贵的查询。
2.1.3.3：get _cat/master?v ：查看当前集群的主节点
id host ip node
AhlyPtZYTta1AVH_7mUSbQ node1 192.168.113.101 master-1
2.1.3.4：GET _cat/nodes?v :查看各节点状态，内存消耗
列出所有node, 并展示node所在机器的运行状态信息.
本人拿自己电脑虚拟机进行测试：ram.percent和任务管理器中的消耗一样
heap.percent 堆内存占用百分比
ram.percent 内存占用百分比，达到100%查看内存优化
cpu CPU占用百分比
master *表示节点是集群中的主节点
name 节点名
es的内存占用大小对es稳定性的影响
ES内存优化以及分析
现在让我们假设您有一个集群，它有三个节点，整体内存压力要高得多。在这个例子中，三个节点中的两个节点在很长一段时间内非常有规律地最大化，一个节点始终徘徊在垃圾收集开始的75%左右。
High memory pressure
高内存压力从两个方面影响集群性能:当内存压力升至75%及以上时，可用内存会减少，但是您的集群现在还需要花费一些CPU资源来通过垃圾收集回收内存。垃圾收集进行时，这些中央处理器资源不可用于处理用户请求。因此，随着系统资源越来越受限，用户请求的响应时间会增加。如果内存压力持续上升并接近100%，则会使用更激进的垃圾收集形式，这反过来会极大地影响集群响应时间。
High response times
在我们的例子中索引响应时间度量显示，高内存压力会对性能产生显著影响。由于三个节点中的两个节点多次最大化其内存，并在100%内存压力下稳定30到45分钟，因此索引响应时间在23:00、00:00和01:00左右急剧增加。未显示的搜索响应时间也有所增加，但没有那么显著。只有蓝色的节点持续显示出健康得多的记忆压力，很少超过75%，才能维持较低的响应时间。
如果高内存压力对性能的影响不可接受，您需要增加群集大小或减少工作负载
2.1.3.5：GET _cat/allocation?v：各节点分片总数，磁盘使用
GET _cat/allocation?v&s=disk.used:desc
降序：“:desc”
shards 节点所承载的分片数
disk.indices 索引占用的空间大小
disk.used 节点所在机器已使用磁盘空间
disk.avail 节点可用磁盘大小
ip 节点所属机器IP地址
node 节点名
2.1.3.6：GET _cat/shards?v&S=store :desc列出集群中所有分片
index 索引名称
shard 分片序号
prirep p表示该分片是主分片, r 表示该分片是复制分片
store 该分片占用存储空间
node 所属节点节点名
docs 分片存放的文档数
state 分片的状态。一般有下面几种状态
STARTED 正常使用
INITIALIZING 初始化中一般是创建索引或集群启动的时候
UNASSIGNED 分片未分配，详解见下面
RELOCATING 碎片正在搬迁
unassigned状态：此未分配分片状态的原因。这并不能解释为什么分片当前未分配。要了解未分配分片的原因，请使用Cluster allocation explain API。
2.1.3.7：GET /_cat/thread_pool：各节点线程池信息查看
输出每个节点集群范围的线程池统计信息，默认情况下返回正在活动，队列和被拒绝的统计信息，若拒绝或者队列过多，查看资源。
2.1.3.8：GET cat/hot_threads
热点线程。主要用于系统分析。
查看线程： get nodes/hot_threads
查看某ip的线程： get nodes/ip/hot_threads
2.1.3.9：GET /_cluster/pending_tasks？v
返回任何集群级别更改如创建索引，更新映射，分配或失败分片。正常应该为0。
反应的是master节点的压力，处理的队列情况。source列是原因
2.1.2：GET /_nodes/stats：查看节点索引性能状态
{
"_nodes" : {
"total" : 19, 节点总数
"successful" : 19, 成功响应请求的节点数
"failed" : 0 拒绝请求或未能响应的节点数。如果该值不是0，拒绝或失败的原因包含在响应中。
},
"cluster_name" : "elasticsearch_cluster",
"nodes" : { 所有节点的统计信息
"GVgVPeASRWuMJ6h8OKO5ZA" : {
"indices" : {
"docs" : {
"count" : 9508450846, 文档总数量。这不包括已删除的文档
"deleted" : 188210971 删除文档总数
},
"store" : {
"size_in_bytes" : 2842505065472 内存的总大小
},
"indexing" : {
"index_total" : 59153503, 索引请求操作的总数
"index_time_in_millis" : 13889650,执行索引操作所花费的总时间
},
"get" : {
},
"search" : {查询统计信息：节点启动到此查询消耗总时间， query_time_in_millis / query_total的比值可以作为你的查询效率的粗略指标。比值越大，每个查询用的时间越多，你就需要考虑调整或者优化。
"query_total" : 15232,
"query_time_in_millis" : 2302905,
},
"merges" : {包含lucene写入进行段合并的信息
},
"refresh" : {刷新操作的次数
"total" : 13977,
"total_time_in_millis" : 1460189,
"listeners" : 0
},
"flush" : {
"total" : 2930,
"periodic" : 34,
"total_time_in_millis" : 67473
}
"query_cache" : {
"memory_size_in_bytes" : 17219303,用于查询缓存的内存总量
},
"fielddata" : {fielddata字段数据缓存的统计信息
"memory_size_in_bytes" : 4906016,
"evictions" : 0
},
"completion" : {
"size_in_bytes" : 0
},
"segments" : {
"count" : 6801,段数
"memory_in_bytes" : 12687193943,用于片段的内存总量
},
"translog" : {事务日志操作的统计信息
"operations" : 11032999,
"size_in_bytes" : 9744209422,
"uncommitted_operations" : 3804322,
"uncommitted_size_in_bytes" : 3873738994,
"earliest_last_modified_age" : 0
}
},
"os" : {节点操作系统的统计信息
"timestamp" : 1599644486790,
"cpu" : {CPU使用情况的统计信息
"percent" : 1,
"load_average" : {负载平均
"1m" : 0.78,
"5m" : 1.38,
"15m" : 2.06
}
},
"mem" : {
"total_in_bytes" : 270098137088,物理内存总量
"free_in_bytes" : 896585728,)可用物理内存量
"used_in_bytes" : 269201551360,)已用物理内存量
"free_percent" : 0,可用内存的百分比
"used_percent" : 100
},
"swap" : {交换空间的统计信息
"total_in_bytes" : 0,
"free_in_bytes" : 0,
"used_in_bytes" : 0
}
},
"process" : {节点的进程统计信息
"timestamp" : 1599644486791,
"open_file_descriptors" : 2177,
"max_file_descriptors" : 640000,
"cpu" : {Java虚拟机的进程使用的CPU时间
"percent" : 0,
"total_in_millis" : 33154220
},
"mem" : {可用于运行进程的虚拟内存的字节大小
"total_virtual_in_bytes" : 2885923024896
}
},
"jvm" : {
"timestamp" : 1599644486792,
"uptime_in_millis" : 89623661,
"mem" : {
"heap_used_in_bytes" : 19226038952,)堆当前使用的内存
"heap_used_percent" : 57,
}
},
"thread_pool" : {线程池统计信息
},
"fs" : {文件存储统计信息
"timestamp" : 1599644486793,
"total" : {
"total_in_bytes" : 15996614082560,文件存储的总大小
"free_in_bytes" : 13144129576960,可用存储的总大小
"available_in_bytes" : 13144129576960
},
"data" : [
],
"io_stats" : {节点的输入/输出统计信息
}
}
}
}
refresh.total：总刷新计数。刷新总数的计数。
refresh.total_time_in_millis：刷新总时间。汇总所有花在刷新的时间（以毫秒为单位进行测量）。
merges.current_docs：目前的合并。合并目前正在处理中。
merges.total_docs：合并总数。合并总数的计数。
merges.total_stopped_time_in_millis。合并花费的总时间。合并段的所有时间的聚合
JVM模块运行的重要指标如下：
mem：内存使用情况。堆和非堆进程和池的使用情况统计信息。
threads：当前使用的线程和最大数量。
gc：垃圾收集。算和垃圾收集所花费的总时间。
2.2：ES的查询query命令使用
query查询官网介绍
ElasticSearch的DSL查询总结
2.3：ES的过滤器使用
2.2.1：bool布尔过滤器
must:要求所有条件都要满足（类似于&&）
should：任何一个满足就可以（类似于||）
must_not:所有条件都不能满足（类似于! (&&)）
以must作为例子，其余一样。
2.2.3:filter过滤器
filter和query并行度一直，等级一直
{
"query": {"match_all": {}},
"filter": {
"range": { "balance": { "gte":20000, "lte":30000 }
}
}
gte：大于等于
lte：小于等于
3：es的log日志文件
记录了集群运行和请求等的日志信息
1、Elasticsearch.log：集群主要运行日志
- 记录了Elasticsearch集群的健康状态以及在集群上执行的读写操作的信息。例如，写操作日志包括创建索引、索引映射更新、写全队列日志;读操作日志包括查询队列日志和查询异常日志。
参考2：https://www.alibabacloud.com/help/en/elasticsearch/latest/monitor-clusters-and-query-logs-query-logs
2、Elasticsearch_index_indexing_slowlog.log：慢索引日志
- 捕获那些超过指定时间阈值的查询和索引请求。这个日志用来追踪由用户产生的很慢的请求很有用。 默认情况，慢日志是不开启的。要开启它，需要定义具体动作（query，fetch 还是 index），你期望的事件记录等级（ WARN 、 DEBUG 等），以及时间阈值。
3、Elasticsearch_index_search_slowlog.log：慢搜索日志
- 捕获那些超过指定时间阈值的查询和索引请求。这个日志用来追踪由用户产生的很慢的请求很有用。 默认情况，慢日志是不开启的。要开启它，需要定义具体动作（query，fetch 还是 index），你期望的事件记录等级（ WARN 、 DEBUG 等），以及时间阈值。
4、Elasticsearch_access.log访问日志
- 记录了访问Elasticsearch集群的信息。Elasticsearch集群的访问日志包含所有查询请求的详细信息，例如uri、请求体的大小以及请求启动的时间。只能在Elasticsearch控制台中查看Elasticsearch V6.7.0和V7.10集群的访问日志。
5、Elasticsearch_audit.log审计日志
- 可以记录与安全相关的事件，例如身份验证失败和拒绝连接，以监视集群中的可疑活动(包括数据访问授权和用户安全配置更改)。审计日志还可以在发生攻击时提供取证证据。
6、Elasticsearch_deprecation.log：弃用日志
启用对已弃用的日志记录。例如，如果将来需要迁移某些功能，则可以提前确定。默认情况下，在WARN级别（在此级别，所有弃用日志消息都会被输出）启用弃用日志记录。
356
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
