ansible 常用操作

Gitlab权限概念

用户具有不同的能力，具体取决于他们在特定组或项目中的访问级别。如果用户同时在组的项目和项目本身中，则使用最高权限级别。

在公共和内部项目中，不会强制实施Guest角色。所有用户都可以创建问题，发表评论，克隆或下载项目代码。

当成员离开团队时， 将自动取消分配所有分配的问题和合并请求。

GitLab 管理员获得所有权限。

Gitlab权限列表

这里要列一下权限分类，因为gitlab的成员权限不单单只有一种。

• 项目成员角色

• • Guest - 客人
  • Reporter - 记者
  • Developer - 开发者
  • Master (11.0版本中已重命名为 Maintainer) - 维护者
  • Owner - 所有者

• 组成员角色

• • Guest - 客人
  • Reporter - 记者
  • Developer - 开发者
  • Master (11.0版本中已重命名为 Maintainer) - 维护者
  • Owner - 维护者

• GitLab CI-CD 角色

• • Guest, Reporter - 客人，记者
  • Developer - 开发者
  • Maintainer - 维护者
  • Admin - 管理员

• 工作角色

• • Guest, Reporter - 客人，记者
  • Developer - 开发者
  • Maintainer - 维护者
  • Admin - 管理员

一般管理员邀请用户加入到项目里都需要分配权限，如下：

项目成员权限

注意：在GitLab 11.0中，Master已重命名为Maintainer。

组成员权限

GitLab CI / CD权限

工作权限

参考资料

https://docs.gitlab.com/ee/user/permissions.html

服务端钩子

https://github.com/geeeeeeeeek/git-recipes/wiki/5.4-Git-%E9%92%A9%E5%AD%90%EF%BC%9A%E8%87%AA%E5%AE%9A%E4%B9%89%E4%BD%A0%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%B5%81

https://www.git-scm.com/book/zh/v2/%E8%87%AA%E5%AE%9A%E4%B9%89-Git-Git-%E9%92%A9%E5%AD%90
hook可以分为客户端和服务端

这些钩子都允许你对 git push 的不同阶段做出响应。

• pre-receive
• update
• post-receive

修改custom_hooks_dir路径
vi /etc/gitlab/gitlab.rb

gitlab_shell['custom_hooks_dir'] = /opt/gitlab/embedded/service/gitlab-shell/custom_hooks
sudo gitlab-ctl reconfigure 
gitlab-ctl restart//重启gitlab

#!/bin/sh
read  new ref
log=$(git log -1 $ref )
em=${log#*<}
email=${em%>*}
temp=${log#*@}
email_suffix=${temp%>*}
if [ ${email_suffix} != 'qq.com' ];then
echo 'you commit code use email is: "'$email '" the suffix of this email  is :'${email_suffix}'
Email format error: "'$email'" is not  formal qq OA email
can not commit your code , unless follow these steps to modify your email to OA email
steps:1. git config --global  --replace-all user.email [email protected]
      2.  git commit --amend --author "xxx <[email protected]>" 
         (modify author email to OA email([email protected]) in your commit infos )
      3. :wq
 
attention: if your commit code use email is different from your OA email ([email protected]) ,your code will not statistical'
exit 1
        else
echo 'your email is OA email'
exit 0
fi

一、配置文件调优

elasticsearch.yml

内存锁定

bootstrap.memory_lock：true 锁定堆内存；

zen.discovery

ES是一个P2P类型的分布式系统，使用gossip协议，集群的任意请求都可以发送到集群的任一节点，然后es内部会找到需要转发的节点，并且与之进行通信。在es1.x的版本，es默认是开启组播，启动es之后，可以快速将局域网内集群名称，默认端口的相同实例加入到一个大的集群，后续再es2.x之后，都调整成了单播，避免安全问题和网络风暴；单播discovery.zen.ping.unicast.hosts，建议写入集群内所有的节点及端口，如果新实例加入集群，新实例只需要写入当前集群的实例，即可自动加入到当前集群，之后再处理原实例的配置即可，新实例加入集群，不需要重启原有实例；节点zen相关配置：discovery.zen.ping_timeout：判断master选举过程中，发现其他node存活的超时设置，主要影响选举的耗时，参数仅在加入或者选举 master 主节点的时候才起作用discovery.zen.join_timeout：节点确定加入到集群中，向主节点发送加入请求的超时时间，默认为3sdiscovery.zen.minimum_master_nodes：参与master选举的最小节点数，当集群能够被选为master的节点数量小于最小数量时，集群将无法正常选举。

故障检测（ fault detection ）

两种情况下回进行故障检测，第一种是由master向集群的所有其他节点发起ping，验证节点是否处于活动状态；第二种是：集群每个节点向master发起ping，判断master是否存活，是否需要发起选举。故障检测需要配置以下设置使用形如：discovery.zen.fd.ping_interval 节点被ping的频率，默认为1s。discovery.zen.fd.ping_timeout 等待ping响应的时间，默认为 30s，运行的集群中，master 检测所有节点，以及节点检测 master 是否正常。discovery.zen.fd.ping_retries ping失败/超时多少导致节点被视为失败，默认为3。

https://www.elastic.co/guide/en/elasticsearch/reference/6.x/modules-discovery-zen.html

队列数量

不建议盲目加大es的队列数量，如果是偶发的因为数据突增，导致队列阻塞，加大队列size可以使用内存来缓存数据，如果是持续性的数据阻塞在队列，加大队列size除了加大内存占用，并不能有效提高数据写入速率，反而可能加大es宕机时候，在内存中可能丢失的上数据量。哪些情况下，加大队列size呢？GET /_cat/thread_pool，观察api中返回的queue和rejected，如果确实存在队列拒绝或者是持续的queue，可以酌情调整队列size。

https://www.elastic.co/guide/en/elasticsearch/reference/6.x/modules-threadpool.html

内存使用

设置indices的内存熔断相关参数，根据实际情况进行调整，防止写入或查询压力过高导致OOM，indices.breaker.total.limit: 50%，集群级别的断路器，默认为jvm堆的70%；indices.breaker.request.limit: 10%，单个request的断路器限制，默认为jvm堆的60%；indices.breaker.fielddata.limit: 10%，fielddata breaker限制，默认为jvm堆的60%。

https://www.elastic.co/guide/en/elasticsearch/reference/6.x/circuit-breaker.html

根据实际情况调整查询占用cache，避免查询cache占用过多的jvm内存，参数为静态的，需要在每个数据节点配置。indices.queries.cache.size: 5%，控制过滤器缓存的内存大小，默认为10%。接受百分比值，5%或者精确值，例如512mb。

https://www.elastic.co/guide/en/elasticsearch/reference/6.x/query-cache.html

创建shard

如果集群规模较大，可以阻止新建shard时扫描集群内全部shard的元数据，提升shard分配速度。cluster.routing.allocation.disk.include_relocations: false，默认为true。

https://www.elastic.co/guide/en/elasticsearch/reference/6.x/disk-allocator.html

二、系统层面调优

jdk版本

当前根据官方建议，选择匹配的jdk版本；

jdk内存配置

首先，-Xms和-Xmx设置为相同的值，避免在运行过程中再进行内存分配，同时，如果系统内存小于64G，建议设置略小于机器内存的一半，剩余留给系统使用。同时，jvm heap建议不要超过32G（不同jdk版本具体的值会略有不同），否则jvm会因为内存指针压缩导致内存浪费，详见：https://www.elastic.co/guide/cn/elasticsearch/guide/current/heap-sizing.html

交换分区

关闭交换分区，防止内存发生交换导致性能下降（部分情况下，宁死勿慢）swapoff -a

文件句柄

Lucene 使用了 大量的 文件。 同时，Elasticsearch 在节点和 HTTP 客户端之间进行通信也使用了大量的套接字，所有这一切都需要足够的文件描述符，默认情况下，linux默认运行单个进程打开1024个文件句柄，这显然是不够的，故需要加大文件句柄数ulimit -n 65536

https://www.elastic.co/guide/en/elasticsearch/reference/6.5/setting-system-settings.html

mmap

Elasticsearch 对各种文件混合使用了 NioFs（ 注：非阻塞文件系统）和 MMapFs （ 注：内存映射文件系统）。请确保你配置的最大映射数量，以便有足够的虚拟内存可用于 mmapped 文件。这可以暂时设置：sysctl -w vm.max_map_count=262144或者你可以在 /etc/sysctl.conf 通过修改 vm.max_map_count 永久设置它。

https://www.elastic.co/guide/cn/elasticsearch/guide/current/_file_descriptors_and_mmap.html

磁盘

如果你正在使用 SSDs，确保你的系统 I/O 调度程序是配置正确的。 当你向硬盘写数据，I/O 调度程序决定何时把数据实际发送到硬盘。 大多数默认 nix 发行版下的调度程序都叫做 cfq**（完全公平队列）。但它是为旋转介质优化的： 机械硬盘的固有特性意味着它写入数据到基于物理布局的硬盘会更高效。这对 SSD 来说是低效的，尽管这里没有涉及到机械硬盘。但是，deadline 或者 noop 应该被使用。deadline 调度程序基于写入等待时间进行优化， noop 只是一个简单的 FIFO 队列。echo noop > /sys/block/sd/queue/scheduler

磁盘挂载

mount -o noatime,data=writeback,barrier=0,nobh /dev/sd* /esdata*其中，noatime，禁止记录访问时间戳；data=writeback，不记录journal；barrier=0，因为关闭了journal，所以同步关闭barrier；nobh，关闭buffer_head，防止内核影响数据IO

磁盘其他注意事项

使用 RAID 0。条带化 RAID 会提高磁盘I/O，代价显然就是当一块硬盘故障时整个就故障了，不要使用镜像或者奇偶校验 RAID 因为副本已经提供了这个功能。另外，使用多块硬盘，并允许 Elasticsearch 通过多个 path.data 目录配置把数据条带化分配到它们上面。不要使用远程挂载的存储，比如 NFS 或者 SMB/CIFS。这个引入的延迟对性能来说完全是背道而驰的。

三、elasticsearch使用方式调优

当elasticsearch本身的配置没有明显的问题之后，发现es使用还是非常慢，这个时候，就需要我们去定位es本身的问题了，首先祭出定位问题的第一个命令：

hot_threads

GET /_nodes/hot_threads&interval=30s

抓取30s的节点上占用资源的热线程，并通过排查占用资源最多的TOP线程来判断对应的资源消耗是否正常，一般情况下，bulk，search类的线程占用资源都可能是业务造成的，但是如果是merge线程占用了大量的资源，就应该考虑是不是创建index或者刷磁盘间隔太小，批量写入size太小造成的。

https://www.elastic.co/guide/en/elasticsearch/reference/6.x/cluster-nodes-hot-threads.html

pending_tasks

GET /_cluster/pending_tasks

有一些任务只能由主节点去处理，比如创建一个新的 索引或者在集群中移动分片，由于一个集群中只能有一个主节点，所以只有这一master节点可以处理集群级别的元数据变动。在99.9999%的时间里，这不会有什么问题，元数据变动的队列基本上保持为零。在一些罕见的集群里，元数据变动的次数比主节点能处理的还快，这会导致等待中的操作会累积成队列。这个时候可以通过pending_tasks api分析当前什么操作阻塞了es的队列，比如，集群异常时，会有大量的shard在recovery，如果集群在大量创建新字段，会出现大量的put_mappings的操作，所以正常情况下，需要禁用动态mapping。

https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-pending.html

字段存储

当前es主要有doc_values，fielddata，storefield三种类型，大部分情况下，并不需要三种类型都存储，可根据实际场景进行调整：当前用得最多的就是doc_values，列存储，对于不需要进行分词的字段，都可以开启doc_values来进行存储（且只保留keyword字段），节约内存，当然，开启doc_values会对查询性能有一定的影响，但是，这个性能损耗是比较小的，而且是值得的；

fielddata构建和管理 100% 在内存中，常驻于 JVM 内存堆，所以可用于快速查询，但是这也意味着它本质上是不可扩展的，有很多边缘情况下要提防，如果对于字段没有分析需求，可以关闭fielddata；

storefield主要用于_source字段，默认情况下，数据在写入es的时候，es会将doc数据存储为_source字段，查询时可以通过_source字段快速获取doc的原始结构，如果没有update，reindex等需求，可以将_source字段disable；

_all，ES在6.x以前的版本，默认将写入的字段拼接成一个大的字符串，并对该字段进行分词，用于支持整个doc的全文检索，在知道doc字段名称的情况下，建议关闭掉该字段，节约存储空间，也避免不带字段key的全文检索；

norms：搜索时进行评分，日志场景一般不需要评分，建议关闭；

tranlog

Elasticsearch 2.0之后为了保证不丢数据，每次 index、bulk、delete、update 完成的时候，一定触发刷新 translog 到磁盘上，才给请求返回 200 OK。这个改变在提高数据安全性的同时当然也降低了一点性能。如果你不在意这点可能性，还是希望性能优先，可以在 index template 里设置如下参数：

{ “index.translog.durability”: “async”}

index.translog.sync_interval：对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群，使用异步的 fsync 还是比较有益的。比如，写入的数据被缓存到内存中，再每5秒执行一次 fsync ，默认为5s。小于的值100ms是不允许的。index.translog.flush_threshold_size：translog存储尚未安全保存在Lucene中的所有操作。虽然这些操作可用于读取，但如果要关闭并且必须恢复，则需要重新编制索引。此设置控制这些操作的最大总大小，以防止恢复时间过长。达到设置的最大size后，将发生刷新，生成新的Lucene提交点，默认为512mb。

refresh_interval

执行刷新操作的频率，这会使索引的最近更改对搜索可见，默认为1s，可以设置-1为禁用刷新，对于写入速率要求较高的场景，可以适当的加大对应的时长，减小磁盘io和segment的生成；

禁止动态mapping

动态mapping的坏处：1.造成集群元数据一直变更，导致集群不稳定；2.可能造成数据类型与实际类型不一致；3.对于一些异常字段或者是扫描类的字段，也会频繁的修改mapping，导致业务不可控。动态mapping配置的可选值及含义如下：true：支持动态扩展，新增数据有新的字段属性时，自动添加对于的mapping，数据写入成功false：不支持动态扩展，新增数据有新的字段属性时，直接忽略，数据写入成功strict：不支持动态扩展，新增数据有新的字段时，报错，数据写入失败

批量写入

批量请求显然会大大提升写入速率，且这个速率是可以量化的，官方建议每次批量的数据物理字节数5-15MB是一个比较不错的起点，注意这里说的是物理字节数大小。文档计数对批量大小来说不是一个好指标。比如说，如果你每次批量索引 1000 个文档，记住下面的事实：1000 个 1 KB 大小的文档加起来是 1 MB 大。1000 个 100 KB 大小的文档加起来是 100 MB 大。这可是完完全全不一样的批量大小了。批量请求需要在协调节点上加载进内存，所以批量请求的物理大小比文档计数重要得多。从 5–15 MB 开始测试批量请求大小，缓慢增加这个数字，直到你看不到性能提升为止。然后开始增加你的批量写入的并发度（多线程等等办法）。用iostat 、 top 和 ps 等工具监控你的节点，观察资源什么时候达到瓶颈。如果你开始收到 EsRejectedExecutionException ，你的集群没办法再继续了：至少有一种资源到瓶颈了。或者减少并发数，或者提供更多的受限资源（比如从机械磁盘换成 SSD），或者添加更多节点。

索引和shard

es的索引，shard都会有对应的元数据，且因为es的元数据都是保存在master节点，且元数据的更新是要hang住集群向所有节点同步的，当es的新建字段或者新建索引的时候，都会要获取集群元数据，并对元数据进行变更及同步，此时会影响集群的响应，所以需要关注集群的index和shard数量，建议如下：1.使用shrink和rollover api，相对生成合适的数据shard数；2.根据数据量级及对应的性能需求，选择创建index的名称，形如：按月生成索引：test-YYYYMM，按天生成索引：test-YYYYMMDD；3.控制单个shard的size，正常情况下，日志场景，建议单个shard不大于50GB，线上业务场景，建议单个shard不超过20GB；

segment merge

段合并的计算量庞大， 而且还要吃掉大量磁盘 I/O。合并在后台定期操作，因为他们可能要很长时间才能完成，尤其是比较大的段。这个通常来说都没问题，因为大规模段合并的概率是很小的。如果发现merge占用了大量的资源，可以设置：index.merge.scheduler.max_thread_count: 1特别是机械磁盘在并发 I/O 支持方面比较差，所以我们需要降低每个索引并发访问磁盘的线程数。这个设置允许 max_thread_count + 2 个线程同时进行磁盘操作，也就是设置为 1 允许三个线程。对于 SSD，你可以忽略这个设置，默认是 Math.min(3, Runtime.getRuntime().availableProcessors() / 2) ，对 SSD 来说运行的很好。业务低峰期通过force_merge强制合并segment，降低segment的数量，减小内存消耗；关闭冷索引，业务需要的时候再进行开启，如果一直不使用的索引，可以定期删除，或者备份到hadoop集群；

自动生成_id

当写入端使用特定的id将数据写入es时，es会去检查对应的index下是否存在相同的id，这个操作会随着文档数量的增加而消耗越来越大，所以如果业务上没有强需求，建议使用es自动生成的id，加快写入速率。

routing

对于数据量较大的业务查询场景，es侧一般会创建多个shard，并将shard分配到集群中的多个实例来分摊压力，正常情况下，一个查询会遍历查询所有的shard，然后将查询到的结果进行merge之后，再返回给查询端。此时，写入的时候设置routing，可以避免每次查询都遍历全量shard，而是查询的时候也指定对应的routingkey，这种情况下，es会只去查询对应的shard，可以大幅度降低合并数据和调度全量shard的开销。

使用alias

生产提供服务的索引，切记使用别名提供服务，而不是直接暴露索引名称，避免后续因为业务变更或者索引数据需要reindex等情况造成业务中断。

避免宽表

在索引中定义太多字段是一种可能导致映射爆炸的情况，这可能导致内存不足错误和难以恢复的情况，这个问题可能比预期更常见，index.mapping.total_fields.limit ，默认值是1000

避免稀疏索引

因为索引稀疏之后，对应的相邻文档id的delta值会很大，lucene基于文档id做delta编码压缩导致压缩率降低，从而导致索引文件增大，同时，es的keyword，数组类型采用doc_values结构，每个文档都会占用一定的空间，即使字段是空值，所以稀疏索引会造成磁盘size增大，导致查询和写入效率降低。

通过配置Monitoring监控日志
您可以查看阿里云Elasticsearch（简称ES）实例的监控日志并配置监控索引，避免因监控日志占用空间过大而影响实例的正常使用。

背景信息

默认情况下，X-Pack监控客户端会每隔10s采集一次集群的监控信息，并保存到对应阿里云ES实例的以.monitoring-*为前缀的索引中。
目前主要有.monitoring-es-6-*和.monitoring-kibana-6-*这两种索引，以天为单位滚动创建。采集完的信息会保存在以.monitoring-es-6-为前缀，以当前日期为后缀的索引中。
其中.monitoring-es-6-*索引占用磁盘空间较大，主要存放了集群状态、集群统计、节点统计、索引统计等信息。

操作步骤

系统默认保留最近7天的监控索引，此类监控索引（.monitoring-es-6-*）会占用阿里云ES实例的存储空间。索引的大小与实例中的索引个数（包含系统索引）和节点个数有关系。为了避免实例的大部分空间被监控索引占用，可通过以下两种方式进行优化（实际使用中，可以将以上两种方案结合使用）

• 设置监控索引的保留天数。可以按照需求自定义监控索引的保留天数，最少保留一天。

  PUT _cluster/settings
  {"persistent": {"xpack.monitoring.history.duration":"1d"}}

• 设置需要采集的监控索引。
  通过调用API设置哪些索引需要监控以及哪些索引不需要监控，以减少.monitoring-es-6-*索引所占用的磁盘空间。以下命令以禁掉采集系统索引为例。

  PUT _cluster/settings
  {"persistent": {"xpack.monitoring.collection.indices": "*,-.*"}}

说明 禁掉的索引监控信息将不会在Kibana控制台的Montioring页面（索引列表及索引监控信息页面）中显示。但是会在GET _cat/indices获取的索引列表中显示，并且可查看索引的状态是open还是close。

ES failed shard on node[XXX]: failed recovery, failure RecoveryFailedException

原因是：某节点上的分片尝试恢复5次没有成功，然后就丢弃不管。导致该分片无法恢复。

解决办法：重新恢复失败的分片，一会集群就恢复为green
POST /_cluster/reroute?retry_failed=true

es 剩余磁盘空间达到es最小值，添加数据被block

剩余磁盘空间达到es最小值，添加数据被block

查看集群索引是否依然为read_only状态，如果是请执行以下命令，将集群中所有索引的index.blocks.read_only_allow_delete属性设置为null，使集群中不再存在read_only状态的索引。

PUT _all/_settings
{"index.blocks.read_only_allow_delete": null}

删除单个index全部内容，或删除无用的索引
DELETE /new_listings_investment
{ "query": { "match_all": {} } }

若集群是否依然为Red状态，执行以下命令，查看集群中是否存在未分配的分片。
_cat/allocation?v

如果存在未分配的分片，执行以下命令，查看未分配分片的原因。
GET _cluster/allocation/explain

如果使用 ES 的默认设置，ES 为了保持节点可用，设置了几个存储的安全值。分别为：

cluster.routing.allocation.disk.watermark.low: 默认 85% 当达到时，replica 不再写入 .导致新的分片无法分配。
cluster.routing.allocation.disk.watermark.high: 默认 90%. 当达到时Elasticsearch会尝试将对应节点中的分片迁移到其他磁盘使用率比较低的数据节点中
cluster.routing.allocation.disk.watermark.flood_stage: 默认 95% 系统会对Elasticsearch集群中的每个索引强制设置read_only_allow_delete属性，此时索引将无法写入数据，只能读取和删除对应索引

1、vim /etc/security/limits.conf

*   soft    nofile     65536
*   hard   nofile     65536

#number of threads

*   soft     nproc     64000
*   hard    nproc    64000

vim /etc/security/limits.d/20-nproc.conf

(处理max number of threads [3885] for user [elk] is too low, increase to at least [4096])

*     soft  nproc   10240
*     hard  nproc   10240

2、关闭交换分区

swapoff -a

注释掉/etc/fstab中有swap的一行，

或者在/etc/sysctl.conf中添加 vm.swappiness=1。

3、Enable bootstrap.memory_lock

vim $ES_HOME/config/elasticsearch.yml

bootstrap.memory_lock: true

添加/etc/security/limits.conf

* hard memlock unlimited * soft memlock unlimited

vim /etc/systemd/system.conf

DefaultLimitNOFILE=65536 DefaultLimitNPROC=32000 DefaultLimitMEMLOCK=infinity

/bin/systemctl daemon-reload

4、虚拟内存的配置

sysctl -w vm.max_map_count=262144

并在/etc/sysctl.conf中添加

echo  "vm.max_map_count=262144">>/etc/sysctl.conf

sysctl -p

常见报错：

ERROR: [2] bootstrap checks failed

[1]: max file descriptors [65535] for elasticsearch process is too low, increase to at least [65536]

[2]: memory locking requested for elasticsearch process but memory is not locked

vim /etc/security/limits.conf

*   soft    nofile     65536
*   hard   nofile     65536

vim /etc/security/limits.conf

* soft memlock unlimited
* hard memlock unlimited

elastic 系统初始化脚本

#!/bin/bash
#elasticsearch安装系统配置初始化脚本
esuser=elasitc
create_user() {
if ! grep "^$esuser:" /etc/passwd ; then
	useradd $esuser
	echo "$esuser" | passwd "$esuser" --stdin &>/dev/null
	check_ok
else
	echo $esuser already exist!
fi
}


set_system() {
cat >> /etc/security/limits.conf << EOF
#max open files
*   soft    nofile     65536
*   hard    nofile     65536
#number of threads	
*   soft    nproc    64000
*   hard    nproc    64000
*   soft    memlock unlimited
*   hard    memlock unlimited
EOF

# 配置最大虚拟内存
cat >> /etc/sysctl.conf << EOF
vm.max_map_count=262144
EOF
# 生效
sysctl -p


cat >> /etc/systemd/system.conf << EOF
DefaultLimitNOFILE=65536
DefaultLimitNPROC=32000
DefaultLimitMEMLOCK=infinity
EOF
/bin/systemctl daemon-reload

#关闭swap
swapoff -a
sed -i 's/^[^#].*swap/#&/' /etc/fstab

}


create_user
set_system

快照备份

创建仓库

PUT _snapshot/my_backup 
{
    "type": "fs", 
    "settings": {
        "location": "/mount/backups/my_backup" 
    }
}

• 1、给我们的仓库取一个名字my_backup。
• 2、我们指定仓库的类型应该是一个共享文件系统。比如nfs共享，挂载在/mount/backups/my_backup
• 3、最后，我们提供一个已挂载的设备作为目的地址。
• 4、其他的配置

  max_snapshot_bytes_per_sec

  当快照数据进入仓库时，这个参数控制这个过程的限流情况。默认是每秒 20mb 。

  max_restore_bytes_per_sec

  当从仓库恢复数据时，这个参数控制什么时候恢复过程会被限流以保障你的网络不会被占满。默认是每秒 20mb。

  POST _snapshot/my_backup/ 
  {
      "type": "fs",
      "settings": {
          "location": "/mount/backups/my_backup",
          "max_snapshot_bytes_per_sec" : "50mb", 
          "max_restore_bytes_per_sec" : "50mb"
      }
  }

  注意我们用的是 POST 而不是 PUT 。这会更新已有仓库的设置。
  然后添加我们的新设置。

快照所有打开的索引

PUT _snapshot/my_backup/snapshot_1

份所有打开的索引到 my_backup 仓库下 snapshot_1 的快照里

快照指定索引

这个快照命令现在只会备份 index1 和 index2 了。

PUT _snapshot/my_backup/snapshot_2
{
    "indices": "index_1,index_2"
}

列出快照相关的信息

列出快照snapshot_2的信息

GET _snapshot/my_backup/snapshot_2

获取my_backup仓库下所有的快照信息

GET _snapshot/my_backup/_all

删除快照

删除snapshot_2快照

DELETE _snapshot/my_backup/snapshot_2

监控快照进度

GET _snapshot/my_backup/snapshot_2/_status

取消一个快照

DELETE _snapshot/my_backup/snapshot_2

从快照恢复

将snapshot_1恢复。

POST _snapshot/my_backup/snapshot_1/_restore

默认行为是把这个快照里存有的所有索引都恢复，也可以指定这个快照中的具体索引进行恢复。

恢复snapshot_1快照中的index_1索引，并重命名为restored_index_1

POST /_snapshot/my_backup/snapshot_1/_restore
{
    "indices": "index_1", 
    "rename_pattern": "index_(.+)", 
    "rename_replacement": "restored_index_$1" 
}

- 只恢复 index_1 索引，忽略快照中存在的其余索引。
- 查找所提供的模式能匹配上的正在恢复的索引。
- 然后把它们重命名成替代的模式。

监控恢复操作

GET restored_index_3/_recovery

或者查看你集群里所有索引，可能包括跟你的恢复进程无关的其他分片移动：

GET /_recovery/

取消一个恢复

要取消一个恢复，你需要删除正在恢复的索引。因为恢复进程其实就是分片恢复，发送一个 删除索引 API 修改集群状态，就可以停止恢复进程。比如：

DELETE /restored_index_3

如果 restored_index_3 正在恢复中，这个删除命令会停止恢复，同时删除所有已经恢复到集群里的数据。

运维工具

ElasticHQ：https://github.com/ElasticHQ/elasticsearch-HQ

celebro

kibana

迁移工具

elasticsearch-migration

github：https://github.com/medcl/esm-v1

elasticsearch-dump：

github ：https://github.com/taskrabbit/elasticsearch-dump

bigdesk：https://github.com/lukas-vlcek/bigdesk

Elasticsearch-Exporter

logstash

官网

logstash :https://www.elastic.co/guide/en/logstash/7.2/index.html

kibana :https://www.elastic.co/guide/en/kibana/7.2/index.html

elastic :https://www.elastic.co/guide/en/elasticsearch/reference/7.2/index.html

filebeat :https://www.elastic.co/guide/en/beats/filebeat/7.2/index.html