对应7.10官方文档路径：Monitor a cluster
官方地址如下：
https://www.elastic.co/guide/en/elasticsearch/reference/7.10/monitor-elasticsearch-cluster.html

Elastic Stack监控功能是对es群集的运行状况和健康情况的持续关注。本单元共分八个章节，如下：

• 总览
• 监控功能如何工作
• 在生产环境中进行监控
• 使用Metricbeat收集监视数据
• 使用Filebeat收集日志数据
• 配置用于监控的索引
• 旧版收集监控数据方法(6.5以后建议使用Metricbeat收集,但目前(7.10)为止，metricbeat收集数据维度相比旧版本较小)
• 故障排除

1 Monitoring总览

当监控一个集群，你从集群中的ELKB节点实例上收集数据。你也可以使用Filebeat收集es日志数据。
所有的监控指标都存储在es里面，这样你可以很容易使用kibana可视化数据，默认数据会存在本地索引中。

注：在生产环境中，我们强烈建议使用单独的es集群用来存储监控数据。使用单独的监控集群可以使你在生产集群中断时仍能访问监控数据，同时也可以防止监控活动影响生产集群的性能。同样我们也建议使用单独的kibana实例来查看监控数据。

你可以使用Metricbeat收集和传送ELKB的监控数据到监控集群而不是通过生产集群路由。一个典型的Monitoring体系结构如下图示(其中包含独立的生产和监控集群)：

monitoring体系
如果您具有适当的许可证，则可以将数据从多个生产群集路由到单个监视群集(收费)。
注：通常，监视群集和被监视的群集应运行相同版本的组件。监视群集无法监视运行较新版本组件的生产群集。如有必要，监视集群可以监视运行之前主版本的最新版本的生产集群。

2 Monitoring如何工作

每个ELKB节点或实例在集群中都是唯一的，它们都有一个永久的UUID，在节点实例启动的时候就写入了path.data目录。
Monitoring文档就是以指定的收集间隔监控每个Elastic Stack组件而构建的普通JSON文档。如果要更改这些存储监控数据的索引的模板，请参阅第六章节-配置存储Monitoring数据的索引。
Metricbeat用于收集监控数据并将其直接传送到监视群集。
要了解如何收集监视数据，请参阅：

• 第七章节
• 第四章节
• Kibana官方文档monitoring单元
• Logstash官方文档Monitoring单元
• Beats家族的官方文档
  • Auditbeat
  • Filebeat
  • Functionbeat
  • Heartbeat
  • Metricbeat
  • Packetbeat
  • Winlogbeat

3 生产环境中的Monitoring

在生产环境中，你应该将监控数据发送到独立的监控集群，这样即便你监控的节点离线了历史监控数据也可用。例如，你可以使用Metricbeat将ELKB的监控数据发送到监控集群。
注：Metricbeat是收集传送监控数据的推荐方式。如果你目前使用的是旧版本的collection方式，建议切换到Metricbeat。二者选其一，不可同时使用。Metricbeat方式具体参考下一章节。
如果你具有黄金版本以上订阅，则使用专用的监视群集还可以使你从中心位置监控多个群集(收费)。
如何将监控数据存储到独立集群：

1. 设置要用作监控的es群集。例如，可以使用节点es-mon-1和es-mon-2设置一个双主机集群。
   注：理想情况下，生产监控集群版本一致，最新版的7.X监控集群可以用于最新版7.X生产集群，也可以用于最新版6.X生产集群。
   监控集群中至少有一个ingest node，但不必是专用的ingest node。
   1.1 (可选)验证是否禁用了监视群集上的监视数据收集功能，默认xpack.monitoring.collection.enabled设置为false。
   你可以使用以下API检查修改设置：

   GET _cluster/settings
   PUT _cluster/settings
   {
     "persistent": {
       "xpack.monitoring.collection.enabled": false
     }
   }
   

   1.2 如果在监控群集上启用了es的security功能，请创建可以发送和检索监控数据的用户。
   注：如果计划使用Kibana查看监控数据，则用户名和密码在Kibana服务器和monitor群集上都必须有效。
   • 如果您打算使用Metricbeat收集Elasticsearch或Kibana的数据，请创建一个具有内置角色remote_monitoring_collector的用户和一个具有内置角色remote_monitoring_agent 的用户。或者使用内置用户remote_monitoring_user。
   • 如果您打算使用HTTP exporters路由生产集群的数据，请创建一个具有内置角色remote_monitoring_agent 的用户。
     例如，以下请求创建了一个具有remote_monitoring_agent角色的用户remote_monitor：

     POST /_security/user/remote_monitor
     {
       "password" : "changeme",
       "roles" : [ "remote_monitoring_agent"],
       "full_name" : "Internal Agent For Remote Monitoring"
     }
     

     或者，使用remote_monitoring_user 内置用户。
2. 配置你的es生产集群收集和发送数据到监控集群
   • Metricbeat方式(第四章节)
   • 旧版本collection方式(第七章节)
3. (可选)配置Logstash开启监控，具体查看其官网montior单元
4. (可选)配置Beats开启监控，具体查看其官网montior单元
5. (可选)配置Kibana开启监控，具体查看其官网montior单元
6. (可选)创建专用于监控的Kibana实例，而不是使用单个Kibana实例来访问生产集群和监控集群
   注：如果使用SAML、Kerberos、PKI、OpenID Connect或令牌身份验证登录Kibana，则需要一个专用的Kibana实例用于监控。这些安全手段是特定于集群的，因此不能使用单个Kibana实例连接到生产集群和监控集群。
   • (可选) 禁用监控kibana实例的收集监控数据功能。将kibana.yml中的xpack.monitoring.kibana.collection.enabled设置为false。具体参考kibana监控设置。
7. 配置kibana检索和展示监控数据

4 使用Metricbeat收集es的Monitoring数据

在6.5版本及更高版本中，你可以使用Metricbeat收集es数据并发送到监控集群，从而取代第七章节中旧版本通过exporters路由的方法。

1. 启动监控数据收集
   设置生产集群的xpack.monitoring.collection.enabled为true(默认为false)。
   你可以使用以下API检查修改设置：

   GET _cluster/settings
   
   PUT _cluster/settings
   {
     "persistent": {
       "xpack.monitoring.collection.enabled": true
     }
   }    
   

   如果启用了es security功能，则您必须具有monitor集群特权才能查看集群设置，并且必须具有manage集群权限才能更改设置。
   具体更多细节请查看es官方文档Monitoring settings单元和Cluster update settings单元。

2. 在生产集群中每个es节点上安装Metricbeat，任一节点安装失败可能导致结果不完整或丢失。

3. 在每个节点上的Metricbeat中启用es X-Pack模块。
   例如，要在modules.d目录中启用默认配置，请运行以下命令：

   metricbeat modules enable elasticsearch-xpack
   

   或者，您可以使用Elasticsearch module,具体参考Metricbeat官方文档中的Elasticsearch module单元。

4. 配置每个节点Metricbeat上的Elasticsearch X-Pack模块。配置文件modules.d/elasticsearch-xpack.yml包含以下配置：

   - module: elasticsearch
     xpack.enabled: true
     period: 10s
     hosts: ["http://localhost:9200"] 
     #scope: node 
     #username: "user"
     #password: "secret"
     #ssl.enabled: true
     #ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]
     #ssl.certificate: "/etc/pki/client/cert.pem"
     #ssl.key: "/etc/pki/client/cert.key"
     #ssl.verification_mode: "full"
   

   • 默认情况下，该模块从http://localhost:9200收集es监控指标 。如果该host和port不正确，则必须更新hosts设置。如果您将es配置为使用加密通信，则必须通过HTTPS访问它。例如，使用类似https://localhost:9200形式的hosts。
   • 默认情况下，scope设置为node。hosts列表中的每一条代表es集群中的不同节点。如果设置scope为cluster，则hosts列表中的每一条都代表不同的es集群的单个端点（例如，集群暴露出来的负载均衡代理）。

   如果启用了es security功能，还必须提供用户标识和密码，以便Metricbeat可以成功收集指标：

   • 创建一个具有内置角色remote_monitoring_collector的用户，或者使用内置用户remote_monitoring_user。
   • 添加用户名密码到配置文件中的elasticsearch module。
   • 如果es集群的HTTP层面启用了TLS，则必须在hosts设置中使用https作为URL方式或添加ssl.enabled: true设置。根据您的集群的TLS配置，您可能还需要指定其他SSL设置。

5. (可选)在Metricbeat中禁用system module。
   默认情况下，system module处于启用状态。但是它收集的信息未显示在Kibana的Monitoring页面上。除非你在其他地方需要使用该信息，否则请运行以下命令：

   metricbeat modules disable system
   

6. 确认将监控数据发到哪里
   注：在生产环境中，我们强烈建议你使用单独的集群（监控集群）来存储数据。使用单独的监视群集可防止生产群集中断而影响你访问监控数据，还可以防止监控活动影响生产集群的性能。
   例如，在Metricbeat配置文件（metricbeat.yml）中指定输出信息：

   output.elasticsearch:
     # Array of hosts to connect to.
     hosts: ["http://es-mon-1:9200", "http://es-mon2:9200"] *
   
     # Optional protocol and basic auth credentials.
     #protocol: "https"
     #username: "elastic"
     #password: "changeme"
   

   *将数据存储到具有两个节点的监控集群中。

   如果将监控群集配置为使用加密的通信，则必须通过HTTPS访问它。例如，使用类似 https://es-mon-1:9200的hosts设置。
   注：Elasticsearch监控功能使用ingest pipelines，因此存储监控数据的集群必须至少具有一个ingest node。

   如果在监视群集上启用了es security功能，则必须提供有效的用户ID和密码，以便Metricbeat可以成功发送指标：

   1. 在监控群集上创建一个具有内置角色remote_monitoring_agent的用户，或者使用内置用户remote_monitoring_user。
   2. 将username和password设置添加到Metricbeat配置文件中的Elasticsearch输出信息中。

   有关这些配置选项的更多信息，请参阅Metricbeat官网 配置Elasticsearch输出单元。

7. 启动每个节点上的metricbeat

8. 禁用默认开启的收集es监控指标
   在生产集群上将xpack.monitoring.elasticsearch.collection.enabled设置为false。
   你可以使用以下API修改配置：

   PUT _cluster/settings
   {
     "persistent": {
       "xpack.monitoring.elasticsearch.collection.enabled": false
     }
   }
   

   如果启用了es security功能，则您必须具有monitor集群特权才能查看集群设置，并且必须具有manage集群权限才能更改设置。

9. 在kibana上查看monitoring数据

5 使用Filebeat收集es的日志数据

Coming soon

6 配置存储Monitoring数据的索引

Coming soon

7 使用旧版本收集器收集Monitoring数据

7.1 数据收集器

收集器(collectors)，顾名思义，是用来收集东西。每个收集器会在每个收集周期内运行一次es或者x-pack提供的公开API来收集数据用以监控。收集完毕后，数据会通过exporters批量发送给监控集群。无论exporters的数量是多少，每个collector每个收集间隔仅运行一次。

每种数据类型仅有一个收集器。换句话说，对于生成的任何monitoring文档，都来自单个收集器，而不是来自多个收集器。当前，es监控功能具有多个收集器，目的是最大程度地减少它们之间的重叠以实现最佳性能。

每个收集器可以创建零个或多个monitoring文档。例如index_stats收集器同时收集全部索引的统计信息，以避免许多不必要的调用。

收集器	数据类型	描述
Cluster Stats	cluster_stats	收集集群状态的详细信息，包括部分集群状态的元数据信息(GET /_cluster/state)以及集群的统计信息(GET /_cluster/stats)，只生成一个文档类型。在X-Pack5.5之前的版本中，有三个独立的collcetor生成三个文档类型：cluster_stats，cluster_state，和cluster_info。在5.5以及更高版本中合并为cluster_stats类型。收集只在当前的主节点上运行，且收集到的数据(cluster_stats)在很大程度上控制着UI。如果此数据不存在，则表示在所选主节点上配置有错误、数据收集超时或数据存储有问题。每个收集周期内只生成一个文档。
Index Stats	indices_stats, index_stats	收集集群中的索引信息，包括汇总和每个独立索引的。这会创建许多文档，这些文档都是索引统计信息结果的一部分(GET /_stats)。该信息只需要收集一次，因此可以在当前主节点上收集。此收集器最常见的故障是索引数量过大（因此收集它们的时间过长）导致超时。每个收集周期内生成一个汇总文档indices_stats，每个索引也会生成独立文档index_stats。
Index Recovery	index_recovery	收集集群中索引恢复的信息，索引恢复代表集群级别的分片分配。如果索引没有恢复则不可用。这也适用于通过快照进行分片还原。该信息只需要收集一次，因此在当前主节点上收集。此收集器最常见的故障是shards数量过多（因此收集它们的时间很长）从而导致超时。默认会创建一个包含所有恢复信息的文档，该文档可能非常大，但是它提供了生产集群中最准确的恢复情况。
Shards	shards	收集所有索引的所有已分配分片的详细信息，尤其包含分片所分配到的节点。该信息只需要收集一次，因此在当前主节点上收集。与其他大多数收集器不同，此收集器使用本地集群状态cluster state获取路由表，而没有任何网络超时问题。每个shard由单独的文档记录。
Jobs	job_stats	收集所有机器学习作业的统计信息（GET /_ml/anomaly_detectors/_stats）的详细信息。该信息只需要收集一次，因此可以在当前主节点上收集。但是要使主节点能够执行收集，必须设置其xpack.ml.enabled配置为true(默认)，并且其许可证级别支持机器学习功能。
Node Stats	node_stats	收集运行中节点的信息，例如内存、CPU的使用率(GET /_nodes/_local/stats)。它在启用了监视功能的每个节点上运行。一种常见故障是由于段文件太多而导致节点统计信息请求超时，收集器花费太多时间等待文件系统统计信息被计算出来，直到最终超时。每个收集周期内每个节点会创建一个node_stats文档，这样可以帮助发现生产进群的节点间的通信问题(网络延时或者内存压力)。

es监控功能使用单线程调度程序来运行每个节点上所有相关收集器的数据收集任务。该调度程序由每个节点自身管理，并且其间隔通过在节点或集群级别指定的xpack.monitoring.collection.interval参数（默认10s）来控制。

从根本上说，每个收集器都遵循相同的原理。在每个收集周期间隔中，检查每个收集器是否需要运行，然后运行适当的收集器。单个收集器的故障不会影响任何其他收集器。

收集完成后，所有监控数据都将传递到导出器(exporters)，以将监控数据路由到监控群集。

如果Kibana的监控视图中存在空隙，通常是因为收集器发生故障或监控集群未接收到数据（例如，正在重新启动）。如果收集器失败，则执行收集任务的节点上应该存在相关错误日志。
注：当前收集是串行而不是并行完成的，以避免在选择的主节点上产生额外的开销。这种方法的缺点是，收集器可能会在同一收集期内观察到不同版本的群集状态。实际上，并行运行收集器也不会阻止这种可能性。

有关收集器的配置选项的更多信息，请参阅 Monitoring collection settings。

收集整个Elastic Stack家族数据

7.2 数据导出器

7.3 数据导出到本地

7.4 HTTP方式数据导出

7.5 暂停数据收集

8 Monitoring故障排除

Coming soon