Elastic Stack 和 IBM Platform EGO 的集成与实战（3）

look_w

三、Elastic Stack 与 Platform EGO 的集成实战1.Elastic stack                服务的注册 所谓服务注册，是指将预先定义好的 service 的 XML 配置文件，放到指定的文件夹下，当 EGOSC 重启的时候，自动读取。这个文件夹一般为 $EGO_TOP/eservice/esc/conf/services，其中 $EGO_TOP 为环境变量，指示 EGO 的安装目录。在此集成实例中，为 Elastic Stack 定义了四个文件，分别对应的是 Elasticsearch,Kibana,Logstash 和 Filebeat。其中elk_indexer.xml 对应于 Logstash，elk_shipper.xml 对应于 filebeat。如下所示：

1 2 3 4 5

# ls $EGO_TOP/eservice/esc/conf/services elk_elasticsearch.xml elk_kibana.xml elk_indexer.xml elk_shipper.xml

如果需要安装完毕或者重启 EGOSC 之后，自动启动这些 service，就需要在 service 中配置启动类型为AUTOMATIC ，                如下所示。
<sc:StartType>AUTOMATIC</sc:StartType>
2.依赖的注入与配置 所谓依赖是指，这些 Service 启动和正常运行期间，需要依赖于其他 Service，如果被依赖的 Service 停止工作，或者出现异常，就需要同样停掉依赖此 Service 的所有服务。
举例来说，在此集成模型中，如果 Elasticsearch 出了问题，那么 Logstash 就不能往 Elasticsearch 中写数据，Logstash 也就没有存活的必要了，同理，Logstash 如果因为某种原因停止了，Filebeat 发送的数据，Logstash 就收不到了，Filebeat 就没有继续运行的必要了。所以，Filebeat 依赖 Logstash, Logstash 又依赖 Elasticsearch。我们就需要在 Service 的定义文件中，配置这种关系。
下面是在 elk_indexer.xml 中对 Elasticsearch 依赖关系的定义：
<scependency type="conditional" satisfy="STARTED"                keep="TENTATIVE,STARTED"                autoStart="TRUE">elk-elasticsearch</scependency>
在此，我们对此定义做一简单说明，“satisfy”参数指的是启动 Logstash 时候，Elasticsearch 服务的状态，也就是说，只有在 Elasticsearch 服务的状态为 STARTED 的时候，Logstash 才开始启动。“keep”参数是 Logstash 保持运行所必需的 Elasticsearch 服务的状态，当 Elasticsearch 服务状态为 TENTATIVEH 或者 STARTED 的时候，Logstash 保持正常运行，否则，Logstash 将被暂停。当 Elasticsearch 状态恢复之后，Logstash 服务便会自动恢复运行。
3.服务的监控和 Job                Monitor 在上面的依赖的配置里，我们多次提到了服务的状态，那么如何判断这个服务运行正常与否呢？这个工作就需要 Job Monitor 来完成，每个服务都可以配置 Job Monitor 功能。需要说明的是，EGO Job Monitor 自由度很大，具体监控什么，如何监控，就需要自己通过脚本来完成。比如监控端口号是否正常，在 Elasticsearch Cluster 的健康状况、Logstash 的处理速率等，来判断这个 Service 是否正常运行。如果发现 Service 已经不满足于某个条件，Job Monitor 变修改 Service 的状态到 TENTATIVE，或者 ERROR，此时，依赖与这个 Service 的其他服务也相继改变。
同样，Job Monitor 也有启动检测的功能，比如说，已经检测到某个服务已经完全启动就绪，能接受客户端请求的时候，便将这个 Service 的状态由 TENTATIVE 变为 STARTED。依赖与此服务的 Service 才会相继启动。
在此集成实例中，我们对每个 service 都配置了 Job Monitor 功能。Elasticsearch 的 Job Monitor 中检测 Elasticsearch 的进程、端口、Cluster 的状态等。Logstash 的 Job Monitor 监控 Elasticseach Service 状态和自身的端口等。
4.日志 Rotate                机制 我们发现，由于大数据平台的日志量比较大的情况下，Elastic Stack 负荷量很大，在这种情况下，如果一旦出错， Elastic Stack 自身的日志量也比较大，有可能在几分钟之内，便会产生上百 MB 的日志，这对于一般的大数据平台来说，持续性产生的日志，会对磁盘存储造成一定的影响。在这种情况下，就需要日志 Rotate 机制。所谓日志 Rotate 机制，通过轮转的方式来删除时间比较久的日志，仅仅保留最近一段时间之内（可配置）的日志和数据。
在此集成实例中，此功能的实现，主要借助了Linux自带的 logrotate 工具完成的。用户只需要配置 logrotate 的 conf 文件即可。每 10M 做一个轮换，最多保留 5 个日志文件。并且重定向了 Elasticsearch 的日志。