火花监控：如何每天处理10B请求( 二 ) _监视

如果您使用的是ELK堆栈，则第二个地方是，然后查看要到达那里的数据类型。
例如，在中，它们具有更新堆栈的MySQL部分的过程。因此，他们在更新过程中遇到了一个问题，即在设置的自定义警报发现问题之前，需要从数据库本身获取有关该问题的指示。由于他们监视的自定义指标遵循上一次成功写入数据库的时间，因此可以实现此目的。它超过了他们设置的阈值，然后他们从Spark Web UI中获得了一个线程转储，这使他们能够找到问题的原因并加以解决。

文章插图
2.硬件问题
在硬件方面，到目前为止，已成功实现了对称部署，并且具有相同数量的Spark和实例。这里要注意的动作是添加更多节点。由于和Spark可以很好地进行扩展。通常这是增加更多CPU能力的问题，这就是他们对其进行监视的原因。
您怎么知道您需要添加一个额外的节点？
的流量正在上升，并且他们定期获取越来越多的数据以进行处理。数据保存在中，然后在一段时间后将其删除，但是当他们注意到磁盘空间利用率的步伐逐渐提高时，他们将添加另一个节点并向其中传递一些数据。当磁盘利用率超过某个阈值（例如50％）时，将触发触发添加新节点的警报。由于整个过程都受到监控-这不足为奇。
在CPU方面，如果由于流量增加或某些逻辑更改而导致更多处理活动而导致它们比平时运行更多的处理–他们看到CPU利用率超过某个阈值，因此添加了另一个Spark节点。
3.缺少的链接–在不进行远程调试的情况下获取变量数据
塔尔认为，塔博拉目前的主要痛点是对错误的更深入分析。他说：“即使在获得堆栈跟踪之后，也无法将我们引导到导致每个错误的真正根本原因和可变状态。这是痛苦的失踪” 。在使用监视的生产环境以解决此问题并查看导致每个错误的变量值之后，Tal说，下一步就是将其安装在其Spark节点上。“目前，只有在意识到出了点问题并尝试重新创建问题之后，我们才能使用远程调试器手动连接JVM，以便我们找出导致问题的状态。这非常麻烦，并且不允许我们查看事件的历史记录并完全了解可能出了什么问题。”
结论
即使您的代码经过了彻底的测试，也不意味着您不会在生产系统中遇到问题，这绝对是监视关键指标以了解如何前进的绝对必要。需要一种全方位的监视策略，以便能够对可能发生的任何事件做出及时的响应，并且不给意外带来任何余地。
我们还要感谢Tal，他分享了他在的Spark基础架构扩展方面的见解和经验。如果您还有其他有关Tal的Spark监控相关问题，请使用下面的评论部分。
【火花监控：如何每天处理10B请求】翻译自: