使用 InfoSphere BigInsights 和 IBM Accelerator for Machine Data Analytics 进行系统日志分析

简介

随着系统变得越来越复杂，如果没有正确的工具，快速评估系统健康状态和故障排除问题就会变得越来越困难。本文将介绍如何使用 InfoSphere BigInsights 和 IBM Accelerator for Machine Data Analytics 来完成以下任务：

• 提高可见性，使得测量系统和应用程序的健康状态变得更容易
• 在出现问题时极大地加速故障排除

我的一个客户已经决定部署 IBM Maximo Enterprise Asset Management (EAM)，这是一个有效的全球系统，可监控和管理全球范围的可见性、部署、性能、可靠性、可用性、使用期限和资产维护。之所以说这是一个大型的复杂系统，是因为解决方案需要跨五个洲部署在大约 80 个工厂中。到目前为止，部署的完成百分比是 20%。

最近，客户在这个系统中经历了多个严重的性能问题，问题一直在变是因为部署正在进行当中。IT 和 IS 运行团队在查找性能问题的根源时遇到了一些困难，而且客户请求可能会加速分析和解决这些问题的根本原因。

我建议采用一个使用了 InfoSphere BigInsights 和 IBM Accelerator for Machine Data Analytics 的概念验证解决方案来分析系统日志，这样做主要有两个目的：

• 帮助客户解决性能问题
• 展示这个 IBM 解决方案的价值

了解日志之后，就会发现日志就是调试、性能分析、根源分析和系统健康状态评估的一个宝库。不过您知道，我和客户都对这个概念验证解决方案所展示的所有发现感到惊奇。我们能够快速确定性能问题的根源，同时制定一个行动计划来解决问题和跟踪项目。

回页首

概念验证解决方案的技术环境

概念验证包含基于 Maximo Enterprise Asset Management 和 InfoSphere BigInsights 的一个应用程序，该应用程序运行了 IBM Accelerator for Machine Data Analytics 应用程序。

基于 Maximo Enterprise Asset Management 的应用程序

客户运行两个应用程序实例：一个面向北美用户，一个面向欧洲用户。这两个实例的所有服务器都位于欧洲。应用程序的每个实例都包含以下组件：

• 1 个 IBM HTTP Server 实例
• 6 个 IBM WebSphere® Application Server 实例，运行用户界面、计划任务和按需报告
• 1 个 IBM WebSphere Application Server 实例，运行预定报告、计划任务，以及用于集成应用程序与企业资源规划 (Enterprise Resource Planning, ERP) 解决方案的 Maximo 集成框架。
• 1 个 Oracle 数据库

InfoSphere BigInsights 环境

InfoSphere BigInsights 安装在一个独立计算机上（一台运行在 IBM ThinkPad W530 之上的虚拟计算机），而且应用程序的日志文件是手动转移到这台虚拟计算机的。

在这个 InfoSphere BigInsights 环境中，我们对应用程序的每个实例都导入了以下日志：

• IBM HTTP Server 访问日志（一种半结构化文本文件）。

• 所有 WebSphere Application Server 实例的 SystemOut 和 SystemErr 日志，包括 154 个非结构化文本文件。当达到 10MB 缓冲时，就会关闭并重新命名当前日志文件。然后创建一个新的日志文件。在 WebSphere 配置中，要旋转（rotate）的日志文件数量被设置为 10。在本例中，我们拥有每台应用程序服务器的 22 份日志文件：

  • SystemOut 日志文件：一个当前日志文件加上 10 个重命名文件
  • SystemErr 日志文件：一个当前日志文件加上 10 个重命名文件

  这些日志在到达 10MB 时开始旋转。

• Oracle 数据库警告日志（一种半结构化 XML 文件）。

总计有 312 个日志文件。很容易就能想到的噩梦场景就是需要手动分析这 312 份日志文件，没有恰当的工具。

InfoSphere BigInsights MDA 应用程序

我们运行以下 InfoSphere BigInsights MDA 应用程序：

• 一个 Distributed File Copy 应用程序，用于将日志导入 Hadoop 文件系统。
• 一个 Extract 应用程序，使用文本分析从提取到 InfoSphere BigInsights 中的成批日志文件中提取信息。
• 一个 Index 应用程序，为所有日志文件的记录建立索引。需要创建这个索引，以便使用多面的浏览界面根据多重条件快速查找日志条目并加速故障排除。
• 由于虚拟机的物理资源（主要是存储）是有限的，所以我们没有运行以下 InfoSphere BigInsights MDA 应用程序：
  • Frequent Sequence Analysis 应用程序，检查在出现错误条件前哪些事件模式最常发生
  • Significance Analysis 应用程序，检查哪些特定事件是错误条件的最可能原因
• 生成特定报告和提要仪表板的 BigSheets 特性。

下一节将介绍概念验证解决方案如何增加系统健康状态的可见性，并加速故障排除。其中包括 IBM BigInsights 和 IBM Accelerator for Machine Data Analytics 为这个特殊案例提供的一些输出示例。

回页首

通过这个解决方案提高可见性并加快故障排除

这个解决方案通过提供以下优势使得查看互连系统内部情况变得更容易，而且可以更快速地故障排除问题：

• 全方位视图
• 多面浏览
• 使用仪表板进行日志分析
• 测量 Maximo EAM 错误消息的数量
• 分析 Maximo BMXAA6720W 警告消息
• 测量 Oracle 错误消息的数量

全方位视图

这个解决方案可以获得不同组件记录的所有事件的全方位视图。来自 IBM HTTP Server、WebSphere Application Server 和 Oracle 数据库服务器的日志经过转换、聚合和索引后可支持跨不同的日志文件（在本例中，该 Maximo EAM 应用程序的每个实例有 156 个日志文件）进行高级搜索。这种增强的视图极大地促进了根本原因的故障排除和检测。

图 1. 全方位视图

多面浏览

多面浏览界面更易于根据多个标准快速查找日志条目。图 2 显示了通过使用多个搜索条件从一个实例的 156 个日志文件中查找日志条目会非常简单。

图 2. 使用多面浏览查找日志条目

使用 InfoSphere BigInsights 仪表板进行 HTTP 日志分析

InfoSphere BigInsights 仪表板使得发布并共享分析的输出变得很容易。它促进了不同 IT 和 IS 团队（开发团队、IT 运营团队等）之间的通信与协作。

图 3 显示了一个仪表板，我们已经在其中发布了 HTTP 访问日志的分析结果，包括：

• HTTP 状态代码 ，适用于 HTTP 服务器接收到的所有 HTTP 请求。状态代码使您能够检查：
  • HTTP 服务器记录的错误数量（HTTP 状态代码 > 400）。这个数量有助于测量应用程序的健康状态。
  • 浏览器缓存效率：304 HTTP 状态代码的比率。（比率是包括 304 状态代码的 HTTP 请求数量与 HTTP 请求总数的比值）。
• 对用户来说， 造成 HTTP 状态代码 404 错误的 URL 路径 通常会导致性能降低，有时甚至是不可见。

  改进服务器性能的 建议 就是删除所有 404 错误。

• 每个 IP 地址的 HTTP 请求数量 允许您查看比其他 IP 地址发送的 HTTP 请求多得多的所有可疑 IP 地址。
• 用于所有 HTTP 请求的 HTTP 协议版本 。

  图 3. 发布 HTTP 访问日志分析结果的仪表板

  

通过查看这个仪表板，可以根据一些性能问题的初步总结提供一些建议：

• 图 3 最左边的饼状图 ：请注意，与 NA 实例的 47% 相比，用于 EU 实例的 HTML 对象只有 7% 是从用户代理缓存区（HTTP 状态代码 304）中获取的。
• 图 3 中饼状图最右边的柱状图 ：一些 IP 地址显示了可疑的行为。例如，一些 IP 地址发送了比应用程序的标准用户多得多的 HTTP 请求。

  建议：通过进一步调查，我们发现这些 IP 地址被分配到运行脚本来监控应用程序响应时间的计算机。一些高级用户试着测量响应时间，以提供这些响应时间的证据，但他们并未意识到这些脚本降低了系统的整体性能（尤其是服务器资源利用率和 WAN 带宽利用率）。此外，这些脚本扭曲了从用户代理缓存区（HTTP 状态代码 304）提取的有关 HTML 对象的信息。对于其中的一些脚本，HTML 对象始终从用户代理缓存区提取。我们建议终止这些脚本。

• 图 3 中间偏右的表格 ：在欧洲，一些客户端机器使用的是 HTTP 协议的 V1.0 版而不是 V1.1 版。在性能方面，使用 HTTP 1.0 通常会产生糟糕的体验，因为 HTTP 1.0 并不支持多个请求使用单个连接。

  建议：通过进一步的调查，我们发现 HTTP 1.0 请求由遗留终端用户发送至运行 Microsoft Internet Explorer V6 的废弃的 MS Windows® XP 工作站（参见参考资料，获取 Microsoft Support 的链接）。因此，我们提供的建议是应用 Microsoft 提供的解决方案，或者在应用程序身份验证页面上实现一个代码段，以测试所使用的浏览器。如果检测到 Microsoft Internet Explorer V6，那么我们建议询问用户是否需要切换到另一个浏览器，比如 Mozilla Firefox V3.5。

• 图 3 最右边的表格 ：HTTP 状态代码 404 起始位置的所有 URL 路径都显示。

  建议：我们建议在应用程序上进行必要的更改，以避免所有这些 404 错误。

IBM Maximo 软件记录的错误消息

帮助评估应用程序健康状态的另一个指标是 WebSphere Application Server SystemOut 日志文件中记录的 Maximo 错误消息数量。

附带了 IBM Accelerator for Machine Data Analytics 的 WebSphere Application Server 日志提取程序并不支持获得有关这些 Maximo 错误消息的及时信息。包含这些错误消息的记录格式并不总是相同。

要获取这一信息，我们有两个选择：

• 开发我们自己的提取程序
• 使用 InfoSphere BigInsights 的 BigSheets 特性

我们选择使用 BigSheets 特性。只需使用标准的 BigSheets 基本功能（MID、SLICEITEM、PIVOT、FILTER 等），就可以在生成有关记录的 Maximo 错误消息数量的报告方面少花费半小时。（参见图 4 和图 5。）

一些 Maximo 错误消息频繁出现在日志中，我们认为要么是出现了应用程序级的技术问题，要么是 Maximo 软件中存在缺陷。我们建议打开 PMR，请求进行更深入的根源分析，以便解决基础的问题。

图 4. EU 实例

图 5. NA 实例

分析 Maximo BMWAA6720W 消息

Maximo BMXAA6720W 警告消息表示长期运行了查询执行并提供有用的系统性能信息。通过 BigInsights，我们可以轻松提取下列样例的日志记录中用粗体突出显示的信息。

WebSphere SystemOut 日志记录包含 Maximo BMXAA6720W 警告消息，如下所示：

[6/25/13 8:28:32:140 CEST] 000000ec SystemOut     O 25 Jun 2013 08:28:32:140 [WARN] BMXAA6720W - USER = (UID00195) SPID = (2082) app (WOTRACK) object (WORKORDER) :  select * from workorder  where (workorderid = 4568)  (execution took 1317 milliseconds)

至于 Maximo 错误消息，我们决定使用 InfoSphere BigInsights 的 BigSheets 特性来提取上述样例日志记录中用粗体突出显示的字段。然后，我们使用 SQL 查询生成了突出显示问题的报告（参见图 6）。

数据库专家通过进一步的深入分析，揭示了数据库服务器级别上的多个问题：

• 在数据库服务器上缺乏物理内存
• 数据模型设计问题
• 包含一些指标的问题
• 利用该软件的较新版本修复的 Oracle 数据库软件缺陷

图 6. 使用 SQL 查询突出显示问题的报告

回页首

Oracle 警告日志中记录的 Oracle 错误消息

在处理 Maximo 错误消息时，我们使用 BigSheets 特性来生成 Oracle 警告日志中记录的有关 Oracle 错误消息数量的报告（参见图 7）。这是帮助评估系统健康状态的另一个指标。

图 7. Oracle 警告日志

回页首

结束语

同时使用 InfoSphere BigInsights 和 IBM Accelerator for Machine Data Analytics 有助于调试性能问题，尤其是在使用这个 Maximo EAM 应用程序的情况下。但是，也可以将这个解决方案应用到其他情况和系统中。我们现在与客户共同部署了 BigInsights 解决方案，以便在生产环境中运行它。

我们将试用三个业务关键型应用程序，如果试用成功，则会为该客户的 20 个最关键应用程序部署该解决方案。对于试用应用程序和每一个应用程序，将会包含 3 个用例：

• 发布提供系统健康状态的仪表板。仪表板将会：
  • 每天自动出现
  • 跨操作团队进行共享来促进协作
  • 当观察到偏差时，支持客户积极采取行动
• 在将主要应用程序验证迁移到生产环境之前，免除主要应用程序验证。这包括分析 QA 环境的日志来促进制定是否迁移到生产环境的决策。
• 使用概念验证解决方案的高级特性进行问题故障排除和解决，从而加快根源分析和问题解决。

简而言之，这个概念验证解决方案可应用于多个上下文中，逐渐增加互连系统健康状态的可见性并加速故障排除和根源分析。