随着单个 Elasticsearch 集群规模的越来越大，大家要么在拆集群的路上，要么是已经是多套集群了， 据路边社消息，一个公司超过5个集群的情况已经变得非常普遍，而管理多个集群着实是有点痛苦，比如常规的玩法可能是一套集群一个 Kibana，集群一多，切换来切换去就有点懵圈了有木有？

作为一个优雅的程序员或者运维管理员，是可忍孰不可忍啊。

另外，多个集群的监控也是一个麻烦事，目前常见的几种监控如：

• 使用 Kibana 自带的监控
• 使用 Prometheus + Grafana
• 使用 Zabbix

Kibana 自带的监控可以很好的满足单个集群的监控场景，不过集群规模大了之后，经常会出现指标丢失的问题，如果使用单独的监控集群，需要修改每个节点的配置，集群都需要重启，对于已经上了生产的集群，有点不方便，另外多集群监控需要商业授权。

那 Prometheus 呢， 一个 Elasticsearch 集群如果要监控起来，首先需要部署一个 Exporter 来暴露集群指标，然后部署一套Prometheus 来采集 Elasticsearch 指标，采集完了之后再部署一套 Grafana 来进行报表分析，不同的集群要做好切换，简单的事情，搞复杂了，整个监控体系偏重，维护成本高。

Zabbix 和 Prometheus 的场景差不多，就不赘述了。

那么问题来了，有没有一个更加简单方便的多集群监控和管理方案呢，并且要支持不同版本的集群，最好是 v2、v5、v6、v7 以及最新的 v8 都能统统接管，哈哈，没错了，这里给大家介绍一个我们极限实验室团队最近开发出来的一款免费的多集群监控和管理工具-极限数据平台，目前版本 v0.1，新鲜出炉。

废话不多少，咱们直接看图说话：

首先是多集群的纳管，目前从 1.0 到最新的 8.0 统统都可以接进来。

然后就是集群的监控拉，要多简单有多简单，就是一个开关的事情，注册集群的时候，启用即开启监控，目标集群啥都不用动，费那劲干啥。

监控界面如图：

集群概览，总体情况一目了然。

各个节点信息，分门别类。

各个索引级别的信息，挨个查看。

多个集群之间的监控查看一键切换，非常方便。

查看监控的时候，发现不对劲，要操作一下集群，直接调出控制台，如下图：

常用的操作命令，可以保存起来，方便下次使用。

别再保存在记事本里面了，下次又找不到，直接加载执行就好了。

好了，你要是用 Elasticsearch 不知道这个工具，那就 out 了，赶快耍起来吧。

下载地址：

http://release.elasticsearch.cn/console/snapshot/

安装巨简单，简直懒得说，一个二进制可执行文件，一个 yml 配置文件，里面修改 Elasticsearch 地址，结束。

可以在这里查看 介绍和 Demo 演示视频

最后，欢迎关注极限实验室，获取更多 Elasticsearch 免费工具及业界资讯的第一手消息。

前言

对于广大 Elasticsearch 使用者而言，在面对系统资源分配、问题请求排查时是否曾遇到以下问题：

• 只知道需要预留许多内存资源给 lucene（一般为系统资源的一半），但是分配的这些是否够用，以及这些内存资源被什么文件所占用，往往都不得而知；
• 线上服务突然出现一波超时告警，告警波及的索引面积较广，但波动具体由哪个索引，甚至哪个查询导致的，在排查时容易陷入无从下手的困境。

​

通常在 Elasticsearch 的监控层面，我们会选择去查看 kibana 的监控报表，但 kibana 在内存方面的监控指标通常都基于 JVM 本身，无法追溯到 lucene 层面。而 lucene 的文件使用的是操作系统的 page cache，如何监控 page cache，并将之映射到 Elasticsearch 的索引维度，便是本文着手解决的问题。 ​

接下来本文将分为三个主要部分，第一部分介绍和 Elasticsearch 内存使用相关的基础知识，适合对 ES 内存资源占用有兴趣的同学，第二部分介绍 Elasticsearch 的 page cache 监控工具和使用说明，第三部分列举一些典型的使用案例。

基础知识

对搜索引擎而言，各级缓存的命中率和查询效率密切相关。ES 的缓存主要由 JVM 堆内存，以及 lucene 所依赖的堆外内存两部分组成。考虑到大多数查询场景的多样性，ES 的 query cache 覆盖能力有限，因此 ES 的查询性能和 lucene 各类文件的缓存状况息息相关，能否通过 page cache 尽量减少查询过程中产生的文件IO 将直接影响到查询效率。本节将从 Elasticsearch 内存分布，lucene 文件类型和使用场景，文件读取方式几个层面展开介绍。

Elasticsearch 内存相关

ES 进程的 JVM 堆内存主要包括以下几部分内容（不详细展开）

• Indexing Buffer：索引缓冲区，用于存储新索引的文档，当其达到阈值时，会触发 ES flush 将段落到磁盘上；
• Fielddata：用于 text 字段分词或排序时获取字段值，基于 lucene 的 segment 构建，伴随 segment 生命周期常驻在堆内存中。
• Node Query Cache：负责缓存 filter 查询结果，基于 lucene 的 segment 构建，缓存在堆内存中，ES 节点默认的 cache 大小为堆内存的10%，采用LRU机制。
• Shard Request Cache：针对 ES 的 query 请求，缓存各分片的查询结果，主要用于缓存聚合结果，采用LRU机制，当分片 refresh 后会失效。

对于 lucene 而言，其使用的是堆外内存

• Page Cache：lucene 读写段文件时会依赖操作系统的 page cache 缓存，如果多次查询都涉及到读取某个段文件的同一部分内容，就直接使用 page cache 进行读取，无需再从磁盘获取数据。page cahce 由操作系统管理，淘汰策略类似LRU。

  lucene 文件类型

  ES 的一个分片就是一个 lucene 实例，实例由一个或多个 segment 构成。lucene 每次 flush 操作都会对一个 segment 进行持久化操作（会将内存中的 segment 写到文件，但不执行 FileChannel::force，即存在数据丢失的可能），其内容为期间有变更的文档，同一个段涉及到的文件前缀都是相同的 generation（36进制的一个数字，每次 flush 会加一），每个段可能涉及到的文件如下表所示。

lucene 文件功能说明备注

• tip 和 fdx 类型的文件在 ES 7.3 以前都是常驻 JVM 堆内存的，ES 7.3 之后将 fst 移至堆外，交由系统的 page cache 管理，若某个索引的 fst cache 不幸被置换出去，理论上会给搜索带来较大的抖动，对于使用 7.x 版本的用户，建议多关注 tip 文件的 cache 情况；
• 上述文件中占用存储空间较多的是 tim、doc、fdt、dvd 以及 cfs 这几类数据文件，除 cfs 以外的几类文件加载情况和查询条件密切相关；

• range 查询即可能使用 dim BKD 索引，也可能使用 dvd DocValue，其背后是一个基于代价的优化器处理逻辑 ，如有兴趣，细节逻辑可自行参考 IndexOrDocValuesQuery。

  lucene 文件读取方式

  lucene 文件的读取方式将影响磁盘 IO 调用，以及 page cache 中缓存的内容，常用的主要是如下两种类型：

• niofs：通过 NIO 的方式读取文件内容，基于 Java 提供的 FileChannel::read 方法读取数据，支持多线程读取同一个文件，按需读取，需要注意的是 niofs 模式下读取到的内容在系统层面也会进 page cache。
• mmapfs：通过mmap读写文件，会比常规文件读写方式减少一次内存拷贝的过程，因此对于命中 page cache 的文件读取会非常快，该模式即零拷贝的一种实现（可减少内核态和用户态间的数据拷贝）。不过 mmap 系统调用在内核层面会产生预读，对于 .fdt 这类文件，预读读到的内容后续命中的概率极低，还容易引起page cache的争用，进而产生频繁的缺页中断，相关问题可参考https://github.com/elastic/elasticsearch/issues/27748

​

ES 支持通过 index.store.type 设定文件加载方式

• ES 6.*版本默认为 mmapfs
• ES 7.0开始默认为 hybridfs，该模式下每类文件会选择最优的读取方式，例如 .doc 由于倒排表的缓存命中率较高，被设定为 mmapfs，而 .fdt 只在获取 _source 时使用，访问较为稀疏，被设定为 niofs。

  工具使用说明

  综上所述，lucene 各类文件占用 page cache 的情况将极大的影响 Elasticsearch 的查询效率，如何系统的监控各类文件在 page cache 中的占用，以及换入换出的波动，将为 ES 的资源分析和性能监控提供一种新的角度。 ​

如果想采集系统的 page cache，可以借助 pcstat、vmtouch 等工具，其实现原理均是通过 mincore(2) 系统调用，mincore能确定一块虚拟内存区域中的分页是否驻留在物理内存中。其中 pcstat 是款基于Go的开源工具（https://github.com/tobert/pcstat），开发初衷是用于监控 Cassandra 中 ssTables 的占用情况。 ​

本工具 es-pcstat 基于 pcstat 进行二次开发，以 ES 索引为维度，细化到 lucene 文件的粒度来对 page cache 占用情况进行采集，可对cfs、fdt、doc、pos、tim、dvd等重要文件进行细粒度的采集和监控。支持数据输出到控制台、日志、ES，配套kibana仪表盘支持查看各索引、各类文件的时序变化曲线。

源码地址

https://github.com/zhangdapao995/es-pcstat

功能点

采集目标：ES索引下各类 lucene 文件的 page cache 占用，单位MB，默认采集全部索引，支持配置采集的索引前缀。 ​

运行环境

• 系统环境： 类unix、linux环境
• ES 版本：6.x、7.x

功能项

• 数据输出：控制台、日志和ES
  • 控制台：查看各索引 cache，支持排序
  • 日志和ES：采集维度从上到下依次为 节点->索引->主副分片->文件后缀
• 可视化：数据输出为 ES 时，支持 kibana 仪表盘配置
  • 支持按节点、索引、主副分片类型筛选查看
  • 支持查看索引 page cache top10 波动曲线

获取可执行文件

linux_x64

linux 64位可通过如下命令获取可执行文件

curl -L -o es-pcstat https://gitee.com/verdant/es-pcstat/attach_files/835465/download/es-pcstat-linux-x64
chmod 755 es-pcstat

mac

mac 64位可通过如下命令获取可执行文件

curl -L -o es-pcstat https://gitee.com/verdant/es-pcstat/attach_files/835463/download/es-pcstat-darwin-x64
chmod 755 es-pcstat

运行

执行命令

./es-pcstat [parameters] <config_file>

例：./es-pcstat -collectIntervalFlag=30 -sortFlag=true ./es.conf

​

运行可选参数

  -collectIntervalFlag int
        采集间隔 (default 60)
  -outputTypeFlag string
        数据输出方式 [es, log, console] (default "console")
  -sortFlag
        仅对console类型生效，结果按page cache大小排序

配置文件

配置文件需填写es ip、端口、节点名、集群名和数据目录，其中path需要填写indices目录，一般为es的 data.path配置后增加"/nodes/0/indices"。

#es conf
es.ip=127.0.0.1
es.port=9200
es.indicesPath=/xxx/xxx/elasticsearch-6.7.1/data/nodes/0/indices
es.nodeName=node1
es.clusterName=es_local

#采集索引前缀,设置为空则采集全部
es.collection.indicesPrefix=

#该配置仅日志输出生效 output log,保留个数单位为天
output.log.keepLogNum=5
output.log.logPath=/tmp/pcstat.log

#该配置仅es输出生效 output es,保留个数单位为天
output.es.keepIndexNum=5
output.es.pcIndexName=pc_stat

输出模式

控制台输出

执行命令

./es-pcstat -collectIntervalFlag=30 -sortFlag=true ./es.conf

结果示例

| index_name                            | cache (MB) | pri cache  | rep cache  |
+---------------------------------------+------------+------------+------------+
| fusion-media.task.task                |  247       |  247       |  0         |
| total                                 |  247       |  247       |  0         |
+---------------------------------------+------------+------------+------------+

日志输出

执行命令

./es-pcstat -outputTypeFlag=log ./es.conf

对应日志文件得到的内容，日志可进一步通过日志服务采集分析（如阿里云sls等）

{"cache":{"cfs":0,"dim":0,"doc":0,"dvd":0,"fdt":0,"nvd":0,"other":0,"pos":0,"tim":0,"total":0},"cluster_name":"es_local","fields.time":"2021-05-06T15:16:30.525475+08:00","index_name":"total","level":"info","msg":"","node_name":"node1","primary":false,"time":"2021-05-06T15:16:30"}

ES 输出

执行命令

./es-pcstat -outputTypeFlag=es ./es.conf

运行后会将采集到的数据回写到被监控的 ES 集群 可导入kibana仪表盘配置文件es-pcstat-kibana.json，通过图表进行page cache分析。 ​

导入方式

导入后打开dashboards菜单栏，page_cache仪表盘

细节可查看如下图表 1）cache占用top10的索引波动图

2）cache详细信息，可筛选节点、索引、主副分片，不选择展示合计数据。

备注

• 如需使用上述kibana仪表盘导入文件，请勿修改conf文件中的output.es.pcIndexName以及运行命令的collectIntervalFlag，修改output.es.pcIndexName会导致仪表盘读不到数据，修改collectIntervalFlag会导致仪表盘聚合数据异常；
• kibana7.5后Date Histogram的interval有所调整，会导致时间拉长后interval成倍增大，统计值不准，建议选取时间范围在4-6小时内，https://elasticsearch.cn/question/11062

  使用案例

  通过 es-pcstat 采集得到的 page cache 时序图，可为性能监控、资源分析、异常请求定位等问题提供一定帮助，以下将从笔者团队使用中的几个案例进行展开。 ​

一个简单示例：每条横线代表一个索引的所有 lucene 文件资源占用，一小时内的采样可以发现两个转折点

• 1 触发了副本清0操作，由于该集群副本不涉及搜索，所占用的内存比例较少
• 2 触发了一些查询请求，部分索引所占资源上涨

案例一：资源分析

通过观察一段时间的资源波动可评估预留给 lucene 的 page cache 是否充裕，如下两张图展示了两个集群中单个节点一天的资源占用情况，图6资源较为充裕，整体趋势几乎无大的波动，图7资源较为紧张，频繁出现 page cache 的换入换出。

案例二：merge的影响

如图8所示，通过监控可以发现某个索引的 page cache 上涨非常明显，导致其他索引的资源被换出，这种抢占会导致搜索服务波动；通过kibana排查该时间段内该索引的监控，发现段的数量有所下降，查看段文件后发现在该时间段后生成了几个较大的段文件，判定是 merge 导致 page cache 上涨，通过图9可以看到 merge 过程中 fdt 文件的上涨尤其明显（主要因为 merge 需要 load 原始内容进行处理），merge 完成后 fdt 的 cache 会慢慢的换出。 ​

由于采用了存储计算分离的架构，后续可考虑将数据规模达到一定阈值的 merge 操作移到专属的 merge 节点处理，以此减少 merge 引起的 cache 换入换出对搜索服务节点带来的波动。

案例三：异常查询请求定位

有时集群的整体响应突然变慢，却不知道是由哪个索引、或哪个查询引起的？ ​

例如某天一个 ES 集群突然出现大量超时请求，查看节点监控，ygc有所下降，cpu利用率一直在高位；再查看磁盘监控，发现磁盘读吞吐处于高负荷状态。

通过这些常规的监控无法进一步定位到异常原因，再来看看 page cache 的监控。根据“索引cache top N”图表可以明显发现异常时间点有个索引的cache大幅度上涨，其他索引的 cache 都有所下降，在异常时间段内，曲线的毛刺极为明显，由此可以判断是堆外内存不够，导致各索引的 page cache 出现争用，进而需要从磁盘上获取数据。

再进一步查看 cache 上涨期间问题索引各类文件的 cache 情况，可看到 doc和pos 有明显上涨，doc文件存储倒排表及词频，由包含每个 term 以及频率的 docs 列表组成，pos 存储出现在索引中 term 的位置信息。二者在 phrase 查询中会被联合使用。当一个平时使用率不高的索引突然出现了大量的 phrase 查询，内存资源比较吃紧（该节点预留给堆外的只有7 GB），进而就产生了上述问题。

对于某些突发的，却给集群造成较大压力的请求，可以尝试通过 page cache 监控去排查定位。 ​

当然要把具体的 lucene 文件类型变化趋势和查询关联起来，需要对各类查询涉及的文件有一定了解，相关细节可查看“基础知识->lucene 文件类型”一节，典型的如

• dvd 上涨可以猜测是有聚合、脚本、排序的请求
• doc、pos上涨可以联想到是否有 phrase 查询请求
• fdt 上涨可能涉及大量的源数据拉取或 merge 操作

案例四：为性能优化制定方向

随着系统的发展、数据量的增长，在某个业务场景 ES 相关的资源和效率可能逐渐成为瓶颈，这时候我们就需要从底层视角来推动上层的优化，如图13所示，根据监控曲线可发现 fdt、doc、pos 几类文件的常驻内存资源较多，便可从这3类文件的使用情况出发来制定优化方向：

• fdt 常用于获取_source字段的内容，如果存储并在查询结果中获取大量字段很容易导致该文件频繁访问，进而占用较多资源，可以考虑对 _source 进行适当删减，或将数据获取逻辑移至宽表数据库，如HBase等，让 ES 的资源更多的用于搜索本身；
• doc 在 term 和全文搜索场景均有使用，这类文件的加载通常不可避免，可以从降低文件大小来入手，如在分词层面进行优化，对词的分布进行统计分析，来评估是否可以补充停用词等；
• pos 用于需要位置信息的 phrase 查询，可从查询语句的拼装进行优化。

总结及未来展望

es-pcstat 从 ES 索引和 lucene 各类文件 page cache 占用的角度，提供了一种对 ES 进行监控的全新思路，基于这些监控数据我们可以进行资源的饱和度评估，异常查询请求的定位，或者为性能优化制定方向。 ​

当然异常请求的定位都只能限于事后分析，无法避免问题的产生，如何通过监控数据和查询请求去评估一个 query 可能对集群产生的影响，并拦截可能导致较大 page cache 争用的请求，这将能为集群的稳定性提供更大的保障。 ​

es-pcstat 采集细化到了 lucene 文件的粒度，需要具备一定基础知识和经验才能快速定位背后原因，因此在分析上具备一定门槛，如果能根据文件波动来为监控者提供一些 ES 层面的提示，将能服务更广大的 ES 用户。 ​

在 ES 中对一个查询的成本（涉及JVM中的缓存、系统内存缺页中断、IO、CPU等）进行评估本身是一件比较难的事，page cache 的监控可能能提供一定的帮助，当然还有更多的作用等待我们去探索。

参考链接

https://github.com/tobert/pcstat
https://www.amazingkoala.com.cn/Lucene/2019/1205/115.html
https://www.elastic.co/guide/en/elasticsearch/reference/master/index-modules-store.html

随着单个 Elasticsearch 集群规模的越来越大，大家要么在拆集群的路上，要么是已经是多套集群了， 据路边社消息，一个公司超过5个集群的情况已经变得非常普遍，而管理多个集群着实是有点痛苦，比如常规的玩法可能是一套集群一个 Kibana，集群一多，切换来切换去就有点懵圈了有木有？

作为一个优雅的程序员或者运维管理员，是可忍孰不可忍啊。

另外，多个集群的监控也是一个麻烦事，目前常见的几种监控如：

• 使用 Kibana 自带的监控
• 使用 Prometheus + Grafana
• 使用 Zabbix

Kibana 自带的监控可以很好的满足单个集群的监控场景，不过集群规模大了之后，经常会出现指标丢失的问题，如果使用单独的监控集群，需要修改每个节点的配置，集群都需要重启，对于已经上了生产的集群，有点不方便，另外多集群监控需要商业授权。

那 Prometheus 呢， 一个 Elasticsearch 集群如果要监控起来，首先需要部署一个 Exporter 来暴露集群指标，然后部署一套Prometheus 来采集 Elasticsearch 指标，采集完了之后再部署一套 Grafana 来进行报表分析，不同的集群要做好切换，简单的事情，搞复杂了，整个监控体系偏重，维护成本高。

Zabbix 和 Prometheus 的场景差不多，就不赘述了。

那么问题来了，有没有一个更加简单方便的多集群监控和管理方案呢，并且要支持不同版本的集群，最好是 v2、v5、v6、v7 以及最新的 v8 都能统统接管，哈哈，没错了，这里给大家介绍一个我们极限实验室团队最近开发出来的一款免费的多集群监控和管理工具-极限数据平台，目前版本 v0.1，新鲜出炉。

废话不多少，咱们直接看图说话：

首先是多集群的纳管，目前从 1.0 到最新的 8.0 统统都可以接进来。

然后就是集群的监控拉，要多简单有多简单，就是一个开关的事情，注册集群的时候，启用即开启监控，目标集群啥都不用动，费那劲干啥。

监控界面如图：

集群概览，总体情况一目了然。

各个节点信息，分门别类。

各个索引级别的信息，挨个查看。

多个集群之间的监控查看一键切换，非常方便。

查看监控的时候，发现不对劲，要操作一下集群，直接调出控制台，如下图：

常用的操作命令，可以保存起来，方便下次使用。

别再保存在记事本里面了，下次又找不到，直接加载执行就好了。

好了，你要是用 Elasticsearch 不知道这个工具，那就 out 了，赶快耍起来吧。

下载地址：

http://release.elasticsearch.cn/console/snapshot/

安装巨简单，简直懒得说，一个二进制可执行文件，一个 yml 配置文件，里面修改 Elasticsearch 地址，结束。

可以在这里查看 介绍和 Demo 演示视频

最后，欢迎关注极限实验室，获取更多 Elasticsearch 免费工具及业界资讯的第一手消息。

接上一篇：Elastic 中文社区运维监控实战 (1) - 序

本文为系列文章第二篇，主要介绍如何把 Elastic 中文社区的网站服务器监控起来，对有同样想了解如何使用 Elastic Stack 来做运维监控的同学，可以作为一个很好的参考和入门资料，学习门槛定义为入门级。

本节内容

在深入到具体的监控指标收集的细节之前，今天先主要介绍一下 Elastic 中文社区的总体方案。这样我们在动手之前会有一个总体的思路和对所用工具有一个大致的了解。

技术选型

工欲善其事必先利其器

前面已经提到我们要对服务器进行各项性能指标的监控以及日志的监控。

看起来很复杂，因为有很多信息需要收集。 好在我们有 Elastic Stack，使用它们来作为我们的监控工具，整个工作就变得简单了，我们结合我们社区监控的这个场景，具体来看的话，需要的工具主要是如下几个：

• 监控数据存储：Elasticsearch

Elasticsearch 是一个分布式的 RESTful 风格的搜索和数据分析引擎。简单易用，用户众多，性能优良，久经考验，支持单节点部署到虚拟机，并可随着业务增长无缝伸缩扩容至上千个节点规模的集群，PB 级别数据也不在话下。

日志数据和指标监控数据都能放，通过集中式存储所有的这些时序型数据，可以快速方便的对这些数据进行分析和关联，实在是排障运维和性能调优的不二选择，你如果还不知道 Elasticsearch，那我只能说你真的是 out 了。

• 日志数据收集：Filebeat

Elastic Beats 家族的一员，Go 语言编写，轻量级，无依赖，这样就可以很方便的完成收集端的部署，所以如果你的场景和我一样， 可以优先使用 Filebeat 代替 Logstash 来收集日志，当然如果有日志的进一步加工，可以让 Filebeat 把数据发送给 Logstash，然后 Logstash 处理完之后再发送给 Elasticsearch。

Filebeat 使用很灵活，可以指定你的日志路径来进行收集，还可以对数据进行预过滤，对于一些常见的监控需求，Filebeat 以模块的方式替你打包好了一切，如：日志路径配置、解析规则、机器学习的任务，甚至还自带 Dashboard，简单几个操作，就可以完成从数据收集到最终可视化分析的所有工作。

• 指标数据收集：Metricbeat

我们这次需要监控的服务器都是一些常规的指标，而 Metricbeat 刚好都支持这些指标的收集，你说这不巧了不是。

Metricbeat 同样也是 Elastic Beats 家族的一员，同样也是开源的。定位是一个轻量级的监控指标采集器，采用 Go 语言编写，同样提供的是一个很小的无依赖的二进制文件包，能够收集服务器（Linux、Windows、Mac）本身的运行指标，如： CPU 使用率、内存、文件系统、磁盘 IO 和网络 IO 统计数据等，还能获取服务器上面的各项服务的运行指标，常见的如： Apache、NGINX、MongoDB、MySQL、PostgreSQL、Prometheus、Redis 等都有直接支持，并且内置了 Elasticsearch 索引和 mapping 设置，以及 Ingest pipeline 设置，还提前预置了不少 Kibana 的 Dashboard，开箱即用、即分析。

• 数据分析展现：Kibana

和 Elasticsearch 工作的最佳拍档，结合 Elasticsearch 的实时分析能力，可以非常方便的对各种数据进行搜索和分析，你可以灵活的自定义的各种图形展现和 Dashboard，不用编写一行代码，即可进行数据分析，除了分析，还整合了 Elastic Stack 的各个产品的管理功能，作为 Elastic Stack 的图形交互终端。

除了上面这些工具，后续我们还可以考虑使用 Auditbeat 来收集服务器的安全行为日志，使用 Heartbeat 来监控各个服务的端口是否正常，我们先完成基本的监控之后，再慢慢将这些加上。

可以看到，我们没有用到 Logstash，是的，这个规模的监控，可以不考虑 Logstash，这样我们可以做到架构简单和足够的轻量级。

上面列的这些软件都是 Elastic 家族的产品，并且都是开源的，所有的源码都在：https://github.com/elastic/ 。

部署方案

在收集数据之前，我们需要明确我们数据放在哪里，毫无疑问，所有的数据都将放在 Elasticsearch 里面，不过 Elasticsearch 不能部署在 Elastic 中文社区的这台服务器上面，一个是资源的限制，另外一个是基于安全的考虑，如果 Elastic 社区的服务器挂了，数据不光收不到，连什么时候挂的都不知道。所以我们需要把 Elasticsearch 服务搭建在别的地方，有多种选择：

• 使用 Elastic Cloud，很方便就能开通，缺点国内访问速度慢，暂时还没开放机器学习的功能。
• 使用阿里云的 Elasticsearch，Elastic 官方合作伙伴，国内唯一包含 X-Pack 的完整功能的 Elasticsearch 云服务，国内访问速度快。
• 自己搭建的 Elasticsearch 集群。

使用阿里云的 Elasticsearch 无疑很方便，不过我家里刚好有一台服务器，型号 HP Gen8，16GB 内存，上面运行了 SmartOS，跑几个 zone 很轻松，每天用来备份社区的数据库，再来起一个 Elasticsearch 服务也很方便，通过路由器将内网 IP 映射出去，让社区服务器将监控数据发送到这台服务器上面来，安全上面，需要保证这台服务器不被黑客攻击，需要做一些必要的访问控制，可以使用 X-Pack 的身份验证，结合 IP 白名单功能，只允许内网和 Elastic 中文社区服务器的 IP 访问。

我们将之命名为：Ops Center，方便后面招呼。

可以看到，Elastic 社区服务器除了启动 Filebeat 和 Metricbeat 之外，不需要额外做什么服务器本身的设置。

这里画一个简单的部署拓扑图，方便理解：

今天主要写到这里，后面将具体介绍它们的安装部署过程。

序

本文为系列文章第一篇，主要介绍如何把 Elastic 中文社区的网站服务器监控起来，对有同样想了解如何使用 Elastic Stack 来做运维监控的同学，可以作为一个很好的参考和入门资料，学习门槛定义为入门级。

首先，我们要监控的网站，也就是大家现在正在访问的 Elastic 官方中文社区，网址：elasticsearch.cn，这个网站基于开源的 WeCenter 搭建，开发语言是 PHP，后端数据库是 MySQL，目前只有一台服务器，由 ConvertLab 友情无偿赞助，大写的赞！再次感谢！

服务器部署环境是 Ubuntu 16.04.2，部署了以下服务及软件：

• Nginx - Http 反向代理，不要介绍了吧
• PHP-FPM - 一个常用的 PHP FastCGI 管理
• Elasticsearch - Elasticsearch 服务，用于社区的垂直搜索服务 Elastic 情报局 服务
• GOPA - 可以说是为社区而写的，一个轻量级的爬虫，用于爬取 Elatic 周边相关相关资料，创建索引存放到 Elasticsearch 里面，提供垂直搜索服务，代码地址
• Grok Debugger - 一个 Java 的 Grok pattern 调试服务，方便大家调试 Grok 日志解析规则，访问地址：grok.elasticsearch.cn

服务器上所有的财产就这些了，一个平淡无奇的网站，基本上所有的东西都能公开访问到，这个网站的目的就是为所有 Elastic 爱好者服务的，供大家交流和沟通的专属平台，所以请各位黑客大侠不要再扫描和攻击啦，画一个简单的拓扑图如下所示：

作为一个合格的网管，除了重启服务器之外，还必须要保证网站的正常运行，所以了解网站的运行情况就变成了一个需要解决的首要问题，我们可以先把任务具体列一下：

• 网站是否正常访问，各项服务有没有挂
• 网站访问情况如何，用户访问速度如何
• 网站访客统计分析，访客相关数据分析
• 服务器的各项指标，详细指标监控分析
• 服务器的各项服务，日志集中分析处理
• 服务器是否很安全，有没有黑客来造访
• 数据是否安全备份，有没有定期测试过

实在编不下去了（话说对的还蛮齐），说人话就是监控起服务器的各项指标和收集服务的日志，然后出几个分析的 Dashboard，监控报警整起来。

我们这次需要用到的工具主要就是 Elastic Stack 啦，Elastic Stack 包括 Elasticsearch、Logstash、Beats 和 Kibana，版本都用最新的 6.x，再结合我们实际的数据和实际的需求，在后面的文章里面，我会具体介绍它们是什么以及如何使用。

今天先写到这里，明天写监控指标的收集，此系列文章暂且定为需要 100 期完成。（开个玩笑，哈哈）。

活动介绍

本期邀请了几位ES大咖做主题分享，并以Demo show和Workshop的形式介绍Elastisearch及其相关组件在搜索、日志分析和监控领域的应用，帮助用户更好的理解Elastisearch及其相关组件，在更多的搜索和分析场景中应用。Workshop环节请务必携带个人电脑参加。

活动安排

时间：2018年1月20日周六 13：30-17：00

地点：北京市海淀区中关村大街46号院-众海加速器（阿里巴巴创新中心）

活动主题

• 13:30—14:00 签到
• 14:00—14:30 主题分享《Elasticsearch在智能运维领域的应用》 Elastic布道师 曾勇
• 14:30—14:40 Q&A
• 14:40—15:10 Demo show《使用X-Pack和Kibana实现Elasticsearch 的监控与报警》 阿里云技术专家 李靖威
• 15:10—15:20 Q&A
• 15:20—15:50 Workshop《基于阿里云Elasticsearch构建网站日志处理系统》 阿里云产品专家 洪阳
• 15:50—16:00 Q&A
• 16:00—16:30 主题分享《ELK在运维工作中应用两三事》 上海安畅运维专家 韩军辉
• 16:30—17:00 现场快闪分享
• 17:00—17:30 现场专家一对一交流

报名通道

活动报名通道：

https://yq.aliyun.com/event/193/join

可提前报名现场快闪分享(5分钟/位），讲讲自己的ELK实践心得，报名链接：

https://survey.aliyun.com/survey/kMXx0zCfB

也可使用钉钉扫描，加入Elasticsearch技术交流群：

嘉宾介绍

曾勇 Elastic布道师

Elastic开发工程师与布道师，在分布式搜索、高性能、高可用架构、自动化运维等方面积累了超过七年的经验。曾勇是Elasticsearch国内首批用户，自2010年起就开始接触Elasticsearch并投入到生产环境中使用，并编写过一系列的中文处理相关的插件。

演讲主题：《Elasticsearch在智能运维领域的应用》

分享Elasticsearch和X-Pack组件在智能运维领域的技术原理和应用实践，如非监督型机器学习在自动的异常检测、高级关联和分类、根源问题诊断、早期故障预测等方面的应用等。

李靖威 阿里云技术专家

全栈程序员，精通前后端，在Web微服务系统架构上有深入研究。3年搜索产品相关经验，现负责阿里云Elasticsearch的产品业务部分的开发。

演讲主题：《使用X-Pack和Kibana实现Elasticsearch 的监控与报警》

以开源 Elasticsearch、阿里云 Elasticsearch和X-Pack的Demo show的形式， 对 Elasticsearch 集群监控和报警的内部原理进行讲解和使用方法演示。

洪阳 阿里云产品专家

阿里云搜索产品经理，从事多年大数据及搜索相关产品工作，在离线数据加工、离线调度系统、在线搜索等场景深入研究，对大数据和搜索相关产品有丰富的经验。

演讲主题：《基于阿里云Elasticsearch构建网站日志处理系统》

基于阿里云的Elasticsearch，离线数仓加工工具，数据同步工具等一些列产品来快速构建一个日志处理系统，从离线数据加工到在线数据搜索和分析展现诠释数据加工在阿里云产品上如何快速展开。

韩军辉 上海安畅运维专家

上海安畅网络运维主管，热衷于开源技术的学习和深入研究，从事多年的ELK运维相关工作，对ELK Stack有深入研究，对ELK相关运维有丰富的经验。

演讲主题：《ELK在运维工作中应用两三事》

基于ELK Stack、sflow技术、sflowtool工具、kafka消息队列等开源技术构建一套流量分析、DDOS告警系统。从流量收集、分析、存储、展现、告警一套流程来诠释ELK在流量分析中的应用。