本篇不详写prometheus、grafana的搭建，需要可以翻阅linux监控篇
ElasticSearch入门篇
一、监控
- docker-compose.yml
elasticsearch_exporter: #监控
image: quay.io/prometheuscommunity/elasticsearch-exporter:v1.3.0
command:
- '--es.uri=http://elasticsearch:9200'
- '--es.all'
- '--es.indices'
- '--es.indices_settings'
- '--es.indices_mappings'
- '--es.shards'
- '--es.snapshots'
- '--es.timeout=30s'
restart: always
ports:
- "9114:9114
参数说明
–es.uri
默认http://localhost:9200，连接到的Elasticsearch节点的地址（主机和端口）, 这可以是本地节
点（例如localhost：9200），也可以是远程Elasticsearch服务器的地址
–es.all
默认flase，如果为true，则查询集群中所有节点的统计信息，而不仅仅是查询我们连接到的节点。
–es.cluster_settings
默认flase，如果为true，请在统计信息中查询集群设置
–es.indices
默认flase，如果为true，则查询统计信息以获取集群中的所有索引。
–es.indices_settings
默认flase，如果为true，则查询集群中所有索引的设置统计信息。
–es.shards
默认flase，如果为true，则查询集群中所有索引的统计信息，包括分片级统计信息（意味着es.indices
= true）。
–es.snapshots
默认flase，如果为true，则查询集群快照的统计信息。
docker compose up -d
- prometheus.yml
- job_name: 'es-export'
static_configs:
- targets: ['xxxxxxx:9114']
- http://ip:9114/metrics
- grafana ：模版id：6483
二、优化
2.1 优化策略
在搜索引擎的业务场景下，用户一般并不需要那么高的写入实时性。比如你在网站发布一条征婚信息，或者二手交易平台发布一个商品信息。其他人并不是马上能搜索到的，这其实也是正常的处理逻辑。这个延时的过程需要处理很多事情，业务层面比如：你的信息需要后台审核。你发布的内容在搜索服务中需要建立索引，而且你的数据可能并不会马上被写入索引，而是等待要写入的数据达到一定数量之后，批量写入。这种操作优点类似于我们快递物流的场景，只有当快递数量达到一定量级的时候，比如能装满整个车的时候，快递车才会发车。因为反正是要跑一趟，装的越多，平均成本越低。这和我们数据写入到磁盘的过程是非常相似的，我们可以把一条文档数据看做是一个快递，而快递车每次发车就是向磁盘写入数据的一个过程。这个过程不宜太多，太多只会降低性能，就是体现在运输成本上面。而对于我们数据写入而言就是体现在我们硬件性能损耗上面。
ES 数据写入具有一定的延时性，这是为了减少频繁的索引文件产生。默认情况下 ES 每秒生成一个segment 文件，当达到一定阈值的时候 会执行merge（合并），merge 过程发生在 JVM中，频繁的生成segment 文件可能会导致频繁的触发 FGC，导致 OOM。为了避免这种情况，通常采取的手段是降低segment 文件的生成频率，手段有两个，一个是 增加时间阈值，另一个是增大 Buffer的空间阈值，因为缓冲区写满也会生成 Segment 文件。
2.2 优化手段
1、增加refresh_interval的参数值
- 默认情况下，Elasticsearch 每秒定期刷新索引， es支持近实时原因
- 如果没有搜索流量或搜索流量很少（例如每 5 分钟不到一个搜索请求）并且想要优化索引写入效率，时间建议加大
PUT /{index}/_settings
{
"refresh_interval": "30s"
}
2、增加Buffer大小
- 本质也是减小refresh的时间间隔，因为导致segment文件创建的原因不仅有时间阈值，还有buffer空间大小，写满了也会创建。
最小值 48MB< 默认值 JVM 空间的10% < 默认最大无限制
indices.memory.index_buffer_size
- elasticsearch.ym配置项indices.memory.index_buffer_size是es写入buffer缓存，默认是jvm heap的10%，设置的这个index buffer大小，是所有的shard公用的，也就是shard越多，每个shard分配的memory就会越少，一般建议，但是对于每个shard来说，最多给512mb，因为再大性能就没什么提升了（主要是segment的大小）
3、关闭Disable swapping
https://blog.csdn.net/wang7075202/article/details/111031589
4、内存问题
在 elasticsearch\config 目录下，有三个核心的配置文件：
- elasticsearch.yml，es相关的配置
- jvm.options，Java jvm相关参数的配置
内存设置
5、熔断保护机制
elasticsearch.yml
# 避免发生OOM，发生OOM对集群影响很大的
indices.breaker.total.limit: 80%
# 有了这个设置，最久未使用（LRU）的 fielddata 会被回收为新数据腾出空间
indices.fielddata.cache.size: 10%
# fielddata 断路器默认设置堆的 作为 fielddata 大小的上限。
indices.breaker.fielddata.limit: 60%
# request 断路器估算需要完成其他请求部分的结构大小，例如创建一个聚合桶，默认限制是堆内存
indices.breaker.request.limit: 60%
6、重启或者手工清理
POST {idnex}/_cache/clear
7、按照年月日建索引
三、jmeter-ES
Content-Type:application/json
1. 插入数据
2. 查询数据
