共计 7147 个字符，预计需要花费 18 分钟才能阅读完成。
简介
Elasticsearch 提供了许多指标，能够帮忙您检测故障迹象并在遇到不牢靠的节点，内存不足的谬误以及较长的垃圾收集工夫等问题时采取措施。须要监督的几个要害畛域是：
- 集群运行状况和节点可用性
- 主机的网络和零碎
- 搜寻性能指标
- 索引性能指标
- 内存应用和 GC 指标
- 资源饱和度和谬误
场景视图
ElasticSearch 场景视图
内置视图
ElasticSearch 内置视图
前置条件
已装置 DataKit DataKit 装置文档
配置
监控指标采集
进入 DataKit 装置目录下的 conf.d/db 目录，复制 elasticsearch.conf.sample 并命名为 elasticsearch.conf。示例如下：
[[inputs.elasticsearch]]
## specify a list of one or more Elasticsearch servers
# you can add username and password to your url to use basic authentication:
# servers = ["http://user:pass@localhost:9200"]
servers = ["http://localhost:9200"]
## Timeout for HTTP requests to the elastic search server(s)
http_timeout = "5s"
## When local is true (the default), the node will read only its own stats.
## Set local to false when you want to read the node stats from all nodes
## of the cluster.
local = true
## Set cluster_health to true when you want to also obtain cluster health stats
cluster_health = true
## Adjust cluster_health_level when you want to also obtain detailed health stats
## The options are
## - indices (default)
## - cluster
# cluster_health_level = "cluster"
## Set cluster_stats to true when you want to also obtain cluster stats.
cluster_stats = true
## Only gather cluster_stats from the master node. To work this require local = true
cluster_stats_only_from_master = true
## Indices to collect; can be one or more indices names or _all
indices_include = ["_all"]
## One of "shards", "cluster", "indices"
indices_level = "shards"
## node_stats is a list of sub-stats that you want to have gathered. Valid options
## are "indices", "os", "process", "jvm", "thread_pool", "fs", "transport", "http",
## "breaker". Per default, all stats are gathered.
node_stats = ["jvm", "http","indices","os","process","thread_pool","fs","transport"]
## HTTP Basic Authentication username and password.
# username = ""# password =""
## Optional TLS Config
# tls_ca = "/etc/telegraf/ca.pem"
# tls_cert = "/etc/telegraf/cert.pem"
# tls_key = "/etc/telegraf/key.pem"
## Use TLS but skip chain & host verification
# insecure_skip_verify = false重新启动 datakit 失效
systemctl restart datakit
日志采集
进入 DataKit 装置目录下的 conf.d/log 目录，复制 tailf.conf.sample 并命名为 tailf.conf。示例如下：
[[inputs.tailf]]
# glob logfiles
# required
logfiles = ["/var/log/elasticsearch/solution.log"]
# glob filteer
ignore = [""]
# required
source = "es_clusterlog"
# grok pipeline script path
pipeline = "elasticsearch_cluster_log.p"
# read file from beginning
# if from_begin was false, off auto discovery file
from_beginning = true
## characters are replaced using the unicode replacement character
## When set to the empty string the data is not decoded to text.
## ex: character_encoding = "utf-8"
## character_encoding = "utf-16le"
## character_encoding = "utf-16le"
## character_encoding = "gbk"
## character_encoding = "gb18030"
## character_encoding = ""# character_encoding =""
## The pattern should be a regexp
## Note the use of '''XXX'''
# match = '''^\d{4}-\d{2}-\d{2}'''
#Add Tag for elasticsearch cluster
[inputs.tailf.tags]
cluster_name = "solution"Elasticsearch 集群信息日志切割 grok 脚本
elasticsearch_cluster_log.p
重新启动 datakit 失效
systemctl restart datakit
监控指标阐明
1. 集群运行状况和节点可用性
集群运行状况和节点可用性的要点
- 集群状态 : 如果集群状态为 YELLOW，阐明至多有一个正本分片未调配或者失落。只管这个时候搜寻后果依然是残缺的，然而如果更多的分片隐没的话，有可能造成整个索引的数据失落。如果集群状态为 RED，则示意至多有一个主分片失落，索引短少数据，这意味着搜寻将返回局部后果，而且新的文档数据也无奈索引到该分片。这时能够思考设置一个告警，如果状态为黄色超过 5 分钟，或者上次检测状态为红色，则触发警报。
- 初始化（initializing）和未调配（unassigned）状态的分片 : 当索引首次创立或者节点重新启动时，因为 Master 节点试图将分片调配给 Data 节点，所以在转换为“started”或“unassigned”状态之前，该分片将临时处于“initializing”状态。如果您看到分片处于初始化状态或未调配状态的工夫过长，则可能是群集不稳固的信号。
2. 主机的网络和零碎
主机的网络和零碎的要点
- 磁盘空间 : 如果当 Elasticsearch 集群是写负载型的，那么这个指标将变得更加重要。因为一旦空间有余，将不能进行任何插入和更新操作，节点也会下线，这应该是业务上不容许的。如果节点的可用空间小于 20%，应该利用相似 Curator 这样的工具，删除一些占用空间较大的索引来开释局部空间。如果业务逻辑上不容许删除索引，那么另一种计划就是扩容更多的节点，让 Master 在新节点间重新分配分片（只管这样会减少 Master 节点的负载）。另外须要记住一点，蕴含须要剖析（analyzed）的字段的文档占用的磁盘空间比那些不须要剖析（non-analyzed）的字段（准确值）的文档要多得多。
- 节点上的 CPU 利用率 : 利用图示来展现不同节点类型的 CPU 应用状况会很有帮忙。例如，能够创立三个不同的图来示意群集中的不同节点类型（例如 Data 节点，Master 节点和 Client 节点）的 CPU 应用状况，通过比照图示来发现是否某一种类型的节点过载了。如果您看到 CPU 使用率减少，这通常是因为大量的搜寻或索引工作造成的负载。设置一个告诉，以确定您的节点的 CPU 使用率是否持续增长，并依据须要增加更多的节点来重新分配负载。
- 网络字节发送 / 接管 : 节点之间的通信是掂量群集是否均衡的要害组成部分。须要监督网络以确保网络失常运行，并且可能跟上群集的需要（例如，在节点间复制或分片的重新分配）。Elasticsearch 提供无关集群节点间通信的传输指标，然而也能够通过发送和接管的字节速率，来查看网络正在接管多少流量。
- 关上文件描述符 : 文件描述符用于节点间的通信、客户端连贯和文件操作。如果关上的文件描述符达到零碎的限度，那么新的连贯和文件操作将不可用，直到有旧的被敞开。如果超过 80%的可用文件描述符正在应用中，则可能须要减少零碎的最大文件描述符计数。大多数 Linux 零碎限度每个过程中只容许有 1024 个文件描述符。在生产中应用 Elasticsearch 时，应该将操作系统文件描述符数量设置为更大的值，例如 64,000。
- HTTP 链接 : 除了 Java Client 以外的任何语言发送的申请都将应用基于 HTTP 的 RESTful API 与 Elasticsearch 进行通信。如果关上的 HTTP 连贯总数一直减少，则可能表明您的 HTTP 客户端没有正确建设长久化连贯。从新建设连贯会在申请响应工夫内减少额定的工夫开销。因而务必确保您的客户端配置正确，以防止对性能造成影响，或者应用已正确配置 HTTP 连贯的官网 Elasticsearch 客户端之一。
3. 查问性能指标
如果您次要应用 Elasticsearch 进行查问，那么您应该关注查问提早并在超出阈值时采取措施。监控 Query 和 Fetch 的相干指标能够帮忙您跟踪查问在一段时间内的执行状况。例如，您可能须要跟踪查问曲线的峰值以及长期的查问申请增长趋势，以便能够优化配置来取得更好的性能和可靠性。
搜寻性能指标的要点:
- 查问（Query）负载 : 监控以后查问并发数能够大抵理解集群在某个时刻解决的申请数量。对不寻常的峰值峰谷的关注，兴许能发现一些潜在的危险。可能还须要监控查问线程池队列的应用状况。
- 查问（Query）提早 : 尽管 Elasticsearch 并没有间接提供这个指标，然而咱们能够通过定期采样查问申请总数除以所消耗的时长来简略计算均匀查问延迟时间。如果超过咱们设定的某个阀值，就须要排查潜在的资源瓶颈或者优化查问语句。
- 获取（Fetch）提早 : 查问（search）过程的第二阶段，即获取阶段，通常比查问（query）阶段破费更少的工夫。如果您留神到此度量指标继续减少，则可能示意磁盘速度慢、富文档化（比方文档高亮解决等）或申请的后果太多等问题。
4. 索引性能指标
索引（Indexing）申请相似于传统数据库外面的写操作。如果您的 Elasticsearch 集群是写负载类型的，那么监控和剖析索引（indices）更新的性能和效率就变得很重要。在探讨这些指标之前，咱们先看一下 Elasticsearch 更新索引的过程。如果索引产生了变动（比方新增了数据、或者现有数据须要更新或者删除），索引的每一个相干分片都要经验如下两个过程来实现更新操作：refresh 和 flush。
索引性能指标的要点:
- 索引（Indexing）提早 : Elasticsearch 并未间接提供这个指标，然而能够通过计算 index_total 和 index_time_in_millis 来获取均匀索引提早。如果您发现这个指标一直攀升，可能是因为一次性 bulk 了太多的文档。Elasticsearch 举荐的单个 bulk 的文档大小在 5-15MB 之间，如果资源容许，能够从这个值缓缓加大到适合的值。
- Flush 提早 : 因为 Elasticsearch 是通过 flush 操作来将数据长久化到磁盘的，因而关注这个指标十分有用，能够在必要的时候采取一些措施。比方如果发现这个指标继续稳定增长，则可能阐明磁盘 I/O 能力曾经有余，如果继续上来最终将导致无奈持续索引数据。此时您能够尝试适当调低 index.translog.flush_threshold_size 的值，来减小触发 flush 操作的 translog 大小。与此同时，如果你的集群是一个典型的 write-heavy 零碎，您应该利用 iostat 这样的工具继续监控磁盘的 IO，必要的时候能够思考降级磁盘类型。
5. 内存应用和 GC 指标
在 Elasticsearch 运行过程中，内存是须要亲密关注的要害资源之一。Elasticsearch 和 Lucene 以两种形式利用节点上的所有可用 RAM：JVM 堆和文件系统缓存。Elasticsearch 运行在 Java 虚拟机（JVM）上，这意味着 JVM 垃圾回收的持续时间和频率将是其余重要的监控畛域。
内存应用和 GC 指标的要点:
- JVM 堆内存的使用量 : Elasticsearch 默认当 JVM 堆栈使用率达到 75% 的时候启动垃圾回收。因而监控节点堆栈应用状况并设置告警阀值来定位哪些节点的堆栈使用率继续维持在 85% 变得十分有用，这表明垃圾回收的速度曾经赶不上垃圾产生的速度了。要解决这个问题，能够减少堆栈大小，或者通过增加更多的节点来扩大群集。
- JVM 堆内存的使用量和提交的 JVM 堆内存大小 : 和 JVM 堆栈调配了多少内存（committed）相比，监控 JVM 应用了多少内存（used）会更加有用。应用中的堆栈内存的曲线通常会呈锯齿状，在垃圾累积时逐步回升在垃圾回收时又会降落。如果这个趋势随着工夫的推移开始向上倾斜，这意味着垃圾回收的速度跟不上创建对象的速度，这可能导致垃圾回收工夫变慢，最终导致 OutOfMemoryError。
- 垃圾收集持续时间和频率 : 为了收集无用的对象信息，JVM 会暂停执行所有工作，通常这种状态被称为“Stop the world”，不论是 young 还是 old 垃圾回收器都会经验这个阶段。因为 Master 节点每隔 30s 检测一下其余节点的存活状态，如果某个节点的垃圾回收时长超过这个工夫，就极可能被 Master 认为该节点曾经失联。
- 内存应用状况 : Elasticsearch 能够很好地应用任何尚未调配给 JVM 堆的 RAM。和 Kafka 一样，Elasticsearch 被设计为依附操作系统的文件系统缓存来疾速牢靠地解决申请。如果某个 segment 最近由 Elasticsearch 写入磁盘，那么它曾经在缓存中。然而，如果一个节点已被敞开并重启，则在第一次查问一个 segment 的时候，必须先从磁盘读取数据。所以这是确保群集保持稳定并且节点不会解体的重要起因之一。通常，监督节点上的内存应用状况十分重要，并尽可能为 Elasticsearch 提供更多的 RAM，以便在不溢出的状况下最大化利用文件系统缓存。
6. 资源饱和度和谬误
Elasticsearch 节点应用线程池来治理线程对内存和 CPU 应用。因为线程池是依据处理器的核数主动配置的，因而调整它们通常是没有意义的。然而通过申请队列和申请被回绝的状况，来确定你的节点是否够用是一个不错的主见。如果呈现了情况，您可能须要增加更多的节点来解决所有的并发申请。
- 线程池的申请队列（queues）和回绝状况（rejections）: 每个 Elasticsearch 节点都保护着很多类型的线程池。具体应该监控哪些线程池，须要依据 Elasticsearch 的应用场景而定。一般来讲，最重要的几个线程池是搜寻（search），索引（index），合并（merger）和批处理（bulk）。每个线程池队列的大小代表着以后节点有多少申请正在期待服务。队列的作用是容许节点追踪并最终解决这些申请，而不是间接抛弃它们。然而线程池队列不是有限扩大的（队列越大占用的内存越多），一旦线程池达到最大队列大小（不同类型的线程池的默认值不一样），前面的申请都会被线程池回绝。
资源饱和度和谬误的要点:
- 线程池队列 : 线程池队列并不是越大越好，因为线程池越大占用的资源越多，并且增大了节点宕机时申请失落的危险。如果您看到排队和回绝的线程数量继续减少，则须要尝试减慢申请速率、减少节点上的处理器数量或减少集群中的节点数量。
- 批处理（bulk）的申请队列和申请回绝 : 批处理是同时发送多个申请的更无效形式。通常如果要执行许多操作（创立索引，或者增加，更新或删除文档），则应尝试将申请作为批处理发送，而不是多个独自的申请。批处理申请被回绝通常与试图在一个批处理申请中索引太多文档无关。尽管据 Elasticsearch 的文档所说，呈现批处理申请被回绝的状况，不肯定是必须要放心的事件，然而应该尝试施行一些退却策略，以无效解决这种状况。
- 缓存使用率指标 : 每个查问申请都发送到索引中的每个分片，而后命中每个分片的每个段。Elasticsearch 逐段缓存查问，以放慢响应工夫。另一方面，如果您的缓存占用了太多的堆，它们可能会升高速度而不是加快速度！
正文完