火花监控：如何每天处理10B请求

的Spark监视架构可处理每日10B +的用户事件
他们说独角兽不存在，但是您当然知道那是不对的 -至少在科技界并非如此。当我们希望了解有关Spark监视的更多信息时，我们的首选是这些独角兽之一-。这篇文章将深入了解他们如何为5.5亿唯一身份每月用户提供服务，以及如何使用Spark提供2000亿每月的内容推荐。以这种规模工作意味着错误很小，只有0.1％的时间会发生，很容易影响成千上万的用户。那么您如何应对这种压力？您需要遵循哪些指标？您需要掌握哪些工具？感谢的研发主管Tal 为我们提供了他的集群的内部视图，以回答这些问题。
新帖子：火花监控：如何处理每天的10B请求 /
— （@） 2015年6月2日

文章插图
中的数字
Spark Stack
从0.7版开始使用Spark，目前在带有40个活动节点的1.2版上运行其Spark集群。一个节点具有256GB RAM和8T SSD，其中用作Spark上的读/写操作的主要数据源，并带有MySQL提示。此设置在的私有数据中心中运行，并由Mesos和进行管理。
为了进行监视，它们遵循的度量标准通过推送-其中包括有关硬件，JVM的数据，以及更具体的代码级数据以及它们遵循的计数器和自定义统计信息。数据在中可视化，最重要的是，和设置了警报系统。要获得的更多动手知识，您可以查看此逐步指南，为您的应用选择正确的体系结构。在日志记录方面，使用ELK堆栈搜索和可视化其日志。
如何收集数据？
除了向Spark的Web UI报告的标准度量标准外，在机器上还具有独立的Sensu代理，用于向报告的硬件监视。对于代码级指标，正在使用的指标库。除此之外，JMX Bean与一起使用和收集，使这些Bean可用于查询。从一开始就在中使用了此Spark监视设置，请记住，没有监视的大型系统会失去其大部分价值。最初，所有监视都基于提取数据，但是现在添加了另一层，以使用管理此数据流。

文章插图
您可以预期的错误类型
Spark 1.2在基础架构方面非常稳定，您可能会遇到的问题主要是因为您做错了事，而不是因为Spark行为不当。让我们看一下生产中可能遇到的事件类型以及它们需要执行哪些操作（这些操作大致分为硬件和应用程序特定的问题）：
1.应用逻辑
Spark是为处理数据而设计的，因此您在应用程序级别上会遇到的最常见问题是关于您拥有的数据的某些假设不正确。并不是说生产中没有错误-而是某种特殊的和特定于应用程序的错误。意思是，一些自定义指标超出了您对其统计模型有一些假设的阈值。如果这些假设不适用–可能意味着出了点问题。此外，您还经常会偶尔看到一些例外情况，例如，尝试加载一些您认为存在但不是由于问题引起的数据。
测量–自定义指标和阈值的重要性
假设您要衡量每秒处理多少个事件，或者应该忽略多少个事件，这可以通过使用指标和来实现。还使用火花累加器报告这些指标。另一个重要的指标来自检查新数据最后一次成功写入的时间。您将获得一个时间戳，如果时间戳超过某个阈值，即未写入任何数据，则表示例如经过一分钟而未写入数据，则可能会出现问题。
根据警报阈值采取行动
当其中某些情况发生并且警报触发时，首先要去的是Spark Web UI 。很多时候它可以很好地指示出什么地方出了问题。您可以看到问题所在，获取执行程序的线程转储，并查看它们的挂起位置。如果某些任务失败，则可以查看引发了哪些异常，并在日志中或使用继续搜索其原因。基本上，它使您可以查看问题发生在哪个节点以及异常消息-这样您便拥有了日志挖掘所需的信息。