2017年年中，我们与世界上最大的医疗保健公司中的一家合作，将新的数据应用投入生产。这家公司通过收购其他公司来进行扩张，为了保持对FDA的合规性，他们需要从公司的数十个不同部门实时汇总数据。这个应用程序的消费者并不关心我们如何构建数据管道。他们关心的是如果数据管道出问题了，导致最终用户没有获得他们的数据，这家公司将因为无法满足合规可能遭受巨额罚款。

数据管道主要使用Apache Spark Streaming，Apache Kudu和Apache Impala在CDH平台上进行搭建；但是，有些组件依赖于Bash和Python内置的自动化。基于过去所支持的数据产品，我们知道除了前期科学的规划和开发之外，数据应用程序也需要强大的支持。具体一点就是我们需要确保任何错误都不会被忽视，如果数据管道的任何部分出现问题，都需要能够主动采取行动。Cloudera Manager可以被用于服务器，OS和Hadoop相关服务的告警，但是如果应用程序在CDH平台上或者之外发生故障，我们如何进行告警？

1

Apache Solr

市面上有很多日志聚合和告警工具，Elasticsearch可以提供与Apache Solr相同的开箱即用的日志搜索功能。但在这个案例中，如果采用ES将会带来额外的管理成本，并且这个客户已经在使用Cloudera Search(即CDH之上的Solr)。同时如果使用ES需要另外新搭一个集群从成本开销上也不值得。其他的解决方案我们评估过后也觉得花费较大。例如，其中一个选择是根据数据量来定价的。往往因为这个原因之前大家会花很多时间来调整日志保存的时间颗粒度，从而只保存比较重要的日志。这种调整工作是没有意义的，因为我们认为存储是（或应该）廉价的。

鉴于该应用程序包含PHI和HIPAA数据，我们还需要一个包含基于角色的访问控制（RBAC）的解决方案。而CDH之上的Apache Sentry支持Solr的基于角色的访问控制赋权，这意味着这个客户能够使用现有的Sentry角色来保护其日志数据，以防止未经授权的访问。

简而言之，Cloudera Search(开箱即用的Solr+CDH)似乎已经是最佳选择，同时简化了整体的解决方案技术架构。

2

Pulse

选择Cloudera Search存储日志后，我们还需要以下功能能满足客户的需求：

1.能够按照思维的思路和速度(line and speed of thought)去搜索和钻取日志，以便快速找到问题。能够在一个统一的地方搜索聚合日志会大大缩短调试时间。

2.创建灵活的告警，以便在日志数据到达时实时响应。

3.保护日志免受未经授权的访问。这一点尤其重要，因为应用程序包括PHI和HIPAA数据。

4.日志的保留时间可以配置。

为了满足这些需求，我们开发了Pulse:

一个日志和告警框架。Pulse将日志存储在Solr中，它可以对所有日志数据进行全文搜索。如上所述，Sentry将处理Solr之上的基于角色的访问控制，因此可以轻松控制对私有数据的访问。Pulse本身增加了日志生命周期管理等功能，因此日志只在需要时保留。它包括多种语言的日志追加器，可以轻松地在中心位置索引和搜索日志。Pulse还内置告警功能，因此在出现问题时告警会实时触发。

Pulse可以在你现有的基础架构上运行，而不是基于云的服务。Pulse打包了一个Cloudera Custom Service Descriptor (CSD)，意味着你可以使用Cloudera Manager轻松的安装。除了在CDH集群上实现Pulse的部署和安装，Cloudera Manager还可以监控Pulse应用，提供访问进程日志和监控。

Pulse包含以下4个部分：

1.Log Appenders: Pulse预先打包了一个log4j appender，其他Python和Bash的appender也可用。

2.Log Collector：一个http服务，用于监听来自appender的日志消息，并将它们存储到Solr中。这个Log Collector可以在集群中进行动态扩容以处理大量日志。

3.Alert Engine: 这个服务会定时基于准实时索引到Solr Cloud中的日志数据运行，并可以通过Email或者http hook发出告警。

4.Collection Roller: 处理应用程序日志生命周期和管道。用户可以配置多久为日志创建一次新的索引和将日志保存多长时间。

存储在Pulse中的每条日志记录都包含原始日志消息时间戳，从而可以轻松创建日志数据的时间序列可视化。

下面我们看看组成Pulse的几个重要部分：

2.1Log Appenders

由于我们客户的应用程序是用多种语言编写的，因此我们创建了可以轻松插入现有应用程序的日志追加器。Pulse有Java的日志收集器（使用log4j），Python和Bash。appender会写入Log Collector，它将应用程序与日志存储层分离。

2.2Log Collector

我们不希望每个应用程序管理自己与Solr的连接，因此我们创建了Log Collector，它会列出日志事件，处理身份认证和授权，批处理它们，并将它们写入Solr。由于Log Collector只是一个REST API，因此可以轻松配置并使用它，不管你的应用程序是什么语言。Log Collector还将应用程序与存储分离，使我们在将来可以灵活地编写不同类型的appender，或使用Logstash或Fluentd等工具来消费现有的日志。

2.3Collection Roller

另一件我们不想手动管理事是应用程序日志的生命周期，因此我们创建了Collection Roller，以便在它们达到预先配置的时间后自动循环并删除collections。

下图描述了Collection Roller如何与collection aliases一起使用。write alias（在Pulse内部以_latest为后缀）指向最近创建的集合。 它被Log Collector使用，所以它不需要了解特定的collection。read alias（在Pulse内部以_all为后缀）将始终指向单个应用程序的所有日志集合。它由想要访问所有日志数据的可视化或搜索工具使用。

collection aliases：

每天，新的collection会被创建，然后最老的collection会被删除。下图展示了这个流程。

2.4Alerts Engine and Visualization

创建Alert Engine是为了持续监控来自客户端应用程序的传入日志，以便在出现问题时能够快速做出反应。alert engine使用标准的Lucene查询语法，因此我们可以尽可能灵活的创建告警类型。

例如，这个查询会对最近10分钟的任何错误做出告警：

timestamp:[NOW-10MINUTES TO NOW] AND level: ERROR

如果指标超出50-100的范围，则会发出告警：

timestamp:[NOW-10MINUTES TO NOW] AND metric:[101 TO *] OR metric: [0 TO 49]

为了让日志可视化以便我们的客户可以看到趋势并深入了解错误，我们为每个应用程序创建了一个仪表板。

以下是使用Arcadia Data的仪表板的屏幕截图：

3

总结

我们创建了Pulse来处理Cloudera Search上的日志收集，生命周期和告警。如果你已经部署了CDH，Cloudera Search是一个优秀且功能强大的内置日志分析搜索解决方案。它降低了IT复杂性，因为你不需要考虑如何实现安全因为CDH中有Apache Sentry，同时它非常方便部署，也可以同很多周边的工具做愉快的集成。

Pulse可以让你在现有的技术架构和工具之上管理你的日志。同时Pulse是基于Apache2.0开源许可的，具体参考：

本文作者Tony Foerster是phData的一名工程师。 phData是Cloudera的战略合作伙伴，为Cloudera上的大数据应用程序提供部署和托管服务。

phData：

原文参考：