Elasticsearch 监控和部署
Elasticsearch:
! [ https://elasticsearch.cn/book/elasticsearch_definitive_guide_2.x/_cluster_health.html ]
【监控】
server command：
1.集群健康 ：
a.health check --- command：GET _cluster/health
example:
{
"cluster_name": "elasticsearch_zach",
"status": "green",
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 10,
"active_shards": 10,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
}
b.issue example:
command：GET _cluster/health?level=indices
{
"cluster_name": "elasticsearch_zach",
"status": "red",
"timed_out": false,
"number_of_nodes": 8,
"number_of_data_nodes": 8,
"active_primary_shards": 90,
"active_shards": 180,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 20
"indices": {
"v1": {
"status": "green",
"number_of_shards": 10,
"number_of_replicas": 1,
"active_primary_shards": 10,
"active_shards": 20,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
},
"v2": {
"status": "red", -----------issue
"number_of_shards": 10,
"number_of_replicas": 1,
"active_primary_shards": 0,
"active_shards": 0,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 20 ----------issue
},
"v3": {
"status": "green",
"number_of_shards": 10,
"number_of_replicas": 1,
"active_primary_shards": 10,
"active_shards": 20,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
},
....
}
}
c.当构建单元和集成测试时，或者实现和 Elasticsearch 相关的自动化脚本时，
cluster-health API 还有另一个小技巧非常有用。你可以指定一个 wait_for_status 参数，
它只有在状态达标之后才会返回。比如：
command：GET _cluster/health?wait_for_status=green
2.单个节点统计：
a.GET _nodes/stats
在输出内容的开头，我们可以看到集群名称和我们的第一个节点：
{
"cluster_name": "elasticsearch_zach",
"nodes": {
"UNr6ZMf5Qk-YCPA_L18BOQ": {
"timestamp": 1408474151742,
"name": "Zach",
"transport_address": "inet[zacharys-air/192.168.1.131:9300]",
"host": "zacharys-air",
"ip": [
"inet[zacharys-air/192.168.1.131:9300]",
"NONE"
],
b.索引
c.操作系统和进程部分
CPU/负载/内存使用率/Swap 使用率/打开的文件描述符
d.线程池
e.文件系统和网络部分
f.断路器
3.集群统计
GET _cluster/stats
4.索引统计：
GET my_index/_stats
GET my_index,another_index/_stats
GET _all/_stats
统计 my_index 索引。
使用逗号分隔索引名可以请求多个索引统计值。
使用特定的 _all 可以请求全部索引的统计值
5.等待中任务：
GET _cluster/pending_tasks
6.cat API
a.GET /_cat
eg：GET /_cat
=^.^=
/_cat/allocation
/_cat/shards
/_cat/shards/{index}
/_cat/master
/_cat/nodes
/_cat/indices
/_cat/indices/{index}
/_cat/segments
/_cat/segments/{index}
/_cat/count
/_cat/count/{index}
/_cat/recovery
/_cat/recovery/{index}
/_cat/health
/_cat/pending_tasks
/_cat/aliases
/_cat/aliases/{alias}
/_cat/thread_pool
/_cat/plugins
/_cat/fielddata
/_cat/fielddata/{fields}
b.要启用表头，添加 ?v 参数即可：
GET /_cat/health?v
epoch time cluster status node.total node.data shards pri relo init
1408[..] 12[..] el[..] 1 1 114 114 0 0 114
unassign
【部署】
1.硬件/内存/CPU/硬盘/网络
2.Java虚拟机
3.Transport Client (传输客户端) 与 Node Client (节点客户端)
4.配置管理
elasticsearch.yml:
a.集群/节点
cluster.name: elasticsearch_production
node.name: elasticsearch_005_data
b.插件、日志以及你最重要的数据路径：
path.data: /path/to/data1,/path/to/data2
# Path to log files:
path.logs: /path/to/logs
# Path to where plugins are installed:
path.plugins: /path/to/plugins
c.最小主节点数：
minimum_master_nodes
eg：discovery.zen.minimum_master_nodes: 2
d.集群恢复方面设置：
keywords example:
gateway.recover_after_nodes: 8
gateway.expected_nodes: 10
gateway.recover_after_time: 5m
eg：
这意味着 Elasticsearch 会采取如下操作：
等待集群至少存在 8 个节点
等待 5 分钟，或者10 个节点上线后，才进行数据恢复，这取决于哪个条件先达到。
e.单播代替组播：
#discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]
5.[red]不要触碰的配置：
a.垃圾回收器
b.线程池
6.堆内存:大小(小于32GB)和交换
a.设置：
（1）指定 ES_HEAP_SIZE 环境变量或者用下面的命令设置它：export ES_HEAP_SIZE=10g
（2）此外，你也可以通过命令行参数的形式，在程序启动的时候把内存大小传递给它，
如果你觉得这样更简单的话：./bin/elasticsearch -Xmx10g -Xms10g
确保堆内存最小值（ Xms ）与最大值（ Xmx ）的大小是相同的，
防止程序在运行时改变堆内存大小， 这是一个很耗系统资源的过程。
b.内存的（少于）一半给 Lucene
Lucene 被设计为可以利用操作系统底层机制来缓存内存数据结构。
标准的建议是把 50％ 的可用内存作为 Elasticsearch 的堆内存.
c.性能优化：
禁用swapping：
1.临时：sudo swapoff -a
2.需要永久禁用，你可能需要修改 /etc/fstab 文件，这要参考你的操作系统相关文档。
3.降低 swappiness 的值：
对于大部分Linux操作系统，可以在 sysctl 中这样配置：
vm.swappiness = 1
4.需要打开配置文件中的 mlockall 开关。 它的作用就是允许 JVM 锁住内存，
禁止操作系统交换出去。在你的 elasticsearch.yml 文件中，设置如下：
bootstrap.mlockall: true
7.文件描述符和 MMap
a.GET /_nodes/process
{
"cluster_name": "elasticsearch__zach",
"nodes": {
"TGn9iO2_QQKb0kavcLbnDw": {
"name": "Zach",
"transport_address": "inet[/192.168.1.131:9300]",
"host": "zacharys-air",
"ip": "192.168.1.131",
"version": "2.0.0-SNAPSHOT",
"build": "612f461",
"http_address": "inet[/192.168.1.131:9200]",
"process": {
"refresh_interval_in_millis": 1000,
"id": 19808,
"max_file_descriptors": 64000, --------【显示 Elasticsearch 进程可以访问的可用文件描述符数量】
"mlockall": true
}
}
}
}
b.Elasticsearch 对各种文件混合使用了 NioFs（ 注：非阻塞文件系统）和
MMapFs （ 注：内存映射文件系统）。请确保你配置的最大映射数量，
以便有足够的虚拟内存可用于 mmapped 文件。这可以暂时设置：
sysctl -w vm.max_map_count=262144
或者你可以在 /etc/sysctl.conf 通过修改 vm.max_map_count 永久设置它。
【部署后】
1.动态变更设置
eg：
PUT /_cluster/settings
{
"persistent" : {
"discovery.zen.minimum_master_nodes" : --这个永久设置会在全集群重启时存活下来
},
"transient" : {
"indices.store.throttle.max_bytes_per_sec" : "50mb" --这个临时设置会在第一次全集群重启后被移除。
}
}
2.日志记录：
a.Elasticsearch 会输出很多日志，都放在 ES_HOME/logs 目录下
b.我们调高节点发现的日志记录级别：
PUT /_cluster/settings
{
"transient" : {
"logger.discovery" : "DEBUG"
}
}
c.慢日志：
PUT /my_index/_settings
{
"index.search.slowlog.threshold.query.warn" : "10s", 查询慢于 10 秒输出一个 WARN 日志。
"index.search.slowlog.threshold.fetch.debug": "500ms", 获取慢于 500 毫秒输出一个 DEBUG 日志
"index.indexing.slowlog.threshold.index.info": "5s" 索引慢于 5 秒输出一个 INFO 日志。
}
PUT /_cluster/settings
{
"transient" : {
"logger.index.search.slowlog" : "DEBUG", 设置搜索慢日志为 DEBUG 级别。
"logger.index.indexing.slowlog" : "WARN" 设置索引慢日志为 WARN 级别。
}
}
d.索引性能技巧:
(1)科学的测试性能
(2)使用批量请求并调整其大小
(3)存储
(4)段和合并
PUT /_cluster/settings
{
"persistent" : {
"indices.store.throttle.max_bytes_per_sec" : "100mb"
}
}
PUT /_cluster/settings
{
"transient" : {
"indices.store.throttle.type" : "none" 设置限流类型为 none 彻底关闭合并限流。等你完成了导入，记得改回 merge 重新打开限流。
}
}
如果你使用的是机械磁盘而非 SSD，你需要添加下面这个配置到你的 elasticsearch.yml 里：
index.merge.scheduler.max_thread_count: 1
(5)
其他
最后，还有一些其他值得考虑的东西需要记住：
如果你的搜索结果不需要近实时的准确度，考虑把每个索引的 index.refresh_interval 改到 30s 。如果你是在做大批量导入，导入期间你可以通过设置这个值为 -1 关掉刷新。别忘记在完工的时候重新开启它。
如果你在做大批量导入，考虑通过设置 index.number_of_replicas: 0关闭副本。文档在复制的时候，整个文档内容都被发往副本节点，然后逐字的把索引过程重复一遍。这意味着每个副本也会执行分析、索引以及可能的合并过程。
相反，如果你的索引是零副本，然后在写入完成后再开启副本，恢复过程本质上只是一个字节到字节的网络传输。相比重复索引过程，这个算是相当高效的了。
如果你没有给每个文档自带 ID，使用 Elasticsearch 的自动 ID 功能。 这个为避免版本查找做了优化，因为自动生成的 ID 是唯一的。
如果你在使用自己的 ID，尝试使用一种 Lucene 友好的 ID。包括零填充序列 ID、UUID-1 和纳秒；这些 ID 都是有一致的，压缩良好的序列模式。相反的，像 UUID-4 这样的 ID，本质上是随机的，压缩比很低，会明显拖慢 Lucene。
f.推迟分片分配
修改参数 delayed_timeout ，默认等待时间可以全局设置也可以在索引级别进行修改:
eg:PUT /_all/_settings 通过使用 _all 索引名，我们可以为集群里面的所有的索引使用这个参数
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "5m" 默认时间被修改成了 5 分钟
}
}
g.滚动重启
可能的话，停止索引新的数据。虽然不是每次都能真的做到，但是这一步可以帮助提高恢复速度。
禁止分片分配。这一步阻止 Elasticsearch 再平衡缺失的分片，直到你告诉它可以进行了。如果你知道维护窗口会很短，这个主意棒极了。你可以像下面这样禁止分配：
PUT /_cluster/settings
{
"transient" : {
"cluster.routing.allocation.enable" : "none"
}
}
关闭单个节点。
执行维护/升级。
重启节点，然后确认它加入到集群了。
用如下命令重启分片分配：
PUT /_cluster/settings
{
"transient" : {
"cluster.routing.allocation.enable" : "all"
}
}
分片再平衡会花一些时间。一直等到集群变成 绿色 状态后再继续。 to status green before continuing.
重复第 2 到 6 步操作剩余节点。
到这步你可以安全的恢复索引了（如果你之前停止了的话），不过等待集群完全均衡后再恢复索引，也会有助于提高处理速度。
h.备份集群: (https://elasticsearch.cn/book/elasticsearch_definitive_guide_2.x/backing-up-your-cluster.html)
使用 snapshot API
创建仓库:
PUT _snapshot/my_backup 给我们的仓库取一个名字，在本例它叫 my_backup 。
{
"type": "fs", 我们指定仓库的类型应该是一个共享文件系统。
"settings": {
"location": "/mount/backups/my_backup" 最后，我们提供一个已挂载的设备作为目的地址。
}
}
快照所有打开的索引
快照指定索引
列出快照相关的信息
删除快照
监控快照进度
取消一个快照
i.从快照恢复 (https://elasticsearch.cn/book/elasticsearch_definitive_guide_2.x/_restoring_from_a_snapshot.html#_restoring_from_a_snapshot)
