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

look_w

5.Troubleshooting 的方法 在 Elastic Stack 和 EGO 集成过程中，在某些情况下，会出现 Service 启动失败或者 Service 进入 TENTATIVE 的状态，或者 Service 启动正常，但是 Elasticsearch 无数据写入的情况等。如果是 Service 进入 TENTATIVE 状态，而不变成 STARTED 状态，一般是由于启动过程某个检测条件未满足，或者启动出错。Elasticsearch 无数据的情况就相对来说比较复杂，原因可能会出现在 Elastic Stack 各个环节和数据链。对于此类问题，最行之有效的 Troubleshooting 办法是查看 Elastic Stack 的日志，集成后的日志在此目录下：                $EGO_TOP/integration/elk/log ，此文件下的 LOG 包括了 Elastic Stack 本身打印出的日志和                 Elastic 在 EGO 中的 services 打印出的日志，如下所示：
# ls $EGO_TOP/integration/elk/log
elasticsearch     es-out.log.cnv31m1    indexer-out.log.cnv31m1                  shipper-err.log.cnv31m1   es-err.log.cnv31m1    indexer-err.log.cnv31m1    install.log     shipper-out.log.cnv31m1
其次，可以查看 EGOSC 的 log 来定位 Service 不能启动成功的原因，此 LOG 一般在 EGOSC 的安装目录下。如果 LOG 还不能解决问题，可以在 elk.conf 配置 DEBUG=1 来启动 DEBUG 模式，进一步的锁定问题。最后，可以尝试暂时脱离 EGO，来手动在 Debug 模式下，启动 Elastic Stac k锁定问题。
四、Elastic Stack 对 Platform EGO 的监控 我们知道，Elastic Stack 的主要功能之一是监控，当然也可能监控 EGO 的运行情况、资源分配情况等。此章节中，我们仅展示部分监控功能。Elastic Stack 收集的大致流程为 Filebeat 从 EGO 日志中读取数据（部分数据是从数据库中直接加载得到），发送给 Logstash，经过Logstash Filter GROK 插件的格式化处理和优化之后，再发送给 Elasticsearch 存储和检索，由 Kibana 展示出来。图3 为节点是否开机的状态和 EGO 是否在节点上运行正常，其中 Monitoring Agent 指的是 EGO Client 的状态。
图3  Elastic                    Stack监控集群节点 图4 为 EGO 资源分配的情况，EGO 中资源以 Slot 为单位的，从下图中我们可以看出 Slot 的使用情况和为每个 Consumer 的分配的 CPU 情况。从此图中，我们可以一目了然的看出，有多少剩余的资源。
图4                      Elastic Stack 监控 EGO 资源使用情况五、结束语 Elastic Stack 在近两年迅速崛起，在实时的日志处理领域发挥着主要的作用，并且 Elastic Stack 很容易上手，处理方式灵活，性能稳定，前端采用的技术比较先进。在 Beats 端和 Logstash 端，只需要进行配置， Kibana 端甚至只需要用鼠标点击，即可画出绚丽的图形。Elastic Stack 的社区也日渐活跃，参与使用和研究的企业或个人成指数型增长。Platform EGO 是所有 IBM Platform 产品资源管理和配置的工具，应用比较广泛。本文以 Elastic Stack 和 Platform EGO 的集成，展示了如何管理和更好的使用 Elastic 产品。当然了，Elastic Stack 不是万能的，可能还需要我们在集成的过程中，添加一些定制化的功能，例如辅助收集日志和数据的脚本等，才能完全满足需求。在 Elastic Stack 集成的过程中，也相继解决了许多和 IBM Java 和 POWER 平台的集成问题。